敏捷开发的目的不是为了快速交付! 它是一种用来应付需求快速变化的软体开发方法。 – 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) 是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理。
问答
实践者：
hi Ruddy 老师，目前我们团队 RD 人数 从 7 变成 20, 发现光在每日站立会议，就会花费许多时间。我记得您的书上有写，敏捷团队是 7 加减 2 人，是比较合适的。所以想请教您，这种情况要怎么调整? 希望您给点建议。
Ruddy老师： 站立会议的目的是让项目透明化，不是风险管理或是项目review会议，简短的只报告三件事应该是很快的过程，但一旦开始有问题式的应答之后，便会开始变得冗长了。 请把握原则，有需要深入讨论的另外开会议室开会。人数太多是严重的问题，按照相关性分批来开是一个解决的方法，实在必须一起听的时候，在聚集在一起，也就是说：例如9个、9个人个别进行站立会议，之后在将二组人结合起来一起开，以组的方式交换必要资讯进行，速度就会快很多了。 或是由一组先开站立会议，之后再让另一组加入。请以相关必要知道的资讯流通与交换为原则即可。 过去，我开过28个人的站立会议，但只要把握原则，很少超时的。也看过5个人的站立会议开了半个小时以上还没开完，完全没有把握原则，实在是一种浪费。请以产能为考量就不会去开太长的会议了。
实践者：
目前在使用Kanban 有遇到问题，再请教一下:需求变的太快。当已经排入sprint 的task，常常因为需求端的改变，必须重新定义task、取消task，或是插件。目前一个sprint已经是一周安排一次，应该已经很短了。那这部分应该怎么调整，会使这样类似的情形降低?
Ruddy老师： 需求的品质需要设法提升。 当有需求产生时处理的过程太早了就会产生因为后续的变化必须更改需求而重作 Task. 尽量延迟决策 Decide as late as possible 的精实原则或许可以帮上忙。另外，在看板的Product Backlog之后加上ㄧ个审查需求是否备妥的栏位(definition of ready), 用来review 需求是否真的ok了。 这个栏位可以配合每周运用1个小时来召开需求的 refinement meeting 对需求品质的提升帮助会很大。试试看.
