筆者介紹了Scrum敏捷開(kāi)發(fā)模式應(yīng)該包含的五個(gè)會(huì)議及內(nèi)容，并舉例說(shuō)明了該如何解決迭代中遇到的問(wèn)題。

一、開(kāi)發(fā)模式

我們團(tuán)隊(duì)用的是Scrum敏捷開(kāi)發(fā)模式，這個(gè)模式的優(yōu)點(diǎn)是：比傳統(tǒng)的瀑布式開(kāi)發(fā)靈活，但是對(duì)于團(tuán)隊(duì)中每個(gè)人的要求又比較高。

Scrum中有三個(gè)角色，分別由PO、Scrum Master、項(xiàng)目成員組成。那我在這邊就是Product Owner的角色，也就是項(xiàng)目的負(fù)責(zé)人。

一般產(chǎn)品經(jīng)理在需求分析、確定需求之后可能就開(kāi)始做原型設(shè)計(jì)和寫(xiě)PRD文檔了。但是在這個(gè)開(kāi)發(fā)模式下，我是不寫(xiě)PRD文檔的，我會(huì)把所有想法體現(xiàn)在原型上，再加上相應(yīng)的備注，如果說(shuō)開(kāi)發(fā)人員遇到問(wèn)題就會(huì)找到我問(wèn)清需求。因?yàn)镾crum的最關(guān)鍵的點(diǎn)就是多溝通，用溝通來(lái)替代文檔。

當(dāng)然，如果在開(kāi)發(fā)的時(shí)候直接扔個(gè)原型給開(kāi)發(fā)，那他們肯定一臉懵逼然后想把你打一頓。

為了產(chǎn)品經(jīng)理的人身安全，所以這就涉及到我接下來(lái)要說(shuō)的Scrum五個(gè)會(huì)議：由需求澄清會(huì)、計(jì)劃分析會(huì)、站立會(huì)、評(píng)審會(huì)和回顧會(huì)組成。

1. 需求澄清會(huì)

顧名思義，就是澄清需求，但是人家就會(huì)問(wèn)了，你沒(méi)有PRD你澄清什么需求。

對(duì)的，我準(zhǔn)備的是User Story，也就是用戶故事：如果說(shuō)我是這個(gè)產(chǎn)品的用戶，我要實(shí)現(xiàn)什么功能。

這邊的功能描述可能就是“我想要有XXX增刪改查的功能”而不是詳細(xì)到“我的提交按鈕要放在哪里”。

簡(jiǎn)單點(diǎn)說(shuō)，就是這個(gè)用戶故事是有一定的顆粒度的，但是它在所有產(chǎn)品的設(shè)計(jì)者、開(kāi)發(fā)者和使用者的理解下是沒(méi)有歧義的。只要我們大家都確定了，我們要做的就是這樣的一個(gè)東西那就沒(méi)有問(wèn)題。

因?yàn)橛脩艄适露急容^多，我們一般會(huì)把用戶故事排一下優(yōu)先級(jí)，然后根據(jù)優(yōu)先級(jí)把用戶故事分成幾次sprint來(lái)做，就是不斷地迭代。每次迭代的周期很短，一般是一周或者是兩周，還有迭代出來(lái)的一定是一個(gè)可以使用的產(chǎn)品，可能功能有點(diǎn)缺陷，但一定是可以正常使用的產(chǎn)品。

2. 計(jì)劃分析會(huì)

計(jì)劃分析會(huì)，就是根據(jù)原型還有用戶故事分task。

這個(gè)會(huì)議一般由SM來(lái)主持，當(dāng)然這里的SM不是你想的那個(gè)SM。

因?yàn)橹耙呀?jīng)開(kāi)過(guò)需求澄清會(huì)了，開(kāi)發(fā)人員也知道了需要開(kāi)發(fā)什么樣的產(chǎn)品，這時(shí)候就可以根據(jù)每個(gè)用戶故事對(duì)著原型分任務(wù)了。

需要注意的是：這里的每個(gè)任務(wù)都是開(kāi)發(fā)人員自己分給自己的，比如：后端開(kāi)發(fā)看到這個(gè)頁(yè)面，需要寫(xiě)幾個(gè)接口，每個(gè)接口大概需要多少小時(shí)，需要前端人員如何配合，這都是需要在這個(gè)會(huì)議搞清楚。所以為了后續(xù)的正常開(kāi)發(fā)，這個(gè)會(huì)議一般都會(huì)比較長(zhǎng)，大概需要4-5個(gè)小時(shí)左右。

3. 站立會(huì)

這個(gè)是每天都需要開(kāi)的會(huì)議，每個(gè)項(xiàng)目成員都說(shuō)一下自己昨天做了什么工作、今天做了什么工作。

這個(gè)會(huì)議的話主要是前端開(kāi)發(fā)和后端開(kāi)發(fā)之前的互相配合，就是為了避免前端已經(jīng)擼好了一個(gè)界面但是沒(méi)有接口對(duì)的尷尬情況。

