作者簡介：

Ruddy Lee（李智樺）老師，DevOpsDays北京站金牌講師，臺灣著名精益佈道師，敏捷專家，著有《精益開發與看板方法 》。

敏捷開發的目的不是為了快速交付!
它是一種用來應付需求快速變化的軟體開發方法。

– 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 對需求品質的提升幫助會很大。試試看.

文章來自微信公眾號：DevOps時代