为什么要敏捷？

为什么要敏捷？这个问题可能有很多种答案，既有简单的回答，也有复杂的回答，还可以从多个角度、多个层面来问题这个问题，比如个人、团队、企业和组织分别为什么要敏捷等等。

这里，我想列出几个最基本的原因。

Better, Faster, Cheaper（BFC）

软件研发要敏捷，首先是因为敏捷能给我们带来很多好处，比如降低风险，提高质量，缩短时间，减少成本等等。如果敏捷软件工程不能带来比传统软件工程更多的好处，那为什么要敏捷？没有必要。这是最基本的逻辑。

任何软件工程、软件过程改进的目标，有点像奥运口号，无非是 BFC: better, faster and cheaper，还有人提出了 cooler, happier ... 显然，敏捷改进的目的是为了比传统管理和开发方法做得更好、更快、更节省等等，这是我们的基本出发点和判断准则。

敏捷方法的崛起是 20 年来世界软件工程的又一次重大革新

也许很多人还没有意识到，敏捷变革（agile transformation）是当前正在进行中的世界软件工程史上又一次重大的 paradigm shift（范式转变）。另一次著名的范式转变发生在上世纪末的八九十年代，也就是大家比较熟悉、公认的由传统结构化编程向新型结构化编程（OO，面向对象）技术的转变。

“敏捷”是一个形容词，“敏捷”也是一种状态，敏捷（如快速应变）能力是所有优秀企业/组织、优秀团队和优秀个人都具有的一种基本特质。因此，不出意料，敏捷软件工程、敏捷过程和方法，也率先被世界上最优秀的一批软件研发领导企业、组织、团队所实践和采用，目前业界熟知的有微软、IBM、Yahoo!、诺西、华为等等。

“敏捷”的一个反义词是“迟钝”，作为个人或组织，不能及时地响应变化，适应变化，代表他已经衰老，不合时宜了。进化论告诉我们，物竞天择，适者生存。历史和未来都将证明，不具有敏捷能力的软件研发组织，迟早会被现代市场竞争所淘汰。

敏捷过程改进是国内中小软件企业和组织提升竞争力的重要手段

与整体实力和适应能力更强的大中型企业相比，中小企业通常对项目的时间、成本、风险和利润率等要素更为敏感，经不起几次折腾。

而与传统软件过程、传统管理和开发方法相比，敏捷方法具有以人为本、轻载（lightweight）而灵活、成本低、开销小、效率高、见效快等优点，尤其适合中小软件研发企业或组织的软件过程改进和企业业务流程再造（BPR）。

敏捷方法弥补了 CMM/CMMI、ISO 9001 等体系的不足

在过去八年中，我们看到真正的 CMMI 专家一直在研究敏捷，学习和吸收敏捷的长处，出现了 CMMI 主动拥抱敏捷、与敏捷集成或融合的显著趋势。既然 CMMI 要拥抱敏捷，就说明敏捷有 CMMI 所缺少的东西，如此庞大的 CMMI 体系仍然是不全面的。

CMMI 与敏捷并非水火不相容的关系，而是可以相互补充、相互促进的关系。现在人们逐步认识到，没有敏捷度（Agility）考量的成熟是不全面（片面）的成熟。

通过了 CMMI L5 之后，软件研发组织的过程改进向何处去？敏捷过程改进是组织过程持续改进的一个重要和主攻方向。这两年来，国内不断有 CMMI 组织的客户和朋友向我打听敏捷改进的事情，征求我的建议，CMMI L3 到 CMMI L5 的企业都有。这的确是一个好现象。

事实上，不论您的软件研发组织、企业已经获得了 ISO 9001 证书，还是 CMM 各级证书，或 CMMI 各级证书，甚至 CMM L5 或 CMMI L5 等各类顶级证书，抑或以上各级、各类证书啥都没有，从提高效率、加强内功的角度看，实施敏捷过程改进，或者参考敏捷方法、敏捷过程模型进行持续过程改进，都是一个非常值得考虑的举措。

小结

概括一下，为了加强核心竞争力，取得市场优势地位，超越竞争对手，追求更加优秀、成熟和卓越，所以要敏捷。

您是否还有更好的理由？欢迎来信告诉我们。

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

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

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

简答

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

