一  引言
  
      近來,在BOSS系統團隊敏捷開發薰陶和感染下,對敏捷開發求知是蠢蠢欲動. 心動不如行動. 咱也不能被動接受捱打吧. 這幾天向戰鬥在BOSS一線具體參入人員問了卷,
實施敏捷開發大哥們們請教. 感覺是個好東西.它是對傳統的以瀑布模式為主的專案管理一次抽取精華和改進(個人認為,PMB專案管理的理念，敏捷開發中具體方法都有它的影子，只是濃縮精華).但覺得腦子裡只是一些零散的概念，沒有對敏捷開發系統理解。沒有整體把握，底氣不足，作為敏捷開發中注重以人為主，團隊自管的思想， 咱也提不出好的改進意見 . 不利於敏捷持續發展. 於是利用中午和晚上時間在網上下載一些敏捷開發文件學習 , 趕快來武裝自己。與時俱進，落後就要捱打哦！
 
   系統學習了敏捷中兩個方法（極限程式設計和Scrum）,結合以前學習的pmb以傳統的過程為主，強調文件：一個階段的輸出就是下一個階段的輸入，文件是個階段銜接的唯一資訊。
有點像工廠流水線作業. 這一綜合，思想就有點火化了。感觸敏捷開發體現了一些我們平常生活、人生哲理。就不再太羅嗦，言歸正捲了。
 
    
二  敏捷開發所體現的哲理
 
    1、與時俱進，不斷改進，不斷完善理想
 
       敏捷開發中一個重要的思想就是要在具體專案中不斷改進。主張要不斷完善，發現問題，勇於針對具體的問題，引起敏捷方法實踐
     勇於重構程式碼。這些理念在我們生活中也同樣受用。古人云：知錯就改，人無完人。也是要求我們要勇於承認自己的不足，只要我們有勇氣
     發現問題，分析問題，勇於改進。這樣我們才能夠前進。哲學上講矛盾的原理也是一樣的。
 
    2、集中力量解決重點問題，小步前進，穩紮穩打,步步為營
      
      敏捷開發注重迭代開發，增量的進行工作，小步前進,不停的思考、反省和總結，不停地進行自我調整、完善、改進. 這種方法很明顯是能夠
    及時發現問題、總結問題，降低專案中的需求風險和開發進度風險（需求列表排了優先順序，前期就可以把客戶確認的重點需求投入精力做好，
    後面迭代sprint週期能夠根據前一個週期srpint情況來及時調整和改進）.
 
    3、注重以人為本的思想，注重參入、溝通、反饋
 
        敏捷開發中的極限程式設計方法論中實踐原理中很多體現了這些理念。如：讓客戶編寫user Story,讓客戶參入具體的功能需求編寫過程中；sprint週期
    中定期加強為客戶的溝通；客戶與開發人員儘量在一起辦公；開發人員集中辦公，及時溝通；結對程式設計；隱喻（一些好的規範，專業術語提前在團隊
    中整合共識） ,程式碼共用，晨會等.
        
         這些方法在我們實際生活同樣實用.畢竟任何東西還是要由人來做的。因此在各個場合都會存在調動人的積極因素來影響環境和事物。
 
     4、簡單原則
 
          極限程式設計體現跟蹤客戶的需求變化，既然需求是變化的，所以對於目前的需求就不必過多地考慮擴充套件性的開發，講求簡單設計，
     實現目前需求即可。簡單設計的本身也為短期迭代提供了方便，若開發者考慮“通用”因素較多，增加了軟體的複雜度，開發的

     迭代週期就會加長。簡單設計包括四方面含義：

                  1、通過測試。2、避免重複程式碼。3、明確表達每步編碼的目的，程式碼可讀性強。

 

       簡單哲理在我們生活中也是無處不見，感覺最明顯是我們穿的衣服更簡樸和舒適，更適合我們個性展示；還有大家經常說複雜問題簡單化,簡單生活,

    快樂生活等都體現對人生豁達、快樂的態度.

 

     ......

 

