唯品會靈活Scrum實踐2：産品開發、路線圖與需求管理

作者介紹

邱戈川，現任唯品會基礎架構部分布式服務架構、定時任務排程系統以及容器化管理平台産品經理。16個年頭的it老兵，除了銷售和老闆角色，做過it中的各種角色，遊走于架構與産品間。關注docker、mesos等容器化技術領域的實踐。主導的分布式服務架構已經廣泛用于唯品會各大核心業務系統，以高性能、低延遲廣受好評。個人訂閱号：vipdocker。

1産品開發節奏的思考

談到産品開發節奏，不得不說一下scrum中的backlog、疊代和planning game。backlog和planning game的操作細節後面細講，這裡隻是說下和開發節奏的關聯性。

疊代上一般的指引是2-6周，但是具體如何做更合适就沒有人說清楚了。這裡可以給我們實踐的作為參考。

首先我們要區分是否是需要釋出生産的産品還是隻是釋出開發包給業務做開發産品。對于釋出生産的産品，我們做法是5周一個大疊代，前面每兩周一個小疊代，最後一周是大疊代的總結，下個大疊代的planning game，以及做釋出的相關事宜等。對于隻是釋出開發包的産品如隻需釋出到maven庫等，則4周一個大疊代，每兩周一個小疊代。

無論哪種産品，對于一次大疊代的結束都要以可釋出的版本作為成果。

每個大的疊代中總會遇到不同的情況，如就要到來的雙十一的支援工作等，但是需要做的不是去推遲版本的釋出，而是去判定哪些是重要的高優先級的需求，将其縮小到可以釋出為止。

談到版本的管理，下一篇再細談，也買個關子。不過有個搞笑的事，有同學竟然問我什麼時候可以不用出版本？我隻能笑而不語，因為從産品的角度，沒有版本可出就将意味着産品已經到頭了。

簡單而言，每次大疊代都要讓團隊看到可以運作的産品，能給客戶帶來新價值的産品，進而樹立對産品的資訊和興趣。

backlog的管理可以借助多種工具做管理，可以是一張execl表，也可以放wiki上描述都可以。但是從開發節奏的角度，疊代的範圍從一開始大疊代就要謹慎做出選擇。雖然backlog大家都知道需要明确标明優先級，但是在每個大疊代做選擇時是否都是需要選高優先級的呢？我們的答案時“否”。在所有backlog裡有超過5個／最好3個高優先級的需求，這個優先級将失去意義。

産品經理一定要強迫自己根據疊代的人力的一半情況，選出2-3個真正最高優先級的需求，然後配套安排些提高性的需求一起做為大疊代的範圍。這樣才有可能在每次小疊代總結的時候，確定高優先級的需求在有幹擾的情況依然能被完成，而提高性的需求則是可以随時調整出版本範圍的。從經驗上看，很多時候無法出版本的原因就是同時有多個高優先級的特性功能在開發，而受外界影響時又都無法完成，最終造成産品無可運作的版本，隻能延期。

planning game對于開發節奏的影響最大在于前期的準備是否足夠充分。很多人了解上planning game的目标是為了評估工作量，但是其實最大的目的是讓所有人了解需求、了解架構設計、了解外圍影響。隻有把需求分析、架構設計、風險評估提前做好，才有可能確定開發節奏不受影響。

最後一點，無論遇到什麼情況，想到的事情是砍需求，而不是去改變版本計劃。因為每次大疊代就像培育一個孩子，中途夭折将打擊團隊的激情，也同時影響外界對于産品和團隊的口碑。當然也有可能遇到需求砍無可砍的地步，如我們最近做的版本，隻有一個需求，那麼無法完成，唯一可做的就隻有延期了。節奏同時也會影響你的生活品質，無序的步驟将是大家加班噩夢的開始。

2産品路線圖的定義

産品和項目最大的差別在于産品是有自己的路線圖roadmap，也就是自己的生命周期。roadmap該如何定義更容易管理？這個問題我們内部有過不小的争議，因為它容易和release management混淆在一起。先來看看roadmap的目的，再談下我個人的看法。

roadmap的目的是去定義産品的模樣vision以及它的重要特性。就像描述一個人的成長曆程，他兒童時什麼樣，青年時什麼樣，中年什麼樣，老年什麼樣。

