时间盒迭代删减任务会导致完不成原定开发计划？

(c) 张恂  www.zhangxun.com

 

本文的最新版在《敏捷 FAQ》： http://www.zhangxun.com/entry.aspx?sname=AgileFAQ

问：

在每一次固定长度的迭代中，开发团队的可用工作时间总量是有限的，而完成每一个需求任务都必然要消耗一定的人力和时间。所以，可能存在这种情况，事先制定的迭代计划中所安排的需求和任务，无法在固定的时间内完成，也就是说，剩余的工作量（计划耗时）超出了团队预测可用的工作时间。

此时，时间盒迭代允许删减需求开发任务，通过任务调度，把预测超出可用时间的开发任务和需求项放入下一次或以后的迭代中。

那么这样做，是否会导致既定的已向客户承诺的整体需求开发计划（如发布计划）最终无法全部完成？

 

答：

简答

的确，存在这种可能性，由于在迭代开发中不断删减或推迟既定任务，导致既定的整体开发计划无法完成。如果每次迭代都有任务不能及时完成，需要放入下一次迭代（发生了挤出效应），那么累积的结果很有可能是最终无法完成事先计划的所有需求任务。

不过，还存在另一种可能性，尽管在某次或某些迭代中，我们删减、推迟了某些需求或任务，但最终还是赶上了进度，所有计划的需求仍然可以在 deadline 之前完成（未发生挤出效应）。

我想，对于任何软件开发项目，这两种可能性都不能排除。究竟哪一种可能性更大，项目最终能不能按计划完成，其实不到最后一刻（或最后两周），我们并不能确切的（100%）知道。因为，用科学的术语说，软件开发本质上是一种探索性的、非线性的、不确定过程。

所以，简单的回答是，时间盒迭代删减需求任务，不但不一定会导致既定的开发计划和所有客户需求最终无法完成，相反，与加班、加人、降低质量相比，它却有可能是一种相对合理的、最佳有效解决办法之一。

正确的因果

导致进度滞后的原因有 n 多种，有一些是由不合理的意外（人为失误）造成的，而有一些是由于合理的意外（人为无法控制）造成的，比方主力开发人员意外生病/住院等等 ...

这里我们首先应该明确一个因果问题：

究竟是因为我们在迭代中删减或推迟了任务的完成，导致整体的发布计划最终无法完成，还是因为开发进度滞后的现实情况已经发生，导致我们不得不选择删减或推迟任务？

我想，我们在这里讨论的是后者。也就是说，如果在实际开发中，已经发生了进度滞后的情况，我们该怎么办？

此时，删减或推迟一些迭代任务是可选项。那么，它会不会导致最终项目计划无法按期完成？前面提到，答案只有两个，yes or no。如果不能完成，我们也不应该感到遗憾，因为进度滞后（落后于计划）的情况在我们采取行动之前已经发生了，我们不过是做出努力，尽力弥补。

而如果一切工作都能按照我们预先制定的进度计划完成，自然也不需要我们删减需求或任务。

这是一种正确的因果逻辑。

那么，在进度已经滞后的情况下，如果采取加班、加人、降低质量等措施，是否也会最终导致计划完不成？情况可能各有不同，但处于开发的进程中，有谁能够担保，不删减需求任务，通过加班、加人就能 100% 地完成事先制定的计划（所有客户需求）？

计划的不确定性

当人们提出诸如“客户的需求计划能不能完成？完不成怎么办？...”此类的疑问或担心时，往往隐含着这样一种误解：任何计划（包括固定工期、固定费用的），只要是由聪明的人类作出的，都应该 100% 完成；如果完不成，那么就是由于开发商、工程开发人员的无能，或者不努力、消极怠工所造成的。

假设，开发商事先向客户承诺计划用 10 个人在 6 个月内保证完成 100 项需求的开发。问题的关键是，这样的事先承诺具有多少科学性（依据）？

人们（尤其管理者）普遍存在这样一种误解，只要是制定计划，就一定能 100% 的完成。而且基于这种 100% 的决心，信心满满地向客户/用户作出了承诺，一旦做不到 100% 的交付，就要怎样怎样怎样。

然而，软件工程 40 年发展所反映的事实情况又如何呢？任何事先制定的计划其实都只是一种对未来情况作出的预测，任何软件开发项目或多或少都存在着一定数量的风险。您是否听到过，或者亲身经历过风险为 0 的项目？只要存在着风险，人们在正式开发之前所作出的各种预测计划就有可能完不成。所以，项目的实际情况能否完全按照计划执行，存在一个发生概率/几率的问题。即便成功完成的把握非常大，达到 99.999%，那也存在 0.001% 失败的可能。不同项目的实际进展，可能完全符合人们预先制定的计划，也有可能与计划有较大的偏差。谁都不能排除发生任何意外的可能（除了神仙）。

计划，与计划的实际执行情况，是两个不同的概念。决心不同于现实。所以，我们说，跟踪、确保计划的执行比制定完美的计划更重要。

在发生进度滞后的情况下，确保原定计划实现的办法，在迭代开发中有多种选择，比如加人、加班、降低交付/发布质量、减少需求任务等等。我们在这里探讨了 为什么敏捷迭代开发提倡删减任务，而不是一味地加人、加班或者降低质量。

为了确保开发进度，加班是人们常用的手段。但加班可以利用的时间有一个上限，一个 10 个人的团队，如果每天 24 小时工作，连续工作 6 个月，可用的时间资源上限为 10 * 24 * 6 * 31，这是一个常数。如果预测实际的工作量超过了这个最大数值，那么再怎么要求员工加班可能都是无济于事的。

也有人认为，我们可以通过大量增加人手来保证进度。如果 10 个人完不成，那就再加 10 个人，怎么样？的确，有的项目通过增加人手，增加加班时间可以完成。

而也有的项目，简单地通过增加人手和加班，是无效的。比方，项目遇到一个棘手的技术难题，团队始终找不到一个最优的算法来解决系统的性能问题，而性能不能获得改善，系统将无法交付，客户也不同意验收。此时，不但现有的 10 个人完不成，即使再找到 100 个人，如果能力不够，恐怕一时也完成不了。这说明，在这类项目或这种情况下，能不能保证进度、完成计划、按时交付，与人数多少无关，与人的能力有关。

这就是软件开发本身以及软件开发计划的不确定性。

软件开发、软件工程中往往会涉及到很多科学问题，而解决许多科学问题，依靠的是恰到好处的智力，而非简单的人数乘以体力。100 个人通常比 10 个人能举起、拉动更多的重物，而 100 个人未必比 10 个人更聪明，能解决更多的科学问题（比如软件设计中的）。如果灵感到了，可能几个小时就能解决，而如果灵感和经验不足，可能一些问题即使花上半年也解决不了。

对于固定工期和费用的项目，在不适合采用加人、加班、降低质量等手段的前提下，敏捷迭代方法推荐采用删减需求开发任务（或调整需求）的建议显然是合理的。在质量和范围的这对权衡关系中，敏捷方法选择了缩小范围，而不是轻易地降低质量。

另一个问题是，在同样的情况下，传统的做法能否保证计划完成？

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13633641/viewspace-600548/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13633641/viewspace-600548/