Scrum敏捷開發,帶來的不僅僅是敏捷,還有理不清的煩惱。

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

比如說:碰到有改交互原型圖,改視覺設計稿,改代碼的情況,因為Sprint Planning Meeting(周期計劃會議),就沒有考慮到交互原型圖和視覺設計稿需要改幾次,bug需要修幾次,所以碰到這種情況,一般需要加班或者放到下個sprint再做計劃。

又比如:本來1天可以完成的工作,但是需要計劃成2-3天去安排,因為在某一個sprint之內,在項目的某一環節上,確實是沒有什麼事情可以安排的。總不能在計劃上寫:“1天上班,2天自由活動。”另外,在Daily Scrum Meeting(每日站立會議)上,要求每個團隊成員,都需要口頭說一說自己昨天的工作進度,今天的工作計劃。這個時候,有些同事,只能編造一些無關緊要的事情,或者把1天可以完成的事情,分成2-3天來彙報,因為他這個環節,這幾天本來就沒什麼事做嘛。

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

下面先介紹一下Scrum敏捷開發的流程,然後再針對上面的這些煩惱,提出我個人的改進方案。

什麼是Sprint?

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

如何進行Scrum開發?

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

針對本文開篇提到的煩惱,我在這裏總結了3個針對性的方案。

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

根據【Ui中國】發布的《UIweek6》雜誌上的一份《上海Ui設計師工作現狀調查》显示:一般從產品初期到產品上線所需要修改次數的比例為:改稿4-6次的情況佔41%,改稿1-3次的情況佔40%,改稿7-9次的情況佔7%,改稿10次的情況佔12%。為了避免後期要求Ui設計師改設計稿的時候,Ui設計師因為怕加班而不改,或隨便修改應付了事的情況,我建議需要在計劃會議的時候,把修改的時間,預留到計劃裏面。這樣,Ui設計師就可以大大方方的改。

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

3. 關於Sprint Star的評選,一般情況,優先被選中的是,誰加班多,誰在這個sprint我接觸比較多,誰被選中的機會就大。這個標準,我建議改成:誰可以在完成這個Sprint任務之外,多做一些Sprint計劃之外的事情,就盡量選誰。

以上是我最近在敏捷開發的實施過程中,碰到的一些煩惱和推薦的方案。具體實施過程中,需要綜合這4種(瀑布式開發,迭代式開發,螺旋開發,敏捷開發)開發方式的優缺點,來運用到具體的項目當中。這樣,敏捷開發就可以做到取長補短的效果。

 

本文由人人都是產品經理專欄作家 @張雲錢(微信號:944352559) 原創發佈於人人都是產品經理 。未經許可,禁止轉載。