主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷

平衡积分法的核心就在于精确量化，这恰恰是软件开发无法做到的，你的例子恰恰说明是不可量化的，所以使用一些虚拟的量化指标来代替。过于追求量化的考核指标，最后往往得不尝试。如果软件能够真正意义上解决量化问题，那么也就意味着有了真正的银弹。这个问题两年前我在这和人讨论过。软件其实是人的思维方式和社会活动的一种延续，在这方面基础科学没有大的进步之前，是很难有什么真正解决方案的。软件开发过程的难点基本都集中在需求的二义理解和开发过程的不可量化准备评估上。

我曾经和一个主管销售多年后来转去管理软件开发的资深老总谈过这个问题，他认为软件团队和销售团队管理最大的差别就在这个上面，销售团队的工作是可以量化的，但是软件团队很难做到精确量化，刻意追求这种量化过程，最后往往都以失败告终，因为付出的管理成本及其高昂，但是得不偿失。

前几年的cmm就是对这种量化过程的一种极致表现，而现在流行的agile则是一种反之，即把软件开发更多的放在需求和沟通上，淡化量化和随之的管理问题。

而比较现实的是，这几十年随着信息技术的大规模普及，软件的使用环境发生了巨大的变化，体现在需求的复杂度和可变度都大幅度提高了，传统的软件工程和重量模型根本无法刚上这种变化，相对于管理科学的进步来说，这种变化要快的多。这迫使我们改变工作方式，接受这种变化。

在死亡之旅的第一版里，作者建议对于死亡项目的处理就是辞职闪人完事，而到了第二版，作者说，现在不可避免的，大部分项目都存在严重的资源，进度，需求问题，所有的项目都是死亡项目，回避已经不再可能，必须寻找新的出路，这也是agile的起源。

如果继续抱定可以精确量化软件开发过程的态度来谈论scrum，那么就是背道而驰了。

但是现实中，管理层从自身利益出发，都不可避免的试图尝试这个精确量化的过程，但是很遗憾，至今没有真正意义上大规模成功过的案例。