不过，还存在另一种可能性，尽管在某次或某些迭代中，我们删减、推迟了某些需求或任务，但最终还是赶上了进度，所有计划的需求仍然可以在 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 个人更聪明，能解决更多的科学问题（比如软件设计中的）。如果灵感到了，可能几个小时就能解决，而如果灵感和经验不足，可能一些问题即使花上半年也解决不了。

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

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

时间盒迭代（timeboxing/timeboxed iterations）是国际上流行的开发方式，它的特点是每次迭代的结束时间点是固定的，一旦确定，就不允许推迟或变更这个时间。到点时，开发团队必须提交一个稳定的、通过了系统测试的版本，以便参加评审或向客户演示。

如果在迭代进行中，开发团队发现进度落后，无法完成全部的迭代开发任务和计划的需求功能时，敏捷方法通常允许或要求开发团队与客户协商，减少开发任务或需求（可以放入下一次迭代中），以保证在既定的时间点提交高质量的成果（尽管这个成果可能不完整）。

这是为什么？

也有人担心，如果因进度紧张，计划的需求任务老是被推迟到下一次迭代中，那么是否会导致开发团队在既定的工期内，永远都无法实现既定的完整客户需求？

简答

当进度滞后的情况发生时，为了确保开发进度，保证按时交付系统，增加人手、提高加班强度、降低质量以及删减需求任务是一些人们常用的手段。

敏捷方法提倡在一个迭代（固定时间片）内删减需求任务，这主要是因为其他手段（增加人手、提高加班强度、降低质量等）不适用，或者已采用但仍不能满足要求。

原理

根据项目管理的基本原理，我们在从事一个软件开发项目时，往往需要在时间、资源、质量和范围（需求、内容）等 4 个要素之间进行权衡。



这 4 个因素/因子之间存在着相互制约、相互依赖、相互影响（拉动）的关系。

例如，对于给定的范围（比方 100 个明确、固定的软件需求项），如果要获得较高的软件质量，往往需要我们在时间和资源上作出更多的投入，即花更多的时间和资源，包括资金、设备、工具和人力上的投入等等。也就是说，一旦范围（内容）固定，那么为了在原有基础上提高质量，往往需要我们增加时间，或者资源。

假设有一个 10 人的开发团队，计划在 6 个月内完成 100 项需求的软件开发。迭代长度为 1 个月。

如果交付时间固定，比方要求必须在 6 个月内交付，那么剩下范围、资源和质量 3 个因素可供调节。如果范围也固定，必须交付这 100 个需求项，那么就需要我们在资源和质量这两个因素之间进行权衡。

在国内外的软件工程实践中，普遍存在着大量固定工期、固定费用（比如招投标中）的合同项目。如果开发团队在项目过程中发现，难以在某次迭代中完成既定计划中的所有需求项的开发，该怎么办？

办法一

第一种办法是增加资源（人力等），也就是通常所说的增加人手。著名的《人月神话》告诉我们，简单地依靠增加人手，来确保 deadline 往往是不可行的，增加新人的结果往往会导致项目延期。

当然，对于那些简单的、比较确定的项目和任务（比如“电脑打字”类的），增加人手和加班时间，显然能够解决问题。通常这类的项目具有线性特征。如果 1 个人 1 天能完成一件标准工作，而对于以上 10 人的团队，在 dealine 之前还有 120 件工作需要完成，而剩余的时间只有 10 天，那么再增加 2 个人就可以了。

然而，实践表明，大量的软件研发项目具有非线性、非确定特征，无法按照以上简单、理想的计算结果来确保进度。

办法二

与加人相关的另一个常用办法是，增加加班时间，可以与加人办法一同采用。

尽管 dealine 是不能修改的，工期也有限，总共只有 6 个月，那么最好是向黑夜要时间，在有限的工期内挤出更多的可用工作时间来。原来规定每人工作 12 个小时（加班 4 小时），如果进度来不及，还可以尝试进一步延长加班时间，比如让每人的工作时间为 14 到 16 个小时等。当然，最好是三班倒，不分白天黑夜地干，这样每天 24 小时都被充分利用了。

事实上，加人、加班的确是业界（尤其劳动密集型产业）常见的对付进度滞后、工期偏紧的办法。

然而，加人、加班共有的一个缺陷是，它们都有一个上限。加人意味着企业成本的增加，需要拆东墙补西墙，无法无限制地增加人数；而加班超出限度，会导致员工疲劳，生产力下降，进而导致质量下降，反而无法实现进度目标。

