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