转载

Re：如何让你的敏捷开发真正起效

敏捷开发大家都在讲：起不起效冷暖自知。作者有个亲戚在一家保险公司当CEO，买了个敏捷开发的银弹，效果出人意料的不如人意。这位CEO说到：

这不是扯淡嘛！我们整个流程全变了。还花钱请了咨询师。请了一群高级产品经理。钱全扔水里了！连个管事的都没有。全是借口！

作者是这样解释的：

流程效率

先看看前置时间（lead time）：从产生想法到交付顾客的时间。画个图出来，很明显大部分时间都浪费在等待上了：15%的流程效率（工作时间/前置时间）都不算低。好的公司可以达到40%的流程效率：很明显，想解决速度问题，应该从增高流程效率入手。
拍脑门和多任务处理

开发团队会浪费很多时间在没有规划的任务和任务切换上，有可能高达开发时间的75%。这些时间一般不会列入工单系统，无从跟踪。团队里人人都抱怨：但是没人着手处理。如果这个团队一边维护一边开发，这种瓶颈会一下凸显出来。

怎么办？所有没有规划的工作都要记录来源；量化多任务处理的影响。除非预先设计好，不让团队进行多任务。
S、M和L

按任务大小记录完成时间，和为用户产生的价值进行对比：你会发现任务大小和为用户产生的价值并没有什么关系。为什么？因为影响任务时间的因素很复杂：例如依赖、没有规划的任务、积攒的任务量等等。
效益实现

我们都想降低“发布风险”：如果软件发布是一手交钱一手交货的一锤子买卖这样想无可厚非，但是在SaaS的环境下，不是软件发布就可以立即有钱进账的。作者将这种风险称为“效益风险”。

为什么很多大企业采用敏捷开发后没有效果？因为他们没有做到 1）做出正确的产品决定 2）专注于效益实现。敏捷的核心在于降低风险：在项目中，风险来自于软件有可能不能按时保质保量发布；在产品中，风险来自软件有可能不好用。所以 按功能计算风险是错误的：应该按效益计算 。

很多公司用左边图的模型计算风险：如果结果不尽如人意，他们会投放更多的资源进去，最终闹个大红脸。
复杂性不可控

软件的复杂性必须得到控制：该削减削减、该重构重构、该自动化自动化。很多人都忘记了：即使是同样的团队完成同样的功能，需要的时间还是会随着软件的复杂性增加。一开始只需要3天就能写完的功能，几年后有可能需要一个半月。