办法三

如果不能加人、加班，或者即使加人、加班也不能满足要求，那么降低质量也是一个办法。我确实听说国内外有不少团队为了实现 deadline 目标，获得客户/用户和领导们的最大满意度，或者赢得最佳的 time-to-market，宁愿牺牲或降低质量，也要按时准点交付。

降低质量有很多种手段。实在来不及了，省略测试，或者干脆不做测试，或者放弃修正以有的 bug 就交付，是常见的做法。

这种做法有一个明显的缺陷，就是可能会带来质量后遗症。表面上是按时交付了，各种需求都满足了，可以使用，但由于隐藏着质量问题，开发团队不得不在发布之后继续花更多的时间一边开发新功能，一边修正以前残留的质量问题。

另一方面，任何发布的软件都不可避免的存在一些或大或小的错误，即使经过了严密的测试。要避免质量后遗症，如何把握、掐准发布/交付的质量门槛是一个关键。

办法四

如果资源、质量都不能变动，或者加班、加人、降低质量都无济于事，那么还剩下一个因素可以调节，也就是范围。减少范围，在迭代中删减或不再增加新的开发任务，同时不删减质保活动，集中团队的精力解决现有问题、完成现有任务，就能保证在规定时间内不断地交付较高质量的产品（或其一部分/增量）。

通常以上 4 种办法可以结合起来运用。在进度滞后、既定任务计划完不成的情况下，为了确保进度/赶进度，人们通常想到的办法首先是加班，也就是增加现有人员的有效工作时间；如果加班不行，那么就加人，增加人手；如果加班、加人还不行，那么可以降低质量，减少精雕细琢的行为，把主要精力放在主要任务上；可是，如果降低质量还不能满足进度，怎么办？

在时间、进度紧迫的情况下，交付一个功能、需求可能不完整但是质量较高的系统，与交付一个功能、需求完整但是质量较低的系统，哪一种结果更好？客户会更喜欢哪一个？恐怕我们不能一概而论。

以上就是为什么开发团队遇到此类情况时，以时间盒迭代为特点的当代敏捷方法通常推荐我们在迭代的进行过程中，减少计划完成的需求或任务，并根据迭代中可用的时间片来安排、填充迭代任务的原因。

总之，为了保证开发进度，当既不能加班、加人，也不能降低开发质量时，与客户或产品经理等需求管理者进行协商，减少迭代中待开发的需求任务是更为合理的选择。当然，如果开发团队发现进度超前，自己还有余力接受更多的任务时，敏捷方法也鼓励增加需求任务。

不管增加还是减少需求任务，都是敏捷方法进行适应性计划、灵活和 just-in-time 任务调度的一个选项。

...

敏捷开发（方法）是近十年来国际上兴起的一种新型的软件开发和管理方式、方法，首先在一批国际上领先的先进软件研发企业和机构中得到了成功应用。

针对传统软件工程方式方法的弊病和不足，以及现代软件开发所面临的特殊环境与要求，敏捷开发提出了许多更为先进和成熟的创新思想、价值观、原则和具体做法。

敏捷开发认为，实际的软件开发活动往往具有非线性、随机性等特点，主张采用自适应、自组织的开发和管理方式来消除不确定性和防范风险，提高开发的成功率。

敏捷开发具有轻量、简化，易操作，易适应变化，反馈周期短，尽早、频繁的自动化测试，强调协作与沟通，以人为本等显著的特点。

几乎当前所有的敏捷方法都采用了迭代递增式开发（IID）方式。可以这么说，迭代式开发是过去 20 年来国外软件工程的先进、主流开发方式，迭代构成了敏捷的基础。

在过去的 10 年中，我们陆续看到不少的统计数据和报道，以迭代为基本特征的敏捷方法能够显著提高软件开发的生产率和质量。

这是什么原因呢？

所谓生产率（Productivity），通常是指这样一个公式：

生产率 = 工作量/时间

完成同样的工作量，如果所用的时间越短，那么生产率就越高。换句话说，在相同的时间内，生产率越高的开发团队，其产出、成果也就越多。

迭代开发之所以能够显著提高生产率，是由多方面的综合因素造成的。这里，我提出几个可能是最主要的原因。

首先，迭代的并行开发方式可以缩短工期。

