团队使用Scrum 已经有半年多了, 基本形成了一周一个迭代周期的正常开发节奏，团队的开发状态也进入了正规；但是在Scrum的迭代中，时常会出现一些比较大项目需求，这种大项目工期长，时常会跨团队/部门配合，因此在迭代中会出现很多问题，难以管理。

这篇文章是我们团队在周会上专门讨论大项目管理时的总结。

1. Scrum迭代管理

在Scrum迭代中有是哪个重要的节点：

• Sprint需求会

  在需求会上，主要是产品经理（PO）向技术团队阐述产品功能，在这个过程中开发人员会参与到产品细节的讨论中；这个讨论过程不仅能让开发更深入的理解产品的意义和细节，同时也可以提出自己对产品不同的见解，也可以直接挑战PO。最终会完成Story评审，对Stroy进行估点（评定Point），对各个Story确定优先级。需求会一般持续一个半小时以内。

• Sprint计划会

  计划会（planning）上会review一下上个迭代遗留下来的story和task，评估剩余的时间；之后会评估在需求会上评审通过的story，划分task，给出实现所需时间。之后每个人会主动领取task。目前我们每个迭代按照每天6小时计算开发时间，剩余的时间作为运营时间。

• 产品交付

  对应系统功能就是功能上线，最终交付给PO。

2. 大项目管理

大项目具有以下特点：

• 功能复杂，需要有技术设计来厘清
• 开发量大，项目工期长；
• Story难以拆小，或者拆小之后的Story没有意义；
• 可能跨团队/部门的合作。

针对需要跨团队/部门合作的大项目，因为其他团队/部门的开发并不一定使用Scrum的迭代管理方式，即使他们使用相同的Scrum迭代周期，所以针对这种大项目更适合是使用瀑布式管理方式。大项目管理主要做好一下几个关键点，在实施过程中也就不会出现大的问题：

• 需求评审

  大项目说明需求本身就很大，因此在需求评审阶段把控好需求的方向和细节，包括需求内容和背景、确定干系方、初步技术可行性聘雇和初步的分线评估。

• 技术设计

• 分工排期

  这个分工排期需要确定各个干系方的分工，每个干系方不同阶段的时间节点，包括PO需要提供到的物料（交互、视觉设计等），必要的情况下，需要干系方定期召开例会以同步进度和问题。

• 上线方案和时间点

  大项目时常涉及到的较多的项目修改，需要做好上线方案和回滚方案的评审。上线方案需要确定需要上线的项目、配置、数据表（库）及其他运维项，这个上线方案需要分步骤验证，避免出现上线步骤接口或功能的兼容性问题；回滚方案是针对上线过程中一单某个步骤出现问题该如何回滚，也需要针对回滚方案分步骤验证。

3. Scrum中的大项目管理

大项目放在Scrum中管理，有种把大象放到冰箱里，不过这次的步骤却不是打开冰箱把大象放进去。不过大项目可以借助Scrum中迭代的方式进行管理。

• 需求评审放在Scrum迭代需求评审会上进行
• Scrum计划会上划分task，如技术评审task，与其他团队/部门沟通task，开发task，测试task和上线task等。
• 在每个迭代计划会上，同样会review大项目的task，评估剩余时间，只不过大项目与其他团队/部门是有时间节点的，如果剩余时间超过预期，就需要评估风险并适度增加人力。