起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從5個會議入手，聊聊Scrum敏捷開發實戰
筆者介紹了Scrum敏捷開發模式應該包含的五個會議及內容，并舉例說明了該如何解決迭代中遇到的問題。
一、開發模式
我們團隊用的是Scrum敏捷開發模式，這個模式的優點是：比傳統的瀑布式開發靈活，但是對于團隊中每個人的要求又比較高。
Scrum中有三個角色，分別由PO、Scrum Master、項目成員組成。那我在這邊就是Product Owner的角色，也就是項目的負責人。
一般產品經理在需求分析、確定需求之后可能就開始做原型設計和寫PRD文檔了。但是在這個開發模式下，我是不寫PRD文檔的，我會把所有想法體現在原型上，再加上相應的備注，如果說開發人員遇到問題就會找到我問清需求。因為Scrum的最關鍵的點就是多溝通，用溝通來替代文檔。
當然，如果在開發的時候直接扔個原型給開發，那他們肯定一臉懵逼然后想把你打一頓。
為了產品經理的人身安全，所以這就涉及到我接下來要說的Scrum五個會議：由需求澄清會、計劃分析會、站立會、評審會和回顧會組成。
1. 需求澄清會
顧名思義，就是澄清需求，但是人家就會問了，你沒有PRD你澄清什么需求。
對的，我準備的是User Story，也就是用戶故事：如果說我是這個產品的用戶，我要實現什么功能。
這邊的功能描述可能就是“我想要有XXX增刪改查的功能”而不是詳細到“我的提交按鈕要放在哪里”。
簡單點說，就是這個用戶故事是有一定的顆粒度的，但是它在所有產品的設計者、開發者和使用者的理解下是沒有歧義的。只要我們大家都確定了，我們要做的就是這樣的一個東西那就沒有問題。
因為用戶故事都比較多，我們一般會把用戶故事排一下優先級，然后根據優先級把用戶故事分成幾次sprint來做，就是不斷地迭代。每次迭代的周期很短，一般是一周或者是兩周，還有迭代出來的一定是一個可以使用的產品，可能功能有點缺陷，但一定是可以正常使用的產品。
2. 計劃分析會
計劃分析會，就是根據原型還有用戶故事分task。
這個會議一般由SM來主持，當然這里的SM不是你想的那個SM。
因為之前已經開過需求澄清會了，開發人員也知道了需要開發什么樣的產品，這時候就可以根據每個用戶故事對著原型分任務了。
需要注意的是：這里的每個任務都是開發人員自己分給自己的，比如：后端開發看到這個頁面，需要寫幾個接口，每個接口大概需要多少小時，需要前端人員如何配合，這都是需要在這個會議搞清楚。所以為了后續的正常開發，這個會議一般都會比較長，大概需要4-5個小時左右。
3. 站立會
這個是每天都需要開的會議，每個項目成員都說一下自己昨天做了什么工作、今天做了什么工作。
這個會議的話主要是前端開發和后端開發之前的互相配合，就是為了避免前端已經擼好了一個界面但是沒有接口對的尷尬情況。
4. 評審會
主要是進行本次迭代的功能評審，對照用戶故事，我們是不是已經完成了這幾個用戶故事所說的內容。
5. 回顧會
分析這次迭代我們團隊有什么優點、有什么缺點、可以怎樣改進，產出對應的改進措施。
敏捷宣言：個體和互動高于流程和工具；工作的軟件高于詳盡的文檔；客戶合作高于合同談判；響應變化高于遵循計劃。
二、第一次迭代遇到的問題及改進方案
1. Task漏項
在第一次使用該模式開發的時候，遇到的最大問題就是task漏項。這說明了我們在開計劃會的時候并沒有把task分好，缺乏溝通可能是導致這個問題的主要原因。
解決問題的方案就是：我們的前端和后端在領取task的時候需要考慮任務的優先級，先做哪個后做哪個，多溝通。
如果說有某個task工作量大于8小時的話，我們建議將這個task再細分，盡量做到每個task的工作量都在一天之內，這樣把task分得更細的方法也是可以避免task漏項的。畢竟在開發的時候發現漏task了，那只能是通過加班來解決了。
2. 接口文檔未及時更新
這個鍋直接甩給了后端開發小哥。當然解決方案就是接口文檔及時更新和署名。
3. 用戶故事漏項，原型不夠細致
當然，迭代出問題，PO也是要背鍋的。
在沒有詳細的PRD文檔的情況下，原型成為了開發人員的主要參考對象。如果用戶故事漏項并且原型畫得不清不楚的話，導致的問題就是開發人員無法開發。
即使我們使用的是敏捷開發模式，核心就是溝通，但是這也會大大大大增加了溝通成本。
所以，對用戶故事的把控、對原型設計的理解還有對業務流程的思考應該算是對剛使用敏捷模式的產品經理最大的挑戰。
4. 測試不規范
在沒有測試人員的情況下，產品經理就是項目中最好的測試。
其實，這樣子說并不是最準確的，產品經理應該把控住測試的最后一道關卡，而不是在開發人員開發完一個模塊還未自測的情況下就把這個模塊丟給你測。這樣不僅增加了產品經理的工作量，還可能會導致項目延期。
所以說，敏捷模式其實非?？简灻總€人在整個團隊中的能力的。
5. 在sprint之前未確認好資源
像我們初創的小團隊，我們不僅沒有測試，也沒有UI。如果我們需要UI的話就需要向外部申請資源，要是我們在迭代之前未考慮到這點，那我們的頁面做出來有可能真的會不忍直視。
三、總結
作為一個剛出生不久的產品經理，我對于敏捷的理解還是在持續的工作中不斷加深的，從最開始Mike Cohn的《用戶故事與敏捷方法》一書中了解到的理論內容，再到實際開發中的一點點實踐，敏捷的思想也在慢慢成長。
作者：yoge，MadPecker產品經理。
本文由 @yoge 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于CC0協議
文中User Story的舉例“我想要有XXX增刪改查的功能”感覺不是很恰當，私以為User Story至少應該包含角色、意圖和（商業）價值，即“作為系統超級管理員，我想要能創建、移除和管理員賬號，這樣我就可以管理本系統操作人員了”
對的對的，是我的疏忽，感謝指出問題！
你不寫清楚，導致對同一個事情的看法不一。。。
是的，剛開始做敏捷的時候，特別是第一次迭代，沒有把用戶故事說清楚，導致和開發人員的看法不一致，這個真的很難受。