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

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

》許多IT主管或是工程師，都把敏捷開發誤覺得是一種快速交付的方法，就由於它比傳統開發方法快一些，固然；還有它叫作「敏捷」的緣故。所以咱們經常聽到主管們在會議上抱怨:「不是已經在RUN敏捷開發法了嗎，爲何開發速度仍是那麼慢呢?」
.api

「敏捷」二字的誤導

這一篇文章的目的不在回答上面那個說來話長，必須用聽診器仔細推敲才能回答的問題，而只是想修正一下你們對「敏捷」這二個字的誤解。敏捷二字實際上是針對需求變化的快速反應而來，而不是過去所謂的 RAD 快速應用程序開發法(附註1)。下面的說明則是在解釋敏捷開發爲什麼會比傳統開發方法快的緣由。
.微信

透過遊戲來作說明

敏捷開發不是一種快速的開發方法，爲了解釋這件事敏捷課程的講師們常常會在課程裏依靠遊戲的方式來做說明(這是效果最好的一種方式，你們玩上一回便知道前置時間所形成的浪費之處了)，但時間不夠的時候，則會改爲放影片的形式。請欣賞上課時咱們常常會放的一段翻銅板遊戲(Coin Flip Game: https://www.youtube.com/watch?v=HW2DEZLRAhw)。app

放這段影片的目的在導正你們對敏捷的誤解。尤爲是給高階的主管知道 – 敏捷開發不是一種爲了快速交付而出現的方法，它之因此比較快則是由於避開了許多浪費的處理方式。下面這一張圖是爲了更容易做說明而畫的，但願能解決困擾。
.運維

透過圖示的方式做說明

上面這一張傳統vs敏捷的開發流程圖示，強調四個實施敏捷開發時爲什麼會快於傳統開發流程的地方:
.wordpress

※ 前置時間

傳統開發法依循計劃、分析、設計、程序開發、測試再進行修改整合後發佈的步驟進行，是一種順序性的開發模式，也就是說當前一個步驟還沒完成以前，後面的步驟就會位在等待的行列，當前一個步驟用掉越多時間時則後面步驟的前置時間就會越長，而造成時間上越多的浪費。也就是說傳統開發浪費了太多的時間，在前置做業上的意思。前置時間形成了一種沒有充分運用資源的現象，當進行到分析或設計的步驟時，程序設計人員仍然處於等待的狀態，所以造成了時間的浪費。
反觀敏捷開發，實行的是一種務實的作法，例如:在進行需求蒐集的步驟時，當收集到足夠一次迭代開發的需求時即向下一個步驟前進，儘可能縮短前置時間的浪費，而後將」分析、設計、開發與測試「造成一個開發步驟，減小了步驟與步驟之間的銜接時間，這種開發方式造成了一種所謂的「衍生式的設計」，也就是遇到實質上的問題時才採用設計方法來克服它，而不是預先做好設計的方式。所以讓起步顯得輕量化了，再加上只有少少的規範，因此敏捷才有了輕量化的開發方法的稱謂。測試

(在銅板遊戲中，咱們一般會用一張A4的紙張做爲前置時間的限制，要求學員把10或20個銅板放上去，遊戲進行時只有在全部在紙張上的銅板都徹底翻轉過以後才能傳遞給下一位，造成後面的學員空等待的時間，也就是前置時間的浪費。在銅板遊戲中，咱們一般會分紅三次來進行遊戲，第一次採用 A4的紙張，表明最大的前置時間，接着將A4紙張撕成四等分，也就是採用四分之一的前置時間大小的紙張，最後一回則徹底拿掉紙張，也就是極小化前置時間的限制，目的在讓學員更容易意識到速度上的差別)
.優化

※ 首次發佈的時間

敏捷開發採用迭代的開發方式，每一個循環都會有一個潛在能夠進行發佈的小增量用來展現開發的成果，透過這種展現給了咱們要求客戶在看完以後給予回饋以便進行改善的機會，這種讓客戶體會開發成果的做法同時也給予了客戶決定開發方向的絕對主權(客戶能夠在看到需求如何被達成，而後評估產品的堪用程度，是否已經達到提早上線的水平，也就是產品足以提早交付了嗎?)。
一般這個展現時間會設定在 1到 4個星期以內，所以客戶幾乎能夠預期在這段時間以後能夠看到預期的開發成果。這與傳統開發只在產品完成後才作一次發佈的方式，客戶只有在這個時候纔看獲得成果，在開發過程當中徹底沒有改善的機會。這種迭代展現的形式，給予了客戶提早驗收的機會，也給予了開發團隊天然提早完工的機會。
.設計

※ 數據需求

敏捷開發不做完整的需求分析(由於計劃老是趕不上變化的)，當需求的蒐集量及質量，已經足夠一個開發週期的工做量時就能夠開工了。這即是敏捷開發著名的「需求夠二個星期的工做量了，能夠開幹了!」，一種儘快開工不浪費時間去等待需求所有收集完整的開發模式。(需求的質量，就是所謂的 Definition Of Ready: DOR，它纔是決定開發速度的決定性因素)
.code

※ 測試方法

敏捷開發對軟件帶來的最大影響即是測試了。傳統的α(內部測試，注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/

相關閱讀：

請關注微信公衆號【devopshub】，獲取更多關於DevOps研發運維一體化的信息