在大型项目中, 只为单个迭代做计划, 很可能会丢失长远意义(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)紧抓不放, 那么已经回归到了瀑布模型.
- 这种情形下的项目组, 请自觉使用瀑布模型.