517
京東網上商城
唯品會敏捷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測試點的設計，並從而思考開發中潛在的問題。在某些代碼作出改變的時候，則應立即提醒測試潛在的風險做好相應的回歸。
前麵一篇《唯品會敏捷Scrum實踐係列1：團隊組成和人員配比》，我提到了我個人是反對“提測”這個概念和做法的，因為這樣會人為的割裂開發與測試。Scrum模式下開發每做一個特性都應該是可以運行的，測試不應該等待整個迭代完成才開始測試，而是在每個可以端到端運行的功能特性完成的時候就進入測試。開發的迭代是一個一個的小循環，測試也應該是一個一個的小循環。“提測”概念下你總會聽到這樣的聲音：“你真的做完了？你單元測試也做了？別讓我重複測哦。”
那麼什麼尺度把控測試開始工作呢？答案是Demo。每個功能特性，在大家都難以把控是否能做完整的情況下，團隊任何成員都可以提出需要開發的作者做演示的要求。一來可以讓產品來看看是否滿足他的需求，二來測試也可以看看是否有信心開始做相關的測試。
最後，我用我常說的一句話作為總結：開發應該Drive測試，測試應該Drive開發。
原文發布時間為：2016-11-17
本文來自雲棲社區合作夥伴DBAplus最後更新：2017-05-11 11:31:15