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

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

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

「敏捷」二字的误导

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

透过游戏来做说明

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

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

透过图示的方式作说明

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

※ 前置时间

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

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

※ 首次发布的时间

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

※ 数据需求

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

※ 测试方法

敏捷开发对软件带来的最大影响便是测试了。传统的α(内部测试，注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研发运维一体化的信息