|
-项目团队交互的动态性
-里程碑的特性
-对依赖的处理
-度量和测度
-必要的资源项目经理圈子
项目工作的并行程度
最重要的区别之一是进展的度量方式。取代用中间工作产物（如需求文档、分析模型和设计规格）的完成来度量进展，我们根据开发和测试的方案的多少来度量进展。 如图 3-4 所示，每次迭代都将导致向解决方案的交付的可度量的发展。
blog.mypm.net
 项目管理者联盟
图 3-4：度量成功测试的软件中的增量
从对进展的主管评价（经常根据生成的文档）到对进展的客观度量（通过生产软件的工作量来度量）的转移是迭代方法和更传统方法的最根本的区别。分析每次迭代结束时对进展的客观评价的趋势可以使项目管理人员控制项目并做出变更以提高项目成功的几率。
迭代可以使项目成为一系列更小的独立项目，每个项目都依赖于前一个项目的结果和性能。由每次迭代的结束时刻进行的评价所形成的反馈使您可以对下一个和所有后来的迭代调整计划。
质量管理人员的视角
这些常规的迭代评估提供了评价进展的机制。在这些局部的里程碑上，要根据目的和目标集由团队评估迭代计划中的进展。一个暗示是基于活动的状态报告（您所处理的内容是什么？）并不像基于成就的状态报告（您已经完成了什么？您接近到什么程度？）那么重要。利用迭代的方法，很难将事实隐藏很久。
事实上，这种测量活动而不是真实进展的方法只会引发问题。项目团队需要灵活地使他们的活动达到所期望的目标，项目管理人也许不能足够准确地预见未来，以计划所有用来实现目标的工作。更加开明且解放的做法是给予项目团队一些需要达到的目标，并授权给他们可以灵活地响应变更。 通过约束创造能力和响应性，详细的活动程度计划实际上会危及项目成功而不是确保成功。
在每次迭代过程中对项目结果的客观测量省掉了通过对中间产品的主观质量评估来对项目进展进行的评估。取代通过坚持在开始建立任何内容之前结束使用需求来判定需求的质量，您可以通过拿到第一批可用的需求并使他们通过开发循环，在迭代的过程中，生成工作和测试了的代码来评估需求。这为项目是否达到目标提供了客观的证据，因为他们将在实际中使用而不仅是用于称赞。度量质量的方法从根本上改变了。质量度量着重于常规的可以提供对项目的持续洞察的迭代评估。对过程和工作实践的回顾有规律地捕捉从项目中得到的经验，并在项目中造成一个持续的过程改进的文化。这些观察可以立即被应用到下一次的迭代中以提高质量和团队效率。
通过在每次迭代过程中测试生产出的版本、提供管理和质量指示器，以及测量项目进展来进行客观的度量。因为每次都要对前一次迭代交付的需求进行反复回归测试，所以这种不断的整合及测试导致了随着项目进展而不断增加的测试覆盖面，如图 3-5 所示。 转自项目管理者联盟
 项目经理博客
