.
小增量、多迭代與取得回饋構成了敏捷之所以務實的基礎.
—敏捷口訣
.
敏捷開發的目的不是為了快速交付!
它是一種用來應付需求快速變化的軟體開發方法。
– Wiki
》許多IT主管或是工程師，都把敏捷開發誤以為是一種快速交付的方法，就因為它比傳統開發方法快一些，當然；還有它叫做「敏捷」的緣故。因此我們常常聽到主管們在會議上抱怨:「不是已經在RUN敏捷開發法了嗎，為什麼開發速度還是那麼慢呢?」
.
「敏捷」二字的誤導
這一篇文章的目的不在回答上面那個說來話長，必須用聽診器仔細推敲才能回答的問題，而只是想修正一下大家對「敏捷」這二個字的誤解。敏捷二字其實是針對需求變化的快速反應而來，而不是過去所謂的 RAD 快速應用程式開發法(附註1)。下面的說明則是在解釋敏捷開發為何會比傳統開發方法快的原因。
.
透過遊戲來做說明
敏捷開發不是一種快速的開發方法，為了解釋這件事敏捷課程的講師們經常會在課程裡依靠遊戲的方式來作說明(這是效果最好的一種方式，大家玩上一回便知道前置時間所造成的浪費之處了)，但時間不夠的時候，則會改成放影片的形式。請欣賞上課時我們經常會放的一段翻銅板遊戲(Coin Flip Game)。放這段影片的目的在導正大家對敏捷的誤解。尤其是給高階的主管知道 – 敏捷開發不是一種為了快速交付而出現的方法，它之所以比較快則是因為避開了許多浪費的處理方式 。下面這一張圖是為了更容易作說明而畫的，希望能解決困擾。
.
透過圖示的方式作說明
補上敏捷視為最重要的回饋.
上面這一張傳統 vs 敏捷的開發流程圖示，強調四個實施敏捷開發時為何會快於傳統開發流程的地方:
.
※ 前置時間
傳統開發法依循計畫、分析、設計、程式開發、測試再進行修改整合後發布的步驟進行，是一種順序性的開發模式，也就是說當前一個步驟還沒完成之前，後面的步驟就會位在等待的行列，當前一個步驟用掉越多時間時則後面步驟的前置時間就會越長，而形成時間上越多的浪費。也就是說傳統開發浪費了太多的時間，在前置作業上的意思。前置時間造成了一種沒有充分運用資源的現象，當進行到分析或設計的步驟時，程式設計人員仍然處於等待的狀態，因此形成了時間的浪費。
反觀敏捷開發，實行的是一種務實的做法，例如:在進行需求蒐集的步驟時，當收集到足夠一次迭代開發的需求時即向下一個步驟前進，盡量縮短前置時間的浪費，然後將"分析、設計、開發與測試“形成一個開發步驟，減少了步驟與步驟之間的銜接時間，這種開發方式形成了一種所謂的「衍生式的設計」，也就是遇到實質上的問題時才採用設計方法來克服它，而不是預先作好設計的方式。 因此讓起步顯得輕量化了，再加上只有少少的規範，所以敏捷才有了輕量化的開發方法的稱謂。
(在銅板遊戲中，我們通常會用一張A4的紙張作為前置時間的限制，要求學員把10或20個銅板放上去，遊戲進行時只有在所有在紙張上的銅板都完全翻轉過之後才能傳遞給下一位，形成後面的學員空等待的時間，也就是前置時間的浪費。在銅板遊戲中，我們通常會分成三次來進行遊戲，第一次採用 A4的紙張，代表最大的前置時間，接著將A4紙張撕成四等分，也就是採用四分之一的前置時間大小的紙張，最後一回則完全拿掉紙張，也就是極小化前置時間的限制，目的在讓學員更容易意識到速度上的差異)
.
※ 首次發布的時間
敏捷開發採用迭代的開發方式，每個循環都會有一個潛在可以進行發布的小增量用來展示開發的成果，透過這種展示給了我們要求客戶在看完之後給予回饋以便進行改善的機會，這種讓客戶體會開發成果的作法同時也給予了客戶決定開發方向的絕對主權(客戶可以在看到需求如何被達成，然後評估產品的堪用程度，是否已經達到提前上線的水準，也就是產品足以提前交付了嗎?)。
通常這個展示時間會設定在 1到 4個星期之內，因此客戶幾乎可以預期在這段時間之後可以看到預期的開發成果。這與傳統開發只在產品完成後才做一次發布的方式，客戶只有在這個時候才看得到成果，在開發過程中完全沒有改善的機會。這種迭代展示的形式，給予了客戶提前驗收的機會，也給予了開發團隊自然提前完工的機會。
.
※ 資料需求
敏捷開發不作完整的需求分析(因為計畫總是趕不上變化的)，當需求的蒐集量及品質，已經足夠一個開發週期的工作量時就可以開工了。這便是敏捷開發著名的「需求夠二個星期的工作量了，可以開幹了!」，一種盡快開工不浪費時間去等待需求全部收集完整的開發模式。(需求的品質，就是所謂的 Definition Of Ready: DOR，它才是決定開發速度的決定性因素)
傳統開發的一個盲點是即便你將需求全都做完分析了，你還是會從這裡開始做起，也就是即便沒做完分析工作還是從一樣的地方做起(就是必做的工作)，哪為什麼不一在開始就依循分析多少就做多的方式，盡快開工開始累積知識呢?! 經典的反駁是；匆匆開始難道不怕一開始就走偏了嗎? 這便是敏捷依靠回饋來持續推進與修正的緣故，沒有回饋就沒有敏捷。敏捷持續依靠回饋進行修正，所以敏捷敢於大膽地進行假設，然後快速完成驗證假設，再依據學習到的知識向下一個假設推進；這便是敏捷的口訣:「小增量、多迭代與持續回饋」的依循精神。
.
※ 測試方法
敏捷開發對軟體帶來的最大影響便是測試了。傳統的α(內部測試，註2)、β(交付客戶測試)、γ測試(優化處理)方式在採用敏捷開發後幾乎不存在了，因為敏捷開發在開發週期內即不斷的在進行測試的動作，因此也就沒有了在交付做α、β、γ測試時必須停下開發作業來，凍結程式開發的時間浪費了。
走了近二十年的敏捷開發，有二個明顯的趨勢成為了敏捷團隊的持續研究重點，一個就是測試，也就是從頭到尾都要測試。另一個則是組織上頭的徹底改變，這個較難，因為觀念要變(說得更明確一些是心態Mindset要改變)。有空再來聊一聊.
.
以達成目標為使命的開發模式
符合人性，激發潛能
這是敏捷開發為何比傳統開發法快的人性因素，也是最重要的因素。敏捷把開發的週期稱為 Sprint，Sprint 的意思是衝刺，意思是開發團隊在一個開發週期裡用盡全力的去完成一個有意義的增量。因此達成目標便成了團隊努力的動力。大家全力以赴的工作模式讓敏捷開發成為一種以激發潛能的方式在運行開發週期，所以不需要用日期來設限，反過來用激勵的方式讓專案能夠順利進行並符合預期，當然讓專案提前完成是always可以期待的。這對知識工作者而言無疑的比強制壓迫他更為有效。人性在這裡成為表現好壞的根本，因此信任與團隊協作便成了表現好壞的重要關鍵。
讓團隊發揮效能的最好方法，是運用各種方式激勵他們.
-敏捷開發過程
.
小結
這是觀念的問題，當你知道敏捷開發是針對需求變化的快速反應而來以後，便容易意會到為什麼它會花費那麼多的功夫在處理需求的變化了。例如Scrum 目前很流行的 Refinement會議，為什麼它每周都要召開一次呢，有必要嗎?是不是太浪費時間了呢?其實，它的目的是在讓部分成員(例如 UX/UI成員)可以提前進入開發週期，再來就是運用抽象估算的方式，用來應付隨著時間而善於改變的需求變化罷了。
如果想要加速開發的時間，則前提是把需求弄好，擁有好的需求品質，當需求越能抽象的解題(注意不是明確的解題，一旦太明確化就失去變化的能力了)，抽象解題提供了巨觀上的 Big Picture, 讓我們能夠看見全貌，然後據此擬定正確的開發方向，方向對了返工(rework)的次數自然變少，減少了在返工時所浪費的時間，減少了浪費的時間開發作業也就自然地變快起來了。
》為何要抽象化呢? 因為抽象時比較能包容那些屬於不確定的因素，也就是未來還沒發生的事情，他可以減少我們提前做決策時的方向偏差。而敏捷開發對抽象化最大的貢獻大概就是採用使用者故事(User Story )來描述需求了，它實現了我們用抽象化來做快速解題的能力。如果你尚未或是正準備進入敏捷開發的領域，記得從需求開始，而需求的撰寫請不要忘了採用使用者故事。
.
》如果一定要把敏捷開發說成是一種快速的開發方法的話，則應該要正名成〝一種快速處理需求變化的方法〞。是的；用來處理改變需求它就變得快得不得了了。原因是它在迭代中採用了使用者故事作為需求描述的方法，所以比起傳統的文件規格更能應付需求的變化，更加擁有彈性，所以特別能夠變通。而你運用使用者故事來描述需求的好壞，也決定了你應付需求變化的速度及能力。
》因為失敗得快，所以可以學得快、修正得更快。(博伊德法則：迭代的速度會打敗迭代的質量。這是一條出人意料的法則，但當我們在處理複雜、不可預知、總是混亂無序的系統時，這條法則就很有意義了。註3.)
.
Scrum 採用迭代的開發方式，注重客戶真正的需求，所以當客戶覺得目前功能已經夠用了，我們就會減少開發一堆無用的功能，因此由於少做了功能就變快了。
Scrum 注視品質，減少了反工，就變快了。
-Marc Loeffler.
.
附註1.
快速應用程式開發法 RAD
快速應用程式開發(Rapid Application Development: RAD)是指一種以最小幅度的 … 技術設計的方式"。 快速應用程式開發的方法正是需要在功能與效能間取得一個平衡點，藉此來加速應用程式的開發時間，並減少之後所需的維護成本。他是對應到1970至80年代間的非敏捷流程開發，例如說結構化系統分析與設計方法以及其他像是瀑布模型等所誕生的一種開發法。(wiki)
註2.
α、β、γ 常用來表示軟體測試過程中的三個階段： α (Alpha) 是第一階段，一般只供内部測試使用； β (Beta) 是第二階段，已經消除了軟件中大部分的不完善之處； γ (Gamma) 是第三個階段，此時產品已經相當成熟，只需在個別地方再做進一步的優化處理。
註3. 參考自"奔跑吧，程序員"
博伊德法則：迭代的速度會打敗迭代的質量。這是一條出人意料的法則，但當我們在處理複雜、不可預知、總是混亂無序的系統時，這條法則就很有意義了。下圖；產品開發的敏捷/精益方法和瀑布方法的對比（速度製勝）
Ruddy Lee 分享空間 
hi Ruddy 老師
目前我們團隊 RD 人數 從 7 變成 20, 發現光在每日站立會議，就會花費許多時間。
我記得您的書上有寫，敏捷團隊是 7 加減 2 人，是比較合適的。
所以想請教您，這種情況要怎麼調整? 希望您給點建議。
謝謝
站立會議的目的是讓專案透明化，不是風險管理或是專案review會議，簡短的只報告三件事應該是很快的過程，但一旦開始有問題式的應答之後，便會開始變得冗長了。請把握原則，有需要深入討論的另外開會議室開會。 人數太多是嚴重的問題，按照相關性分批來開是一個解決的方法，實在必須一起聽的時候，在聚集在一起，也就是說：例如9個、9個人個別進行站立會議，之後在將二組人結合起來一起開，以組的方式交換必要資訊進行，速度就會快很多了。或是由一組先開站立會議，之後再讓另一組加入。請以相關必要知道的資訊流通與交換為原則即可。
過去，我開過28個人的站立會議，但只要把握原則，很少超時的。也看過5個人的站立會議開了半個小時以上還沒開完，完全沒有把握原則，實在是一種浪費。請精實的以產能為考量就不會去開太長的會議了。
謝謝回覆. 目前在使用Kanban 有遇到問題，再請教一下:
需求變的太快。當已經排入sprint 的task，常常因為需求端的改變，必須重新定義task、取消task，或是插件。目前一個sprint已經是一周安排一次，應該已經很短了。那這部分應該怎麼調整，會使這樣類似的情形降低?
需求的品質需要設法提升。
當有需求產生時處理的過程太早了就會產生因為後續的變化必須更改需求而重作 Task. 盡量延遲決策 Decide as late as possible 的精實原則或許可以幫上忙。另外，在看板的Product Backlog之後加上ㄧ個審查需求是否備妥的欄位(definition of ready), 用來review 需求是否真的ok了。這個欄位可以配合每週運用1個小時來召開需求的 refinement meeting 對需求品質的提升幫助會很大。試試看.
多謝分享！
Ruddy 老師好,
請教您, 由您的文章了解,進行敏捷式開發仍還是會需要進行系統的分析與設計的,但對於傳統系統分析與設計會產出的文件(eg: PDM/LDM ERD文件,Data Dictionary ,Data Flow …等),於敏捷式的開發下還會存在?或是於何時必須產出? 要如何確保採sprint開發的結果,系統資料模型的設計仍如統傳統整體規劃的方式是完整的,而非一個需求加一個資料表般疊床架屋的設計.
謝謝
其實最大的差異在文件的製作是漸進式完成的，隨著專案的進度逐步產出需要的文件。產出的文件，一般是用來提供將來用作溝通、維護或是記錄、保存專業知識時使用。並非用在預測上。因此多為溝通用或記錄式的文件，或可稱為敏捷式的筆記。強調的是剛剛好足夠就可以了。至於確保Sprint的開發結果，就見仁見智了。Sprint 預設的結果是希望達成的目標，做出來的結果是團隊努力衝刺後的所得，Scrum看重的是持續改善後的漸進式收穫，至於結果則是這個團隊的在這段時間內的產出罷了。完整性是一個謎樣的字眼，一個統計數據在描述這個資訊爆炸時代下的應用軟體，最初所作的需求描述在最終完成時，發掘有55%以上都被修改過了。也就因此才會有敏捷這種漸進式的開發模式產生。這樣子的設計方式稱之為[浮現式設計]，沒有所謂傳統式整體性巨細靡遺的全盤規劃，當遇到需要較全面性的規劃時，通常會做較抽象式，具有較大包容性的設計，而細節的部份經常是遇到才做應對的，因此也稱為衍生式的設計方式。Scrum的核心三個支柱支撐著每一個經驗工作流程控制的實施：它們分別是：透明化，檢驗，與調適性。善用敏捷化的觀念，自然能克服這些疑慮。
謝謝，