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從簡單的列表模式變爲一張二維地圖，從而能容易地看到整個產品規劃的全貌，不僅能幫助業務人員整理產品需求，協助開發人員更快速便捷地瞭解客戶的需求，同時還能夠確定產品模塊的實現優先級，實現最大用戶價值。

在豬齒魚敏捷管理系統中，我們將史詩、用戶故事、發佈版本、衝刺迭代緊密結合，以史詩爲主軸，用戶故事爲核心元素，實現了發佈版本和迭代衝刺兩個維度的產品需求規劃，更加直觀、快捷地將用戶故事也其他的相關任務進行編排規劃。

通過選擇故事地圖的泳道類型，我們將故事地圖區分爲衝刺維度和版本維度兩種編排方式。

1. 衝刺維度

• 以史詩作爲地圖的橫軸座標，將地圖中的用戶故事根據史詩進行分類。

• 衝刺迭代作爲地圖的縱軸子tab頁，可以將地圖中的用戶故事放入對應的迭代。

• 未規劃區的故事是指已經分配了史詩，但是沒有編入任意一個衝刺迭代的用戶故事。

• 需求池是指未完成的，並且未分配史詩、也未編入任意一個衝刺迭代的用戶故事。

2. 版本維度

• 同樣也是以史詩作爲地圖的橫軸座標，將地圖中的用戶故事根據史詩進行分類。

• 軟件的發佈版本作爲地圖的縱軸子tab頁，可以將地圖中的用戶故事放入對應的版本。

• 未規劃區的故事是指已經分配了史詩，但是沒有編入任意一個發佈版本的用戶故事。

• 需求池是指未完成的，並且未分配史詩、也未編入任意一個發佈版本的用戶故事。

            

通過在故事地圖中對用戶故事進行操作，可以對用戶故事的史詩、迭代、版本進行直觀的編排，完成用戶故事的規劃過程。

總 結

在軟件系統的開發中，不論是瀑布流模式還是敏捷模式，需求管理都是開發過程中最重要的環節之一，細緻深入的項目需求和有效的需求工程管理可以讓項目成員所做的工作儘可能地明晰，每一分資源的投入都儘量保證有效地產出。開發者們花費了大量的精力開發的功能由於需求調研的失誤發現最後並沒有用戶去用，或者在大量的開發之後業務人員一句沒用便推倒了所有的設計，這些情況是項目管理中是十分常見和極爲頭疼的情況，不僅打擊團隊成員的積極性，激化產品和開發的矛盾，還會浪費大量的資源，導致返工頻繁、質量低下等結果。

需求管理在敏捷中並不是在項目開始就全部蓋棺定論的，在項目期初進行的是大致需求和核心功能的討論確定，但是後續實現的細節會在每次迭代完成後儘早的反饋給客戶，由實際的使用用戶來討論鑑定他們真正的需求，然後根據反饋的情況和效果進行鍼對性地修改，儘可能做到不合理的需求儘早發現修改，減少返工的成本，同時保證最終項目產出的結果是最爲貼合用戶需求的產品。

當然這種管理模式也會有一些弊端，比如在實際的項目管控中需要在項目開啓時便完成人天的預估，大量的需求變更會導致項目時間的不可控。其實這個問題反過來看，如果真的有如此之多的需求變更，那按照原先確定的需求執着地進行開發可能導致的後果會更加嚴重。所以在實際項目的中，如何讓需求管理也變得敏捷不是單純地用敏捷理論來生搬硬套，我們要切實的明白敏捷的核心理念，然後貼合實際項目的情況來做出對應的變化。讓敏捷管理真的能讓我們的項目敏捷起來，讓客戶、產品、開發者在敏捷中產生享受的快感。

關於Choerodon豬齒魚

Choerodon豬齒魚是一個開源企業服務平臺，是基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、數據、智能洞察、企業應用市場等業務組件，致力幫助企業聚焦於業務，加速數字化轉型。

大家可以通過以下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

• 官網：http://choerodon.io
• 論壇：http://forum.choerodon.io
• Github：https://github.com/choerodon/
• 微信：Choerodon豬齒魚
• 微博：Choerodon豬齒魚

歡迎加入Choerodon豬齒魚社區，共同爲企業數字化服務打造一個開放的生態平臺。