Scrum 思考

      下個月就要離職，因此這個月特別悠閒，上班時間都在上網看書，偶然在Startup News的一篇文章（http://blog.devtang.com/blog/2013/06/17/startup-anniversary-note/）中看到一個Scrum這個名詞，第一印象覺得是某種工具-_-!!!，遂google之，才知道是一種敏捷開發框架，看了兩本相關的書，以爲這種方法很是高效，迭代式的增量開發，每次sprint都有產出，開發者很是有成就感，也能及時收到反饋，項目也不會遙遙無期。因而開始思考是否適用於如今的工做環境。

背景：

    現有IT部門主要職責是負責維護舊系統（10年曆史）以及基於這個系統進行功能擴展。公司是美國公司，技術部門在中國。工做模式就是，美國的客服使用SugarCRM記錄客戶報告的case和bug，建立後直接指派給相關負責人，負責人再分配給程序員，程序員按照priority按順序修復。完成後發回給Q/A，Q/A確認沒問題，在每週二進行預發佈，每週四真正發佈到正式服務器。

問題：

    這樣的流程已經有一段時間，程序員通常都很是悠閒，只要把case和bug完成了就行。系統代碼雜亂不堪，只要你能修復客服問題，能實現他們要的功能，美國同事就不理了，代碼一直停留在最原始的的狀態，程序員在這種環境下變得鬆散，慵懶。因而我就想，可否經過引入Scrum工做方法，來提高產品質量和性能，同時，對於程序員自己也是一種負責任的態度，畢竟成天沒事作很無聊。因而有了下面的設想：

設想：

    1. 將每週發佈一次的週期改成更長週期，好比兩週

    2. 第一個週一開全體開發人員例會（至關於sprint計劃會議），會前準備須要修復的bug和新增功能， 整理出兩個星期內須要緊急完成的任務，通常不須要太多，預留充足時間，以防中途有一些critical的case。同時，全組人員討論，系統須要優化的項目，每一個人發表意見，經過投票挑選出急需優化的1項, 討論是否能在這次週期中完成，是否須要將該項分割。

    3. 肯定這次要完成的任務後，你們對全部任務進行評價，按重要程度分配工做

    4. 設定「看板」，看板包含四列：To Do, Work in Progress, Q/A , Done。看板的好處直觀的瞭解到天天的進展，保持緊迫感，到最後一天看到全部任務都在Done列，也有必定的成就感。 這個「看板」在《精益創業》這本書也提到過，只是書中提到了verify列，咱們很難作到。由於咱們不是產品負責人，因此只保留最簡單的四項。

    5. 程序員完成一個case和bug，仍是自行測試，而後assgin給Q/A進一步測試，確認沒問題就能夠直接發佈到預發佈服務器進一步測試。

    6. 創建wiki頁面，記錄每次sprint完成的主要內容。

好處：

　這樣相對於如今有下面幾個好處：

   1. 解決程序員有時候無事可作，有時候很忙的狀況。

   2. 冷卻某些高管天馬行空，可是對用戶根本毫無用處的想法。

   3. 每次sprint都能對系統進行小規模優化，穩定性及可靠性不斷提高。

   4. 全部任務對於團隊成員很是透明，方便交流。

   5. 每次sprint的產出都具可直觀體現。

 

     這是看了兩天關於Scrum後的思考，未經實踐，有點邯鄲學步的感受。雖然目前狀況沒能力改變，可是也針對的一些思考，對我將來職業生涯有所幫助。對於即將任職的新公司，是多個項目同時進行公司，每一個項目相對獨立，可是每一個項目成員只要1-2個程序員，人員分配應該若是處理？ 有什麼實踐中的細節須要處理？但願有實戰經驗的園友們賜教！

 

參考書籍及文章：

[硝煙中的 Scrum 和 XP ]

[看板和Scrum相得益彰]

http://zh.wikipedia.org/wiki/Scrum