部門推廣scrum敏捷開發已經小半年了、團隊也從不適應、慢慢地開始變的習慣。之前領導安排我作為我們組的scrum master、因為從來沒有做過leader、然後直接之前也沒有接觸過scrum、更是非常彆扭、很吃力、因為不僅要做master的工作、還要承擔100%的開發工作、開始的時候非常吃力。現在隨著大家都開始慢慢習慣scrum的工作模式、我才開始慢慢地從每天1/3的時間、降到每天只要半個多小時花在scrum的管理上面。
如果要我總結中間的模式轉換的話、我覺得最關鍵的有兩點、一是大家對於敏捷的認知要深刻、要讓全體成員都自我改造成敏捷開發者、二是要做好對product backlog的管理。

自我驅動

雖然我們號稱敏捷了、也每天開早會、也有了自己的sprint看板、每個sprint也要開總結回顧會議、但是我覺得這些更多的都是敏捷的行、而不是敏捷的神、那麼什麼是神呢？我個人覺得是作為團隊成員來說、神就是從被驅動、改變為自我驅動，這兩者簡直是兩種思路。
最開始的時候、我會每個sprint之前、為組員整理好人力分配圖、其實就是幫每個人安排每天的任務、然後在接口出問題的時候、也要我去催、介面卡在哪裡了、有哪些解決方法。我非常累、大小事情都要操心、組員遇到問題了、也會問”master、這個出問題了“，然後就等我幫忙解決。後來領導開會、一起聊、發現其他的組也是有這個問題、每個組的scrum master都是身心俱疲、這時候、領導也說、我們其實只是組織大家在一起協作、而不是所謂的”專案經理“。
在這之後、我就有意思的從具體的事物中脫離出來、把原來的什麼都管、轉換為專注為大家提供一個更流暢的合作上來。我不再幫每個人分配要做哪些、而是大家自己去分配、去協調、我不再去管具體的介面的釋出日期、而是讓做這個story的人、自己去商量。慢慢地、大家就知道了、這個story是我的、那麼、所有關於它的事物、我都要關心、story不是產品經理、也不是master的、所以大家有責任去把它做好、這樣反而極大地提高了我們的開發效率、從中央處理式、變成了分散式處理、每個人都很關心當前的story、大家也有了更高的目標、不再是“我要把這個功能完成”，而是“我要為使用者創造價值”。

product backlog管理

第二個非常重要的、我覺得是backlog的管理、我覺得一定要有一定數量的backlog、不僅讓整個團隊時刻有目標感、知道我這個階段要做哪些事情、而且能幫助產品負責人理清自己的思路。可能很多人會覺得、作為產品負責人、肯定是接下來半年做的、都在心裡了、我覺得未必、我就遇到過完全沒有思路、甚至需要我一起幫理清產品思路的人。因為公司的業務非常多、任務也比較重、導致很多需求的質量不高、下個sprint都要開始了、UI的設計風格還沒定、 這種事情就發生在身邊！
從一個開發的角度來講、我當時是希望需求早就定了下來、並且永遠都不會變、但我知道、這個是妄想、但是我覺得、提到開發面前的需求、至少要是經過產品深思熟慮、考慮了很多不同的方式、最終覺得的一個比較好的方式、這樣、即使有變化、也不會是大的變化。開發的角度就是、很不喜歡大的變化、尤其不喜歡不確定的東西、寫了if、總要寫個else吧、如果sprint過程中不斷的變化需求、那感覺就像、正打著LOL、不停地斷電、時間都白白浪費了、我覺得爛需求就是在扼殺開發的生命、就是在浪費團隊的資源！一定不要讓這種事情頻繁發生。
我的經驗是、最好下個sprint開始之前的兩三天、就可以和產品要具體點需求、master先大致看下、沒有什麼致命的漏洞、也近來難過保證UI之類的都是完整的、會把後面可能的變動降低很多。另外需求的變更一定要有記錄、這樣幾個sprint下來、就可以拿著記錄去和產品負責人談這些問題。

從普通的開發流程、到敏捷開發、是會有很多的痛苦、但我覺得、適應了之後、成果會讓你覺得、都是值得的！