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