先來看故事來
故事情節(jié)
現(xiàn)在回想起來當(dāng)初做人事的時候，那是叫一個慘啊，記得有一次是客戶那邊的需求修改了，加上原來我們對于業(yè)務(wù)了解的不是很熟悉，又加了三個大將（響、江江、亞光）來參與，我和唐歡完成一些功能算是V1.0版吧，后來客戶需求發(fā)生變化，功能加多、內(nèi)容開始復(fù)雜起來，通過現(xiàn)有的變更業(yè)務(wù)需求整體分析，大家一致決定，還是重新做吧，因?yàn)槿绻?/span>V1.0上繼續(xù)修改，修改的代價遠(yuǎn)遠(yuǎn)大于重新開發(fā)的時間，大伙們說，重做吧，在這個過程中我們討論了的問題：文檔文檔文檔不全他們?nèi)龥]法干?。I(yè)務(wù)不是很熟、業(yè)務(wù)講講后代碼不是很熟悉，他們?nèi)率蛛y啦）、UML圖、數(shù)據(jù)庫等等隨著不斷的修改文檔和圖已經(jīng)嚴(yán)重不對應(yīng)了，不斷的開發(fā)都修改了很多……
那個時候我們頭腦中的開發(fā)理念是：如果文檔、數(shù)據(jù)庫、UML都有了，我們開發(fā)人員根據(jù)文檔驅(qū)動開發(fā)不就讀了嘛？很簡單啊，照著敲就行了吧，畢竟有過合作的經(jīng)驗(yàn)，大家吐槽最多的就是文檔不全、文檔寫的不好、文檔……，數(shù)據(jù)庫設(shè)計的不合理、數(shù)據(jù)庫文檔也不好？等等！
我們的開發(fā)理念是軟件功能中的經(jīng)典的瀑布模型，想一直遵循那個，知道最后大體上還是沒有遵循，不得不說這個已經(jīng)不再適合這個需求持續(xù)變更的年代啦，那種開發(fā)模型太老套啦，傳統(tǒng)的開發(fā)模式不經(jīng)在文檔和時序圖上花費(fèi)了很大的時間，到頭來可能由于需求的變更而翻了船；大家也是時常根據(jù)文檔的開發(fā)起來遇到了問題有時爭吵……整個團(tuán)隊(duì)影響還是不小的啊
直到現(xiàn)在我深刻的體會到，在現(xiàn)在的軟件開發(fā)過程中，需求持續(xù)變動的項(xiàng)目，如果按照傳統(tǒng)的瀑布模型的一條條的來的話（太天真了），軟件越向下開發(fā)，有點(diǎn)想把自己做死的感覺……。
敏捷開發(fā)相見恨晚啊
近期準(zhǔn)備軟考，需求這塊主要由響來溝通，在我們的小組中推廣者敏捷開發(fā)的方法，其實(shí)平時我們也一直在這樣做，但是并沒有真正的體會到這已經(jīng)形成了較為高效、科學(xué)的軟件開發(fā)方法了，我和響帶著四個人做項(xiàng)目來說，整體感覺還是不錯的，我學(xué)習(xí)了敏捷開發(fā)的一些書籍、一些博客和師哥們也在交流，爭取把更多敏捷開發(fā)的指導(dǎo)思想用到我們的人事二次開發(fā)的整個項(xiàng)目中。
Scrum概覽
Scrum是一種兼顧計劃性與靈活性的敏捷開發(fā)過程，原詞來自于橄欖球中的“帶球過人”。在橄欖球比賽的每次沖刺前，都將有一個計劃安排的過程，但沖刺開始后則由隊(duì)員在原計劃的基礎(chǔ)上隨機(jī)應(yīng)變。
瀑布模型將開發(fā)過程劃分為需求、設(shè)計、編碼、測試等階段，Scrum將整個開發(fā)過程分為多次迭代（稱為Sprint，沖刺），一般為期2～4周。
在日常工作時，產(chǎn)品負(fù)責(zé)人會維護(hù)一個按優(yōu)先級排序的“產(chǎn)品待開發(fā)項(xiàng)”（Product Backlog），即從客戶價值理解和描述的產(chǎn)品功能條目。
在每次迭代的第一天，召開迭代計劃會(Sprint Planning Meeting)。產(chǎn)品負(fù)責(zé)人會逐一挑選最高優(yōu)先級的部分進(jìn)行講解。團(tuán)隊(duì)可就需求細(xì)節(jié)、完成標(biāo)準(zhǔn)等進(jìn)行詢問，并逐條估算，放入本次迭代的開發(fā)任務(wù)中，直至任務(wù)量飽和。一旦迭代開始，這些任務(wù)將不會發(fā)生大的變化。
在迭代期內(nèi)，團(tuán)隊(duì)將決定任務(wù)分配、所需的技術(shù)等，逐一完成任務(wù)。每天團(tuán)隊(duì)會進(jìn)行一個簡短的站立會議即每日立會 Daily Stand-up Meeting，溝通當(dāng)前進(jìn)度、下一步任務(wù)和當(dāng)前存在的問題，以借助團(tuán)隊(duì)的力量解決。團(tuán)隊(duì)還維護(hù)一張“燃燒圖”（Burn Down Chart），即所有任務(wù)的累積剩余時間隨開發(fā)進(jìn)程與日遞減的圖形，以觀察和預(yù)測所有任務(wù)是否會按期完成。
在每個迭代的最后一天，團(tuán)隊(duì)會召集評審會(Review Meeting)，邀請產(chǎn)品負(fù)責(zé)人等參加，對已經(jīng)完成的產(chǎn)品功能條目進(jìn)行評審，后者做出判斷并給出改進(jìn)反饋。當(dāng)天還會召開反思會(Retrospective Meeting)，對本次迭代中的成功與失敗之處做出總結(jié)，并在以后迭代中進(jìn)行改進(jìn)。
我們在項(xiàng)目中敏捷開發(fā)如何體現(xiàn)？
我們的迭代期為一周（每周三給客戶增加一個新的版本），同時向客戶展示我們快速開發(fā)的能力。在掌握整體緊急重要的需求之后，根據(jù)時間由響確定需求之后分出單個合適的小模塊、顆粒，分配工作時之后再讓大家自己類似搶小米一樣槍功能（自己愿意做的，一種是自己很熟悉的；一種是自己確實(shí)想鍛煉練習(xí)、拓展、挑戰(zhàn)的），極大了提高了小組成員的興趣和友好性、工作的效率。
當(dāng)然在制定任務(wù)和抽象顆粒的時候會和組員一起商量制定，這樣更加結(jié)合大家自己的情況來完成，避免顆粒過于大、過于小，更加的接近人性化吧，最主要是整體Team團(tuán)結(jié)大家開心有干勁哈。
Scrum過程-每日立會（Standup Meeting）
由于每次會議只持續(xù)10～15分鐘，人們習(xí)慣在工位附近的四樓樓道上站著開會，所以被叫做“每日立會”，每天10:10-10:25為晨會時間每日立會上每個人匯報三個問題：我昨天做了什么，我今天要做什么，我遇到了什么困難。
由于小組曾經(jīng)共同估算任務(wù)，所以如果出現(xiàn)偏差，可以溝通解決出現(xiàn)的問題……
每周的評審會
主要是大家展示自己的成果（成就感?。。?，檢查大家做出來的效果和用戶提出的要求的是否一致性？是否滿足需求？
代碼規(guī)范、注釋規(guī)范，都要查！
盡管有正式的評審會，但很多團(tuán)隊(duì)習(xí)慣在單個故事完成時，就讓產(chǎn)品負(fù)責(zé)人進(jìn)行單個故事評審，以確保交付時不會有“驚喜”
Scrum過程-反思會（RetrospectiveMeeting）
怎樣開展反思會？
?反思會是Scrum中最難以實(shí)施的活動之一。
?反思會上討論三個問題：我們上個迭代有哪些事情做的好希望繼續(xù)，那些事情做的不好希望改進(jìn)，有何改進(jìn)計
劃。
?經(jīng)常出現(xiàn)一些問題多次被提到，但卻始終沒有解決。應(yīng)該每次僅就1～3個關(guān)鍵問題做出可行的解決方案，在
下一個迭代執(zhí)行改進(jìn)?！翱尚小钡母拍畎▋蓚€含義：第一是方法簡單，影響面小，見效快；第二個是目標(biāo)不
要激進(jìn)，而要現(xiàn)實(shí)可行，積少成多。
?如果必要可以執(zhí)行領(lǐng)導(dǎo)回避制度，即具有管理職能的人不參加反思會，即使這些人是產(chǎn)品負(fù)責(zé)人，項(xiàng)目經(jīng)理，乃至Scrum Master。
大家共同思考近期出現(xiàn)的問題（調(diào)試出現(xiàn)問題）、交流少、效率低下的原因，大家相互分析共同把項(xiàng)目做好，客戶滿意。
項(xiàng)目管理工具--禪道
由響確定需求之后分出單個合適的小模塊、顆粒，之后再讓大家自己類似搶小米一樣槍功能（自己愿意做的，一種是自己很熟悉的；一種是自己確實(shí)想鍛煉練習(xí)拓展挑戰(zhàn)的），極大了提高了小組成員的興趣和友好性、工作的效率
現(xiàn)在來說當(dāng)初他們四個（徐嬌、文哲、一清、孫晴）接觸了解、上手，整體上還是很快的，在一周之內(nèi)完成了客戶提出的急需的功能還是很滿意的哈。
作為項(xiàng)目組長的我們可以及時了解組員的進(jìn)度情況、心情、遇到的難題、功能的實(shí)現(xiàn)過程中遇到的好的實(shí)現(xiàn)思路都實(shí)時跟進(jìn)了解，為他們做好服務(wù)、盡量讓他們站在巨人的肩膀之上來快速成長，當(dāng)然也有碰壁他們接觸鍛煉，為我們項(xiàng)目的后續(xù)持續(xù)的迭代有了明確的方向指南。
未知筆記
每日的日報記錄詳細(xì)記錄，每天都有目標(biāo)、有收獲；為今后個人的學(xué)習(xí)總結(jié)提供了好的日志、總結(jié)；共性問題解決方法和大家及時的共享，避免重復(fù)做重復(fù)性的工作，記錄著每個人的成長腳印。
總結(jié)
面對這樣需求持續(xù)的變更，根據(jù)客戶實(shí)施情況及時完成客戶需要的功能，敏捷開發(fā)很好的做到了這一點(diǎn)，當(dāng)然這個過程中會遇到各種各樣的問題，只要我們以一顆平常心對待，把它當(dāng)做我們成長的橋梁，剩下的事就都好辦了，在整個項(xiàng)目管理中我們還是最注重關(guān)心組員的個人心態(tài)、情緒、每天是否有所收獲等等畢竟這才是一個人是否可以持續(xù)戰(zhàn)斗下去的最關(guān)鍵因素，良好的溝通、及時的解決遇到的問題、給予方向性的指導(dǎo)、親和力都是重要的、。
我們在敏捷開發(fā)理念在指導(dǎo)下前進(jìn)，整個Team快速的成長、盡情的體驗(yàn)軟件開發(fā)帶來的愉快的體驗(yàn)，加油，My Team，Good Team!
