先來看故事來

    故事情節

    現在回想起來當初做人事的時候，那是叫一個慘啊，記得有一次是客戶那邊的需求修改了，加上原來我們對於業務瞭解的不是很熟悉，又加了三個大將（響、江江、亞光）來參與，我和唐歡完成一些功能算是V1.0版吧，後來客戶需求發生變化，功能加多、內容開始複雜起來，通過現有的變更業務需求整體分析，大家一致決定，還是重新做吧，因為如果在V1.0上繼續修改，修改的代價遠遠大於重新開發的時間，大夥們說，重做吧，在這個過程中我們討論了的問題：文件文件文件不全他們三沒法幹啊（業務不是很熟、業務講講後代碼不是很熟悉，他們三下手難啦）、UML圖、資料庫等等隨著不斷的修改文件和圖已經嚴重不對應了，不斷的開發都修改了很多……

    那個時候我們頭腦中的開發理念是：如果文件、資料庫、UML都有了，我們開發人員根據文件驅動開發不就讀了嘛？很簡單啊，照著敲就行了吧，畢竟有過合作的經驗，大家吐槽最多的就是文件不全、文件寫的不好、文件……，資料庫設計的不合理、資料庫文件也不好？等等！

    我們的開發理念是軟體功能中的經典的瀑布模型，想一直遵循那個，知道最後大體上還是沒有遵循，不得不說這個已經不再適合這個需求持續變更的年代啦，那種開發模型太老套啦，傳統的開發模式不經在文件和時序圖上花費了很大的時間，到頭來可能由於需求的變更而翻了船；大家也是時常根據文件的開發起來遇到了問題有時爭吵……整個團隊影響還是不小的啊

直到現在我深刻的體會到，在現在的軟體開發過程中，需求持續變動的專案，如果按照傳統的瀑布模型的一條條的來的話（太天真了），軟體越向下開發，有點想把自己做死的感覺……。

敏捷開發相見恨晚啊

    近期準備軟考，需求這塊主要由響來溝通，在我們的小組中推廣者敏捷開發的方法，其實平時我們也一直在這樣做，但是並沒有真正的體會到這已經形成了較為高效、科學的軟體開發方法了，我和響帶著四個人做專案來說，整體感覺還是不錯的，我學習了敏捷開發的一些書籍、一些部落格和師哥們也在交流，爭取把更多敏捷開發的指導思想用到我們的人事二次開發的整個專案中。

Scrum概覽

    Scrum是一種兼顧計劃性與靈活性的敏捷開發過程，原詞來自於橄欖球中的“帶球過人”。在橄欖球比賽的每次衝刺前，都將有一個計劃安排的過程，但衝刺開始後則由隊員在原計劃的基礎上隨機應變。

    瀑布模型將開發過程劃分為需求、設計、編碼、測試等階段，Scrum將整個開發過程分為多次迭代（稱為Sprint，衝刺），一般為期2～4周。

    在日常工作時，產品負責人會維護一個按優先順序排序的“產品待開發項”（Product Backlog），即從客戶價值理解和描述的產品功能條目。

    在每次迭代的第一天，召開迭代計劃會(Sprint Planning Meeting)。產品負責人會逐一挑選最高優先順序的部分進行講解。團隊可就需求細節、完成標準等進行詢問，並逐條估算，放入本次迭代的開發任務中，直至任務量飽和。一旦迭代開始，這些任務將不會發生大的變化。

    在迭代期內，團隊將決定任務分配、所需的技術等，逐一完成任務。每天團隊會進行一個簡短的站立會議即每日立會 Daily Stand-up Meeting，溝通當前進度、下一步任務和當前存在的問題，以藉助團隊的力量解決。團隊還維護一張“燃燒圖”（Burn Down Chart），即所有任務的累積剩餘時間隨開發程序與日遞減的圖形，以觀察和預測所有任務是否會按期完成。

    在每個迭代的最後一天，團隊會召集評審會(Review Meeting)，邀請產品負責人等參加，對已經完成的產品功能條目進行評審，後者做出判斷並給出改進反饋。當天還會召開反思會(Retrospective Meeting)，對本次迭代中的成功與失敗之處做出總結，並在以後迭代中進行改進。

