敏捷項目以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。本文通過一個真實的案例介紹了敏捷項目的實踐過程和產品經理在其中的角色和作用，與大家分享。

一、產品經理在敏捷項目中的角色

在敏捷交付項目中，PO扮演著重要角色。PO確定產品的方向和愿景，定義產品發布的內容、優先級及交付時間，為產品ROI（profitability of product）負責，是維護產品需求清單（ product backlog ）的人，代表利益相關者的利益。

PO在敏捷項目中的主要職責如下：

1. 確定產品的功能；
2. 決定發布的日期和發布內容；
3. 為產品的ROI負責；
4. 根據市場價值確定功能優先級；
5. 每個sprint中，根據需要調整功能和優先級（每個sprint開始前調整）；
6. 接受或拒絕開發團隊的工作成果；
7. 參與Scrum Planning Meetings（Sprint計劃會議），Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）

一句話總結PO的職責：告訴產品團隊要做什么，做功能的先后順序是怎樣的，需求有變動時該如何處理。

二、如何在一個月的時間完成20個史詩級故事？

毫無疑問，這是一個impossible mission。先看著個需求是怎么來的。

筆者服務過一家做園林綠化的公司，這是一個傳統行業，主要承接市政工程項目。老板在尋找新的市場機會，他看到了客戶在信息化產品方面的需求，決定投入智慧園林產業。老板希望為客戶提供信息化、智慧化的公園物聯網平臺和整體解決方案，以此增加公司的業務范圍，為此公司成了新的智慧公園事業部。

在前期在經歷了9個月的的探索并交付了一個內部用戶項目后，并沒有取得預期的成果，銷售部門不知道該賣什么也不了解客戶的需求，研發部門面臨巨大的交付壓力，老板對部門的整個部門的業績不是很滿意。

我作為新項目的高級產品經理，臨危受命，目的是就是幫助老板探索新的市場機會，盡早推出產品，讓銷售的兄弟可以帶著彈藥上戰場。

1. 愿景

愿景是描述了項目的發起原因以及預期的最終狀態。

–施瓦伯《scrum敏捷項目管理》

第一步是了解項目的需求。這里有兩個主要的利益相關者，一個是客戶，一個是老板。在經過兩周的市場調研、競品分析后，我決定對老板進行一次訪談以確定需求。經過訪談，確認了老板的關注點：

1. 盡快(最后確定下來是1個月)讓客戶看到智慧公園產品的樣子，包括軟件demo和硬件設備；
2. 盡可能充分展示公園的業務場景和設備(最后確認20個業務場景，40個設備)；
3. 在項目啟動前，提供項目的預算。
4. 可以先開發一個演示產品(MVP)，數據可以是靜態的。

如果按照以下公式來”一鍵生成”產品愿景：

今天，當【用戶群】 想要【期望的活動/結果】時，他們必須【當前的解決方案】 。

這是不可接受的，因為【當前解決方案的缺點】。我們相信有【一種體驗/一個場景/一項服務/…，是令人向往的】，我們通過【技術/方法】達成它。

那么，本項目的愿景就是：”今天，當客戶想要了解我們的產品時，他們只能通過畫冊的方式，這種體驗不是很直觀，他們看不到設備的狀態和運營數據，我們要給客戶一種更接近實際效果的產品體驗，我們希望通過開發一個演示產品達成它。”

Got it，原來老板就是想做一個演示APP!

通過這個APP客戶會可以進行瀏覽、拖拽、點擊等交互操作，可以看到運營數據和設備的狀態(演示數據)，甚至可到公園的視頻監控畫面(提前錄好視頻)。

本項目和BOSS溝通后決定采用敏捷項目交付產品，主要目的是:

• 簡化文檔
• 提高效率
• 盡早交付

敏捷項目有很多好處。其中一個就是交付可供客戶使用和驗證的最小可行性產品（MVP），獲取反饋后再不斷迭代改進，連接真實的設備和數據，最終打磨出真正符合客戶需求的爆款產品。

在愿景階段我們還需要確定任務角色和場景，以及發布產品路線圖。

2. 人物角色和場景

角色可以幫助我們確定目標客戶，也就是“誰”的問題；場景可以是我們理解產品如何改變客戶的生活角，確定“在什么情況下”“干什么&遇到什么問題”?？刹捎妙^腦風暴和業務場景技術確定任務角色和場景，本項目確定任務和主要場景如下：

3. 產品路線圖

接下來是創建產品路線圖，產品路線圖是產品需求的高層次概述，產品路線圖 將用戶關注點/主題按優先級排序，分成若干階段，每個階段都需要一個Sprint計劃。創建產品路線圖需遵循4 個步驟：

1. 確認需求
2. 將需求分類或分定主題，
3. 評估相對工作量和優先化級，
4. 評估粗略時間框架（評估sprint持續時間，以及粗略發布時間）

本項目是整個產品路線圖的第一個階段。

三、發布計劃

發布計劃是宣布產品對外發布的時間和功能范圍，大部分軟件項目以每 2 到 6 個月作為一個發布周期，一般以產品開發線路圖開始規劃發布。

1. 確認優先級

優先級排序是根據利益相關者的關注點(或主題）確定版本發布的計劃。如何排列出關注點(或主題)的優先級呢？

這里推薦莫斯科規則（ MoSCoW ) 排列優先級的方法，MoSCoW將功能分為四類：