release mangement則是描述什麼時候産品達到什麼階段。例如在0.0.1版本，隻是具有爬的功能，并不代表他已經是兒童時了。也就說可能需要多個版本才能描述出産品roadmpa中的某個階段。

本人不是那種教科書的教條主義者，個人喜歡的做法是用魚骨頭來描述不同版本的功能特性來展示産品的線路圖，也就是混淆了roadmap和relase managment，如下圖例子：

混淆的好處是管理起來比較簡單，不過這個做法見人見此了。

3需求的管理–backlog

這裡可能有些公司還需要管理mrd(market requirement description)，這個通常是與業務緊密度比較高的時候。mrd的做法可以有很多種，比較常見的方式是寫一段故事user story，并不涉及任何實作細節，隻是需要将使用者的期望描述清楚。

backlog的做法一般是與産品，與實作技術有某種結合顆粒度比mrd小，當然也可以是寫user story。我們的做法相對“寬松”隻要描述清晰就好，形式沒有要求。backlog的管理我們放在了一個wiki的表格中，每個backlog的管理，需要考慮以下細節：

id: 需求編号，便于追蹤

title: 标題

description: 需求較長的描述

priority : 優先級

fesibility study: 是否需要需求分析

solution: 是否需要架構／方案設計

review: 是否需要評審需求分析或方案

status: 目前狀态

action: 計劃的實施的版本

日常操作上，我們的方式是每個大疊代開始前，和相關的關系人（通常是你的上司，或者商務的代表等）一起過這張表格，在了解、優先級等方面達成一緻。

工作task!=backlog

在團隊日常工作任務管理，包括planning game中需要預先定義出來評估的任務，直接使用backlog是不合适。我們的做法backlog通常是一個比較大的feature(功能特性)，需要做詳細的分解如需要分為：前端開發、後端開發、測試點設計、性能測試等等。

用作task管理的工具很多，不過我們為了簡便直接使用gitlab的issue來做管理，同時開發在送出代碼的時候同時注明issue的id（git commit的時候備注寫#xxx），這樣做代碼評審就可以關聯看具體是什麼問題做的送出了。backlog拆解成task的顆粒度的把握是比較講求藝術的地方，太細的話工作起來比較繁瑣，太粗不容易跟蹤協調。建議是3天内的工作做為一個大小參考值，不過如果團隊比較不夠成熟的話，建議控制在1天内的次元比較好，這樣每天的站會溝通容易盡早發現問題并作出調整。

4開發與測試的配合

溝通、溝通還是溝通，團隊配合無論什麼角色，最重要的還是溝通，順暢的溝通。溝通的效率很大程度上反映了一個團隊的成熟程度。但是在工作中，由于工具的多樣化，使很多人把人與人之間的溝通變成了人與工具的溝通。有些很搞笑的例子給大家分享下，曾經看見過肩靠肩坐的兩位仁兄在互相寫一對一的郵件。最經常發生的是，對于可以立即解決的問題，大家的屁股不願意離開自己的座位互相間說一聲，而是大篇幅的和im工具溝通。其實離開下座位對大家身體也有好處。

開發和測試的資訊來源将都來自于産品需求，而不再通過開發提測試提要求的模式。

開發與測試的定位的轉化。在scrum模式下，開發與測試的工作邊界将更加模糊。開發在做測試用例開發，測試也在做測試用例的開發。但是測試有個最主要的功能是測試點的設計，如何設計出更全面，更有條理的測試點，協助開發思考實作過程中遺漏的需求、遺漏的異常保護等才是測試的價值所在。而不是通過複雜的重複性工作來展現測試的價值。

測試應該更好的思考如何提供便利的工具、便利環境讓開發很快得到代碼的測試結果。如在30分鐘内就可以評估出來新功能的引入是否對性能造成了影響。

開發則應該配合測試一起詳細review測試點的設計，并進而思考開發中潛在的問題。在某些代碼作出改變的時候，則應立即提醒測試潛在的風險做好相應的回歸。

那麼什麼尺度把控測試開始工作呢？答案是demo。每個功能特性，在大家都難以把控是否能做完整的情況下，團隊任何成員都可以提出需要開發的作者做示範的要求。一來可以讓産品來看看是否滿足他的需求，二來測試也可以看看是否有信心開始做相關的測試。

最後，我用我常說的一句話作為總結：開發應該drive測試，測試應該drive開發。

 原文釋出時間為：2016-11-17 

本文來自雲栖社群合作夥伴dbaplus