迭代开发往往采用并行、并发开发方式，是软件工程的并行工程，而显然，并行、重叠式开发与瀑布、串行式开发方式相比，可以缩短总体工期。



假设有一个工期为 6 个月的项目，传统瀑布方式通常会设定一个长度为 1 个月的需求分析阶段，一个长度为 1 个月的设计阶段，一个长度为 2 个月的实现阶段，以及一个长度为 2 个月的测试和部署阶段等等。

为什么非要等 1 个月的需求分析全部完成之后，才进行设计和开发呢？

敏捷迭代开发采用并行、重叠方式。一旦在第一个月的第一周明确了部分需求（比方占全部潜在需求数量 5% 的需求）定义之后，在第一个月的第二周就可以开始设计、编码和测试。所有的开发工作几乎是同时并行进展的。在设计、编码、测试的同时，对剩余需求的分析工作可以同时进行，而通过及时的设计、编码、测试和用户评审获得反馈，反过来又可以进一步地改进需求分析工作，提高需求分析的准确性和质量。

其次，迭代开发通过缩短和优化反馈坏，不断验证开发中的系统质量，可以显著减少返工和浪费，从而提高开发生产率。

迭代式开发往往采用时间箱、短迭代，要求在迭代的执行过程中和迭代结束时，通过各种手段和措施不断地进行验证和评审，以及时地获得反馈信息，确保开发始终沿着正确的道路前进。

敏捷迭代方法的质量验证的方式、方法有很多种，比如频繁集成和测试、客户演示、客户评审、每日例会与进度跟踪等等。

这些手段与传统方式相比，能显著地提高软件开发质量。软件质量提高了，自然返工和各种形式的浪费就减少了，开发人员就能在有限的工期内把更多的时间用在完成更有价值的工作上，而不是做无用功，从而提高了系统开发的整体生产率。

停车起步问：

Charlie,我看了你的网站，说实话，有些观点还是很赞同的，但有些概念还没有看明白。

如果说Agile这个起源于西方软件界的名词或者说它的思想和原则，在被包括你我在内的软件从业人员引进国内的时候，需要做一些本地化的改进/改变，这个我就很容易明白。但是，“太极”这个概念我倒是有些糊涂了,有相关可以共享的，关于你的这个理念的资料吗？

停车起步，你好！

简单地说，太极敏捷就是一种中式的敏捷，它是以辩证法、矛盾论为基础的阴阳太极思想在敏捷软件工程中的应用，包括一套有关敏捷文化、开发和管理的思想、价值观、原则和实践方法。



“太极”是指阴阳太极的辩证哲学观，中国人的传统智慧。阴和阳，是一对矛盾，既对立，又统一，二者相克相生，你中有我，我中有你，在一定条件下还可相互转化。这提示我们，分析、解决问题时，要做到一分为二、辩证统一。

那么，阴阳太极与软件工程、敏捷运动又有什么关系？我提出的软件工程太极理论和太极敏捷既简单又复杂，内涵非常丰富，下面我试着用简单的几句话来概括和解释。

为什么要太极

软件本是阴阳（0 和 1），一切都源于阴和阳的运算，而在软件开发、项目管理和软件工程的各个层次上，存在的对立统一关系可谓比比皆是，实在太多了。发现阴和阳，我们只要找找反义词即可，比方，外与内，动与静，高与低，粗与细，大与小，远与近，变与不变，定性与定量，主观与客观，利与弊 ...

在软件开发和管理中，包括每一位开发者和管理者在内，我们每天、每小时都在做出各种各样的、大大小小的决策，小到一行代码、语句的书写，大到企业今后三年内应该采取的战略目标。作出任何正确的决策，都少不了辩证的科学思维。

软件工程本质上就是一门讲究权衡的艺术。决策错误往往是最大的失误。最难的一点是，不论软件工程师还是企业管理者，我们如何确保自己始终能够作出正确的决策，或者退而求其次，尽可能少犯错误，少作错误的决策和决定。而在决策过程中，玩极端的零和游戏，剑走偏锋，一叶障目，往往是比较危险的。

因而，太极敏捷主张在软件工程的开发和管理中，主动运用科学的辩证法和矛盾论，来解决软件开发的各种现实问题，作出正确和有效的决策。

太极敏捷与西式敏捷的关系

