敏捷开发的目的不是为了快速交付!

它是一种用来应付需求快速变化的软件开发方法。
– Wikihtml

》许多IT主管或是工程师，都把敏捷开发误觉得是一种快速交付的方法，就由于它比传统开发方法快一些，固然；还有它叫作「敏捷」的缘故。所以咱们经常听到主管们在会议上抱怨:「不是已经在RUN敏捷开发法了吗，为何开发速度仍是那么慢呢?」
.api

「敏捷」二字的误导

这一篇文章的目的不在回答上面那个说来话长，必须用听诊器仔细推敲才能回答的问题，而只是想修正一下你们对「敏捷」这二个字的误解。敏捷二字实际上是针对需求变化的快速反应而来，而不是过去所谓的 RAD 快速应用程序开发法(附注1)。下面的说明则是在解释敏捷开发为什么会比传统开发方法快的缘由。
.微信

透过游戏来作说明

敏捷开发不是一种快速的开发方法，为了解释这件事敏捷课程的讲师们常常会在课程里依靠游戏的方式来做说明(这是效果最好的一种方式，你们玩上一回便知道前置时间所形成的浪费之处了)，但时间不够的时候，则会改为放影片的形式。请欣赏上课时咱们常常会放的一段翻铜板游戏(Coin Flip Game: https://www.youtube.com/watch?v=HW2DEZLRAhw)。app

放这段影片的目的在导正你们对敏捷的误解。尤为是给高阶的主管知道 – 敏捷开发不是一种为了快速交付而出现的方法，它之因此比较快则是由于避开了许多浪费的处理方式。下面这一张图是为了更容易做说明而画的，但愿能解决困扰。
.运维

透过图示的方式做说明

上面这一张传统vs敏捷的开发流程图示，强调四个实施敏捷开发时为什么会快于传统开发流程的地方:
.wordpress

※ 前置时间

传统开发法依循计划、分析、设计、程序开发、测试再进行修改整合后发布的步骤进行，是一种顺序性的开发模式，也就是说当前一个步骤还没完成以前，后面的步骤就会位在等待的行列，当前一个步骤用掉越多时间时则后面步骤的前置时间就会越长，而造成时间上越多的浪费。也就是说传统开发浪费了太多的时间，在前置做业上的意思。前置时间形成了一种没有充分运用资源的现象，当进行到分析或设计的步骤时，程序设计人员仍然处于等待的状态，所以造成了时间的浪费。
反观敏捷开发，实行的是一种务实的作法，例如:在进行需求搜集的步骤时，当收集到足够一次迭代开发的需求时即向下一个步骤前进，尽可能缩短前置时间的浪费，而后将”分析、设计、开发与测试“造成一个开发步骤，减小了步骤与步骤之间的衔接时间，这种开发方式造成了一种所谓的「衍生式的设计」，也就是遇到实质上的问题时才采用设计方法来克服它，而不是预先做好设计的方式。所以让起步显得轻量化了，再加上只有少少的规范，因此敏捷才有了轻量化的开发方法的称谓。测试

(在铜板游戏中，咱们一般会用一张A4的纸张做为前置时间的限制，要求学员把10或20个铜板放上去，游戏进行时只有在全部在纸张上的铜板都彻底翻转过以后才能传递给下一位，造成后面的学员空等待的时间，也就是前置时间的浪费。在铜板游戏中，咱们一般会分红三次来进行游戏，第一次采用 A4的纸张，表明最大的前置时间，接着将A4纸张撕成四等分，也就是采用四分之一的前置时间大小的纸张，最后一回则彻底拿掉纸张，也就是极小化前置时间的限制，目的在让学员更容易意识到速度上的差别)
.优化

※ 首次发布的时间

敏捷开发采用迭代的开发方式，每一个循环都会有一个潜在能够进行发布的小增量用来展现开发的成果，透过这种展现给了咱们要求客户在看完以后给予回馈以便进行改善的机会，这种让客户体会开发成果的做法同时也给予了客户决定开发方向的绝对主权(客户能够在看到需求如何被达成，而后评估产品的堪用程度，是否已经达到提早上线的水平，也就是产品足以提早交付了吗?)。
一般这个展现时间会设定在 1到 4个星期以内，所以客户几乎能够预期在这段时间以后能够看到预期的开发成果。这与传统开发只在产品完成后才作一次发布的方式，客户只有在这个时候才看获得成果，在开发过程当中彻底没有改善的机会。这种迭代展现的形式，给予了客户提早验收的机会，也给予了开发团队天然提早完工的机会。
.设计

※ 数据需求

敏捷开发不做完整的需求分析(由于计划老是赶不上变化的)，当需求的搜集量及质量，已经足够一个开发周期的工做量时就能够开工了。这即是敏捷开发著名的「需求够二个星期的工做量了，能够开干了!」，一种尽快开工不浪费时间去等待需求所有收集完整的开发模式。(需求的质量，就是所谓的 Definition Of Ready: DOR，它才是决定开发速度的决定性因素)
.code

※ 测试方法

敏捷开发对软件带来的最大影响即是测试了。传统的α(内部测试，注2)、β(交付客户测试)、γ测试(优化处理)方式在采用敏捷开发后几乎不存在了，由于敏捷开发在开发周期内即不断的在进行测试的动做，所以也就没有了在交付作α、β、γ测试时必须停下开发做业来，冻结程序开发的时间浪费了。
走了近二十年的敏捷开发，有二个明显的趋势成为了敏捷团队的持续研究重点，一个就是测试，也就是从头至尾都要测试。另外一个则是组织上头的完全改变，这个较难，由于观念要变。有空再来聊一聊.
.

小结

这是观念的问题，当你知道敏捷开发是针对需求变化的快速反应而来之后，便容易意会到为何它会花费那么多的功夫在处理需求的变化了。例如Scrum 目前很流行的 Refinement会议，为何它每周都要召开一次呢，有必要吗?是否是太浪费时间了呢?其实，它的目的正是在应付随着时间而善于改变的需求变化罢了。

若是想要加速开发的时间，则前提是把需求弄好，拥有好的需求质量，当需求越能抽象的解题(注意不是明确的解题，一旦太明确化就失去变化的能力了)，抽象解题提供了巨观上的 Big Picture, 让咱们可以看见全貌，而后据此拟定正确的开发方向，方向对了返工(rework)的次数天然变少，减小了在返工时所浪费的时间，减小了浪费的时间开发做业也就天然地变快起来了。

》为什么要抽象化呢? 由于抽象时比较能包容那些属于不肯定的因素，也就是将来还没发生的事情，他能够减小咱们提早作决策时的方向误差。而敏捷开发对抽象化最大的贡献大概就是采用使用者故事(User Story )来描述需求了，它实现了咱们用抽象化来作快速解题的能力。若是你还没有或是正准备进入敏捷开发的领域，记得从需求开始，而需求的撰写请不要忘了采用使用者故事。
.
》若是必定要把敏捷开发说成是一种快速的开发方法的话，则应该要正名成〝一种快速处理需求变化的方法〞。是的；用来处理改变需求它就变得快得不得了了。缘由是它在迭代中采用了使用者故事做为需求描述的方法，因此比起传统的文件规格更能应付需求的变化，更加拥有弹性，因此特别可以变通。而你运用使用者故事来描述需求的好坏，也决定了你应付需求变化的速度及能力。
.

附注1.

快速应用程序开发法 RAD

速应用程序开发(Rapid Application Development: RAD)是指一种以最小幅度的 … 技术设计的报告”。快速应用程序开发的方法正是须要在功能与效能间取得一个平衡点，藉此来加速应用程序的开发时间，并减小以后所需的维护成本。他是对应到1970至80年代间的非敏捷流程开发，例如说结构化系统分析与设计方法以及其余像是瀑布模型等所诞生的一种开发法。(wiki)

注2.

α、β、γ 经常使用来表示软件测试过程当中的三个阶段： α (Alpha) 是第一阶段，通常只供内部测试使用； β (Beta) 是第二阶段，已经消除了软件中大部分的不完善之处； γ (Gamma) 是第三个阶段，此时产品已经至关成熟，只需在个别地方再作进一步的优化处理。

本文转自Ruddy Lee老师的博客：https://ruddyblog.wordpress.com/2016/07/21/%E6%95%8F%E6%8D%B7%E9%96%8B%E7%99%BC%E7%82%BA%E4%BD%95%E6%9C%83%E6%AF%94%E8%BC%83%E5%BF%AB/

相关阅读：

请关注微信公众号【devopshub】，获取更多关于DevOps研发运维一体化的信息