Choerodon豬齒魚敏捷管理實踐（一）——需求管理
本文是敏捷管理系列的第一篇，將介紹敏捷中重要的需求管理，涉及需求的獲取和管理，以及後續規劃問題。
▌主要內容：
- 瀑布流開發模式弊端
- 敏捷需求管理
- 如何獲取需求
- 如何管理需求
- 史詩
- 使用者故事
- 如何編寫使用者故事
- 如何規劃需求——故事地圖
- 總結
瀑布流開發模式弊端
在介紹敏捷之前先介紹一下瀑布流模式，這是產品開發中非常常見的一種管理模式，它以文件為驅動，在整個開發過程中，開發人員根據需求文件進行開發。所以在專案初期，確定需求和文件至關重要，通常在專案初期整個專案和產品便已經有了較為明確的雛形，專案成員需要嚴格按照需求文件和專案計劃完成各自需要完成的工作。
由於在開發的中後期才會看到軟體原型，早期只能通過文件來了解系統的模樣，因此在一定的階段，需求文件看起來會比產品實際的程式碼要重要。
這樣的需求管理方式在傳統軟體系統管理中的優勢在於可以在專案初期確定開發內容，更便於確定產品範圍、人天預估、難度確認等，可以大大地減少專案失敗的風險，同時專案成員也能通過詳盡的文件來確認自己的職責和範圍。但是這種管理方式在日新月異的產品開發中顯得越來越笨重，在實踐的過程中產生了以下難以解決的衝突和問題，比如：
-
需求變更：需求變更是軟體研發中經常遇到的一種情況，而在瀑布流的方式中，軟體開發的後一階段都是在前一階段交付後才開始實施，流程多、週期長，這樣的特點導致瀑布流在應對需求變更時需要付出很大的代價。
-
質量管理：瀑布模式的測試階段往往在大塊功能開發完成後才會開始，在產品開發的時間線上都會比較晚，若測出來比較大的缺陷，可能導致產品無法準時上線。
-
成員積極性：由於需求驅動性開發，開發人員容易形成“事不關己”的態度，機械性的等待設計人員或者前階段的產出與設計，不會站在客戶或者實際使用者的角度去進行功能開發，導致開發出的功能常常“很難用”，一旦形成返工修改的惡性迴圈，甚至導致專案延期，會進一步打擊專案成員的積極性。
-
過度開發：由於需求劃定早，但是實際產出較晚，大概率出現實際上線的功能不符合預期或者花了大量時間在使用度並不高的功能上。導致過度開發的時間成本浪費。
-
適應性：市場需求、客戶需求等對於產品的實際預期大概率會產生變化，現在產品需求的靈活度、創新性和變化度變得越來越頻繁，瀑布式的開發模式由於開發流程時間長的特點很難適應這種場景下的需求管理。
針對以上傳統瀑布流開發模式的弊端，敏捷管理的思維應運而生。在下面的文章中，將會以需求的產生、管理和規劃三個部分去詳細描述敏捷團隊如何來處理軟體開發中的需求。
敏捷需求管理
如何獲取需求
需求實際上分為業務需求和軟體需求，業務需求由不一定熟悉IT的業務人員完成，來源很廣，會脫離實際的實現方式，著重於功能的描述。而軟體需求由開發人員根據業務需求編寫，通過基於技術實現的角度對業務需求進行篩選、梳理、歸納，通過演算法、架構、資料庫等設計過程完成向軟體需求的轉化。
在此主要討論業務需求如何獲取，如果一個敏捷團隊能夠有現場客戶，這當然是最理想的情況。但在大多數情況下，我們很難在實際操作中將敏捷團隊與客戶進行無縫結合，這時候，在敏捷團隊中充當客戶這個角色的人往往是敏捷團隊的PO，PO最重要的職責就是與客戶、實際使用者等“終端實際使用者”進行交流，能夠找到並制定軟體系統的功能範圍，充分了解和分析需求，找到並確定軟體系統真正有用的需求，並將其轉化為系統的業務需求，即後續的使用者故事。
一個優秀的PO可以做到如下工作內容：
- 在產品積壓列表（Backlog）中建立容易理解的、可行的故事。
- 根據優先順序調整 Backlog 中故事的完成順序，以最優的計劃實現設定的目標。
- 優化並最大化scrum團隊的輸出。
- 通過儘可能梳理清楚團隊內外所有相關的事項，以避免混亂。
- 幫助團隊對後續的迭代進行規劃。
- 為產品驗收定義標準和關鍵指標
PO在規劃產品需求的過程中，要對產品的商業價值有足夠的理解，只有這樣，才能把產品分解成小的獨立交付價值體，同時也能夠對產品待辦列表進行優化和價值排序，以便團隊能夠始終將工作投入在價值最高的產品功能上。
如何管理需求
在敏捷管理中，產品需求同樣也是非常重要的環節和組成部分，團隊的所有活動都會基於需求展開，由產品負責人維護和排列各自的優先順序。在敏捷管理體系中，我們將需求對映為使用者故事，同時使用史詩對需求進行更粗粒度的劃分和規劃。
史詩
在專案開始，我們在定義一個產品的粗略範圍的時候如果直接以使用者故事作為唯一的細粒度標準進行劃分的話，會非常混亂，因為一個系統往往非常複雜，直接對一整個系統進行分析拆分其實是很困難的。所以針對這種情況，豬齒魚敏捷管理引入了史詩的概念。
史詩是有一個共同目標的大量工作，類似但是區別於系統的“模組”概念，通過定義史詩來劃分產品的功能線，再基於史詩來詳細討論相關的使用者故事，史詩通常需要多個衝刺才能完成。同時，史詩會隨著時間的推移變化，並不是在產品規劃的初期就能確定史詩的規模大小，他會通過一系列衝刺對範圍進行修改以適應需求的變化，隨著團隊通過開發和客戶反饋，團隊成員會不斷新增和刪除史詩相關的使用者故事，以優化團隊的釋出時間。
使用者故事
使用者故事（User Story)是指使用者通過系統完成的一個有價值的目標，使用者故事只是描述系統的外在行為，完全忽略系統的內部動作。好的使用者故事應該包括角色、功能和商業價值三個要素。一個完整的使用者故事可以涵蓋以下問題：
- 實際使用的角色是誰？——期望使用者的型別
- 具體要使用的功能是什麼？——我希望功能
- 完成這個功能的原因是什麼？——產生的價值 和好處
因此，一個使用者故事的經典格式為：作為一個角色 , 我想要功能 , 以便於功能價值。
如何編寫使用者故事
使用者故事的定義必須是從真正業務使用者的角度，不可以是“技術使用者（開發者本身）故事”，在編寫使用者故事之前，應該清楚地瞭解建立使用者故事的使用者是誰，所以，做一個適當的使用者調查，區分所有的使用者角色並根據使用者角色對故事進行區分是非常必要的。通常，客戶代表（如產品所有者）負責使用者故事。儘管如此，使用者故事並不是高層給團隊的規範，而是產品所有者和團隊之間的協作技術，這就是為什麼如果使用者故事是合作編寫的更好。一個好的方法是成立一個故事編寫研討會，由團隊合作編寫。
為了構造好的使用者故事，我們關注以下兩個原則：NVEST 原則和 3C原則
INVEST 原則
-
Independent 相互獨立的：使用者故事之間應該是相互獨立的，相互關聯依賴的故事會導致故事的優先順序和計劃編排變得很困難，複雜的依賴更會導致故事的難以預估和控制。通常我們會通過組合使用者故事、分隔使用者故事的手段去減少使用者故事之間的依賴性。使用者故事的獨立性越高，越能根據實際情況去確立故事的優先順序以及預估故事完成的可能性。
-
Negotiable 便於協商的：使用者故事包含了一個需求的簡短描述，而詳情是通過相關人員（客戶、需求人員、開發人員等）之間通過討論階段來完成，如果使用者故事非常詳細會導致故事的可討論、可協商性大大下降，不便於更好地溝通及協商，也就不可能劃分出既讓客戶滿意，也能讓開發認同的好的使用者故事。
-
Valuable 有價值的：使用者故事一定是站在客戶和使用者的角度去思考和編寫的，描述的是產品的一個一個功能，而不是實際實現的任務。
-
Estimable 能估算的：功能的實現者需要去評估一個使用者故事，來確定他的規劃。估算一個使用者故事需要一定的領域知識，同時太大的故事也會導致估算的不準確。
-
Small 適量小的：故事在評估時在工作量上要小一些，以不超過一個迭代週期為宜（我們實踐中1-3天是一個比較合適的量），短小的使用者故事可以減少劃分過程中估算的誤差，否則很容易在劃分範圍和估計時出現很多錯誤。
-
Testable 可驗證的： 這點用於確定使用者故事是否完成，如果一個故事無法進行測試，那我們就無法確定這個使用者故事是否完成了，在劃分故事時，最好確定一個故事的驗收標準，這一點很重要。
3C原則
-
Card 卡片：作為使用者故事的書面描述，不會包含詳細故事細節，更多的是一個提醒，一個必須跟進後續溝通的承諾。
-
Conversation 交談：與產品負責人和客戶的交談中獲取故事背後的細節，可以通過一些文件進行補充。
-
Confirmation 確認：使用驗收測試來確認故事是否完成，是否符合工作要求。
在這裡需要注意把握需求文件與敏捷故事的平衡點。需求文件屬於產品級的文件，不論一個軟體系統經過多少次的重構開發，它的核心功能是不會有太大的變化的，這類描述產品的需求文件是專案中不可缺少的一部分。而使用者故事則是專案級的功能描述，類似於做完就會扔掉的“拋棄型”需求。很多企業和團隊在實踐敏捷流程時，對於是否需要編寫需求文件經常產生疑問，在實際的操作中，可能部分強調快速交付，或者生命週期很短、業務模式高度可變的網際網路、網遊等專案，是可以減少甚至放棄需求文件而全部使用故事來管理需求，但是現階段要求企業的IT專案全面接納需求完全無文件化其實並不是很現實。
在這裡我們認為更合適的方式是找到需求文件與敏捷故事之間的一個平衡點，理性的辨別兩者的區別，一份需求用例加上使用者故事，然後驅動開發這種方式可能更適合大型企業的敏捷需求實踐模式。
如何規劃需求——故事地圖
在上文，我們已經確定了軟體系統的開發範圍，找出了需要實現的業務需求，同時根據使用者故事的編寫原則生成大量對應的使用者故事，並且在迭代規劃中按照優先順序挑選出迭代需要完成的使用者故事，將這些故事放入了下圖的待辦事項（Backlog）中。
但是我們如何對這些需求進行規劃管理？如何將待辦事項（Backlog）的故事列表在時間軸上進行編排呢？
為了更好地對使用者故事進行規劃，敏捷中使用 故事地圖（User map）作為故事管理方式。故事地圖會將產品的backlog從簡單的列表模式變為一張二維地圖，從而能容易地看到整個產品規劃的全貌，不僅能幫助業務人員整理產品需求，協助開發人員更快速便捷地瞭解客戶的需求，同時還能夠確定產品模組的實現優先順序，實現最大使用者價值。
在豬齒魚敏捷管理系統中，我們將史詩、使用者故事、釋出版本、衝刺迭代緊密結合，以史詩為主軸，使用者故事為核心元素，實現了釋出版本和迭代衝刺兩個維度的產品需求規劃，更加直觀、快捷地將使用者故事也其他的相關任務進行編排規劃。
通過選擇故事地圖的泳道型別，我們將故事地圖區分為衝刺維度和版本維度兩種編排方式。
衝刺維度
- 以史詩作為地圖的橫軸座標，將地圖中的使用者故事根據史詩進行分類。
- 衝刺迭代作為地圖的縱軸子tab頁，可以將地圖中的使用者故事放入對應的迭代。
- 未規劃區的故事是指已經分配了史詩，但是沒有編入任意一個衝刺迭代的使用者故事。
- 需求池是指未完成的，並且未分配史詩、也未編入任意一個衝刺迭代的使用者故事。
版本維度
- 同樣也是以史詩作為地圖的橫軸座標，將地圖中的使用者故事根據史詩進行分類。
- 軟體的釋出版本作為地圖的縱軸子tab頁，可以將地圖中的使用者故事放入對應的版本。
- 未規劃區的故事是指已經分配了史詩，但是沒有編入任意一個釋出版本的使用者故事。
- 需求池是指未完成的，並且未分配史詩、也未編入任意一個釋出版本的使用者故事。
通過在故事地圖中對使用者故事進行操作，可以對使用者故事的史詩、迭代、版本進行直觀的編排，完成使用者故事的規劃過程。
總結
在軟體系統的開發中，不論是瀑布流模式還是敏捷模式，需求管理都是開發過程中最重要的環節之一，細緻深入的專案需求和有效的需求工程管理可以讓專案成員所做的工作儘可能地明晰，每一分資源的投入都儘量保證有效地產出。開發者們花費了大量的精力開發的功能由於需求調研的失誤發現最後並沒有使用者去用，或者在大量的開發之後業務人員一句沒用便推倒了所有的設計，這些情況是專案管理中是十分常見和極為頭疼的情況，不僅打擊團隊成員的積極性，激化產品和開發的矛盾，還會浪費大量的資源，導致返工頻繁、質量低下等結果。
需求管理在敏捷中並不是在專案開始就全部蓋棺定論的，在專案期初進行的是大致需求和核心功能的討論確定，但是後續實現的細節會在每次迭代完成後儘早的反饋給客戶，由實際的使用使用者來討論鑑定他們真正的需求，然後根據反饋的情況和效果進行鍼對性地修改，儘可能做到不合理的需求儘早發現修改，減少返工的成本，同時保證最終專案產出的結果是最為貼合用戶需求的產品。
當然這種管理模式也會有一些弊端，比如在實際的專案管控中需要在專案開啟時便完成人天的預估，大量的需求變更會導致專案時間的不可控。其實這個問題反過來看，如果真的有如此之多的需求變更，那按照原先確定的需求執著地進行開發可能導致的後果會更加嚴重。所以在實際專案的中，如何讓需求管理也變得敏捷不是單純地用敏捷理論來生搬硬套，我們要切實的明白敏捷的核心理念，然後貼合實際專案的情況來做出對應的變化。讓敏捷管理真的能讓我們的專案敏捷起來，讓客戶、產品、開發者在敏捷中產生享受的快感。
#關於Choerodon豬齒魚
Choerodon豬齒魚是一個開源企業服務平臺，是基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、資料、智慧洞察、企業應用市場等業務元件，致力幫助企業聚焦於業務，加速數字化轉型。
大家可以通過以下社群途徑瞭解豬齒魚的最新動態、產品特性，以及參與社群貢獻：
- 官網：choerodon.io
- 論壇：forum.choerodon.io
- Github： ofollow,noindex">github.com/choerodon/
- 微信：Choerodon豬齒魚
- 微博：Choerodon豬齒魚
歡迎加入Choerodon豬齒魚社群，共同為企業數字化服務打造一個開放的生態平臺。