作者簡介
都雲霞，Agilean 公司管理顧問、敏捷教練，CSM 、PMP 、CSPO 認證。近 10 年金融軟件項目管理背景，曾服務於穆迪等國際金融諮詢公司，參與中原銀行、平安銀行等的敏捷精益輔導。本文轉載自公衆號Agilean。
由於某些不恰當的實施方式，敏捷導入有時在企業裏處於「兩頭不討好」的尷尬狀態：業務認爲敏捷是造成低質量交付的推手，而研發覺得敏捷是管理者壓榨團隊的幫兇。
通過分析衆多敏捷實施失敗案例，我們發現大多數情況下，版本迭代節奏不匹配組織和業務特點是導致失敗的根本原因之一。本文將結合 Agilean 諮詢團隊的實踐經驗，推薦一種適合複雜業務場景（如金融科技）的版本迭代節奏：RISE（Release-Iteration Schedule for Enterprise)。
介紹 RISE 之前，讓我們先看一下，在複雜的業務場景中，傳統的雙週迭代會遇到什麼問題。
雙週迭代，指每兩週進行一次發佈。這意味着從業務側承接過來的需求，要在1-2天內完成需求分析和澄清。但對很多複雜業務場景來說，需求澄清通常要花2-3天才能真正完成。現實中很多的交付質量不合格，就是由需求不清晰這個源頭問題造成的。
交付質量差，會促使人們不斷將「功能移交測試時間」前移，比如要求迭代第二週開始之前提測，以避免上線風險。於是，開發同學必須加班加點，自測、聯調也只能對付了事，上線時候還是一堆的故障。
最後，他對當前狀態進行了這樣的評價：
做軟件研發，大腦是我們最重要的生產工具。但團隊一直處於又緊張又疲憊的狀態，別說高質量交付了，連最基本的質量都難以保證。這不是在做迭代，而是連滾帶爬，「死亡行軍」。
在調侃的語氣中，我們仍能感受到滿滿的無奈和倦意。仔細分析上面狀況的產生，能發現兩個主要原因：
團隊將一個版本的所有活動，都壓縮進入了同一個迭代。對於一些複雜業務和複雜系統，這樣做往往導致時間過於緊張。
迭代內部以「一週開發，一週測試」的方式運行，這種情況下，迭代變成了小瀑布。
如何發現「小瀑布」？來瞧瞧下面這個看板：
上圖中，團隊所有事項都集中在開發區域。有些卡片進入了開發的「已完成」列，沒有任何卡片進入「測試」。看板呈現了浪湧式流動——這就是團隊以小瀑布方式運行的表現特徵。
在小瀑布模式下，爲了避免資源浪費，往往將迭代時間按流程切開，比如上半周開發，下半周測試。
聽起來很有「節奏」，對不對？問題來了，測試在上半周的時間裏，要做些什麼？在現實中，上半周往往用來測上一個迭代的內容，於是，團隊中開發測試的協作被強行割裂。
小瀑布模式的核心問題在於，「開發完成」並不是真的完成，還屬於WIP（在製品），並不能產生真正的質量反饋。開發完成的需求，在測試時可能暴露出大量缺陷，造成返工。迭代管理的核心目標是降低交付風險，確保質量可控，但小瀑布模式顯然無法有效實現這點。
如何破解小瀑布？我們通常建議團隊採用「流式開發」。即以小顆粒度需求（如用戶故事）爲單位，讓需求像水一樣不斷向下個階段流動，從而快速獲取反饋，真正達到利用迭代管理降低風險的目標（如下圖）。
以「流式開發」運行的迭代，看板往往呈現下面的變化形式：
誠然，流式開發對需求拆分提出了更高要求，需求要被拆解成可測試可驗收的細小單元。其實，這是敏捷產品經理和敏捷教練需要具備的硬核技能，也是敏捷需求管理的基礎。
另外，爲了減少開發測試工作的併發打擾，開發人員要採取開發自冒煙、代碼評審等質量措施，來保證需求的順暢流動（這方面的詳細內容可以參見FLEET的「潤滑」原則）。
針對複雜業務研發場景，RISE 倡導在流式開發基礎上，將版本和迭代解耦。延長版本存續時間，將一個版本分成需求迭代和研發迭代，前一個版本的研發迭代和後一個版本的需求迭代並行。
上面描述的版本迭代節奏，使團隊可以實現需求澄清前置，即由產品經理提前一個迭代與業務人員進行需求細化。在研發迭代開始時，團隊拿着已經充分細化澄清的需求，直接投入開發工作。
對於發佈流程複雜、生產質量要求高的情況，RISE 版本迭代節奏同時提倡，通過迴歸測試和版本發佈後置進行優化。即在研發迭代之後，再進行迴歸測試和版本發佈活動。這樣做的前提是「需求澄清前置、流式開發、質量內建」等實踐已經建立，移交質量能夠得到充分保障，因此，迴歸測試階段發現缺陷的概率變得很低。
綜合前面描述，下圖爲詳細到每日安排的 RISE版本迭代日曆：
按上面迭代日曆所示，對研發團隊來說，在一個研發迭代內將擁有：
已經得到充分澄清的需求
8 天的開發時間
6 天的測試時間
2 天的缺陷修復時間
這樣的時間分佈，對於以雙週迭代運行的團隊來說，保障交付質量的各階段時間已經相當充足了。並且，由於整個開發過程中並行事項較少，團隊可以減少相互間的打擾，更加專注，交付效率也隨之獲得提升。
按照上面的迭代日曆，進行雙週迭代時，需要注意下面兩點：
合適的需求粗細粒度。把需求拆成合適的粒度以便於其流動，單個粒度需求儘量控制在2-3人天完成。
對當前迭代的需求進行分步移測。讓測試可以從第一週的第3天至第二週的第4天，持續測試不同的需求，而非堆積到一個時間點，一次性移測。
讀者可能會有疑問，增加了一個完整的需求迭代，是否相當於開發後置了？會不會減慢整體交付時效？
首先，我們要引入前置時間（Leadtime）這個概念。需求前置時間指從需求提出到完成上線的整個時間週期。它包含意向形成、需求討論、設計定稿、開發、測試、上線發佈幾個時間段（如下圖），Agilean 自研的敏捷組織管理工具知微，已經可以實現需求前置時間的分段統計：
需求前置時間能夠很好地反映研發的響應速度，是我們倡導優化的核心指標之一。通過縮短需求前置時間，持續進行高質量、有價值的研發交付，也是組織推進敏捷的重要目的。
讓我們推演一下，RISE版本迭代節奏在現實中的運行方式：
運行雙週迭代的團隊，在第一週的第1天收到一個複雜業務需求。首先，由產品經理進行需求澄清，與業務討論並梳理業務規則。通常情況下，這個需求會在第三週（即開發迭代的第一週）投入開發，經過 10 天的開發和測試後，進入迴歸測試，並在第五週上線。
可以看到，該需求從想法提出到上線發佈，一共耗費 4 周 + 4 天 = 32 天。對大部分團隊、大部分複雜業務需求來說，32天的需求前置時間已經很快了。
另外，因爲採用了流式開發模式，在迭代運行過程中，業務方可以加入緊急需求，順延一些還未進入開發的低優先級需求。確保團隊對緊急需求，有更快速、更靈活的響應能力。
本文以一個不理想的雙週迭代案例開始，分析了團隊在迭代過程中時常遇到的問題以及背後成因，並介紹了穩定高效的 RISE版本迭代節奏，以及詳細的迭代運作日曆。這是Agilean基於十年來在企業內推動敏捷落地的實踐總結，希望可以給有類似困擾的團隊，提供一些啓發和思考。
在迭代落地的過程中，架構設計、流程控制、資源配置、人員能力等很多因素，都可能影響其效果。如果您的團隊在迭代運作過程中遇到問題，歡迎隨時與我們展開討論。
隨着Scrum框架的大量使用，敏捷團隊面臨的第二大挑戰就是如何將業務分析師和架構師組合成活躍互動的團隊成員。任何面臨這一挑戰的Scrum Master、經理、決策者都應該閱讀本書。另外，所有參與敏捷項目的團隊成員也將從本書獲益。
可執行需求說明提煉方法要求人們在思維方式上做出改變。本書的重點也在於此。可執行需求說明提煉方法有助於縮小干係人希望軟件能做什麼（什麼）和該軟件的確能做什麼（如何）之間的差距。可執行需求說明以一種使開發團隊很容易根據可執行需求說明來驗證軟件的方法澄清需求，而這跟需求變更一樣在頻繁地發生。
部分圖片及電子書來源於網絡，版權歸原作者所有，僅供學習勿作它用。如果侵犯到您的權益，請聯繫我們撤除。
本文分享自微信公衆號 - 互聯網PMO（tech_pmo）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。