轉(zhuǎn)自Baiyan Huang同學(xué)， 感覺對(duì)初學(xué)者還是很有幫助的。

為什么Scrum

對(duì)于我們team來講，這其實(shí)是個(gè)被動(dòng)的過程。
我們部門之前在一些team實(shí)行過Scrum，可能是感覺效果還不錯(cuò)，而且覺得原來的瀑布模型太過古老和死板，于是決定今年年初開始全面實(shí)施Scrum。
由于大家都是新手，公司采用了兩個(gè)方法：
　　1. 一是超密集的培訓(xùn)。請(qǐng)專門機(jī)構(gòu)來培訓(xùn)；請(qǐng)US的同事來培訓(xùn)；請(qǐng)實(shí)施過Scrum的同事來培訓(xùn)...
　　2. 二是實(shí)戰(zhàn)演練。組成幾個(gè)臨時(shí)的team，用兩個(gè)禮拜的時(shí)間跑一個(gè)sprint，使大家對(duì)Scrum的理解從理論拓展到實(shí)際...，同時(shí)也有利于培養(yǎng)出第一批的Scrum Master...

當(dāng)然，自我學(xué)習(xí)也是一個(gè)很重要的過程，在那段時(shí)間，也參閱了不少這個(gè)領(lǐng)域的好書：Scrum書籍豆列。

我們是怎么做的

配合Scrum的流程，我們使用了Wiki和Jira來管理項(xiàng)目。
Jira主要是管理整個(gè)項(xiàng)目的User Story和Task，以及相關(guān)的一些材料，討論等。Wiki則用來管理整個(gè)項(xiàng)目的安排和每個(gè)Sprint的狀況。
大概列一下我們跑的流程：
　　1. 在項(xiàng)目初始階段，先整個(gè)team在一起頭腦風(fēng)暴，想出所有可能的story，由于問題的不確定性，可能需要幾個(gè)session。
　　2. PO（Product Owner）回去整理，細(xì)化每個(gè)story，并做好rank。
　　3. Team做完所有story的point估算。 （為了獲得team對(duì)story point，對(duì)velocity的感覺，最好先跑一、兩個(gè)sprint。不然可以先估計(jì)，然后逐步調(diào)整）
　　4. 根據(jù)team的velocity和總的story point，做出release plan。并設(shè)定出一些主要的milestone（一般三個(gè)sprint一個(gè)milestone），release plan需要隨著product backlog的不斷更新而更新。
　　5. 我們的sprint長(zhǎng)度是兩周。感覺剛好，因?yàn)橐恢艿脑挘瑴p去所有會(huì)議時(shí)間，剩下的時(shí)間就不多了；三周以上的話感覺對(duì)整個(gè)sprint的掌控度不夠，而且不易應(yīng)對(duì)impediments。
　　6. Plan meeting的agenda一般為：設(shè)定sprint的goal；計(jì)算team的availability；估算上個(gè)sprint中新創(chuàng)建的story的point；選擇這個(gè)sprint的要做的story；Task breakdown & assignment。
　　7. Review和Retrospective meeting一般放在一起，agenda為：對(duì)過去一個(gè)sprint的總體回顧，如planning時(shí)commit的story，遇到的impediments等；輪流demo自己所做的task；確定story的狀態(tài)：complete，split或者defer；restrospective。
　　8. Daily meeting中大家輪流講一下自己的狀態(tài)，人少的話還可以討論一些具體的問題。
　　9. Wiki中包含的信息：項(xiàng)目概況；team組成；項(xiàng)目文檔；release planning；team calendar；product backlog；其中每個(gè)sprint會(huì)有一個(gè)頁面：sprint goal與commit的point；該sprint的team availability；會(huì)議時(shí)間與地點(diǎn)；上個(gè)sprint的retrospective的結(jié)果；本sprint的notes；本sprint的impediments記錄等等。
　　10. Jira是PO的好朋友，是SM（Scrum Master）的好幫手。Jira用來管理所有的story與task，以及關(guān)于story與task的文檔與討論。具體的，我們可以用Epic來表示一些項(xiàng)目的大方向并鏈接相關(guān)story；用其他類型的item（如improvement）表示分隔欄，用來分隔must have，nice to have等，并且可以使用label來標(biāo)記相關(guān)story。
　　11. 對(duì)于不是很明確的story，一般分成兩步走：一個(gè)investigation的story，一個(gè)實(shí)際工作的story。這樣化整為零就能比較好的解決其估算問題了。雖然對(duì)于第一個(gè)investigation的story也不是很清晰，但根據(jù)經(jīng)驗(yàn)，還是可以給一個(gè)比較靠譜的估計(jì)。
　　12. 很多bug很難根據(jù)描述判斷其effort，所以我們一般有個(gè)慣例，就是一個(gè)bug默認(rèn)給3個(gè)小時(shí)，如果經(jīng)過3個(gè)小時(shí)的研究后發(fā)現(xiàn)問題比較大，可以另外拎出來放到下個(gè)sprint去完成。
　　13. 為了便于更好的估算，一般需要積累一些不同size的story作為baseline。
　　14. story point不能太大，不然失去其準(zhǔn)確性就沒有什么意義了，如20,40等，一般情況下，8以上的story是不應(yīng)該出現(xiàn)的sprint中的。
　　15. 用excel表統(tǒng)計(jì)team availability，根據(jù)availability以及歷史數(shù)據(jù)算出可commit的story point數(shù)。利用excel的計(jì)算功能可以自動(dòng)化整個(gè)的計(jì)算過程。

哪里需要改進(jìn)

1. 每個(gè)story的COS(Criteria Of Satisfaction)需要明確定義，也就是需要有完整的acceptance test。
　　2. Scrum是個(gè)比較流程性的東西，尤其是會(huì)議，所以在開會(huì)的時(shí)候，一定要注重實(shí)效，不要為了流程而流程從而浪費(fèi)了無數(shù)時(shí)間。

我對(duì)Scrum的感受

1. Daily meeting有兩個(gè)很重要的作用：一個(gè)是表面上的，讓大家了解team的狀態(tài)；另一個(gè)是潛在的，催促大家努力工作以便在這個(gè)會(huì)議中能講點(diǎn)什么。
　　2. 依賴于product backlog與team velocity的數(shù)據(jù)支持，使得team對(duì)自己能做什么比較清晰，加強(qiáng)了項(xiàng)目的可控性。
　　3. 充分的交流，利于及時(shí)發(fā)現(xiàn)問題，利于得出最佳的方案