從瀑布開發模式到靈活開發模式（scrum）的思路轉換

部門推廣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下來、就可以拿着記錄去和産品負責人談這些問題。

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