1. 必須有（Must ) ：指系統的基本功能
2. 應該有 ( Should ) ：很重要但短期內有替代解決方法的功能
3. 可以有 ( Could ) ：如果沒有時間可以不予考慮
4. 這次不會有 ( Won’t have this time ) ：客戶期望擁有但同時承認需要在后續發布中實現

本項目討論后確定的優先級如下：

2. 選擇迭代長度

團隊所有成員一起選擇一個適合的 Sprint 長度，一般建議1～4周。本項目的一個sprint的長度是2周時間，分成兩個sprint，共四周時間。

3. 任務估算

（1）史詩故事(Epic story)

史詩故事是故事的主干，相當于用戶故事的大綱。本項目把按照MoSCoW排序的關注點分解為20個用戶場景，相當于20個史詩故事，每個史詩故事包括2-3個用戶故事，一共是50個用戶故事。

（2）故事點數(Stroy Point）

項目需要估計預算，所以需要估計工作量，這里用到了敏捷中的故事點數。故事點數代表了開發用戶發故事所需的全部工作量，故事點通常用于評估交付產品的價值，也可以用于評估成本。

一般情況估算故事點是比較困難的事情，但本次項目比較特殊，由于只需要開發靜態頁面，所以工作量主要集中在設計和前端開發上。

團隊很快確定了通過頁面數量確定故事點數的方式，也就是先估計開發頁面的數量，有個頁面數量開發量就很容易估算了。也就是：

故事點數=頁面數量*單個頁面的工作量（0.5天）

本項目中每個用戶故事分配了1個頁面，每個頁面分配了2個故事點，所以項目的規模在50個故事點數(相當于25人天)。有了故事點數再乘上平均人工成本，就很容易估算出項目的費用(主要是研發成本)。

4. 建立發布計劃

最后一步是將 Story 按照優先級分別分配到每個 Sprint 中。有兩種發布Sprint的方式，一種是釘在墻上這樣可視化的方式讓團隊成員每天能看見。

還有一種是Leangoo這樣的軟件發布電子版本的Sprint計劃(見用戶故事一篇)。

5. 迭代計劃

迭代計劃的目的就是確認每個sprint階段的任務單（ticket）和優先級。這里要引入一個敏捷里的重要實踐 – Spint 會議，整個團隊通過舉行 Spint 會議來為下一輪 Sprint 做計劃，會議的內容包括：

（1）討論故事

通常是對已經排好優先級的史詩故事和用戶故事進行討論，以確保成員理解開發任務。

（2）從 用戶故事分解為任務單（ticket）

此步驟是將用戶故事分解為顆粒度更小的任務單(ticket），通常寫在一個人任務卡上。

（3）開發人員承擔每個任務的職責

開發人員可以在分解任務之后對任務進行認領，每個卡片都需要有一個責任人。

（4）討論所有故事，開發人員單獨估計承諾他們的任務

每個開發人員對認領的任務進行詳細估算，如果 Sprint 時間內估算超過了開發人員所能承擔的工作量，有以下幾種選擇：請求團隊其他成員接受一些任務；與 PO 討論，放棄其中一個 Story （或者是分解后的一部分）。

6. Sprint評審

Sprint評審的目的在于演示階段性成果，評審相關的 Backlog 中的問題，檢查是否已達到 Sprint 的目標。Sprint評審在會議中向最終用戶展示工作成果，并獲得反饋，Sprint評審可邀請利益相關者參與。

本項目的Sprint評審在每一個Sprint發布后進行，由PO主持，主要評審人為BOSS、事業部主管和銷售經理。

7. 站立會議

站立會議是scrum中的一個重要實踐，也是筆者認為最容易推廣和執行的敏捷活動。會議需要敏捷小組全員參加，會上每個人輪流發言，就4個問題回答：

1. 我們上次開會后你都干了什么？
2. 每個你負責的、正在做的任務還剩下多少時間？
3. 下次開會之前你要做什么？
4. 你的工作被阻礙了嗎？

如果有人在會議上提出工作被阻礙，PO在會后要及時解決會議上提出的阻礙，發現并解決問題是站立會議的主要目的。

站立會議一般是封閉的，只有敏捷小組成員參加，如果非團隊成員闖入并發言，他會背上一個不好聽的名字。

本項目的站立會議每天上午9點準時進行，效率很高，每次15分鐘就結束了。每次開會的時候總感覺有一雙眼睛在遠處默默的注視著我們。

8. 回顧會議

回顧會議在每輪迭代結束后舉行的會議，目的是分享本輪迭代好的經驗和改進點，促進團隊不斷進步。一般圍繞著三個主題討論：本次迭代哪些做的最好，哪些能做的更好，下一次迭代準備在哪些方面改進。

寫在最后

本項目最終比預期完了三天結束，盡管還有很多不盡人意的地方，但大家都全力以赴，最終結果也得到了公司的認可?；仡檿?，大家也都表達了反思和收獲，我能看到每個人都在進步和成長，我想這就也正是敏捷倡導的學習型組織的意義吧！

#相關閱讀#

B端產品經理養成記（1）：業務場景

B端產品經理養成記（2）：用戶故事

B端產品經理養成記（3）：訪談

作者：濤哥，微信公眾號：濤哥筆談。前華為高級產品經理，TOGAF認證專家，PMP認證專家，PPV課數據科學社區創始人，數字化轉型實踐者

本文由 @濤哥 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議