Scrum 中的大项目管理

团队使用 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,评估剩余时间,只不过大项目与其他团队/部门是有时间节点的,如果剩余时间超过预期,就需要评估风险并适度增加人力。

打赏支持我写出更多好文章,谢谢!

打赏作者

打赏支持我写出更多好文章,谢谢!

任选一种支付方式

1 3 收藏 评论

关于作者:brucefeng

陈景广 自2013.05工作于大众点评至今 个人主页 · 我的文章 · 13 ·   

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部