图 3-5：在不断的迭代中测试负载在增长项目管理者联盟
对迭代方法的采用可以帮助提高由以下内容交付的成果的质量：
-通过将需求迅速地转变成可以进行观察测量的内容来尽早地减少对需求的误解
-通过检验技术方法来尽早地减少开发风险
－从项目的一开始就调节并控制变更项目管理论坛
在项目的早期，还可以进行变更的时候，提供一种方式来评估过程效力、进度表、团队生产力，及资源是否充足项目管理者联盟
在迭代的方法中，质量管理人员集中于产品和过程的有用性，从整体上支持团队的效率。强调从完整性到“适合目标”的其中一项内容的质量变更。质量管理人必须放开这样的误解，即“停止产品并不再做变更会带来更高级别的质量。”www.mypm.net
这并不意味着事情永远不完结 —— 只是要求项目团队不要考虑这样的完成，以便他们发挥积极减少项目风险的才能。项目管理者联盟
有一个普遍的误解，迭代开发从未真正完成工作，一些人将灵活的迭代项目视为要永远进行工作。这肯定不是真的。 对所有的迭代存在一个最终的目标：最终版本。每次迭代就像一面墙中砌好的一列砖：每次迭代都为达到筑墙的最终目标做出贡献，并且可以测量每次迭代对整体目标的贡献，就像可以测量每个砌好的砖列对整堵墙的贡献一样。项目管理者联盟
总结：从团队视角考虑的迭代
采用迭代和增量开发技术不是只影响到开发人员和其他涉及项目的技术人员的纯技术决策。它代表着设计和发展项目所采用的方式的根本变更，一个影响到每个参与项目的人的变更。因此迭代开发要求整个项目团队改变工作和交互的方式。同时，项目管理不再必要，这不是一个意义深远的变更。而是它简单地需要一种不同的更适应管理的方法。项目管理者联盟
迭代开发是针对问题解决和解决方案开发的基于团队的方法。它要求所有参与的人 —— 包括开发团队、客户团队，和管理团队 —— 都采用协作的技术。www.mypm.net
从开发团队的视角出发，采用迭代和增量开发是需要授权的，并要求团队成员积极进取地用他们认为最适当的方式处理项目危机和难题。通过设置清晰的目标和客观地度量结果（但不指示活动）来管理迭代可以确保轻松地找到最佳的方式来交付成果。项目管理者联盟
从客户和业务团队的视角出发，引入清晰有意义的目标，并结合回顾可论证成果的能力，可以使那些最终使用新软件的人在项目中发挥积极作用，并与开发团队分享所有权。迭代对所有涉及项目的业务人员产生深远且长久的影响，并且从根本上改变了他们规定、支付，并实现软件解决方案商业利益的方式。项目管理者联盟
从管理团队的视角出发，每个项目都被分解为一系列小的项目，称为迭代，每个迭代都建立在前一个迭代的结果之上，并不断增加地实现项目的总目标。当授权开发团队创造革新的且有效的解决方案时，这种对项目的分割引入了常规的，可度量的，使项目保持正轨的里程碑，将项目成功的几率最大化。
结束
我们希望您对这篇关于迭代开发如何支持并有助于各种软件开发的参与者的简短分析感到满意。如您从这最后一篇文章中推测到的，我们坚信，好的管理是成功应用迭代方法所必要的部分。我们将在即将面世的书籍 Managing Iterative Software Development（今年后期由 Addison-Wesley 出版）中更深入地探究此话题。项目管理者联盟
注释
1例如在 http://www.standishgroup.com 查阅 The Standish Group 的年度 Chaos Report。
2依照 Process Management Body of Knowledge（PMBOK）。参见 http://www.pmi.org
3迭代的真正长度会随着项目中的人数而变化，也会随着解决方案的复杂度而变化。更大的项目团队需要更长的迭代来处理用来管理通信的复杂的事物。项目管理者联盟
参考资料
您可以参阅本文在 developerWorks 全球站点上的 英文原文。项目管理者联盟
作者简介
Ian Spence 是英国 Ivar Jacobson 咨询公司的首席科学家。他的主要任务是帮助那些创建并执行变更程序的客户提高软件开发水平。为达到此目的，他致力于 IBM Rational Unified Process ® 的大规模采用，以及 IBM Rational Unified Process 所推荐的迭代的、由用例驱动且为中央体系结构的方法。Ian 拥有软件行业方面的十八年经验，涵盖完整的软件生命周期，包括需求获取、体系结构构架、分析、设计、实现以项目管理。 项目管理者联盟
Kurt Bittner 在 IBM Software Group 的 Rational 软件部门进行产品策略方面的工作。他已经为找出帮助团队开发软件的更好方法努力尝试了二十三年以上。他是原来的 RUP 开发团队中的一个成员，并在多种行业中领导开发团队。除了做软件开发的工作以外，他喜欢在休息时间攀爬冰冻的瀑布。转自项目管理者联盟
Ian 和 Kurt 合著了 Use Case Modeling（Kurt Bittner, Ian Spence -- Addison-Wesley, 2003），并且正共同书写着下一本书，即 Managing Iterative Software Development（在今年的后期将由 Addison-Wesley 出版），本系列的文章就取自该书。
www.mypm.net
项目管理者联盟
|