三  建議

 

    1、民主參入度有待加強

      

       這幾天我問了近十幾位一線參入BOSS和CRM敏捷開發人員（大部分是合作方）。主要涉及對敏捷的認知，參入度，參入角色等。發現大家基本還是認同敏捷，

      但是對一些具體的實踐方法還是存在模糊的認識，甚至抵觸心理。比如：結隊程式設計 （實際上結隊程式設計在運用時是要根據實際情況而定，有一定邊界條件。

      像對新員工，對核心關健業務，對sprint迭代檢查過程中發現大家程式設計問題等，這時可以實施結隊程式設計）.其次有就是對敏捷基本都沒有一個完整的概念。如：

      敏捷中的基本思想，敏捷中幾個主要方法，敏捷每個方法用途和使用的條件等。最後，就是參入訪問的人基本都沒有接觸過敏捷開發軟體，對一些天天寫在牆上的

      “燃盡圖”都不知道，缺少參入意識（寫這個時，徐志明發Mingle的使用知會,希望大家在使用這個軟體時對敏捷起到加深理解作用。應早該一點發給我們啊！） 。

 

        a  敏捷開發人員是以人為本，著重的實施還是得靠大家，需要大家共同的參入、支援和理解。希望領導在具體實施過程中讓更多的人蔘與進入。

             參入過程中要加強PL的職責和引導大家作用。讓更多一線工作人員，特別是合作方，有一個認同感，尊重感。調動他們的積極性和主動性

        b  加強團隊組織建設，落實負責人責任制。現在感覺BOSS團隊上層參入討論敏捷很活躍，根據實際的專案運用了敏捷開發中許可權程式設計、Scrum和傳統方法結合，

           政策和方向都是正確的，但是到下面pl下一級具體落實下，需要pl對敏捷開發能夠靈活運用，引導本組人員進行敏捷開發學習，討論、參入.

 

    2、 每日晨報內容要根據具體的情況而定

 

       我們進行的晨報大家現在都認可了，大實現中也取得一定效果。但是感覺有些組還是基於它所表現的三種基本的形式（今天做了什麼，明天做什麼，所遇到困難）.

       個人覺得晨報的內容要根據專案、各個小組具體的情況而定，不可一概而定,基於形式。

 

          a、 根據sprint週期後總結中發現問題，針對性在下一階段的sprint週期中引入晨報內容。如：在sprint週期總結中發現大家程式設計不規範，在Daily Scrum meeting

              注重檢查編碼規範問題；如：上次CRM團隊檢查程式碼質量時發現一些問題，在下幾個Daily Scrum meeting中注重檢查程式碼質量問題，至到問題解決為至。

         

          b、 根據專案開發不同階段制定Daily Scrum meeting；

 

         個人認為引為這個東東，還是為了解決問題。在過程中不斷改進。

 

    3、 技術專家人員支援、重視有待加強

 

         來華為兩年了，感覺這邊是很重視業務的，不注重技術。畢竟BOSS業務比較複雜，業務重要是不言而遇。但是在實際的BOSS維護中，發現很多的二線問題、bug單

       都是由技術引起。而一些有經驗的老員工，管理人員很少參入到技術當中把關。以至BOSS一些問題單每月每天迴圈出現。雖然現在引入了測試驅動開發、持久整合等

       方法，但是一些核心業務還是需要技術專家來監督。

 

       a 、 對一些核心程式碼，關鍵業務，除了要進行測試外，更重要是專家技術人家承擔起負責，對其功能指導、監督、檢查，

            必要時可結隊程式設計；

       b、  在團隊內部要形成一種氣氛和文化，技術和業務都重要。甚至在待遇方面要落實；

 

    .............

 

     看見BOSS團隊根據我們實際出發引入敏捷開發，甚感高興，有喜的事，現在已取一定成果。願我以上的感悟對我們團隊有所幫助和啟發