4. 評(píng)審會(huì)

主要是進(jìn)行本次迭代的功能評(píng)審，對(duì)照用戶故事，我們是不是已經(jīng)完成了這幾個(gè)用戶故事所說(shuō)的內(nèi)容。

5. 回顧會(huì)

分析這次迭代我們團(tuán)隊(duì)有什么優(yōu)點(diǎn)、有什么缺點(diǎn)、可以怎樣改進(jìn)，產(chǎn)出對(duì)應(yīng)的改進(jìn)措施。

敏捷宣言：個(gè)體和互動(dòng)高于流程和工具；工作的軟件高于詳盡的文檔；客戶合作高于合同談判；響應(yīng)變化高于遵循計(jì)劃。

二、第一次迭代遇到的問(wèn)題及改進(jìn)方案

1. Task漏項(xiàng)

在第一次使用該模式開(kāi)發(fā)的時(shí)候，遇到的最大問(wèn)題就是task漏項(xiàng)。這說(shuō)明了我們?cè)陂_(kāi)計(jì)劃會(huì)的時(shí)候并沒(méi)有把task分好，缺乏溝通可能是導(dǎo)致這個(gè)問(wèn)題的主要原因。

解決問(wèn)題的方案就是：我們的前端和后端在領(lǐng)取task的時(shí)候需要考慮任務(wù)的優(yōu)先級(jí)，先做哪個(gè)后做哪個(gè)，多溝通。

如果說(shuō)有某個(gè)task工作量大于8小時(shí)的話，我們建議將這個(gè)task再細(xì)分，盡量做到每個(gè)task的工作量都在一天之內(nèi)，這樣把task分得更細(xì)的方法也是可以避免task漏項(xiàng)的。畢竟在開(kāi)發(fā)的時(shí)候發(fā)現(xiàn)漏task了，那只能是通過(guò)加班來(lái)解決了。

2. 接口文檔未及時(shí)更新

這個(gè)鍋直接甩給了后端開(kāi)發(fā)小哥。當(dāng)然解決方案就是接口文檔及時(shí)更新和署名。

3. 用戶故事漏項(xiàng)，原型不夠細(xì)致

當(dāng)然，迭代出問(wèn)題，PO也是要背鍋的。

在沒(méi)有詳細(xì)的PRD文檔的情況下，原型成為了開(kāi)發(fā)人員的主要參考對(duì)象。如果用戶故事漏項(xiàng)并且原型畫(huà)得不清不楚的話，導(dǎo)致的問(wèn)題就是開(kāi)發(fā)人員無(wú)法開(kāi)發(fā)。

即使我們使用的是敏捷開(kāi)發(fā)模式，核心就是溝通，但是這也會(huì)大大大大增加了溝通成本。

所以，對(duì)用戶故事的把控、對(duì)原型設(shè)計(jì)的理解還有對(duì)業(yè)務(wù)流程的思考應(yīng)該算是對(duì)剛使用敏捷模式的產(chǎn)品經(jīng)理最大的挑戰(zhàn)。

4. 測(cè)試不規(guī)范

在沒(méi)有測(cè)試人員的情況下，產(chǎn)品經(jīng)理就是項(xiàng)目中最好的測(cè)試。

其實(shí)，這樣子說(shuō)并不是最準(zhǔn)確的，產(chǎn)品經(jīng)理應(yīng)該把控住測(cè)試的最后一道關(guān)卡，而不是在開(kāi)發(fā)人員開(kāi)發(fā)完一個(gè)模塊還未自測(cè)的情況下就把這個(gè)模塊丟給你測(cè)。這樣不僅增加了產(chǎn)品經(jīng)理的工作量，還可能會(huì)導(dǎo)致項(xiàng)目延期。

所以說(shuō)，敏捷模式其實(shí)非?？简?yàn)每個(gè)人在整個(gè)團(tuán)隊(duì)中的能力的。

5. 在sprint之前未確認(rèn)好資源

像我們初創(chuàng)的小團(tuán)隊(duì)，我們不僅沒(méi)有測(cè)試，也沒(méi)有UI。如果我們需要UI的話就需要向外部申請(qǐng)資源，要是我們?cè)诘拔纯紤]到這點(diǎn)，那我們的頁(yè)面做出來(lái)有可能真的會(huì)不忍直視。

三、總結(jié)

作為一個(gè)剛出生不久的產(chǎn)品經(jīng)理，我對(duì)于敏捷的理解還是在持續(xù)的工作中不斷加深的，從最開(kāi)始Mike Cohn的《用戶故事與敏捷方法》一書(shū)中了解到的理論內(nèi)容，再到實(shí)際開(kāi)發(fā)中的一點(diǎn)點(diǎn)實(shí)踐，敏捷的思想也在慢慢成長(zhǎng)。

作者：yoge，MadPecker產(chǎn)品經(jīng)理。

本文由 @yoge 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自 Unsplash，基于CC0協(xié)議