发布计划

发布计划会议的目的是对整个项目进行规划,制订项目的发布计划。发布计划稍后会用于为每个迭代创建迭代计划。

技术人员做技术决策,业务人员做业务决策,这至关重要。发布计划提供了一套规则,允许参与项目的每个人做出自己的决策。基于这套规则,项目各方可以协商出合理的、大家都能认可的时间排期。

发布计划会议最关键的议程是,让开发人员以理想开发时间来估算用户故事。所谓“理想开发时间”,是指在没有干扰、没有依赖、没有额外工作的情况下,完成一个用户故事(包括对应的自动化测试)所花费的时间。客户则决定哪个用户故事最重要、具有最高的优先级。

用户故事会被打印或者写到卡片上。开发人员和客户一起围绕着大桌子移动卡片,为第一次(或下一次)发布选定一组待实现的卡片。尽早交付可用、可测试、且具有良好商业价值的系统,才是人们所期望的。

发布计划可以按时间来规划,也可以按范围来规划。可以依据项目速率来判断在指定日期前可完成多少用户故事(这就是“按时间规划”),也可以估算一组用户故事需要多久才能完成(“按范围规划”)。

  • 按时间进行规划时,将迭代数乘以项目速率,可判断能够完成多少用户故事。(用户故事总数 = 迭代数✖️项目速率
  • 按范围进行规划时,将用户故事的总预估理想开发时间除以项目速率,即可确定完成发布需要多少次迭代。(迭代数 = 用户故事总数➗项目速率

在每个迭代开始之前再做迭代计划,不必过早做详细的迭代计划。发布计划会议也被称作计划游戏,可在Portland Pattern Repository找到相关的规则。

如果管理人员对发布计划感到不满,最容易犯的错误就是改变用户故事的估算。绝不应该这么做。估算应是每位参与者所认可的,并且应该在后续的迭代计划会议中坚持相同的原则。低估用户故事的工作量,会造成一系列的问题。只能通过协商和让步,最终得到一个可接受的发布计划,让开发人员、客户、管理人员都能满意。

发布计划的基本理念是,项目可以通过3个变量来限定:范围、资源、时间。范围即需要完成多少内容;资源即有多少可用的人;时间即何时发布或完成项目。没有人能够控制所有3个变量。改变一个变量将不可避免的导致其他变量的变化。

值得注意的是,质量不是一个可以调节的变量。和很多人的直觉不同,降低质量并不能提高开发速度,反而会因为大量的错误和返工而降低速度,从而对3个项目变量(范围、资源、时间)都产生负面的影响。因此,开发团队应该尽力交付能力范围内最高质量的软件,包括采用测试先行方法、随时重构代码、实施持续集成等。