敏捷開發為何會比較快?

.

敏捷開發的目的不是為了快速交付!

它是一種用來應付需求快速變化的軟體開發方法。

–          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) 是第三個階段，此時產品已經相當成熟，只需在個別地方再作進一步的優化處理。

.