敏捷方法 XP 的创始人 Kent Beck 有一个著名的观点，如果一件事情很好，那么就应该把它做到、运用到极致，把 8 点钟的指针拨到 10 点、12 点（似乎这样就可以获得最好的效果和最大的收益）。这大概也就是 Extreme Programming 名称的来历。根据我个人十多年来的经验、观察、研究和认知，张恂对此观点并不认同。

同样主张敏捷，太极敏捷反对各种极限和极端的想法和做法，相反我们认为越极限的东西，其适用面越窄，也越难持久（太极敏捷的极限法则）。我们主张讲究平衡与统筹，以静制动，以柔克刚，兼收并蓄，融汇统一，在诸多对立、矛盾和冲突的关系中巧妙地取得动态的阴阳和谐。因而太极敏捷与西式敏捷，在基本的哲学观、价值观和原则上是有差异的，这也导致了二者在具体操作层面上的一些差别。

太极敏捷不是空洞的理论，它包括了许多可以在日常实际工作中直接运用和操作的具体方法和经验指导，比如如何写需求，如何建模，如何进行架构设计，如何进行测试，如何进行项目管理等等。

太极思想和原则可以运用到软件工程开发和管理的方方面面。目前我研发的太极敏捷第一阶段主要关注软件过程、需求、架构、测试和项目管理、企业团队文化等方面。我提出的统一需求用例方法、太极建模、UDD、太极重构等等具体的操作方法都可以看作是太极思想在这些方面的应用。

当然，太极敏捷也不是一套大而全的东西，精简、实用、有效和灵活是我们追求的目标。太极敏捷主张学习和吸收西式敏捷（Scrum、XP 和 AgileUP 等方法）的优点和长处，直接借鉴、采用其已经比较成熟的做法；用本地化的方法，替换或改变其中一些不适合国内市场、客户和企业环境的做法；用本地化的思维和价值观，来推广某些西式敏捷不太重视、没有强调或被其忽视的内容（原则、做法、技术等），比如 OOAD、建模、前构、风险驱动和架构驱动、软件重用、知识共享等等。

有关太极敏捷的资料，我正在整理。目前一些基本理论观点、原则和实践方法的介绍可以在我网站上的几篇文章和评论中找到，近期我还会公布一些 ppt、pdf。如果你感兴趣，欢迎到我网站上注册，我很乐意和你进行公开的探讨。也欢迎有兴趣的网友一起来研究。

很多经典文献、教材上都有关于这个问题的解答。迭代长度通常建议为 2-6 周（或 1-6 周），这是一个经验数值。到底选择几周为一次迭代，这个问题其实不太难，因为通常你只有 1、2、3、4、5、6 这 6 个数字需要选择。



我们太极敏捷派的建议是这样的：

如何确定迭代长度，有这样几个关键点需要权衡（包括但不限于）：

第一，我们希望每次迭代开发，可以获得实质性的进展，完成足够多的开发任务，所以对于普通项目，1 周甚至小于 1 周的迭代长度就显得有点短，做不了几天的开发就要暂时 close，不太合算。

第二，迭代任务（包括模块集成、系统测试、评审等等）的完成，应该比较顺畅（streamlined）、从容或者适度紧张，没有非常紧迫、仓促的感觉。如果在某次迭代开发中，需要砍掉很多完成不了的任务，感到进度很紧张，那么很可能说明迭代的长度设置太短了，在下一轮的开发中应该增加迭代的长度。

第三，对于每个项目团队而言，合适的迭代长度有一个有效区间。总体上我们希望迭代越短越好，它有个下限，短于这个下限就可能得不偿失。那么，迭代时间为什么不能过长？它的上限是多少呢？迭代的主要目的是为了及时获得各方面反馈，确认已开发的内容是正确和可靠的，从而减少风险，保证开发能够始终稳步地、沿着正确的轨道前进。显然迭代过长，很长时间不对已开发的系统部分进行验证、反馈，随之而累积的各种风险就可能增加，形成返工和浪费。如果超过一个半月（6 周）以上，还都拿不出一些可以执行、验证和 demo 的软件程序，那么这样的项目开发显然不能说是高效的。

从 2 到 6 周，建议选择偶数 2、4、6 周作为迭代长度，排除奇数 3、5 周。执行周计划周总结和月计划月总结是国内很多企业比较普遍的做法，显然设置迭代长度为半个月、一个月或一个半月，就能与之相合拍，更自然和便于管理。设想，当您做月度总结的时候，只完成了 1 又 1/3 的迭代，会是什么感觉？

