它是一種用來應付需求快速變化的軟體開發方法。
– 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/
相關閱讀：
- 看見的力量 – (I) 解題的思維
- 看見的力量 – (II) 影響地圖
- 使用者故事驅動的敏捷開發 – 2. 建立backlog
- 使用者故事驅動的敏捷開發 – 1. 規劃篇
- 解析精益產品開發 – 看板方法的五大核心實踐
- Impact Mapping 影響地圖 讀書與演練心得
- 建立使用者故事地圖(User Story Mapping)的8個步驟
- 使用者故事地圖(User Story Mapping)之初體驗
請關注微信公眾號 【devopshub】，獲取更多關於DevOps研發運維一體化的資訊
