成本会计是分析项目货币价值的标准会计方法，它将项目的各部分分别对待并且鼓励进行局部优化。成本的局部优化意味着强调完成任务的时间，而使任务完成时间最小化的关注就意味着你没时间进行重构和其它完善工作，因为这类工作太浪费时间了。这就是“万源之源”，就是不做这些事的常见理由，即“老板没有给我足够的时间做这些事”。
Henrik Mårtensson在其博客中提到了约束理论（Theory of Constraints）， 并说明产量会计（throughput accounting）是如何营造一个可以接受敏捷开发实践的环境的。他通过一个假想的例子来告诉我们：
假如有两个项目团队，A 团队和 B 团队。每个团队都一个项目经理，四个开发人员和三个测试人员。每个团队成员的薪水是€3,500/ 月，工作时间是 160 小时 / 月。项目经理的薪水是€4,000/ 月。两个团队的生产率都是 80 个故事点 / 星期。在团队 A 中，开发人员都在拼命工作，但测试人员却有很多空闲时间，时常上网冲浪。在团队 B 中，却是另一种景象。测试人员刚好跟上开发步伐，所以开发人员降低了开发速度以免测试人员处理不完。在某一天，两个团队都发现了一个缺陷。这两个缺陷都需要一个开发人员花八小时来修复。那么，团队 A 和团队 B 的成本各是多少呢？
这是给读者的一个思考题：“发现一个缺陷时会怎样？”成本会计告诉我们，这两个团队修复这个缺陷的成本是一样多的。但是多想一会儿，你就会发现这其实只是一个假象：
在团队 A 中，一个开发者去修复这个缺陷时，会直接影响整个团队的生产率。而在团队 B 中，开发者有一定的空闲时间。他们能修复这个缺陷却不受太大影响，在整个团队生产率上可能根本没有什么影响。即使不详细说明，结果也很明显，对两个团队的影响是完成不同的。
那么，问题在哪？关键在于成本会计强调的是局部最优，而实际上我们需要全局最优。利用成本会计，我们营造了一种环境，在该环境下，我们不鼓励任何延长局部周期时间的行为。
简而言之，假如你把软件开发项目的每个组成部分都看作是与其它部分相互独立的部分，那么关注任务完成时间就变成非常重要的了。假如你关注任务完成时间，你就不会在一些琐事上浪费时间，例如重构、写单元测试，以及进行领域设计。就算你想做这些事，管理者也会督促你开始新的任务。
看看“约束理论”和精益生产（Lean Manufacturing）也没什么新鲜的：David J. Anderson写了一本书，名为《软件工程的敏捷管理（Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results）》，而Mary 和 Tom Poppendieck因其在精益软件开发方面的工作而闻名。随着这个社区的成长，我们将看到从这两个领域产生的新观念变成主流，而它们的术语也会变得像“站立会议”和“结对编程”一样普遍。
注册/登录 InfoQ 发表评论