讨论：从客户的角度衡量敏捷项目的成功

作者 Vikas Hazrati 译者 李剑 发布于 2008年2月13日

领域

过程 & 实践,

架构 & 设计

主题

客户及需求 ,

计划 ,

交付价值 ,

值和度量 ,

软件工匠 ,

敏捷

分享到

最近在Scrum Development用户组中发起了一场精彩的讨论：“客户该如何衡量敏捷项目的成功？”讨论重点放在了“衡量”二字上。看起来各方意见就“客户应该能够以他们自己的方式来衡量成功”这一点达成了一致，而且也得出了一些衡量标准。但没有最好的方式，只有最适合具体情况和客户的方式。

传统软件开发方法论中包括多种矩阵：质量矩阵，如每个发布的缺陷率；计划矩阵，如实际的工作量/天数与估算工作量/天数之比，又如交付里程碑的完成情况；还有成本矩阵，如预算与实际成本之比。

但是，绝大多数敏捷开发组织在收集和上报衡量标准相关数据的能力上表现薄弱，并因此而为人所诟病。他们确实有一些技术开发衡量标准，例如checkstyle（译者注：一个Java程序源代码风格检查工具）发现的错误，测试代码覆盖率，NCSS（译者注：一款分析统计软件）等等，这些标准对客户而言却没有太大的吸引力。

以客户的角度来衡量项目成功至关重要，因为纵使开发团队遵守正确的流程，最终结果也未必是客户想要的。可能会南辕北辙。

Mike Dwyer说道：

你这个问题跟外科医生的问题一样：如果我遵守所有的步骤行事，之后病人的生死便与我无关，这种情况下我算是称职吗？我的回答是，你的目标是什么？一个康复的病人还是成功的过程？

在这种情况下，如果最终结果跟我们理智上的期望相同，病人痊愈了。这时我们就可以称之为一个拥有成功过程的成功项目。

Vikrama Dhiman提供了另一个例子：

我的项目可能是打算造起1000层的高楼，我希望把它卖给联合国——团队自组织的非常好，他们也帮我及时意识到自己的远景目标——但联合国不打算买下它，我也不想把它卖给其他人。这个项目是成功的吗？我也许会说是。那这个最终产品是成功的吗？我会说不。那是谁的错？理所当然是产品负责人（Product Owner）的问题。

这里，团队可能正确地遵守了所有的过程，但却可能造出错误的产品。产品负责人应该被指责吗？是的。团队应该被指责吗？是的。客户满意吗？当然不。

那么有没有办法可以让客户衡量一个敏捷项目的成功与否？正如上面几位所述，这个问题的答案与展示一个伟大的过程毫无关联。

有几个人建议说，如果客户满意的话，那他就会认为这个项目是成功的。但“满意度”却很难量化和衡量。在Agile India用户组中也有一个类似的讨论，在该组的讨论中得出了几个比较主观的衡量标准用来衡量客户满意度。如果以下情况满足的话，那客户就是满意的：

• 他得到了项目预期的商业价值。

• 他能够根据商业需要来调整路线，所发布的功能在发布的那一时刻更有价值。

• 他能够给出早期反馈。

• 他能够为特性/故事制定优先级，从而在恰当的时刻得到恰当的功能。

• 他能够在所有的功能被实现完以前终止开发，因为他意识到剩下的功能可能永远都用不到。

• 他与开发团队之间建立了双向的信任关系。

• 他在项目过程中没有碰到出乎意料的事情。

• 他觉得在项目上的投资物有所值。

也有其他几个人认为，在团队启动项目之前，有一个对于完成的定义是很重要的。客户和团队应该能够对一个故事的完成达成一致。一旦团队决定了如何才算“完成”，那么就可以由此来衡量客户满意度和使用其他几个矩阵了。

Mike Dwyer补充说：

有一个对于完成的简单定义：到sprint结束时，团队的工作被客户验收通过，这部分工作就完成了。在这一点上，所有的工作和相关成本就从浪费变成了价值。这就回答了这几个问题：“从计划上来看我们走了多远？（产品backlog——累计验收的工作）”和“从预算角度来看，我们目前干得怎么样？（完整计划预算——实际成本）”。它同样还回答了这些问题：“我们的效率如何？（全部实际成本/已完成任务的计划成本）”和“我们的资金消耗率[译者注：burn rate，一家新公司在赚取营运现金流前消耗创业资金支付日常开支的比率]怎么样？（每个验收或是已完成任务的平均成本）”。

Scott Ambler认为应该使用主观衡量标准和客观衡量标准的组合。他建议团队应该先开始收集一些基本信息，例如： 

1. 实际成本（时间，金钱，等等）
2. 一些交付的功能（用例点，用户故事点，等等）
3. 缺陷趋势
4. 相关干系人满意度
   

通过这种方式，团队就可以用业务词汇（最基本的就是花销和系统能力）跟业务人员沟通，同时还是继续跟踪那些关系到开发成败的衡量标准——如质量。度量相关干系人的满意度也是最重要的衡量标准之一，无论是不是敏捷团队都应该把它引入项目。交付的代码没有缺陷，不一定就意味着交付的软件具备价值。

这里既有主观标准，譬如客户满意度、客户看法；也有客观标准，如已完成的故事、成本、缺陷趋势，它们组合起来帮助客户判断一个敏捷项目的成功与否。

这个讨论看上去在“遵守正确的流程不是最重要的”这个观点上形成了共识。在流程以外，还需要有主观和客观的检查，用以确保项目会走向成功，客户会满意。开发团队需要根据给定的场景来进行选择：是任取其一，还是兼容并蓄？关键是怎样做能够收到最佳成效。

译者 李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！