作者丨Rory Madden
譯者丨方彥
策劃丨Tina
經常有人會問我什麽是敏捷流程。我都會給出那個讓人不盡滿意的答案“沒有一個單獨的流程。它取決於每個團隊的實際情況”。為了更好的回答這個問題，我撰寫該文介紹了軟體交付的演進歷史。我打算歸納成一個線性的發展，即使我知道它並不像我要表達的那樣有序和線性。但我覺得參考它，能得到比前面那個“取決於”的答案更多的信息。希望它對你同樣有用。
開始階段
軟體開發剛開始的時候，並沒有很好的經驗或思想來指導一個開發項目的運行。最開始，人們標識出軟體開發的一些關鍵假設，映射到那時已有的可理解的流程上。
最初的假設如下：
軟體開發需要很長的時間
軟體發布不會頻繁
軟體構建後很難進行更改，所以確保第一次把事情做對
軟體開發需要很多不同的、成本高昂的技能集
建築行業也有著類似的假設。建築需要很長的時間，竣工後不能簡單的添加一層或把面積擴大。建築也涉及到很多不同的專業，從設計師到開發商，到質量監理以及工人、電工和水暖工等等。從這些角色的命名可以看出，軟體開發從建築行業借鑒了很多。
建築行業遵循的流程是，把端到端的項目分成不同的階段，每個流程階段由不同的專業人士來負責。這種在每個階段賦予角色的做法有利於充分利用成本高昂的人力資源。
瀑布流程
這看起來是一個很棒的流程。瀑布模型在 20 世紀 60 年代後期開始採用，直到 80 年代中期它才成為事實上的軟體交付標準。但在流程執行中出現了些問題。根據 2014 問題報告，31% 的瀑布項目在投入很多後被取消，更有 52% 的項目預算需要翻倍。
鑒於這種很低的成功概率，很多人開始各自提出新的、更好的方式來交付項目，以克服瀑布流程中的一些缺陷。
敏捷開發
人們不希望看到自己的工作被廢棄掉，因此最初的一個思想是把大型項目分解成小的部分，逐步迭代出解決方案。這種方法讓人們能對產品隨時間的進展有更直觀的印象，讓團隊可以收集反饋來看產品是否已經解決用戶的問題。這種早期的反饋讓團隊按需進行糾正。
但是從瀑布模型轉型到迭代交付很難，很多組織就把迭代開發解釋成隨時間增量交付解決方案。敏捷這個術語很靈活，按照設計，並沒有什麽敏捷流程——其關注點在於小型迭代、持續學習和反應性。儘管流程很容易遵守和實現，不過這些軟技能很難掌握。對流程闡述不夠，會讓人們繞開一些比較困難的變革，實現“對他們有效”的敏捷流程，並起一個引人注目的名字，如 Wagile 或 WaterScrumFall。
敏捷開發
更好的透明度限制了出現嚴重超限的風險，但是它沒有解決導致瀑布項目高失敗率的根本問題。仍然有項目會花費比預期長的時間來進行構建，有些項目會因為不能交付預期價值的產品被取消。
為了實現到迭代交付的飛躍，我們需要改變對軟體交付的假設。我們要承認，我們前期不知道要構建的產品是什麽樣的，因此我們需要將預先大量設計（Big Design Up Front，BDUF）階段替換成增量設計。
這樣可以讓團隊有能力在項目開展過程中進行學習，並在需要的時候改變設計。這裡的挑戰是，設計階段是保證項目團隊內外進行協調的關鍵階段，並匯總實現解決方案所需的各種時間估計。一個公司的各個流程不是孤立的，所以要改變一個流程，就會影響另外一個看起來好像沒有關聯的流程。比如，從 BDUF 中得到的估計，會被其他支撐流程所需要，如資金、監管、資源分配和環境分配等等。
採用這些“對我們有效的敏捷”中的問題是，沒有認識到或解決我們對軟體交付做出的假設和現有情況的衝突。
假設
軟體開發需要很長的時間
軟體發布不會頻繁
軟體構建後很難進行更改，所以確保第一次把事情做對
前期不可能確切知道要構建成什麽樣的產品，因此把大型開發分解為小部分，並在項目進行中不斷學習
軟體開發需要很多不同的、成本高昂的技能集
如果前期並不能確切知道要構建怎樣的產品，我們怎麽才能做到一次把事情做對呢？軟體的大設計和最終產品經常有很大的出入——這就產生了不能預期的挑戰，即要求設計根據不斷出現的新需求進行調整。這說明，和建築行業不一樣，軟體的變更在構建後並不困難，不需要像實體建築那樣前期做縝密的設計。我們可以簡單的添加（軟體）層數，改變層高或是擴大面積，而不需要推倒重來。因此，假設 2 實際是不正確的。
（真正的）敏捷開發
如果設計可以隨著迭代過程中的學習進行更改，那麽隻做每次迭代所需的設計就會有利於減少可能的返工。
這其實是最難的一步，因為它不僅要求改變項目團隊中的一些職能部門的工作方式，還包括支持部門工作方式的改變。
我們沒有足夠的架構師，無法為每個團隊都配備一個，指導他們進行持續的架構選擇。架構師們需要定義好實踐、原則和強製措施，確保設計符合指定的約束條件，而不是定義一個固定的架構。
開發工程師們將被賦予更多的責任。他們要完成針對問題給出最佳解決方案的任務，而不僅僅是按照需求規格說明書進行軟體構建。架構師們不再面對交付的挑戰，因此他們的假設經常不正確。最前線的開發人員在面臨挑戰時往往能提出更好的解決方案。
不進行預先的大量設計，就很難預估時間和成本。在瀑布項目裡，時間和成本是基於項目啟動時的估計確定的。在增量開發中，項目範圍會根據實際遇到的新情況進行調整。時間和成本估計仍可以根據對交付的大致理解和團隊規模進行，不過因為項目範圍會有變化，投資回報率（ROI）和價值實現進度（benefits realisation schedule）無法在前期給出。
這些不是能輕鬆解決的任務，不過還是可以解決的。我會在後續的文章中詳細談到如何解決這些困難。
現在，我們再更新下我們的假設。
假設
軟體開發需要很長的時間
軟體發布不會頻繁
前期不可能確切知道要構建成什麽樣的產品，因此把大型開發分解為小部分，並在項目進行中不斷學習
軟體開發需要很多不同的、成本高昂的技能集
實現團隊負責在一定的邊界條件下進行設計
持續集成
迭代交付的好處很大程度上是因為它可以獲得關於產品的早期反饋。為了獲取這些反饋，需要有一個軟體的工作版本，解決了客戶的問題，能夠進行演示，並獲得實際的反饋。為了交付這樣一個軟體版本，主要有兩個挑戰需要克服——軟體開發怎樣進行優先排序和怎樣進行測試。
傳統的瀑布項目中，最有效的方法是按組件構建產品——構建完美的輪胎、完美的底盤，最後組裝到汽車上。上下文切換會耗費時間，因此，切換越少就可以越高效地利用開發時間。這種組件開發方式在開發團隊中根深蒂固，即使他們採用了敏捷開發，實際的構建方式仍相同。問題是，如果客戶想從 A 點到 B 地點，而我們給客戶展示的是一個完成了的車輪，客戶沒法給出任何有價值的反饋。這解決不了他們的問題。我們需要從基於組件的開發轉換到迭代開發方式，這要求有一個思想上的轉換，即關注於客戶問題而不是解決方案。只有不再做預先的大量設計，並承認前期我們並不很清楚需要構建的是什麽，這種轉變才可能實現。但即使如此，團隊仍需要培訓，因為它會影響到需求文檔的編寫和開發的進行。
價值增量 (Courtesy of Henrik Kniberg)
開發人員的時間是軟體開發中一項很高的成本，產品定義改變是否值得呢？除了 31% 的失敗率，微軟的分析指出，高達 66% 的功能沒有實現預定的商業價值。考慮到失敗率，確保我們是否做對了事情遠比開發效率更重要。我們會很快回到這一點，因為它即將影響到我們的下一個假設。
第二個挑戰是關於測試的。為了得到有價值的反饋，我們需要讓軟體在客戶面前工作起來，而不僅隻作為演示。但是這需要測試，要花費很多時間和努力來完成的一項工作。過去，只在每次大的發布上執行一次測試，則自動化測試用例並不劃算。但是有兩件事改變了測試的這種情況。第一，現在的軟體為商業的各個環節所需要，過去那種一年花很多天進行一次發布的情況已經不見了。第二，和開發人員的時間一樣，項目中最大的浪費就是開發了錯誤的東西，而自動化測試讓我們可以更頻繁的測試客戶的想法，它帶來的益處超過了其成本。自動化測試周期讓團隊在整個開發過程中，可以持續開發“可發布”的代碼。100% 的自動化測試是個很難達到的目標，因此在軟體發布前還有會小量的手動驗收測試，但其質量已經足夠驗證解決方案。
瀑布流程中，保證不同團隊高效是一個很關鍵的假設，這樣才能降低成本。但是對於軟體，因為軟體發布頻率增大，效率的經濟性也隨之發生了改變。現在的重點是保證端到端流程的有效性，而不再是保證每個職能部門的高效。這對軟體來說並不新鮮——這種方法和技術是直接從精益生產運動中借鑒過來的。
持續交付 / 部署 (DevOps)
持續集成的好處在於代碼在任何階段都是可供部署的。這樣即使項目即將被叫停，我們也有可部署的代碼。不過和前面提到的測試一樣，部署代碼成本高而且耗時多。
即使軟體已經就緒，人們仍然需要一些時間在環境間移動代碼並完成部署步驟。而且軟體還可能遇到新的問題，比如負載性能差。所以你以為軟體已經可以發布了，但實際不是。
越早發現軟體問題，解決的成本就越低。所以理想情況下，團隊應該在每次迭代結束後，發現是否有非功能性需求的問題需要解決。手動部署佔用時間很長，因此部署也應該自動化。
持續交付縮減了代碼發布的時間，但有時可能不需要發布。比如，你可能隻完成了某個特性的一半，那麽在第二個迭代完成後發布也是合理的。
了解整個部署階段有助於我們發現問題，所以應該更頻繁的進行部署。這樣就引入了功能發布控制（feature toggles / feature flags）。在標識後面開發新功能，這樣我們可以部分發布已完成的功能，但讓它們處於關閉狀態。用戶甚至都不會意識到這些新功能，但我們可以測試到，這些代碼不會對其它部分造成破壞。
功能發布控制還有其它的好處。將功能置於一個動態的轉換中，我們可以開始在測試環境下進行 A/B 測試和多元測試，進而更精確的量化出變更的效果，這可以讓我們更精準的驗證我們對於客戶的假設，必要時進行修正。我們可以動態打開或關閉某個功能，因此可以在生產環境進行用戶驗收測試，從而節省時間和成本。
經過這些變化後，我們再來回顧下我們的假設。
團隊將交付時間從幾個月縮減到幾天，到一天幾次。我們真的不能說軟體開發花費很長的時間。如果它花的時間不長，我們是否能讓專業人員分布到不同的階段呢——每天怎樣對多個階段進行管理？我們沒有減少所需的技能集，因此我們仍然需要架構師、業務分析師、手動測試工程師、自動化測試工程師、開發人員、運營人員、安全、管道開發人員等等。每個人隻貢獻一小部分，因此我們不需要讓這些人員一直在一個團隊，這樣成本太高了。但同樣的，我們不能讓他們獨立於團隊之外，因為這樣響應會太慢。如之前描述的架構師一樣，確定邊界和限制後，部分角色不再需要很深地介入到項目。然而，項目其他人員將要承擔更多的責任。這類人員被稱為 T 型人才。他們在某個領域有很深的專業知識（“|”），同時對其它領域有廣博的了解，（“–”）。廣博的知識面讓他們在沒有全職人員參與的領域內，也可以解決相關的問題。
假設
軟體發布可以很快很頻繁
前期不可能知道確切知道要構建成什麽樣的產品，因此把大型開發分解為小部分，並在項目進行中不斷學習
持續交付中，T 型人才是最有效的
實現團隊需要在已定義的邊界下負責設計、開發和發布
持續價值（Continuous Value）
如果我們快速迭代地進行發布，那麽如何進行完工定義？如果我們有既定的範圍和時間，這個問題很簡單。現在，我們要隨時部署代碼，什麽東西會妨礙我們這樣做？我們怎麽才知道什麽時候產品已經足夠好呢?
如果軟體交付不再需要很長時間，它就給我們打開了一個實驗和驗證的世界。
相應的，這也允許我們確認每次小的迭代的效果是否能達到用戶的需求和我們的業務底線。
業務流程被相互協調的團隊所代替，這些團隊必須交付業務所需的產品。該團隊實驗並迭代需要開發的產品理念，從而確保可以達成既定的目標。
該結構確保持續的交付來驗證我們的嘗試，但是仍存在一些效率低下的情況，因為在產品 / 用戶體驗 / 設計和實現團隊之間，可能缺乏一致性。這種隔離通常被歸類為“業務”（定義需開發產品的範圍）和“IT”（做實際的交付工作）。這意味著只有一半的團隊真正負責完成目標，另一半則作為交付的工具。我們仍需進行從交付物到交付業務成果的思想轉變。
假設
軟體發布可以很快很頻繁
前期不可能知道確切知道要構建成什麽樣的產品，因此把大型開發分解為小部分，並在項目進行中不斷學習
持續交付中，跨團隊的 T 型人才是最有效的
實現團隊為交付的產品成果負責
產品團隊
我們將有一個真正的跨職能產品團隊，挖掘需求，交付產品，為客戶和業務創造成果。讓開發工程師在概念階段就介入進來，可以集思廣益，還能對交付它們的複雜度提供輸入信息。設計人員自始至終參與到開發團隊中，可以更好地了解設計對於客戶的影響。
為了全面從瀑布項目已經定義好的階段遷移到產品團隊的持續流中，需要不斷的嘗試和創新，從而消除可能遇到的阻礙。但是萬事都在變化中。團隊隨著產品需求不斷成長，包括市場、客服和運維。流程的演進從不停止。我會增加最後一個假設：最好的流程來源於持續的反饋和嘗試
這些會把我們帶向何方？
流程是很神奇的。當做一些重複性工作時，清晰的流程可以幫助我們明確需要做什麽，需要避免那些已知的錯誤。在大型公司裡，流程制度化是更有效的做事方式。但有時候這也會有問題。Jeff Bezos 在其第一天理論中指出了這點：
“好的流程為我們服務，進而為客戶服務。但是，如果我們不保持警惕，流程就會成為問題。流程成了你希望獲得的結果的替代品。”
所有流程的通病是它們包含了流程建立之初的假設和限制。隨著時間遷移，那些已經嵌入流程之中的最初假設被遺忘了。問題在於，假設和限制不再有意義時，流程會阻礙我們的工作。
我們來看看下面的假設，看看哪一種描述對我們現在的工作狀態描述更準確。
項目 產品時間 軟體開發需要很長時間 軟體發布不頻繁 軟體交付快速且頻繁設計 軟體在構建後很難變更，因此確保第一次把事情做對 前期不可能知道確切知道要構建成什麽樣的產品，因此把大型開發分解為小部分，並在項目進行中不斷學習團隊 定義不同的角色，有效利用成本高昂的技術人員 持續交付中，跨團隊的 T 型人才是最有效的目標 實現團隊對輸出負責 實現團隊對結果負責流程 流程變更集中化，並在組間同步推進 根據持續的反饋和實踐，流程可以在團隊進行變更做這種轉變並不容易，我在接下來的文章中會深入探討，為了支持產品團隊的轉變，整個組織需要做那些相應改變，包括：
管理層 / 組織架構變化
監管層變化
財務制度變化
用戶體驗和設計變化
開發變化
測試變化
https://blog.uxdx.com/the-evolution-of-software-delivery/
點個在看少個 bug
香港九龍灣馬來街興發大廈15樓D室