从瀑布到敏捷(2): Planning

在大型项目中, 只为单个迭代做计划, 很可能会丢失长远意义(long-term implication).
瀑布模型使用大型的预测计划(upfront plan) 来预测整个项目的活动.
敏捷会遵从[避免引入大规模的预先设计(avoid big design upfront)] 的原则, 将计划进行分层.

1. 产品视角(Product Vision)

• Product owner 解释当项目完成时产品的形态.
• 以[期望的产品特性], [目标用户]� 以及[与之前版本或者竞品的关键差异] 的角度, 来做计划.

2. 产品路线图(Product Roadmap)

• 对发布的图形化展示.
  • 包括:日期, 内容, 目标.
• 需要构建产品的backlog(待办事项).
  • 有了简要的产品需求列表, 交付团队可以做估算(estimate).
  • 敏捷项目的成败取决于最高优先级的功能(feature) 的尽早发布.
  • 所以, backlog 的列表, 应该按照业务来排出优先级.
• 除了产品功能, 还应该列出对产品成败有重要影响的非功能性的技术特性(technology feature).
  • 例如, 产品采用何种框架, 如何部署, 如何进行升级等等. 这些都会影响客户体验.

3. 发布计划(Release Plan)

• 对于小型项目, 产品路线图已经能够提供足够的项目纵览.
  • 由于不需要进行多个项目组之间的同步, 所以不需要该阶段.
• 但是对于大型项目, 需要在该阶段进行分组和将任务(release)派发到各个组的活动.
• 发布的特性:
• 分布由日期, 主题, 计划的功能集合构成.
• 由于开发进度的不确定性, 推荐使用具有优先级顺序的backlkog 作为计划事件的基础.
• 所有的项目组都应该以相同的节奏(rhythm) 来进行提交交付.
• 所有的项目组都会有固定的发布日期.
• 发布和迭代的差异:
  • 发布是定义在系统和程序级别上的.
  • 迭代是定义在功能(feature) 级别上的.
  • 一个发布通常含有若干个迭代, 迭代中交付的功能由优先级,速率(开发的效率)和估算决定.
• 该阶段应该是所有的项目组成员都参加的.
• 具体的动作: 将功能从产品backlog列表中�派发到各个项目组的发布中.

4. 迭代计划(Iteration Plan)

• 项目组将拿到的功能分解为tasks. 总体上就是分解为细节来增加精确性.
  • 单个项目组的生产能力(capacity) 会变得更加清晰.
• 该阶段的产出物与发布计划节点相同, 只是是站在单个迭代的角度上的计划.
• 将所有项目组的计划汇总, 可以决定开发阶段的依赖关系. 这在发布计划阶段是不可见的.

5. 每日计划(Daily Plan)

• 具体的做法就是每日站会.
• 项目组的成员会回顾昨日完成的功能, 今天计划完成的功能, 以及最重要的抛出遇到的block.

6. 敏捷的一些思考

• 在大型项目中, 也应该使用刚刚好够用(barely sufficient)原则.
• 添加的(计划)层次, 是为了让正确的人群关注各自级别上的细节(而对另外的人群隔离细节).
• 可接受的误差(acceptably inaccurate)
  • 如果项目组的成员对工作的细节和计划(work specification and plan)紧抓不放, 那么已经回归到了瀑布模型.
  • 这种情形下的项目组, 请自觉使用瀑布模型.