敏捷開發之旅(1) – 新的開始

 在開始之前簡單介紹一下：小龍服務於一家叫做xx的軟體公司,在裡面是一個Team Dev的PL,直接領導是老徐。

 

         小龍的Team Dev總共有七人,一個最佳的ScrumTeam Dev人數
         PL     ： 小龍

         成員   ： 賓哥  紅姐(MM) 小美女(MM) 排骨(MM) 小梅(MM) 小梁(MM)

 

         呵呵,看到性別後大家都傻眼了吧,七個人的團隊中有五個MM!這可是事實!是不是有些羨慕呀.

 

 

 

新的開始

 

         剛做完一個項目，項目的的人員都比較空閑，作為項目PL的小龍也在近期對上一個項目進行了總結(備忘：作為團隊的管理者，一個項目完成之後一定要做一個詳細的項目總結,作為開發人員最好也要總結，總結自己得失，最好能以文本的方式輸出給自己的領導).

 

         上一個項目是一個典型的採用Scrum架構的敏捷項目,也是小龍所帶領團隊重組後的第一個項目,由於剛開始整個團隊對敏捷的認識不足、專案範圍的控制力度不夠、等因素導致原計劃6個月的項目延遲了整整2個月，這樣讓以前自信滿滿的小龍受到了不小的打擊.

 

         唯一值得高興的是經過這長達8個月的敏捷實戰，在經曆了數次血淋淋的教訓之後,團隊上下對敏捷開發的認識更深了一步，團隊之間的配合越加密切，積極性和主人翁意識也越來越高了,並且在項目後期大家一起努力整理出來了一套適合自己團隊的敏捷開發方式.但是，因為是在項目後期，許多工作是不可能重新來做的，所以這些開發方式對這個已經收尾的項目沒有起到多大的作用.這也使團隊每個成員都憋著勁，都希望可以找一個項目好好的實踐一下我們自己的開發方式...於是為了提高團隊的信心和驗證一下我們自己的敏捷開發方式，小龍開始考慮著是否主動去找領導接一個小項目來做做。

         (註：適合我們團隊的敏捷開發方式--並不是我們自己搞了一套敏捷開發方式，還是使用Scrum開發，而是根據我們團隊的特點來決定在Scrum的各個階段我們應該重點關注哪些事情，重點做哪些事情,應該由誰來做等等，一個新團隊如果在沒有充足的敏捷經驗的情況下，照著Scrum的規範來做，都會出現一些亂七八糟的問題，並不是Scrum有問題，而是團隊不知道如何做，或者做到什麼樣子的程度才算符合.)

 

         在接下來的幾天裡，小龍給團隊成員安排了一些學習性的任務，並沒有著急的開始去接項目，畢竟剛做完一個這麼長周期的項目，雖然不怎麼加班，但是大家的心理上還是比較疲勞的，正好在這個階段給大家放鬆一下...順便讓大家充充電，多學習點知識，為下一個項目做好充足的準備.(註：做完一個項目之後一定要然給大家休息一下，但休息不等於放假，讓大家學學新知識，充足一下自己也算是另一種休息) 當然小龍本人也在這段時間完善一下自己整理了幾個專題《開發管理checkLists》《哲理故事與管理之道》《Eclipse rcp/rap 開發經驗總結》,這樣即可以鞏固個人對管理和技術上的認識，又可以讓其他朋友參考和學習，何樂而不為呢...

 

         就這樣又過來幾天，看到大家都放鬆的差不多了，再放鬆下去就容易產生惰性了,小龍準備去找自己的領導老徐去溝通（備忘：為什麼要主動找領導溝通？舉一個很簡單的例子--你站在一個管理者的角度考慮，2個差不多的員工，一個經常找你溝通，向你要需求，一個你要自己去找他溝通，給他分配需求，你喜歡哪個？），很早之前就聽領導老徐說希望要做一個人力資源管理系統，正好現在大家也休息了一小段時間了，不如拿這個項目實驗一下我們總結的的敏捷開發實踐的效果?帶著這份期望，小龍來到了老徐的辦公桌前：

 

          "徐工，最近團隊有點空閑時間，要不我們做一下你前段時間說的人力資源管理系統?"

          "好呀，你們上個項目都測試完了，沒有問題了？"

          "是的，已經沒有問題了，所以才來找你呀!"

          "好!那我給你簡單講下這個需求吧.這個小項目的目的是統一管理我們xx組所有的人力資源，由於我們目前大約有七八十個員工不怎麼好，每個員工最近在幹什麼，是否出差，是否請假都不是很清楚，我希望這個平台能夠管理和查看所有人員目前工作狀態和日誌的管理... ..."

 

          接下來老徐有開始介紹細節"這個系統大約分為2個主要的管理介面，一個是人員個人基本資料管理介面，另外一個是人員所在做的項目和所作任務管介面，系統的許可權也需要進行控制，不同層級的人員登入後看到的介面不一樣，許可權也不一樣..."

 

          經過和老徐半個小時的溝通，小龍終於差不多瞭解項目的需求和介面的展示方式.於是小龍就回到了辦公桌上整理剛才的溝通結果,並讓賓哥預訂一個會議室準備開組內會議. 

 ------待續

 

 

-----------------------------分割線--------------------------------

 

為什麼要寫著這一系列的文章？

    

         第一、如同文章剛開始說的，上一個敏捷項目還算可以，但是個人認為不怎麼成功，後期整理了一套適合自己團隊的敏捷開發管理方式，我個人想把這個方式正式的用在項目中，就如同上面說的哦"寫出來，即可鞏固個人對管理和技術上的認識，又可以讓其他朋友參考和學習，何樂而不為呢..."

         第二、個人也想驗證一下自己整理的《開發管理checkLists》具體實用性,我會按照著這個專欄的大體順序往下執行,當然我也會在文章中指出在什麼階段可以使用哪個checklist

         第三、收到過很多關於《哲理故事與管理之道》的評論,例如"當世之人，知道者多，行道者少",我同樣會把專欄《哲理故事與管理之道》裡面的管理方法用到實際的團隊管理中去.也會在文章中指出個人犯了哪些管理上的錯誤，個人是如何改正的.

 

歡迎大家拍磚。

 

             <敏捷開發之旅> 同步更新於 iteye / csdn   轉在請表明出處

             <敏捷開發之旅> by dyllove98 @  http://jlins.iteye.com/  

          <敏捷開發之旅> by dyllove98  @ http://blog.csdn.net/dyllove98