软件开发中的理想与现实（四）——兴致勃勃做计划

今天实在是很漫长，到重构练习完成，我们还有时间做下一个活动的演练： 计划游戏。
作为一个最不专业的解释，计划游戏就是在现场客户、开发人员、相关负责人员的参与之下，分解、分配和估计任务的活动。之所以可以称之为游戏，因为这个活动充满了游戏性：由客户编制一些“故事卡片”，并初步标明一些优先级，用于描述自己的需求，然后开发人员估计它们；客户可以选择自己最想要实现的“故事”是哪些，并和开发人员一起商定能够实现的时间，开发人员通过不断的优化对故事的任务分解和协调每个人具体的任务来尽可能满足客户的要求。每个开发人员都有选择任务的权利，实际上，任务在最开始都应该是自主选择的，而不是强制指定的，就算选择任务的人并不是“最适合”的人。不过为了满足客户的一些急切的愿望，引导者应该能够兼顾兴趣和效率之间的关系。
根据比较官方的说法，计划是持续的、循序渐进的，每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。不过实际操作中，到底要计划到什么程度倒可以由引导者来指定，例如，发现任务提前快完成了，当然应该就可以准备下一步要做的事情了。
在演练计划游戏中，我是作为现场客户存在的，我今天说的故事比较简单，就是我们项目中的一些前期分析的工作（嗯，其实准确来说，我不是在说故事，而是直接开始指定任务并要求分解了，但作为演练应该还是够了）。大家分解这个任务，并把小的任务写在白板上，每个人每选一个任务就对它进行一次估计，一会就分解完成。XP里面推荐的估计方法是通过“点数”来算的，但这个似乎比较难操作，所以我们是通过“ 理想工作小时数”来估计的。每个人每天有4个小时的理想小时，然后想想自己如果专心致志的做这个任务需要多少个小时。这个演练要持续一天，所以每个人能够做的就只有4个小时的事情，当选完4个小时之后也就是用完自己所有可用的时间，这样也就不能再多选了。另外，还需要为任务分级，这是从开发的角度上进行的估计，分为任务的 架构意义、 风险和 重要性三项，每项有1到3的权值，3为最高。当所有任务分解完毕，而大家手上还有空闲时间，那么我们就可以请求客户增加任务（嗯，这种情况比较少）；当所有时间分配完毕，而还有任务没人认领，那么我们就要考虑重新调整任务的认领人来获得更多空余时间，或需要和客户交流适当把一些低优先级的任务删减掉，保证总时间点在忍受范围内。
由于这只是一个演练，所以事情很简单也很顺利，我们恰好分解完所有任务，然后兴致勃勃准备投入到明天的工作中去。（噢，原来今天结束了啊！ ）

---

参考文献：
[1] Craig Larman，敏捷迭代开发：管理者指南，中国电力出版社，2004
[2] Alistair Cockburn，敏捷软件开发，人民邮电出版社，2003.11