为什么要敏捷开发？

为什么要敏捷开发？ —– 提高开发效率？

在一个知名的互联网公司的一朋友找我喝茶想聊聊敏捷，因为他们想搞敏捷转型，上来想知道怎么转，因为也听说很多敏捷型转型失败的。失败的原因当然各不相同，但想转型成功还是有一些规律可循的，第一个规律就是正确地选择敏捷开发。
所谓“正确”地选择，就是选择敏捷开发的“目的”是对的，也就是说对敏捷开发能解决的问题的期望是敏捷开发能够解决。如果敏捷转型的动机不对，肯定会“失败”，但失败为什么还要加引号？因为即使转型成功了也不能解决原来期望解决的问题，当然认为就是失败了。很多企业想转型敏捷开发的原因是“开发人员的效率低下，这么多人还完不成老板要开发的功能和速度”。这个朋友说他们也是出于这个目的转转型，想提高开发人员的效率，更快地更多地开发出功能。
我当时就给这个朋友泼了凉水，因为敏捷开发不是用来解决所谓的“开发效率”问题的，如果真是开发效率可以从人的技能培养、流程优化、工具改进等方面来提升，而跟敏捷开发本身没太大关系，敏捷反而会降低所谓的效率。因为这里的“效率”被理解为相同的人，在更短的时间内开发完成既定的功能，或者在相同的时间内能够开发更多的功能。因为客观地讲敏捷开发本身会降低效率，原因主要有：
1）敏捷开发中更加强调沟通，沟通频率可能比以前更高，沟通时间可能会比以前更长，占用更多的个人工作时间，反而可能因此导致实际开发时间起过原来开发出某个功能的时间；
2）敏捷开发是从用户视图出发,切分工作任务是纵向下刀，与原来分层设计，分层开发的职能划分方式不同，可能会要求工程师成为所谓“全栈工程师”，而传统的开发方式，一般会彩横向下刀的任务切分模型，人员的任务分配方式的不同，必然要求人员技能结构的调整，会增加一定量的学习成本，使开发人员反而感觉工作量增加了，短时间内会表现出开发效率的下降，而且要求所有开发人员对需求的理解能力也要求更高了，所以很多人会感觉敏捷开发对人员的要求更高，其实是因为对人员要求的改变导致现有开发人员能力木桶效应现象发生。
3）快速的迭代使重构工作量增加，会感觉功能不断被修改导致了很多浪费。这种感觉如果不能正确认识，不仅会误以为影响了工作效率，而且会使程序员很受伤，因为他们认为是在不停地返工。
4）信息的透明性要求较多的数据收集，敏捷成熟度越高，收集的信息就越多，收集这些数据会占用一定的精力，如果不能够正确的理解这些数据的价值，会让程序员感觉浪费了很多时间在做无用功，反而降低了开发效率。
那么，敏捷开发是解决什么问题的呢？它时解决企业效益（ROI，投资回报率）最大化的问题，评价敏捷开发的成功与否要从转型后企业效益的整体提升情况评价，而不能单单从主观判断上看开发人员完成的功能数量与速度来评价，敏捷开发主要从以下方面来帮助企业提升整体效益：
1）拥抱变化。因为长期的计划很难制定得可行，“人月神话”只是个神话，在计划执行过程中世界的变化会导致需求的变化，需求的变化必然导致开发工作不能按计划进行，而且“人”作为开发过程中最重要的因素时时刻刻都在变化，人员会有更替，人会有情绪，人会有私事，各种因素都会影响计划的执行，所以计划要短，及时调整才能响应一切变化导致的计划的不可行性，避免走弯路。
2）快速响应。市场环境的变化，越来越要求产品、服务的响应及时。比如按照传统方式，规划半年一个版本，一旦需要调整需求，后面所有的计划都得改变，会为项目管理带来极大的挑战，变化的成本奇高，多数情况下会因为多数人的反对而不了了之。
3）快速将功能推向市场变现。“成为第一，胜过做得最好”，在很多商业环境下是有效的，特别是在互联网行业，迅速占领市场更显得尤其重要，这是在向时间要效益。举个简单的例子，比如一个应用做个用户系统，其实非常简单成熟的技术，按照程序员的想法，最好是能够一次性把用户注册登录、修改密码、忘记密码、记住密码、登录验证码、注销等功能设计完，假设按照分层设计开发的方法花12个工作日，每个功能需要2天，而如果按功能逐版本开发而不是一次开发完成，而是放在不同的版本里，可能需要18个工作日，每个功能需要3天，因为里面会有重构、修改界面等，但是应用可以在第3天就上线，以后再逐步完成其它功能。有哪个系统因为没有验证码在上线后第3天就就被恶意注册？有几个用户会在6天后就忘记密码？有几个人会在9天后就修改密码？有几个人会因为登录频繁因为没有记住密码功能而不在使用？有几个人会在退出应用时点击“注销”按钮？WEB应用直接关掉浏览器，APP直接退出应用而已。如果一次性完成需要第18天才能上线，如果有了注册登录就上线可以在第3天就上线，争取了15天上市时间，而算算以后15天会对一个公司的影响，再相比增加的那点工作量，快速推向市场显得更加值得。讲到这里，那位朋友想起他们在上一个版本中的一个功能，如果这个功能按照敏捷的方式开发，可以早3个月推向市场，每个月有上千万的收（上线后的效果统计数据），这才是敏捷真正的价值所在。
4）在有限的资源条件下，做最值得做的事。因为Backlog的每一项都具有按唯一优先级顺序，都是已经排好序了，敏捷要求逐项完成用户故事，而不是全面开花，因为其评价结果是二值的，做完就是1，做不完就是0，没有75%一说，因为做完了才能交付，做完了才能投向市场变现。什么事最值得做，什么事就优先级最高，也就是ROI最高，ROI是评价需求优先级的唯一指标。其实ROI是一个综合指标，非常复杂的综合指标，它与开发工作量、市场需求迫切程度、技术关联性、市场价值等因素有关，需要全方位评估。
其实，敏捷转型，还是进行企业蜕变的工具。公司发展到一定阶段，人员结构，组织架构都会制约企业的发展，而进行细微的，局部的调整并不能解决企业的根本问题，改改革总是存在重重压力，新的制度总是执行不下去。趁着传统向敏捷的转型，可以系统地对组织进行优化。
所以，敏捷开发不是用来管理开发人员的，不是用来提高开发人员的工作效率的，而是企业全面提升团队绩效的方法，要向敏捷转型不是说光开发人员参与就行了，需要组织的全面变革，都需要哪些变革，下次再讨论。