|
在本系列三部分文章中的第 1 部分中，我们介绍了精益的软件开发治理，并且介绍了精益治理的使命和原则，以及一个个项目成功所需的组织和项目涉众的协作。在第
2 部分中，我们将着重于围绕精益软件开发治理中使用的必要过程和量度的实践。“过程”指的是用于有效的精益治理的策略
—— 那些使用 Rational 统一过程（Rational Unified Process?，或 RUP?）
的人所熟悉的基本概念。“量度”指的是用于通过支持目标和动机来进行精明的可执行的决策制定的量度策略。
过程
此类别中的实践促进有效且高效执行项目的策略，在没有不必要的开销的情况下，所以项目团队和执行者获得精益治理所需的透明度和监督。与此分类相关的具体实践是：
- Iterative Development（迭代开发）
- Risk-Based Milestones（基于风险的里程碑）
- Adapt the Process（采用过程）
- Continuous Improvement（持续的改进）
- Embedded Compliance（嵌入的法规遵循）
迭代开发
比起传统的（常常称为“瀑布”）软件开发技术 —— 其中需求受困于地点，团队花费数月根据那些规范编码，测试人员只有在编码循环的末尾才收到完成的模块，并且在循环的如此晚的时候才发现需求的不匹配，以至于错过了截至日期
—— 迭代开发技术更经常导致成功的结果。
迭代方法将项目分为一序列短的时间块，称为迭代（有时候称为“短跑”或“循环”）。在每个迭代中，您演进需求、分析、设计、实现，及测试资产。每个迭代都拥有明确的目标集，并且生成最终系统的部分工作实现。每个相继的迭代构建在前面的迭代工作之上，演进并改进系统，直到完成最终的产品。
迭代开发的好处
通过将项目划分为一系列时间块的迭代，并且通过交付可执行的测试的代码作为每个迭代的一部分，您可以完成与有效治理相关的许多事情：
划分时间块促使快速地制定决策，并且明确关注什么最要紧。当您的最后期限是两年以后时，那么比起最后期限是四个星期以后的时候，您会感觉交付和做决定都没那么紧急。
定期的交付工作软件增加反馈机会。通过频繁地交付已测试的代码，您可以通过集成，从编译、各种测试工具，以及可以帮助您评估工作代码的关键项目涉众那里获得无价的反馈。此反馈可以让您尽早的，在最便宜纠正时，找到问题。在您仍旧有时间和这样做的能力的时候采取纠正的操作可以令您的项目交付更大的商业价值。
基于事实的治理。无论我们有多么不喜欢，大多数发生在项目头三分之二的过程中的讨论是主观的：“我审阅了该架构并且依我看来，存在一些主要的缺点。”通过迭代开发，我们从这些主观的讨论转移到客观的，或基于事实的讨论上来：“我查看了性能测试数据，这些数据确定了我的观点，此架构不允许所需的负载”。
迭代开发增加了您构建满足项目涉众真正需求的系统的能力。从软件经济学角度来看，迭代开发考虑到非常有利的发展曲线：已测试的系统生成的更快，因为，相对于未测试的远离航向许多月甚至许多年的系统，沿途它经历了许多相当小的航向修正。相对原始的（且有缺陷的）详细的需求规范，迭代开发造成了那些更符合战略任务的系统。
图 1：根据频繁的论证和项目涉众的反馈，比较“瀑布”项目，迭代（“现代”）项目的生命周期中的小型航向修正导致了更快速的成功。
权衡
在您迁移到迭代开发时，您需要考虑许多权衡：
- 培训和监控。迭代开发需要在再培训和指导上进行投资以确保成功的部署。传统的
IT 专业人员需要去掉那种事先思考所有事情的保证。人们还需要培训当前专业之外的技能，以便他们可以更容易地在项目活动中转移。IT
管理层和商业项目关系人需要了解在什么时候，什么输入和可交付件应该可能发生。这种培训和监控也许要增量地完成。
- 个人技能需要变更。迭代开发需要不同的技能集，以及角色定义集。传统的项目管理需要的团队成员是涉及面窄的专家，迭代开发在专家还可以有较宽泛的技能集时工作得最好。举例来说，代替作为设计人员或实现人员得团队成员，您会期望开发人员进行设计及实现。一些人也许不能有效地过渡到迭代开发。
- 项目资源变更。当需要某个技能集时，迭代技术需要对人员重新分配。举例来说，由于比起只在项目的晚期进行测试，要在项目整个过程中进行测试，所以在生命周期的更早期需要测试人员。类似地，由于及早处理的架构问题
1 在项目过程中不断地得到评估，所以在生命周期的后期也需要架构师。这需要对劳动力重新培训和重新权衡。
- 项目管理需要更大程度的干系。迭代开发对项目经理来说是更困难的，特别是对于项目的头四分之三。这是因为迭代开发迫使及早进行困难的决定，并且因为对于项目来说有更多可动的部分。与其让每个人做三个月的需求，不如您在每个迭代中做一点需求、架构、设计、实现，和测试。好处是您经常可以避免痛苦的失望以及在项目的晚期强硬地重新设置预期结果。迭代的倡导者在对于项目经理和中层经理来说如何管理项目方面进行变更的说服能力，对于迭代开发方法的成功出现是至关重要的。
反模式
以下的反模式表明迭代开发没有（适当地）得到应用：
- 详细的推测的计划。详细地计划整个生命周期，根据计划追踪变化，并且随着项目进展更新细节。（过度详细的计划实际上可能导致项目失败，因为它令项目经理从生产管理活动中分散注意。）
- 文档驱动的追踪。通过依靠审查规范和中间工作产品，而不是评估测试结果的状态以及工作软件的示范来评估头三分之二项目中的状态。
- 长迭代。使用非常少或非常长的迭代，并且尽可能避免项目关系人的反馈，因而避免任何纠正操作。您进行迭代开发的原因是获得反馈并快速调节。我们相信，当您的迭代少于四个或一个迭代持续两个月以上时，您将失去该实践的主要好处。
推荐的默认做法
我们推荐默认四个星期长的迭代。 2 当您发现其他长度的迭代更适合您的环境时，变更迭代长度。争取使用对于您的环境的最短的迭代长度。迭代之间应该没有时间间隔。
基于风险的里程碑
我们已经发现，当您将迭代开发与及早的风险减少和及早的价值创造的谨慎平衡相结合时，它是最有效的。这意味着当您在每个迭代中划分要关注的内容的优先级时，您选择开发那些在交付最大价值的同时，代表最大的商业、组织、计划，和技术风险的特性。然而，这两个目标（最大的风险和最大的价值）不是总充分结合的，这就迫使在将及早的价值创造最大化和及早的风险减少最大化之间进行谨慎的选择。
下推风险减少了技术选择中的不确定性，包括商业成品（off-the-shelf，COTS）选择和架构稳定性，以及我们对团队效力的理解。这种不确定性的削减还减少了估计中的变化，因为在这些因素和生成可靠估值的能力之间存在直接的关联。
由于及早的风险减少和价值创造是项目成功的基础（参见图 2），所以适当设置恰当的控制点是很重要的。这就是为什么所有的四个
RUP 阶段都是以需要评估项目交付件，从而证明适当的风险减少和评估价值创造的管理里程碑为结尾的。举例来说，在
Elaboration 的末尾，您希望去除尽可能多的技术风险，并且交付稳定的架构。团队需要展示出它们有可执行的架构，以及一些选择的可执行的场景，和反映出许多关键技术和其他风险减少了的风险列表。这种风险的减少需要用运行代码的价值，和由迫使及早进行困难的决定所创造的价值来平衡。对一个项目最恰当的平衡可能对下一个是不同的。
图 2：项目生命周期过程中的风险减少（苍白色曲线）和价值（紫色曲线）。
基于风险的里程碑的好处
基于风险的里程碑有以下好处：
- 项目涉众洞察力。里程碑令项目涉众详细检查项目，向项目注入新鲜空气。项目涉众洞察力对项目团队不可见的事件和环境提供方向或反应。
- 及早的价值创造。最大的价值是由制定困难的决策和验证那些是正确的决策而创造的。这将系统的特性反映为人类创造性的表现。这还意味着您及早在项目中进行了最大的变更，如下图
3 所示。
- 及早的损失预防。一些项目基于糟糕的假设，并且从一开始就注定失败。虽然这些项目是明显不幸的，但是您希望在发现这些项目是糟糕的想法之前避免浪费太多的金钱。基于风险的迭代令糟糕的项目在生命周期中及早显现出来。
- 提高的生产力。通过及早去除技术风险，架构将更快速地稳定。这令更节省成本的执行能够进行，因为较少的技术未知数会在项目的后期影响您。
- 在估值中减少的变化。估值总是有变化，且变化与未知数或风险成比例。因而及早的风险减少意味着您估值中的变化将更快地减少。
图 3：及早的价值创造意味着，在风险逐渐地随时间较少时，在项目中及早发生最多的变革。
权衡
在您转移到基于风险的里程碑时，存在许多需要考虑的权衡：
- 新的计划范型。当您根据您所面临的风险变更您的策略时，风险将减少。因此风险驱动的里程碑需要适应的计划过程，计划通过它适应事实。记住
Eisenhower 的评论“Plans are worthless, but planning is
everything”。如果您不愿意接受演进的计划，那么基于风险的里程碑不适合您。
- 适应的过程。类似于适应的计划，您需要适应您的过程。如果您的过程过度的规范，那么它没有为团队提供它们成功所需的灵活性，特别是在图
3 中所示的 Innovation 阶段。更多的过程很少推动更多的变革。随后，在 Cost Efficient
阶段，您想要更严格的过程。
反模式
以下反模式与基于风险的里程碑相关联：
- 曲奇饼成形机过程。团队被迫按照不允许有反应所发现的风险的余地的详细的、规范的，且“可重复的”过程。
文档驱动的追踪。风险由某种形式的项目领导委员会确定、添加到风险列表，讨论，并且如果曾经由团队处理过，那么直到经过大量时间才完成。如果您能做的只有惋惜您没时间或预算来适当处理风险，或仅仅决定由于进度关系，您将推迟到下一个版本，那么确定风险没有好处。
- 详细的推测的计划。整个项目的详细计划及早的建立起来，并且将管理层集中于项目余下部分的，对于计划的追踪。
推荐的默认做法
我们建议使用 RUP 的 初始（Inception）、精化（Elaboration）、构建（Construction），以及精化（Elaboration
）里程碑，它们是定义明确的，且集中于风险减少。
修改过程
令开发过程 3 适应项目的需要是至关重要的。更多的过程较好，还是较少的过程较好不是要讨论的问题。相反，项目中存在的形式、精度和控制的数量必须根据各种因素
—— 包括团队的大小和分布、外部施加的约束条件的数量、项目所处阶段，以及项目审计度和可追踪力的需要 ——
进行裁减。
第一，我们相信更多的过程 —— 不论是否使用更多的工件、生成更详细的文档、开发和维护更多需要同步的模型，或者更正式的审查
—— 不一定是更好的。相反，您需要让过程适应项目需求。随着项目大小的增长，更加分布，使用更复杂的技术，拥有更多的项目涉众，以及需要遵守更严格的遵循标准，过程需要更架构化。但是对于较小的，拥有位于同一地点的团队，以及利用已知技术的项目，过程应该更流水化。
第二，项目应该让过程形式适应生命周期的阶段。项目的开始一般都伴有相当多的不确定性，并且您想要鼓励大量创造力来开发满足商业需要的应用程序。更多的过程一般减少创造力，因此您应该在项目的开始时（当不确定性是每天的因素时）用较少的过程。另一方面，在项目晚期，您常常想要引入更多控制，例如特性冻结或变更控制板，来去除与晚期引入的缺陷相关的非期望的创造力和风险。这解释为在项目的晚期使用更多的过程。
第三，组织应该争取不断地改进过程。在每个迭代的末尾，以及项目末尾进行评估，从而获得所学到的经验，并且利用那些知识改进过程。鼓励所有的团队成员不断地寻找改进的机会，并且向那些过程改进所涉及的组织提供那些改进，例如您公司的软件工程过程组（Software
Engineering and Process Group，SEPG）。为这些活动需要特别地分配资金和时间。
第四，您需要用项目的不确定性来平衡项目计划和相关的估值。这意味着在项目的早期，当不确定性一般相当高时，计划和相关的估值需要着重于全景计划和概要，而不是旨在提供，其中明显什么都不存在的五位数字的精确等级。早期的开发活动应该旨在去掉不确定性，并且按计划的精度逐渐的增加。
图 4：决定所需的过程规程数量的因素。许多因素 —— 项目大小、团队分布、技术复杂性、项目涉众数量、法规遵循需求、项目特殊阶段
—— 决定了您需要一个过程有多结构化。
好处
修改过程带来许多好处：
- 提高的生产力。适应项目需求的过程，相对于阻碍，可以通过为团队提供统一力量，并且通过产生更多的致力于生产的（对比开销）活动的工作成果，增加项目的生产力。它还可以通过提供模板、实例，和指导增加个别团队成员的生产力。
- 可重复的结果。可修改的过程允许团队适应项目的策略上的需要。这给了团队完成可重复的结果所需的支持和灵活性。然而，在许多情况下，可重复的结果需要过程中的某种法规遵循来满足策略上的需求，在此情况下“重复性”不能简单地指过程的
100% 同样的复制，而是过程阶段的重复性，每个阶段都通过一系列调节、结果，和度量进行下去。
- 及早的价值创造和风险减少。通过为项目的不确定性修改饼减少项目形式，进行变革。在项目早期可以创建更多价值，而且允许及早减少风险。
- 共享在团队和项目之间学习的经验。通过修改基于以前项目中的经验的过程，您可以有效地在团队间共享知识。
权衡
有许多与修改过程相关的重要权衡：
- 需要投资。修改过程需要知识投资，这样可以有效地修改和部署过程。
- 需要洞察。要正确地修改过程，组织需要足够的软件工程洞察力来了解是否应该采用的实践的环境，以及需要修改的内容的范围。
- 管理变化。允许团队修改过程，增加了治理项目的困难 —— 特别是，确保在一些项目中，使用了合适的最佳实践。这是因为团队将在不同的时间点生成不同详细级别的各种工作产品。
反模式
以下反模式与修改过程相关联：
- 更多过程是更好的。总是将更多过程、更多文档，和更多详细的预先计划视为更好的，包括坚持及早的估值，以及对那些估值的遵守。
- 一致且可重复的过程。不论什么，总是使用同样的过程。（事实上，目标应该是变化能够使每个项目成功。因此，总是使用同样的过程，并且在项目过程中同样数量的过程是导致失败的反模式。真正的目标是一致的和可重复的结果。）
- 特别的过程。您要么在进行下去时组成过程，要么也许您每次对过程进行如此大程度的修改，以至于从一个项目到下一个项目的过程是不可辨认的。（当没有定义过程时，没有可预测的结果，风险没有确定并减少，并且跨团队之间没有共享的经验。）
推荐的默认做法
我们推荐根据项目需求，利用 RUP 过程框架，以及定制的与众不同的交付过程。
持续的改进
软件开发是动态的，在软件开发中优先级、需求、有时候甚至是团队成员经常的变更。此外，软件开发是非常复杂的，因为它要处理一系列有时候冲突的问题。由于固有的动态和复杂性，您不可能在项目的开始时合理地预测您向下将如何工作的详情。您应该尝试，但如果您想要在软件开发中真正有效，那么您必须愿意在您有必要进行并变更策略时学习。
此实践背后的基本概念是简单的：在机会自己出现时，改进您工作的方式。古老的格言“每天你都应该学些新的东西”说的很好。但此实践更进一步，并推荐您按照您所学的内容行动，并提高您整个的效率。
在软件项目的执行过程中，存在许多您可以确定出对软件过程进行潜在改进的方式：
非正式的改进会议。在常规的基础上，召集您的团队，并且可能的话，召集您项目的重要项目关系人，并简单地让它们讨论什么将是正确的，什么将是错误的，以及改进您们合作方式的可能方法。
回顾
回顾 4 是一个简化的会议，在会议上要问四个问题：我们什么做得好，如果我们不讨论，可能会忘记？我们学到了什么？下次我们应该做什么不同的？什么仍旧使我们迷惑？可以在生命周期过程中随时举行的回顾的目标是确定可能要改进的区域。
- 员工意见箱。有时候确定可能的改进方式的最简单的方法是让人们以匿名的方式随时提供建议。“员工意见箱”可以是物理上的，虽然现在多半是以电子的方式实现的。
- 个人反省。要在员工中发扬的好习惯是让他们花些时间经常反省一下他们做得有多好，他们与他人交流得有多顺利，以及他们有多好地达到实际的目标。这种反省经常导致个人的改进策略，但还可能导致整个过程改进的建议。
- 可编辑的过程。向团队提供基本的过程，但还向他们提供权力和工具，例如
Wikis，在他们觉得适合的时候，编辑该过程。
好处
此实践有许多好处：
您在进行的过程中学习。团队可以马上利用新的见识，而不是等到下一个项目来试验改进。这更快地增加了生产力。当结合了上面介绍的实践“迭代开发”时特别有效，因为在一个迭代中学到的经验可以直接在下一个迭代中利用。
团队可以完全地控制它的命运。此实践有效地令团队能够进行自己的过程改进，并且令它们能够更容易地自组织。（下个月，在第
3 部分中，实践“自组织团队”将对此概念提供更多详细信息。）
权衡
有许多与此实践相关的权衡：
- 它需要投资。您需要从项目进度中拿出时间来投入到过程改进活动中。
- 您需要行动。如果您不实际地行动的话，就没希望确定出改进的机会。
- 您需要对自己说老实话。团队面临的许多问题将集中于个人和他们与其他人交互的方式上。参与项目的人需要感觉足够的安全来指出问题和可能的解决方案，即使解决方案可能不利于其他人想要运作的方式。
- 您可能需要过程的变更和配置管理。一些项目团队需要遵照法规，例如
ISO 900X 或 FDA 的 21 CFR Part 11，这要求要定义团队的过程，并且要求团队提供依照过程的证明。这含义是您可能需要追踪对您的过程进行的所有的变更，您为什么进行每个变更的原因，以及为了遵守这些法规，什么时候进行的变更。
反模式
以下是与软件过程改进相关的反模式：
- 指示的经验。许多项目团队确定出了一个“所学经验”的集合，但是没有人按照它们行动。直到您通过您已经“学到的”东西实际地改进软件过程时，您只是有一个“指示的经验”的集合。
- 推迟的改进。可能的过程改进常常在“项目事后”，在或接近项目的结尾时才确定出来。此处，项目团队按照任何所指示的经验行动就太晚了，并且如果团队成员将要分离到其他项目的其他团队中，那么将非常可能不采取任何重要的行动。
推荐的默认做法
我们推荐您在每个迭代的末尾投入两个小时，开一个非正式的过程改进会议或回顾。
嵌入的法规遵循
嵌入的法规遵循指的是遵循法规和公司政策及指导的概念在任何可能的地方都应该是自动的，并且当它不是一个选择时，它应该是您的文化和日常活动的一部分。法规遵循实现的越简单，IT
专业人员实际地遵守的机会就越大。但如果法规遵循需要大量的额外工作（特别是当做这件工作的人觉得工作繁重时），那么开发团队颠覆您的法规遵循工作的机会就更大。
法规遵循的许多“艰苦工作”可以通过工具来自动化。举例来说，Sarbanes-Oxley 法令（SOX）定义了金融数据应该如何保留、获取，和修改的严密指导。SOX
需要的大量追踪工作可以通过基于 IBM? Tivoli? 的产品，例如 Tivoli Access Manager
和 Tivoli Storage Manager 来自动化。同样地，Food and Drug Administration
指南，以及 Capability Maturity Model Integrated（CMMI）指南，需要维护从需求到测试案例到设计到代码的追溯能力。一组工具集，例如
IBM Rational RequisitePro?、IBM Rational Software Architect，和
IBM Rational ClearQuest?，通过集成需求定义、设计建模，和缺陷追踪功能，将大量追溯工作自动化。
当提到法规遵循时，总是需要人类的干预。当人们理解了法规遵循为什么重要时（包括底层的原则），它就可以成为您的文化中的一部分了。不是您的
IT 部门中的所有人都需要了解 SOX 的错综复杂的，但是他们应该了解，您的组织要能够展示出金融数字是如何生成的，以及不应该事后变更源数据。同样地，不是每个人都需要成为可用性专家，但是他们应该了解，一致性是很重要的，并且他们需要遵守组织的用户接口指南。通过教育将法规遵循嵌入您公司的文化中，通过这样做，进行支持活动，例如法规遵循审查，将容易得多，因为人们将出于自愿，把嵌入的法规遵循加入他们的日常工作中。
好处
嵌入的法规遵循有四个好处：
- 法规遵循的好处。法规遵循的通常好处很明显地表现出来，例如保证您的业务运行，进行销售的能力要求您遵从
ISO-900X、CMMI，等等。此外，大多数法规遵循工作将导致操作效率的提高。
- 较低的成本。通过将法规遵循嵌入到您的工具和过程中，您可以减少实现法规遵循的开销。法规遵循的手工方法，例如繁重的外部文档和详细的审查，证明在实践中是非常昂贵的，并且不是非常有效，因为人们常常叛离复杂的法规遵循工作。
减少项目团队的后退。大多数 IT 专业人员一般不受到官僚主义的震颤，更不用说由法规遵循需求引起的官僚主义。嵌入的法规遵循令人们尽可能容易地做正确的事情。
- 更高层的法规遵循。当把大多数，即使不是全部，法规遵循需求自动化时，项目团队将更可能遵守，并且它们将更可能生成所需的文档来证明。举例来说，要确保需求的追溯能力，如果您的版本控制系统要求提交工作产品的人指出它们在处理的需求或缺陷标识符，那么需求追溯能力会大大地提高：每次提交时十秒钟的操作可以省去项目结尾时几个星期的痛苦且易出错的工作。相反，当手工执行法规遵循时，一般会将此工作留到最后一刻，并且不认真的执行。
权衡
有许多与嵌入的法规遵循相关的权衡：
- 工具投资。您可能需要投资新的工具，将法规遵循工作尽可能多地自动化。您也许还发现您只需要开始使用现有工具集中以前未用的特性。最低限度，您需要做些调查、培训，和工具配置。
- 文化投资。您需要投资构建组织中的法规遵循文化。这包括培训和教育的投资，以及开发让人们参考的实用指南的投资。
将过程流水化。您需要着眼于当前的法规遵循过程，或法规遵循需要，并且决定如何将与法规遵循相关的任务的最小集嵌入到当前的软件开发过程中，从而能够实现法规遵循。这需要知识和投资。
反模式
以下反模式与法规遵循相关：
- 文档泛滥。对法规遵循的需要比对日常业务的需要的优先级更高，并且您的组织开始沉浸于不必要的文书工作。您的目标应该是将保持遵循所需的工作最小化，而更好的是，令法规遵循成为业务的推动者，而不是开销成本。
- 恐惧驱动的法规遵循。组织常常过度投入于它们的法规遵循解决方案中。大多数法规有很大的活动余地，常常公认的是，组织有需要不同的目标法规遵循等级的不同目的。普遍的错误是不让一线的工作人员参与法规遵循工作的确定，减少了确定出对于新的发令的实用方法的机会。
推荐的默认做法
根据适当法规的目的，定义集成到过程和工具中的最小的解决方案。要完成这些，分配恰当的人来解释您必须遵守的法规，并且创建开发团队要依据的指南。如果您分配了官僚主义者做这项工作，那么您将以官僚的解决方案告终，如果您分配“指挥控制”型的人做这项工作，那么您将以“指挥控制”的解决方案告终，而如果您分配实用的，知识渊博的人做这项工作，您将以实用的可使用的解决方案告终。
量度
此类别的实践促进有效的度量标准策略，通过支持目标和鼓励，促进有知识的执行的决策制定。这些实践是：
- Simple and relevant metrics（简单且相关的度量标准）
- Continuous project monitoring（持续的项目监控）
简单且相关的度量标准
度量是了解您如何做事所必要的，这样您就可以按照需要采取纠正行动。当使用度量标准时，有一些重要的规则：
- 度量标准需要简单。大多数组织要么根本不使用度量标准，意味着它们在盲目工作，要么做得过火。简单的度量标准，例如所花的钱数或者当前未解决的缺陷数，有两个关键的属性。第一，很容易收集度量标准，并且在理论上，度量标准的收集是自动化的，由于手工地收集度量标准常常是缓慢且容易出错的。第二，需要很容易理解并解释度量标准，这样当您看到有什么出错时，可以采取行动。
- 度量标准需要通用。度量标准需要在整个组织中普遍使用。如果每个项目都有其自己的度量标准集，以及它们自己对那些度量标准的解释，那么执行的监督将是不可能的。团队可以选择使用一些额外的与它们的项目相关的度量标准，而只要基本的、组织范围的度量还是最新的，那么这就可以。
- 度量标准需要是相关的。许多收集度量标准的组织很少根据结果采取行动。这常常是因为度量标准不是十分相关的。对于每个度量标准，您应该指定根据某个阀值应该采取什么行动。如果您不能指定要采取的行动，那么为什么要度量？此外，您应该拥有尽可能少的度量标准，因为您想要关注必要的，而不是观察和反应没那么必要的问题。
简单且相关的度量标准的好处
当做得对时，采用简单且相关的度量标准会带来许多好处：
- 基于事实的治理。从团队使用的开发和管理工具自动收集来的度量标准提供了关于手边情况的准确信息。自动的度量标准减少了通过手工和不正确的数据集相关度量的收集、分析，或管理的错误引入。自动的收集还可以比手工收集进行得更快且更频繁。以上所有内容导致了治理基于更准确且最新的数据，或者我们称作基于事实的治理。
- 无痛治理。自动的收集还减少了对时间消耗和昂贵的手工收集、分析和管理的需要。当您被迫进行手工的度量标准收集、分析和管理时，简单的度量标准减少了复杂性。这减少了与治理相关的成本和开销，或我们称为无痛治理。
- 先发制人的治理。当有些东西在您主要到之前的阶段出现错误时，相关的度量标准将使您足智多谋。举例来说，通过观察缺陷增长的趋势，您可以推断，您将会在下一个迭代的结尾交付低质量的构建，因此，您可以延迟该迭代的特性，从而确保您仍旧交付高质量的构建。比起事后被迫灭火，及早的探测问题为您提供了选择的自由。
- 过程改进。度量标准使您了解了什么有效而什么无效。它向您提供了进行关于什么出错了以及如何在未来避免问题的开放的讨论所需的信息。
权衡
在您收集度量标准时，要做出许多重要的权衡：
- 度量标准的数量。一旦您开始收集度量标准，可能会收集到许多不同的类型。这感觉更“严峻”了，谁知道呢，额外的度量标准可能实际上总有一天会派上用场。但我们强烈推荐您从最少数量的度量标准开始，然后只在需要时添加额外的度量标准。我们的推荐是少量度量标准，注意越少越好。随着新的度量标准的采用，就的度量标准应该抛弃，否则收集度量标准的复杂性和成本将增加，并且缩减了它们提供的价值的回报。如果您最近不使用某个度量标准，那么为什么您仍旧收集它呢？
- 妨碍计划的进行。收集度量标准也许会揭开组织中的人们宁愿隐藏的某些事实。没有度量标准，您实际上是盲目行事。设想您在一个项目中盲目行事十个月。这感觉轻松自在，您相信所有事情都正常进行。但在项目的结尾会发生什么，您看到这是命中注定的？您被迫去寻找原因
—— 也许甚至设想 —— 为什么早先项目不会成功。由于您没有供分析的度量标准，您会找借口，例如，“客户经常变更主意”
，“预料不到的技术问题” ，和“技术不兼容性”。另一方面，有了度量标准，您至少有在这些情况下什么出了错的客观观点，这最可能证明是一组东西
—— 包括需要在您的组织中解决的一些问题。
- 投资。度量标准不是免费的。如果您将它们自动化，那么就要预先投资。如果您采用手工的度量标准，那么预先投资就比较少，但后期投资较多。
- 偏差：项目有给定的要操作的某个参数集合，例如成本和质量。如果项目偏离了那些参数，或将要，您想要让手边的度量标准指出这样的偏离。
- 信任。当您将度量标准用于诚实的讨论，用于学习，及用于奖励人们时，它是无价的工具。当度量标准变得糟糕时，您不应该惩罚人，但您应该惩罚那些忽视糟糕的度量标准的人。
您仍旧需要与人交谈。度量标准有时候可能指示您有问题，但它决不会提供您做出好决策所需的所有信息。您仍旧需要时常与人谈话，从而了解根本原因。
反模式
以下是与度量标准相关的反模式：
基于文档的所获得的价值。在传统的治理方法中，当您完成关键的文档，例如需求规范或详细的设计文档时，您会估计“所获得价值”的确定百分比，并从此发展下去。实际上，大多数规范是有缺陷的
—— 直到您根据该规范实现并测试之后才能知道如何缺损的。传统的所获的价值因此给出了进展安全的错觉。对软件开发项目进展的唯一真正的度量是工作产品的定期交付。
没有行动的度量标准：收集度量标准，而在度量标准达到某个阀值时不采取行动是起相反作用的，因为您引发了度量标注收集的成本但没有获得利益。
推荐的默认做法
我们推荐从覆盖了软件开发项目的以下区域的度量标准开始：
- 价值：您需要一个度量来指示您为组织增加价值的程度。举例来说，基于团队自己内部的功能的度量的用例点，或某种其他形式的目速度，所交付的每个迭代指示出团队要实现的功能有多少。注意到，应该依据工作功能，而不是依据所交付的规范来说明价值。
- 质量：您需要指示应用程序质量的度量，例如缺陷趋势。
- 成本：您需要一个关于您消耗了什么资源的度量，例如花费的工作月（努力）或金钱。
这些度量标准不仅用于确定项目的当前状态，还可以用于确定团队已经从团队初始的期望值偏离了多远。在商业用例层，对于时间、花费，和资源的使用，进行期望值的设置，这些期望值可能在项目过程中定期的更新。
持续的项目监控
持续的项目监控确切的意思就像该术语所暗示的 —— 通过自动的度量标准的收集、项目审查，甚至口头表达，来常规地监控组织中
IT 项目的健康。许多组织在任意给定的时间都会有几十，有时候几百个 IT 项目在进行。每个项目都有其自己当前的状态，这些状态会在生命周期中变更。您可能拥有位于不同位置和时区的项目，并且您的组织中可能有许多软件过程。不管这些挑战，如果要有效的治理，每个项目都必须受到监控。此外，因为您想要对不利的变更和新兴的机会快速的做出反应，所有您希望持续的监控项目。
有许多可以组合的，用于连续监控项目的方法：
- 自动的度量。关于项目的度量标准是通过在项目过程中日常使用的现有工具的自动化方法获取的。利用项目计分卡软件将这些度量标准进行处理和显示，从而概括每个项目的可计量的状态。
- 项目审查。项目审查，包括里程碑审查，是在迭代模式或在其他管理里程碑处进行的定期审查。它确保交付了工作代码，满足了当前项目关系人的需求，以及项目是健康的。作为审查的副产品，应该确定要改进的部分，并且庆祝成功。
- “事后”审查。“事后”审查出现在项目的末尾，要么因为系统已经成功地交付为产品，要么项目已经取消。当项目已经成功时，审查的目标是评估是否实现了项目的设想，系统是否在正轨中，实现了其陈述的利益，以及项目涉众是否对项目进行的情况满意。当项目注定失败时，审查的目标是为团队成员提供机会来发泄他们的挫败感，并且充满希望地让他们继续前进，并且在理论上确定改进的部分，以便不会重复任何错误，不幸的是，在项目失败之后，这些目标似乎很少达到。
- 口头的交流。有时候，确定项目当前状态的最佳方法是听听人们将告诉您什么。要想发现项目是如何进行的？询问在该团队中工作的人。您的度量标准可能告诉您该项目发生了一些事情，但是直到您询问该团队，才能知道实际发生了什么。
自动的度量标准的方法使项目监控工作能够防缩，从而确定需要关注哪些项目。里程碑审查确保了价值的连续交付，而项目审查使您能够从整个经历中学习。
好处
对于持续的项目监控存在许多好处：
- 基于事实的治理。通过持续的监控项目，您可以将治理活动置于最新的，准确的事实基础之上。普遍的故障指示器包括与期望值的偏差，或者负面趋势，例如越来越多的缺陷。
- 更早的反馈。持续的监控提供更早的问题检测，这令您较早而不是较晚采取修正措施。这令您将项目步入正轨，如果必要，在您损失根基之前取消项目。
- 有效的治理。对正确的度量标准的监控（参见上面介绍的“简单且相关的度量标准”实践）推动对项目团队的正确行为，因为“您得到了您所度量的”（参见下面）。持续的监控推动着整个项目中的正确行为，不只是在里程碑处。
权衡
有许多与此实践相关的权衡：
- 您需要确定正确的度量标准。您将获得您所度量的 —— 意思是团队认为您要它们追踪的任何东西都像度量标准一样重要，而您可以确信，它们将关注那些要测量的东西。这个心理上的事实意思是您需要确保您度量的是正确的东西。度量投资、所交付的功能，和缺陷趋势真的是好的开始，因为您可以利用这些简单的度量标准来确定项目团队的效率。参见实践“简单且相关的度量标准”，了解更多关于此概念的详细信息。
- 您需要灵活。度量标准以及它们所揭示的趋势将在整个项目中发生相关性的变更。举例来说，在项目的
Elaboration 阶段，当您了解各种技术如何一起工作时，故障趋势率可能暂时增加，但在 Construction
末期和 Transition 的过程中，您可能期望故障趋势率平稳的下降。通过了解度量标准如何根据项目阶段进行变化，您更好地准备检测实际的异常情况。
- “警告标志”只是警告。每个项目都是不同的，并且每个项目团队都工作于动态的环境中。一些警告标志指示需要处理的长期难题，而一些标志指示不需要治理关注的短期困难。有时候，“有事情发生”，例如项目的项目涉众团体中的策略的变更，或者新法规的通过，这会将团队置于临时的麻烦中。
- 您需要投资于自动化。就眼前来说，您需要投资于工具，从而自动地收集您感兴趣的度量标准。
您仍旧需要与人交谈。度量标准只能提供警告标志，它们不能准确地指示团队面对的麻烦（或机会）类型，也不能提供帮助团队所需的信息。要有效地治理项目，您将必须积极地联系团队，并与他们密切合作。
反模式
以下反模式与项目监控相关：
- 根据度量标准管理。在没有恰当地了解根本原因的情况下，根据所报告的度量标准采取修正措施来修理故障。举例来说，假设在一个迭代后，团队的报告缺陷上升到
57%。这可能指示团队处于麻烦中，或者他们刚雇佣了一个真的很好的研究的测试人员，或者他们已经开始使用他们的缺陷追踪软件来管理需求和传统的缺陷报告（因而将他们的过程流水化并且提高了整体的生产力）。当在团队中讨论之后，举例来说，您知道是否应该推迟发布或照常继续。
- 度量标准泛滥。自动的度量标准收集的普遍问题是您收集了许多度量标准，因为太容易收集了。当然，您有许多数字可用，但是它们真正意味着什么，以及如何有效使用它们？拥有一些向您提供有价值信息的相关的度量标准远比拥有许多您不确定如何使用的度量标准
—— 似乎收集它们像是个好主意 —— 要重要。您的目标应该是质量胜过数量。
推荐的默认做法
我们建议您从依照实践“简单且相关的度量标准”开始，因为该实践将帮助您通过项目计分卡软件自动地获取并显示您的度量标准。当项目似乎要偏离其预期的路线时，您应该与项目团队成员谈谈，从而确定度量标准的意思是什么，以及团队如何执行得更好。
本系列文章最后的第 3 部分将介绍与精益软件开发治理相关的角色和职责，以及政策和标准。敬请查看！
注释
1.参见“Agile Best Practice: Initial High-Level Architecture
Modeling”，http://www.agilemodeling.com/essays/initialArchitectureModeling.htm
2.在 Dr. Dobb's Journal 的 2007 年 8 月刊中，Scott Ambler
概述了一个调查，它说明大多数敏捷开发团队的迭代长度在两到四周之间。
3.此部分源自 Agility and Discipline Made Easy -- Practices
from OpenUP and RUP，作者 Kroll 和 MacIsaac。
4.Norman L. Kerth。Project Retrospectives: A Handbook
for Team Reviews。Dorset House，2001 年。
| 
