进展
经典开发过程的很多方面造成了涉众关系退化到相互间的不信任。信任对在用户需要、产品特性以及计划中通过指导和协商取得平衡是最基本的。迭代过程加强了涉众间的有效交流（通过一系列可演示的发布实现），允许基于更为客观的所有人理解的协商。这需要客户、用户、以及管理者集中于可用系统的发布，而不是笃信标准和合同条款。它同时还需要开发组织致力于用能获得利润的方式创造价值。
迭代过程需要对一个不断完整的系统进行顺序的建构，这个系统展示了架构，实现了客观的需求协商，证实了技术方法，并指出关键风险。理想的情况下，所有涉众都着眼于这些里程碑，把它们视为有用功能的递增发布，这不同于那些投机的对最终观点的论文描述。向可演示驱动的生存周期的过渡造成了非常不同的项目外观。一个健康的项目将诚实地展示出一个进展与背离共存的序列，而不是一个线性发展价值递增的轨迹（通常是不诚实的）。
下面是两个我从未见过的反例的相关观察：
1.一个具有一张价值持续不断增长曲线图的软件项目一定会有一个待解决的很大的回归。
2.在解决不确定性，会师于一个可接受的解决方案的过程中，健康的软件项目表现为一个进展不断增加，弯路不断减少的序列。
雄心勃勃的展示是一个健康的项目的发展道路上绝好的里程碑。在生存周期早期进行展示的目的是暴露设计缺陷，不是粉饰门面。涉众不应对早期错误、背离或不成熟的设计反应过激。如果早期工程阶段受到过分限制，开发组织建立的中间检查点将不会那么有抱负。早期的增量是不成熟的。外界涉众，比如客户和用户，不能指望初始发布的版本拥有最终发布版本的规格和性能——也就是完整、完全可靠、拥有目标级的质量和性能。
另一方面，开发组织必须对连续增量之上的切实的进展负责，并对之进行展示。客观地量化变化、修改以及更新将会为进展和质量提供诚实的指示。公开和专心的追随对解决问题是必须的。好的和不好的项目性能在生存周期的早期往往更为明显。采用指导式的领导方式，成功就会孕育成功。在发布一系列可演示的结果以后，你就可以很好地预测结果了。持续没有进展或者停滞的结果序列是项目需要认真重新考虑资源、范围或者项目价值的标志。软件项目的经验已多次表明，早期阶段决定项目的成败。这就是使用小型的、能力强的出发团队处理计划和架构设计阶段工作的原因。如果这些早期阶段处理得当，项目将会由能力中等规模的团队向最终产品发展，并成功完成。如果计划和架构设计阶段处理不好，即使出动全世界的程序和测试专家可能也无法在后续阶段取得成功。
质量控制
如果你按照迭代开发的精神正在成功管理一个项目，那么多数集成测试应在部件测试之前进行。停下来思考这一陈述。尽管在任何时候都有两种活动在混合进行，你应该认识到初始的部件开发和测试更多的是作为在一个集成的、系统级的线程或行为内执行一个部件的接口和功能的方法。一旦接口和集成行为被成功测试，部件的完整性也就可以测试了。先进行集成测试加速了架构上重要的问题更早进入生存周期的相应阶段。它还为持续的系统级和部件级进展和性能的评估提供了演进的测试模板。
这种先进行集成测试的方法的一个关键副产品是测试和测试人员成了项目过程中的头等公民。在传统方法中，测试人员建立计划、过程和文档，它们都是次要于分析和设计工件的。测试人员的工作和生存周期早期的工件对项目的成功没有太多指示作用，在多数组织内都是由“B选手”（意思是，不能成为最优秀分析和设计师的人）来完成的。在健康的迭代项目中，生存周期早期的演示需要重要的测试观念和产品。很多测试团队对一些最有效的“分析”活动和结果负有责任。太多分析人员在抽象模型内单独工作，他们的分析受到的制约是有限的。但是测试人员面临的是建立“测试用例”——真实世界中用例或者评估标准或者预期行为的表现。他们提出一整套不同的问题并从一个不同的角度看世界，因为他们的工作是把抽象的东西翻译为可测试的东西。
这是一个例子。现在很多项目都面临着对商业上可获得的部件和应用程序是采取买还是自己写的办法的抉择。如果第一个面向结果的项目的里程碑是通过演示来作出自己写/购买的决定的，那么你应该对你的团队进行如下分工：
分析团队：与用户一起工作，捕捉产生最差性能的关键用例的情况，比如数据量峰值或者最关键的控制画面。
设计团队：设计可以运行候选商业部件的原型。
测试团队：构建测试用例（比如，一个消息集合、一个测试驱动、一个智能桩模块、一个有数据的数据库、一个图形用户界面操作的序列等等）。这些用例能够反映关键用例，驱动原型并记录它的相应。
为了实现这第一个里程碑，你的团队可以只关注其中两个关键用例（约为用户需要的10%）、少数几个关键部件以及少数几个测试用例，但是它们以及用户将会在生存周期非常早的时候就解决掉30%的风险。通过把测试观点作为过程早期一个同等伙伴包括进来，你将可以吸引更多作出更好分析的优秀人才，因为这项工作更为有趣，而且对成功的贡献更为有效。
传统软件测试方法遵循相同的、应用于软件开发的文档驱动方法。开发团队在建立任何源文件或可执行文件之前先建立需求文档、顶层设计文档以及详细设计文档。相似地，测试团队在建立任何测试驱动、桩模块或工具之前先建立系统测试计划文档，系统测试过程文档、集成测试计划文档、单元测试计划文档以及单元测试过程文档。这一文档驱动方法对测试活动造成的问题与它对开发活动造成的问题是相同的：对大量废物的刨光，还要留待日后重新组合整理。
为了在生存周期中提早进行集成测试，测试序列应该由迭代过程来组织，而不是根据部件来组织。典型地，它应该被一组用例和其它文本表现的、能有意义地为用户进行演示的实体所捕获。下面是一个抽象的描述：
初始迭代：大约五到十个评估标准，抓住与主要用例（对结构选择和整体商业案例有影响的）相关的驱动问题。
细化迭代：十几个评估标准，当用候选架构进行演示时，为主要用例检验实体框架，并证明关键风险已经被解决了。
构建迭代：大约数百个与有意义的用例集相关的评估标准，这些用例集通过测试以后将组成有用的产品子集，可以转为产品的alpha或beta发布版本。
产品化迭代：完整的用例集和相关的评估标准（可能有上千个），组成了与真正发布产品相关的接受测试结果的标准。
现代过程在产品的测试活动中使用的基本工具、语言、符号以及工件与在产品的开发过程中使用的是相同的。测试是指对某些组件在一个控制情境下的执行以及期望的客观结果的外在评估。一个测试的成功取决于在一般意义上定义的成功标准下期望结果与实际结果的比较情况。测试就是可以大规模自动化由机器完成的评估形式。
总结
图1提供了项目管理者对改进时间和价值过渡的观点，我们都应该努力实现这一理念。它为概括有效实现指导式领导（我在四项推荐中所暗示的）提供了一个很好的抽象视角。我通过画出开发进度-时间图展示了三个项目的外观，其中进度是用可执行百分比定义的，也就是用目标的可演示形式。在这个意义下的进展是与结果确实相关的，正如我前面描述过的，而且通过可执行演示是很好度量的。可执行不意味着完整、适应或是符合规格；但是它确实意味着软件是可测试的。
当使用这种度量方法时，典型的传统工程项目管理风格序列是（1）通过文字设计和详细（经常过于详细）工件实现的早期成功，（2）承诺在生存周期后期完成可执行代码，（3）由不可预见的实现问题和接口二义性造成的集成噩梦，（4）使系统工作起来的巨大的预算和时间压力，（5）末期不甚理想的产品，没有时间进行重新设计，最后（6）一个脆弱、不可维护的产品推迟发行。
我这里介绍的现代管理方法把集成加入到了设计阶段，并经过一系列可演示的版本发布，于是也就使得架构上重要的缺陷更早出现，能够在生存周期目标的上下文中被解决。顺流而下的集成噩梦被避免了，同时避免的还有以后的补丁和软件修正。结果是一个更为健壮和可维护的产品的按期发行，于是产品在经济上成功的可能性也就更大了。
使用传统方法管理的项目，陷于集成的无效性和实质设计问题的发现过晚，把总资源消耗的40%花在集成和测试活动上，而这些努力大多带来的是过量的碎片和返工。采用迭代过程和指导式领导的现代项目发行一个产品，上述活动只消耗了预算的25%。
我讨论了真正使用迭代开发精神管理的项目的四种成功模式。每个模式表现了一种平衡，它能够帮助团队掌控制做产品和获得经济效益的路径：
用户需要与设计资产间的平衡
创造性过程的自由性与生产过程的严格性间的平衡
产品进度与实验性的识别背离的平衡
抽象观点与通过测试进行的切实评估间的平衡
根据我的经验，前例中的传统项目外观仍然是普遍的，是我们今天见到的一半以上项目的特征。尽管这些项目中的多数使用传统的工程管理方法，有一些声称使用了现代迭代开发。但是，由于不采用指导式领导，它们没能成功取得预期的商业结果。也许今天的项目有四分之一采用了现代模式，但只有八分之一能够在目标外观上进行操作。正是从这些不固定的外观和成功的结果上我观察出了本文所讨论的风格的一致使用问题。
和建造一座桥比起来，软件项目管理真的更像管理一部电影作品吗？也许不是这样，特别是在产品的后几个阶段。但是我希望这种类比能使读者从不同的参考中来审视软件项目管理技术。这些模式不是新的。它们在很多组织，以各种不同的程度，在广泛领域内经过了实践（尽管不太经常）。如果你深入研究在实践中使用这些模式，你会发现它们都着眼于处理管理上的人与团队工作的方面，很少带有科学、工程或是制造业的偏见。我认为采用指导式管理的组织更容易取得经济上的成功——甚至可能一鸣惊人。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
