什么叫敏捷开发？
软件开发是一种对人类智慧的管理，对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元，这与冰冷的机器是不可比的，所以在中国的历史上，管理人是最难的工作；“学而优则仕”的观点就是让最聪明的人应该选出来做官，做官就是管理人的。软件开发不仅是代码编程，而是人员的有效组织，如何既发挥人的主观能动性，避免情绪变化对工作的影响，又可以让大家有效的交流，让多个大脑的思路统一，快速完成目标呢？多年来软件企业的管理者一直在不断地探索。 另外，有一个问题一直是软件开发管理人员的心病：软件是工具，开发的是客户业务的应用，但客户不了解软件，开发者不了解业务，如何有效沟通是软件质量的重大障碍。把开发者变成客户业务的专家是个没有办法的办法，让软件企业付出的代价也是昂贵的。 瀑布模型、敏捷开发是有代表性的开发模式，在对开发者、客户、最终的产品的关注上的变化，体现了软件开发管理者在管理模式上的变化。
瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型软件开发分为：分析与编程，象工厂流水线一样把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路，所以成为软件开发企业使用最多的开发模型。
瀑布模型的特点： 1、强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好 象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。 2、没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应，瀑布就意味着没有回头路。 3、管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。 瀑布模型的用户很多，也有一些反对的意见： 第一 瀑布模型不适合客户需求不断变化的软件开发，尤其是客户的业务管理的软件，业务随着市场变化，而软件初期的设计可能已经大大变化，而后期的需求更改成本是开始的10倍基数。在ERP盛行的软件市场里，一方面市场带动需求变化，另一方面初期客户对需求描述不清楚，都为瀑布模型的使用团队带来困难。 第二 瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣，工作很枯燥，没有激情，编程成了一种没有创意的机械劳动，这让一向以高科技为标志的高级程序人员大为恼火。 在这种背景下，敏捷开发带来了新鲜的空气！
那什么叫敏捷开发呢？简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
敏捷开发宣言： 1. 个体和交互胜过过程和工具 2. 可工作的软件胜过面面俱到的文档 3. 客户协作胜过合同谈判 4. 响应变化胜过遵循计划 从上面的宣言可以看出，敏捷开发的核心是人 、协作、时刻可运行的软件、变化。
为什么要敏捷开发？ —– 提高开发效率？
在一个知名的互联网公司的一朋友找我喝茶想聊聊敏捷，因为他们想搞敏捷转型，上来想知道怎么转，因为也听说很多敏捷型转型失败的。失败的原因当然各不相同，但想转型成功还是有一些规律可循的，第一个规律就是正确地选择敏捷开发。 所谓“正确”地选择，就是选择敏捷开发的“目的”是对的，也就是说对敏捷开发能解决的问题的期望是敏捷开发能够解决。如果敏捷转型的动机不对，肯定会“失败”，但失败为什么还要加引号？因为即使转型成功了也不能解决原来期望解决的问题，当然认为就是失败了。很多企业想转型敏捷开发的原因是“开发人员的效率低下，这么多人还完不成老板要开发的功能和速度”。这个朋友说他们也是出于这个目的转转型，想提高开发人员的效率，更快地更多地开发出功能。 我当时就给这个朋友泼了凉水，因为敏捷开发不是用来解决所谓的“开发效率”问题的，如果真是开发效率可以从人的技能培养、流程优化、工具改进等方面来提升，而跟敏捷开发本身没太大关系，敏捷反而会降低所谓的效率。因为这里的“效率”被理解为相同的人，在更短的时间内开发完成既定的功能，或者在相同的时间内能够开发更多的功能。因为客观地讲敏捷开发本身会降低效率，原因主要有： 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是一个综合指标，非常复杂的综合指标，它与开发工作量、市场需求迫切程度、技术关联性、市场价值等因素有关，需要全方位评估。 其实，敏捷转型，还是进行企业蜕变的工具。公司发展到一定阶段，人员结构，组织架构都会制约企业的发展，而进行细微的，局部的调整并不能解决企业的根本问题，改改革总是存在重重压力，新的制度总是执行不下去。趁着传统向敏捷的转型，可以系统地对组织进行优化。
