最佳實踐，適用於整個產品研發團隊，參考：Scrum中文網知識庫
產品研發完整流程
準則
- 大的版本，按模組進行，把Product Backlog拆成多個Sprint Backlog進行；
- 產品超前設計1-2個Sprint，設計包括：UI設計、開發設計、測試用例設計；
- 設計超前後端開發1-2個Sprint；
- 後端開發超前前端開發1-2個Sprint；
- 所有需求，必須先經過需求確定階段，不允許直接提給開發同學；生產環境問題是bug不是需求，提給QA同學；
- 產品輸出必須詳盡，Sprint計劃會議後不允許修改需求。
角色
- 產品負責人
- Scrum Master
- 產品團隊：產品和設計同學
- 研發團隊：開發和測試同學
產品Worktile協作流程
研發Worktile協作流程（BED & FED）
研發Worktile協作流程（APP）
研發會議安排
Sprint計劃會議
-
每個Sprint都以Sprint計劃會議作為開始；
-
目的： Scrum團隊共同選擇和理解在即將到來的Sprint中要完成的工作；
-
週期： Sprint週期一般為1周，特殊情況不超過2周；
-
時長： Sprint計劃週數 * 2小時內；
-
成員： 整個團隊；
-
職責： Sprint Backlog的需求及優先順序來至產品負責人，對Sprint Backlog任務的安排、拆解、細化由Scrum Master完成；
-
標記： Sprint任務設定截止日期，Scrum Master心中要有數：產品同學當前Sprint的任務是設計同學之後1-2個Sprint迭代應該承接的任務；設計同學當前Sprint的任務是後端開發同學之後1-2個Sprint迭代應該承接的任務；後端開發同學當前Sprint的任務是前端開發同學之後1-2個Sprint迭代應該承接的任務；測試同學當前Sprint的任務應該在該Sprint結束前釋出。
-
Sprint原則
- Sprint任務優先，如需插入新的緊急任務需要與Scrum團隊協商（生產環境問題除外）；
- Scrum Master需要分清楚優先順序，並協調好開發任務；
- Scrum團隊需要齊心協力；
- Scrum團隊需要提前準備Scrum會議內容；
- Scrum Master是Scrum團隊一起的，並不是獨立出去的角色；
- Scrum團隊成員平等、齊心、自由。
每日Scrum會議
- 每日Scrum會議來確認每日要完成的Sprint待辦事項；
- 目的： 確認我們仍然可以實現Sprint的目標，交流進展和需要協作的問題；
- 週期： 每天；
- 時長： 每次不超過15分鐘；
- 成員： 整個團隊；
- 週期： 每天；
- 團隊成員依次快速描述自己昨天完成了哪些Sprint待辦事項、今天準備做哪些待辦事項、有哪些Sprint待辦事項需要其他團隊成員協調。
Sprint回顧會議
- 目的： 回顧一下團隊在流程、人際關係以及工具方面做得如何，討論並得出改進措施運用於下一個Sprint；
- 時長： Sprint計劃週數 * 1小時內；
- 成員： 整個團隊；
- 週期： Scrum Master發現可能存在問題時開，如進展順利可與下一次Sprint計劃一起開。
技術方案評審會議
- 目的： 評審技術方案以期獲得最好的方案，並給團隊介紹方案；
- 時長： 視具體方案；
- 成員： 相關開發同學；
- 週期： 技術方案實施前。
測試用例評審會議
- 目的： 評審測試用例，保證準確率和覆蓋率；
- 時長： 視具體產品而定；
- 成員： 產品和開發同學；
- 週期： 測試開始前。
文件協作
需求文件
-
在石墨上文件相應資料夾內，可多人實時編輯，秒級同步；
-
在部門共享盤裡新建文件放置石墨文件的連結：
圖表
- 包括：產品結構圖、產品用例圖、產品業務邏輯圖、測試用例思維導圖、業務實現邏輯圖；
- 在ProcessOn的對應小組內；
- 用於：需求文件內、實現相關文件、任務說明等；
- 對於用於描述功能實現的圖，在部門共享盤裡新建文件放置圖的連結：
配合環節輸出的具體要求
業務部門—>產品
-
需求說明
- 格式：Worktile任務
- 提至：App bug與需求收集 和 站bug與需求收集 專案的功能改進、新增需求、運營需求任務列表列表
- 要求：描述清楚需求的目標使用者、使用場景等；
- 模板：如何將新增需求描述清楚
- 這個需求的目標使用者有那些？
- 這個需求解決了什麼問題，解決之後達到怎樣的效果？
- 這個需求主要使用的場景是什麼？
- 是否有其他參考方案或競品？
- 未來三個月內，針對該需求實現後，我們的運營計劃是什麼？
-
活動策劃方案
- 格式：文件
- 提至：需求說明附件
- 要求：
- 模板：
產品—>設計、開發、測試
- 原型Mockup
- 格式：墨刀、Axure原型
- 提至：任務說明
- 要求：
- 僅交付設計師一份完整的原型圖；
- 原型圖要詳盡，每個功能點在原型上都有對應的標註；
- 原型圖以例項呈現需求；
- 原型圖示註儘可能精煉，不允許有概念模糊的文案或功能名稱出現；
- 原型圖不必填充圖片，以黑白灰深淺色的方法表現層級關係即可；
- 設計師在互動上的變更產品需提前/同步修改原型/文件；
- 最後保證原型圖與QA驗收的需求文件一致
- 模板：
- 產品需求文件PRD
- 格式：石墨文件
- 提至：任務說明
- 要求：
- 保持和視覺設計圖一致；
- 包括產品結構圖、產品用例圖、產品業務邏輯圖等；
- 需求說明需做到完備，儘量涵蓋正常狀態、資料缺失、服務異常等實際開發和使用過程中可能產生的各種情況。
- 模板：
設計—>開發
- 視覺設計圖和標註
- 格式：Zeplin
- 提至：任務說明
- 要求：
- 保持和PRD文件一致；
- 使用評論功能來儘量明確設計意圖，以及需要開發同學注意的地方：比如底部留白等；
- 使用拉線標註等方法，明確頁面中需要開發設定的元素，避免頁面中元素過多時，開發時遺漏；
- 動畫等動態互動需要提供具體、可復現、可操作的引數；
- 設計評審之後，本地共享盤放置一份jpg效果圖。
- 模板：
- 互動說明
- 格式：PRD
- 提至：任務說明
- 要求：
- 必要的標註；
- 模板：
開發—>測試
- 技術實現方案
- 格式：文件（邏輯流程、技術實現流程、儲存方案等為主）
- 提至：任務說明
- 要求：簡潔解釋
- 模板：
- 介面文件
- 格式：apiDoc線上文件
- 提至：任務說明
- 要求：
- [apiDoc定義規範]({% post_url 2017-11-08-apiDoc-define-standard %})
- [RESTful API定義及使用規範]({% post_url 2017-11-08-RESTful-API-standard %})
- 模板：https://api.baobaobooks.net/docs/account/
- 版本更新日誌
- 格式：文件
- 提至：任務說明
- 要求：清晰描述此版本修改的模組，已經可能涉及到的模組。
- 模板：
測試—>產品、開發
- 測試帳戶和模擬測試資料
- 提至：聯絡獲取
- 要求：
- 模板：
測試—>專案經理
- 測試報告/可釋出評估報告
- 格式：文件（資料為主）
- 提至：Worktile專案的“發版備忘”列表
- 要求：簡明清晰
- 模板：