２０１４年１２月２７日下午３點，Leader 聽完ＩＴＯＯ的Java 和.Net專案的延期原因，總結了以下三點：１．沒有全域性觀，統籌沒有做好　　２．如果遇到問題，沒有去找相應的理論支撐　３．沒能很好的使用工具

　　我們新生入學，作為ＩＴＯＯ的子專案，開發起來也遇到了重重困難。想起了Boss說的第二點，尋找理論支撐，我翻閱了之前推薦給我們的電子書《輕鬆Ｓｃｒｕｍ之旅》，它給專案的管理起到了很好的指導性作用。通過這本書的引導，我對敏捷開發的常用的知識做了詳細的整理。

 

一、準備Scrum之旅

１．瀑布模型VS敏捷開發：

　　瀑布模型的開發模型固定，可行性分析——＞需求分析——＞設計——＞編碼——＞測試——＞運維。優點：提供了各個階級的檢查點，一個階段完成，只需考慮下一個階段（跟貪心演算法是不是很像？）適合於迭代。缺點：文件多、開發末期才能見成果，不適合使用者需求的變化。程式化的東西難免讓人覺得假大空，死板。

　　敏捷開發最大的特殊就是應對客戶變更的需求，以人為核心，採取迭代的方式，循序漸進的開發軟體。一聽到這個名字，感覺開發的過程比較迅速！優點：能很好很快的給使用者提供滿意的產品。缺點：工作彙報，如果沒有完成任務，會害怕暴漏自己能力不足。另外對溝通能力，業務理解能力要求比較高，全能型開發者。總之一句話：門檻高啊！

 

２．禪道的使用：

　　產品負責人：確定產品的功能和時間，優先順序。人員一般是市場部或者開發部使用該產品的人員來擔任，主要目的是根據需求確定功能。

　　Scrum Master:監督整個專案，調整專案計劃，促進團隊成員的溝通，掃除障礙。掌握產品開發進度，參與每日Scrum會議、Sprint計劃會議和Sprint評審會議。

　　Scrum Team:5-10個全職工作成員。

      

       燃盡圖：總剩餘時間的燃盡圖，就是本次迭代中所有拆分任務的剩餘時間總和，隨日期的變化而逐漸遞減的圖，它為敏捷開發提供了可視性。

通過它能幫我們發現以下問題：

1.團隊計劃制定情況如何？

2.在一個Sprint中，團隊對計劃的的故事執行情況如何？

3.團隊是自我管理的嗎？作為“團隊”來說，工作步調一致嗎？

4.團隊能進行哪些改進？

 

 二、激動人心的Scrum之旅——第一站

　　每日Scrum會議：

時長：站著，不應該超過15分鐘。

內容：昨天我完成什麼任務？今天我打算做什麼？我遇到了什麼障礙？

內涵：大家同步資訊的平臺，而不是交流問題，討論問題的渠道。而且制定計劃也要按照大家的實際情況來制定，不能專案組長武斷做決定。

注意：1.團隊成員間的交流，承諾，不是彙報進度。2.不是解決技術問題的會議。

Sprint評審會議：

　　Scrum團隊在會上用Demo的形式來展示他們在這個Sprint上做的工作，與會人員評價它的新功能。

 　　用Demo的原因：1.直觀，及早發現問題，利益相關者可直接反饋 2.為完成功能，團隊會努力併發布這些功能 3.減少99%的也許完成的數量。

 

Sprint回顧會議：

 　　Scrum Master首先給大家看Scrum Backlog,總結這個Sprint,大家討論比較重要的一些事件。認為哪方面做的好，哪方面需要改進，如何改進。討論成果，如何在下一個Sprint中做的更好。

 

三、Sprint計劃與變化

１.思想

　　不應該有理由和藉口拋棄團隊。

 　　不應該隱瞞團隊的技術實力，否則很難做切合實際的計劃和評估。

　　善於尋求幫助是個好習慣，不僅僅是針對敏捷開發。

　　敏捷思想，團隊裡面沒有絕對的權威，每個人都有可取之處，要避免少數服從多數。

２.工具和機制

　　專案文件管理工具Confluence。　

　　單元測試是不可避免的一環。

　　程式碼複審＋結隊程式設計可以提高效率。

 

四、總結

　　專案開發仍在繼續中，總有新的問題出現，Leader說的很對，你做過的每件事肯定有其他的人做過，學會站在巨人的肩膀上是一種能力。欲帶皇冠，必承其重。開始學習的不適是必然的，但是使用工具帶給我們的效益遠遠超乎我們的想象。

 

如果您覺得我寫的東西有些幫助，敬請期待我的下篇部落格輕鬆Scrum之旅（下）。