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