敏捷开发大家都在讲：起不起效冷暖自知。作者有个亲戚在一家保险公司当 CEO，买了个敏捷开发的银弹，效果出人意料的不如人意。这位 CEO 说到：
这不是扯淡嘛！我们整个流程全变了。还花钱请了咨询师。请了一群高级产品经理。钱全扔水里了！连个管事的都没有。全是借口！
作者是这样解释的：
- 流程效率
先看看前置时间（lead time）：从产生想法到交付顾客的时间。画个图出来，很明显大部分时间都浪费在等待上了：15% 的流程效率（工作时间 / 前置时间）都不算低。好的公司可以达到 40% 的流程效率：很明显，想解决速度问题，应该从增高流程效率入手。
2. 拍脑门和多任务处理
开发团队会浪费很多时间在没有规划的任务和任务切换上，有可能高达开发时间的 75%。这些时间一般不会列入工单系统，无从跟踪。团队里人人都抱怨：但是没人着手处理。如果这个团队一边维护一边开发，这种瓶颈会一下凸显出来。
怎么办？所有没有规划的工作都要记录来源；量化多任务处理的影响。除非预先设计好，不让团队进行多任务。
3. S、M 和 L
按任务大小记录完成时间，和为用户产生的价值进行对比：你会发现任务大小和为用户产生的价值并没有什么关系。为什么？因为影响任务时间的因素很复杂：例如依赖、没有规划的任务、积攒的任务量等等。
4. 效益实现
我们都想降低“发布风险”：如果软件发布是一手交钱一手交货的一锤子买卖这样想无可厚非，但是在 SaaS 的环境下，不是软件发布就可以立即有钱进账的。作者将这种风险称为“效益风险”。
为什么很多大企业采用敏捷开发后没有效果？因为他们没有做到 1）做出正确的产品决定 2）专注于效益实现。敏捷的核心在于降低风险：在项目中，风险来自于软件有可能不能按时保质保量发布；在产品中，风险来自软件有可能不好用。所以按功能计算风险是错误的：应该按效益计算。
很多公司用左边图的模型计算风险：如果结果不尽如人意，他们会投放更多的资源进去，最终闹个大红脸。
5. 复杂性不可控
软件的复杂性必须得到控制：该削减削减、该重构重构、该自动化自动化。很多人都忘记了：即使是同样的团队完成同样的功能，需要的时间还是会随着软件的复杂性增加。一开始只需要 3 天就能写完的功能，几年后有可能需要一个半月。
敏捷开发
回过头来说敏捷开发的问题。除非敏捷开发是持续提升的催化剂，否则敏捷无意义。 Scrum 和规模化敏捷框架也是如此。敏捷不是每天开个会、写写用户故事、每半个月演示一下就成了。
想让你的敏捷开发真正起效吗？你需要在这些地方投入资金和精力：
- 做真正创造效益的工作。减轻工作量。
- 使用自动化工具、部署管线、Feature flags 等 DevOps 工具
- 改变管理文化
- 改变拨款方式：尽可能使用增量式按进度计划的拨款方式，而不是按项目拨款
- 减少软件复杂度，定期进行代码重构和架构的重新规划
- 按价值流程图进行工作，将公司按服务规划
- 尽可能不一心多用
没有银弹：必须自己摸着石头过河。如果谁不同意，参见上一句。
查看英文原文： Why Isn’t Agile Working?
感谢郭蕾对本文的审校。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论