「首席架構師看敏捷建模」敏捷核心實踐：怎麼樣排列需求？

• 2019 年 10 月 4 日
• 筆記

敏捷者希望開發高品質和高價值的軟體，而開發高價值軟體最簡單的方法就是首先實現最高優先順序的需求。這使他們能夠最大化涉眾的ROI。因為需求經常變化，您需要一個精簡的、靈活的方法來進行需求變更管理:簡而言之，敏捷者努力真正地管理變更，而不是阻止變更。這一做法有三個版本:

• 產品待辦事項列表(Scrum)
• 工作項目列表(有紀律的敏捷)
• 選擇池(精益)

1. 產品待辦事項列表:簡單

圖1概述了Scrum管理需求的方法，其中您的軟體開發團隊有一堆需要處理的優先順序和估計需求(Scrum將這個優先順序堆棧稱為「產品backlog」)。有幾個要點需要理解:

• 新需求由項目涉眾確定優先順序，並添加到堆棧的適當位置。
• 從根本上說，當涉及到需求優先順序時，一個人需要成為最終的權威。在Scrum和紀律嚴明的敏捷交付(DAD)中，這個角色來自Scrum，這個人被稱為產品負責人。
• 儘管經常有許多項目涉眾，包括最終用戶、經理、架構師、運營人員，但僅舉幾個例子，產品所有者負責代表他們所有人。
• 堆棧/待辦事項列表最初是由您在項目開始時設想的需求所填充的(在Scrum中，他們稱之為「填充待辦事項列表」)。
• 每次迭代(Scrum術語中的「sprint」)，您的團隊都將迭代的工作價值從棧頂提取出來，並承諾在迭代結束時實現它。
• 您的項目涉眾有權定義新的需求，改變他們對現有需求的想法，甚至根據他們認為合適的情況重新排列需求的優先順序。
• 利益相關者負責及時做出決策並提供資訊。在一些項目中，業務分析師(通常扮演產品負責人的角色)可能會承擔此職責。無論誰擔任這個角色，都需要與其他利益相關者合作，確保每個人都得到公平的代表，這通常是一項艱巨的任務。
• 非需求工作項目的優先順序要麼由團隊與涉眾協商，要麼作為計劃中空閑時間的一部分處理。許多Scrum團隊現在不僅僅把需求(比如缺陷)放在他們的backlog上。

圖1所示。Scrum需求管理。

2. 工作項目列表:有紀律的敏捷

圖1中描述的方法非常簡單，反映了我認為敏捷構建級別的思想。圖2概述了一種更規範的方法，它擴展了上面描述的管理工作項的方法。這種方法是有紀律的敏捷交付(DAD)所建議的默認方法，兩者都反映了敏捷交付團隊所面臨的現實世界。你應該考慮以下幾個有趣的改進:

超越功能需求。我們知道我們做的不僅僅是在每次迭代中實現新的需求，我們經常做與需求無關的工作，比如接受培訓，檢查其他團隊的產品，處理缺陷(我認為缺陷只是另一種類型的需求)等等。重點是，不僅僅需要將需求放在堆棧上，我們還需要工作項。

• 採用風險價值方法。紀律嚴明的敏捷團隊認識到開發團隊面臨著一些共同的風險，他們希望儘快解決這些風險。這些風險包括在項目早期達成涉眾一致意見的需要，可以通過需求設想，或者開發一個共享的遠景或者項目章程來解決這個風險。另一個常見的風險是需要證明您的體系結構策略(通過體系結構設想標識)確實有效。最有效的方法是通過為您的系統構建一個端到端框架(或鋼框架)來使用工作程式碼證明您的體系結構，該框架解決了您的團隊所面臨的主要技術風險。有紀律的敏捷交付(DAD)團隊將在項目的早期查看他們的工作項堆棧，通常是在項目的初始階段/「迭代0」/「sprint 0」部分，以確定哪些需求展示了這些技術上有風險的特性。如果這些要求沒有堆棧的頂部,他們常常因為風險和回報(值)傾向於使相互,然後他們用產品所有者討論這個問題,看看他們能激勵人(負責優先順序)將這些需求轉移到堆棧的頂部。如果一個高風險的需求目前接近於棧底，那麼您應該質疑這個需求是否真的是需要的，因為很有可能您永遠不會真正抽出時間來處理它，因為優先順序更高的工作總是會成為先例。
• 提前一點建模。因為我們知道所有的需求，更不用說一般的工作項，都不是平等創建的，所以我們不應該天真地假設我們應該在迭代開始的時候等待從堆棧頂部取出迭代的工作值。如果一個工作項非常複雜，需要比迭代計劃會話中通常發生的更多的思考，該怎麼辦?紀律嚴明的敏捷團隊將採用前瞻性建模實踐，對工作項堆棧進行一兩次迭代，並投入時間研究即將到來的複雜工作項，以降低總體項目風險。提前建模在Scrum中稱為backlog梳理，揭示了Scrum實踐中一些不必要的概念耦合。