我們在專案中敏捷開發如何體現？

    我們的迭代期為一週（每週三給客戶增加一個新的版本），同時向客戶展示我們快速開發的能力。在掌握整體緊急重要的需求之後，根據時間由響確定需求之後分出單個合適的小模組、顆粒，分配工作時之後再讓大家自己類似搶小米一樣槍功能（自己願意做的，一種是自己很熟悉的；一種是自己確實想鍛鍊練習、拓展、挑戰的），極大了提高了小組成員的興趣和友好性、工作的效率。

    當然在制定任務和抽象顆粒的時候會和組員一起商量制定，這樣更加結合大家自己的情況來完成，避免顆粒過於大、過於小，更加的接近人性化吧，最主要是整體Team團結大家開心有幹勁哈。

Scrum過程-每日立會（Standup Meeting）

   由於每次會議只持續10～15分鐘，人們習慣在工位附近的四樓樓道上站著開會，所以被叫做“每日立會”，每天10:10-10:25為晨會時間每日立會上每個人彙報三個問題：我昨天做了什麼，我今天要做什麼，我遇到了什麼困難。 

    由於小組曾經共同估算任務，所以如果出現偏差，可以溝通解決出現的問題……

每週的評審會

   主要是大家展示自己的成果（成就感啊！），檢查大家做出來的效果和使用者提出的要求的是否一致性？是否滿足需求？

    程式碼規範、註釋規範，都要查！

    儘管有正式的評審會，但很多團隊習慣在單個故事完成時，就讓產品負責人進行單個故事評審，以確保交付時不會有“驚喜”

Scrum過程-反思會（RetrospectiveMeeting）

怎樣開展反思會？

☺反思會是Scrum中最難以實施的活動之一。

☺反思會上討論三個問題：我們上個迭代有哪些事情做的好希望繼續，那些事情做的不好希望改進，有何改進計

劃。

☺經常出現一些問題多次被提到，但卻始終沒有解決。應該每次僅就1～3個關鍵問題做出可行的解決方案，在

下一個迭代執行改進。“可行”的概念包括兩個含義：第一是方法簡單，影響面小，見效快；第二個是目標不

要激進，而要現實可行，積少成多。

☺如果必要可以執行領導迴避制度，即具有管理職能的人不參加反思會，即使這些人是產品負責人，專案經理，乃至Scrum Master。

大家共同思考近期出現的問題（調試出現問題）、交流少、效率低下的原因，大家相互分析共同把專案做好，客戶滿意。

專案管理工具--禪道

    由響確定需求之後分出單個合適的小模組、顆粒，之後再讓大家自己類似搶小米一樣槍功能（自己願意做的，一種是自己很熟悉的；一種是自己確實想鍛鍊練習拓展挑戰的），極大了提高了小組成員的興趣和友好性、工作的效率
        
    現在來說當初他們四個（徐嬌、文哲、一清、孫晴）接觸瞭解、上手，整體上還是很快的，在一週之內完成了客戶提出的急需的功能還是很滿意的哈。
        
    作為專案組長的我們可以及時瞭解組員的進度情況、心情、遇到的難題、功能的實現過程中遇到的好的實現思路都實時跟進了解，為他們做好服務、儘量讓他們站在巨人的肩膀之上來快速成長，當然也有碰壁他們接觸鍛鍊，為我們專案的後續持續的迭代有了明確的方向指南。
    

未知筆記

    每日的日報記錄詳細記錄，每天都有目標、有收穫；為今後個人的學習總結提供了好的日誌、總結；共性問題解決方法和大家及時的共享，避免重複做重複性的工作，記錄著每個人的成長腳印。

總結

    面對這樣需求持續的變更，根據客戶實施情況及時完成客戶需要的功能，敏捷開發很好的做到了這一點，當然這個過程中會遇到各種各樣的問題，只要我們以一顆平常心對待，把它當做我們成長的橋樑，剩下的事就都好辦了，在整個專案管理中我們還是最注重關心組員的個人心態、情緒、每天是否有所收穫等等畢竟這才是一個人是否可以持續戰鬥下去的最關鍵因素，良好的溝通、及時的解決遇到的問題、給予方向性的指導、親和力都是重要的、。

    我們在敏捷開發理念在指導下前進，整個Team快速的成長、盡情的體驗軟體開發帶來的愉快的體驗，加油，My Team，Good Team!

接下來會和大家分享

等等……敬請期待吧！