迭代长度通常还与整个项目的工期（或复杂度、规模）有关。如果项目的工期在 1 年以上，那么 1 个月或 1.5 个月的迭代长度就是比较合适的。对于进度压力不同的项目，人们的心理紧张程度是不同的。假设 2 周就要完成一次迭代，持续干上一年，大家会不会感到太累、太频繁？如果整个项目工期小于 3 个月，那么 2 周迭代甚至 1 周迭代，就是非常合适的。对于进度这么紧的项目，可能每周、每天都是非常宝贵的。

通常，张恂会向客户推荐采取 2 周或 4 周作为迭代长度的首选，3 周、5 周和 6 周作为备选，往往大项目、比较复杂的项目才会采用 6 周，6 周以上基本不考虑。2 周通常适合各方面很成熟的开发团队。如果一个传统瀑布团队，要尝试着转向迭代开发方式，从 4 周的迭代开始学习、积累经验，然后逐步缩短迭代长度，是比较稳妥的改进方式。

建议一个团队在熟练使用 2 周迭代一段时间（比方半年）之后，再尝试 1 周迭代。通常一个团队在开发和管理方面经验越丰富、越成熟，各方面的细节控制得越好，就可以尝试越短的迭代。

此外，不同的项目开发阶段，可以采用不同的迭代长度。根据 UP 的建议，我们通常可以把一个项目分为起始、细化、构造和移交四个阶段。项目前期的起始、细化阶段，很多内容不明确，需要做很多探索性的工作，一般迭代的长度可以适度拉长，比方 2-4 周；而在构造、移交阶段，架构已经明确和稳固，主要追求开发实现的速度，所以迭代长度可以适当缩短，比方 1-2 周。

最后，最重要的一点是，在敏捷开发中，迭代的长度完全是可调的。如果开始的迭代长度设置太短，或太长，都没关系，我们可以在随后的迭代中根据项目实际情况的反馈进行调整，这就叫自适应（adaptive）。

网友问：

在开发中，有人代码的编写顺序是这样的：

领域类->持久类->界面类，

而有人是如此：界面类->领域类->持久类，

这仅仅是习惯问题还是有数优孰劣的评判？

我认为，后一种编码顺序更合理，效率更高。

软件开发首先是功能驱动，具体可以落实到用例的实现上。而用例就是反映系统边界上的输入和输出，所以编码实现时，最好是从外向里，始终围绕着用例的输入、输出来开发，依次是界面类，领域类和持久类。这样，我们的编码就有了可靠的指引，不会偏离需求，因为功能需求都是来自于界面的输入和输出，也就是用户想要的结果。这其实是一种 UI 驱动的开发，本质上是用例驱动。

在开发过程中，我们通常都鼓励在开发早期尽早把界面原型做出来，这样可以尽早让用户获得直观的体验，取得它们的反馈，从而稳定需求。这是一种高效的开发方式。有的时候，在没有编写实际的领域类、持久类的情况下，我们甚至可以采用“短路”方式，构造一批仿真数据，不经过后台的处理，直接在界面上进行反映，以稳定需求。然后再根据界面处理的要求，逐层深入，通过重构（系统功能不变），把领域类、持久类编写出来。

第一种顺序，先写领域类，再写持久类，再写界面类。这样做的问题和风险在于，脱离了用例和用例实现，也就是功能需求，来写领域类，往往会偏离实际的需求，造成领域类的设计缺陷。因为在没有外部约束的情况下，领域类的设计往往有多种方案，脱离了用例、功能、界面、外部条件的约束和限制，这样做出来的设计容易出问题，不是过度设计，就是设计不足。用例代表了用户的真实需要，基于用例实现做出来的领域设计，不会多做，也不会少做，刚刚好。

当然，我们实际开发的时候，不是把界面类全部写完，再写领域类，或者把领域类全部写好，再写持久类。不是这样一种块状的方式，是一种条状的方式。也就是根据用例的基本流和扩展流，每一次实现一个流（情节或特性），这个流是从外到里的，依次遍历界面类、领域类和持久类。然后，再增加新的用例流或特性，通过跨越架构，逐步增加界面类、领域类和持久类，直到完成整个用例（功能）实现的编码。

大体上就是这个过程，由外及里，遍历架构，遍历用例，迭代递增，是一种矩阵式的开发方式。

...

...