Scrum敏捷開發(fā)，帶來的不僅僅是敏捷，還有理不清的煩惱。

最近公司開展的Scrum敏捷開發(fā)，幾個Sprint下來，碰到了很多煩惱。

比如說：碰到有改交互原型圖，改視覺設(shè)計稿，改代碼的情況，因?yàn)镾print?Planning?Meeting（周期計劃會議），就沒有考慮到交互原型圖和視覺設(shè)計稿需要改幾次，bug需要修幾次，所以碰到這種情況，一般需要加班或者放到下個sprint再做計劃。

又比如：本來1天可以完成的工作，但是需要計劃成2-3天去安排，因?yàn)樵谀骋粋€sprint之內(nèi)，在項(xiàng)目的某一環(huán)節(jié)上，確實(shí)是沒有什么事情可以安排的?？偛荒茉谟媱澤蠈懀骸?天上班，2天自由活動。”另外，在Daily?Scrum?Meeting（每日站立會議）上，要求每個團(tuán)隊(duì)成員，都需要口頭說一說自己昨天的工作進(jìn)度，今天的工作計劃。這個時候，有些同事，只能編造一些無關(guān)緊要的事情，或者把1天可以完成的事情，分成2-3天來匯報，因?yàn)樗@個環(huán)節(jié)，這幾天本來就沒什么事做嘛。

再比如：臨時有加急事情，需要下單的時候，同事之間就用Sprint?Backlog（周期工作列表）來拒絕工作?！斑@個sprint計劃里面沒有這個任務(wù)啊。”所以，本來需要加急的任務(wù)就這樣被拒絕了。這時候，只好放到下個sprint再弄，或者自己加班做。其實(shí)，本來只需要在1天的工作時間里，擠擠時間，這個急單，就可以完成了。

下面先介紹一下Scrum敏捷開發(fā)的流程，然后再針對上面的這些煩惱，提出我個人的改進(jìn)方案。

什么是Sprint？

Sprint是短距離賽跑的意思，這里面指的是一次迭代，而一次迭代的周期是1個月時間（即4個星期），也就是我們要把一次迭代的開發(fā)內(nèi)容以最快的速度完成它，這個過程我們稱它為Sprint。

如何進(jìn)行Scrum開發(fā)？

1. 我們首先需要確定一個Product Backlog（按優(yōu)先順序排列的一個產(chǎn)品需求列表），這個是由Product Owner 負(fù)責(zé)的；
2. Scrum Team根據(jù)Product Backlog列表，做工作量的預(yù)估和安排；
3. 有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story作為本次迭代完成的目標(biāo)，這個目標(biāo)的時間周期是1~4個星期，然后把這個Story進(jìn)行細(xì)化，形成一個Sprint Backlog；
4. Sprint Backlog是由Scrum Team去完成的，每個成員根據(jù)Sprint Backlog再細(xì)化成更小的任務(wù)（細(xì)到每個任務(wù)的工作量在2天內(nèi)能完成）；
5. 在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進(jìn)行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發(fā)言，并且要向所有成員當(dāng)面匯報你昨天完成了什么，并且向所有成員承諾你今天要完成什么，同時遇到不能解決的問題也可以提出，每個人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖）；
6. 做到每日集成，也就是每天都要有一個可以成功編譯、并且可以演示的版本；很多人可能還沒有用過自動化的每日集成，其實(shí)TFS就有這個功能，它可以支持每次有成員進(jìn)行簽入操作的時候，在服務(wù)器上自動獲取最新版本，然后在服務(wù)器中編譯，如果通過則馬上再執(zhí)行單元測試代碼，如果也全部通過，則將該版本發(fā)布，這時一次正式的簽入操作才保存到TFS中，中間有任何失敗，都會用郵件通知項(xiàng)目管理人員；
7. 當(dāng)一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進(jìn)行 Srpint Review Meeting（演示會議），也稱為評審會議，產(chǎn)品負(fù)責(zé)人和客戶都要參加（最好本公司老板也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟件產(chǎn)品（這個會議非常重要，一定不能取消）；
8. 最后就是 Sprint Retrospective Meeting（回顧會議），也稱為總結(jié)會議，以輪流發(fā)言方式進(jìn)行，每個人都要發(fā)言，總結(jié)并討論改進(jìn)的地方，放入下一輪Sprint的產(chǎn)品需求中。

針對本文開篇提到的煩惱，我在這里總結(jié)了3個針對性的方案。

1. 在計劃會議的時候，需要給交互設(shè)計師預(yù)留改原型的時間，給Ui設(shè)計師預(yù)留改視覺稿的時間，給開發(fā)工程師預(yù)留修bug的時間。比如：Ui設(shè)計師，平均改稿次數(shù)，為3次左右。一次就能定稿的情況，幾乎不存在。

根據(jù)【Ui中國】發(fā)布的《UIweek6》雜志上的一份《上海Ui設(shè)計師工作現(xiàn)狀調(diào)查》顯示：一般從產(chǎn)品初期到產(chǎn)品上線所需要修改次數(shù)的比例為：改稿4-6次的情況占41%，改稿1-3次的情況占40%，改稿7-9次的情況占7%，改稿10次的情況占12%。為了避免后期要求Ui設(shè)計師改設(shè)計稿的時候，Ui設(shè)計師因?yàn)榕录影喽桓模螂S便修改應(yīng)付了事的情況，我建議需要在計劃會議的時候，把修改的時間，預(yù)留到計劃里面。這樣，Ui設(shè)計師就可以大大方方的改。

2. 當(dāng)臨時有急事，需要布置加急任務(wù)的時候，一般就拖到下個Sprint去了。為了避免這種情況，我建議在計劃sprint會議的時候，預(yù)留出2/10的時間，作為臨時任務(wù)的預(yù)留時間。這樣，有任務(wù)需要加急的話，就可以大大方方的給出時間嘛。

3. 關(guān)于Sprint Star的評選，一般情況，優(yōu)先被選中的是，誰加班多，誰在這個sprint我接觸比較多，誰被選中的機(jī)會就大。這個標(biāo)準(zhǔn)，我建議改成：誰可以在完成這個Sprint任務(wù)之外，多做一些Sprint計劃之外的事情，就盡量選誰。

以上是我最近在敏捷開發(fā)的實(shí)施過程中，碰到的一些煩惱和推薦的方案。具體實(shí)施過程中，需要綜合這4種（瀑布式開發(fā)，迭代式開發(fā)，螺旋開發(fā)，敏捷開發(fā)）開發(fā)方式的優(yōu)缺點(diǎn)，來運(yùn)用到具體的項(xiàng)目當(dāng)中。這樣，敏捷開發(fā)就可以做到取長補(bǔ)短的效果。

本文由人人都是產(chǎn)品經(jīng)理專欄作家 @張云錢（微信號：944352559） 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?。未經(jīng)許可，禁止轉(zhuǎn)載。