圖2。有紀律的敏捷工作管理流程。

3.選擇池:精益

圖3描述了一種在看板團隊中常見的需求管理精益方法。需求/工作管理的敏捷方法和精益方法之間有幾個關鍵的區別:

• 選項。工作項被視為解決方案中要處理的潛在選項，而不是必需的工作項。順便提一下，IT中的術語「需求」一直以來都是有問題的(如果某個東西是一個需求，那麼如何將它的一部分或全部從您的交付範圍中刪除呢?)
• 選項被管理為一個池。敏捷團隊將工作項管理為優先順序隊列，精益團隊將選項管理為一個池，當他們有能力執行相應的工作時，他們將從這個池中與涉眾一起選擇最有價值的工作。實際上，優先順序是在團隊涉眾的準時(JIT)基礎上完成的。這可能很複雜，因為單個涉眾將有不同的優先順序，因此需要進行權衡，而且團隊可能支援不同的服務類別。當然，紀律嚴明的敏捷策略所描述的風險緩解問題也應該考慮接下來選擇哪個選項。
• 選項可能被組織到服務類中。並不是所有的選項都是相同的。在《看板》一書中，David J. Anderson描述了您的團隊可能考慮的幾種潛在的選項類別(Anderson將其稱為服務類)。許多工作項屬於「標準」類，它們的優先順序主要基於它們對組織的業務價值。有些工作項目有固定的交付日期，這對於政府立法或與外部客戶簽訂的合約所產生的需求來說是很常見的。您還可能有少量(希望如此)的加急工作項，比如針對生產問題的關鍵修復或高優先順序的客戶需求。最後，你可能有一些低優先順序的「無形」工作項目，你知道在將來的某個時候你需要處理它們，你決定在團隊認為合適的時候處理它們(也許是為了簡化其他工作，從更具挑戰性的工作中休息一下，……)。需要注意的是，這裡描述的類別並不是一成不變的，您的團隊可能會識別出不同的類別，或者根本不需要進行分類。此外，在上面描述的敏捷策略中，服務類可以被支援為多個隊列。
• 目標是限制正在進行的工作(WIP)。當敏捷團隊努力選擇一個固定數量的功能，剛好足夠他們在一次迭代中實現時，精益團隊選擇產生一個連續的功能流，當他們有能力這樣做時，將工作拉入他們的「交付系統」。限制WIP可以提高團隊的交付可預測性，提高品質(由於回饋周期較短)，並提高生產力。
• 淘汰舊的工作項。精益團隊通常會努力確定老化規則,如果一個工作項池中超過一定的時間,從池中移除的假設下,如果它已經很長時間沒有重要到可以選擇從池中就可能永遠不會。如果工作項確實被證明是需要的，那麼它總是可以在將來的某個日期添加到池中。請注意，老化規則在不同的團隊之間會有所不同，一個團隊可能需要3個月，而另一個團隊可能需要5個月。此外，此策略可以應用於前面描述的產品backlog或工作項列表方法。

圖3。精益工作管理流程。

利益相關者可以通過以下幾種方式添加選項:

• 當團隊最初形成時，通過需求想像會話。
• 以利益相關者認為的即興方式。
• 當選項池接近空時，通過有目的的建模會話。
• 通過使用現有的生產系統來識別增強請求或缺陷報告。

4. 哪種策略適合你?

沒有一種策略在所有情況下都是最好的，你需要確定並選擇最適合你的策略。表1比較了這些策略。

表1。比較的策略。

原文：http://agilemodeling.com/essays/prioritizedRequirements.htm

本文：https://pub.intelligentx.net/node/709