在專案中期實踐XP--第一次迭代小結

第一個迭代週期已經完成，因為素材的限制，迭代週期很短，只有1.5Week。目前已經開始第二個迭
代，我從第一個迭代中實施的實踐以及從中得到的經驗和教訓包括：
 
 1、站立式會議
 的確有效果，繼續執行。
 2、計劃遊戲
 我們根據實際的情況，修改了計劃遊戲選取素材，分配任務和領取任務的流程。但還是碰到了一系列
的問題。 首先就是大家對素材的估計相差較大，因為開發人員對素材的熟悉程度不同，導致對素材的
開發量估計相差較大，其次就是大家對理想工作時間的評估不同，還有一個問題就是因為是結對程式設計，
如果A和B程式設計師估計的每週理想工作日都為1.5D，那麼結對者是否就是工作效率為3D每週？在討論之
後，實際將理想工作日的評估改為實際工作日，估計工作效率為3D/實際工作日/每週/每人，因為工作
效率已經考慮了開會，結對等的影響，所以結對團隊的工作效率是可以累加的。
 可能你認為這個計算方法很牽強，但既然是Spike，那就不妨一試。在迭代週期完成後，發現第一個迭
代週期中的個人工作效率為3.6D/實際工作日/每週/每人，也就是說，如果2人結對，一週可以完成7.2D
的工作任務。是否很奇怪？這給目前的這個迭代週期的任務安排帶來困難。另外一個可能有爭議的做法
是，我們採取的是按素材領取任務，而且素材完成期間不更換結對者。
 計劃遊戲中的將素材劃分成Task後再進行估計開發時間這個想法的確不錯，將素材拆成Task後再估計
準確率會大大提高。
 3、簡單設計
 第一次迭代中，只有一個素材，而且領取素材的程式設計師對這個素材比較熟悉，因此設計做得很簡單。
基本上在專門預留的本子上進行的設計書寫，且僅僅寫基礎的框架和重要的內容。在第一次迭代的總結
上發現，這種方式有幾個問題。
 首先就是原本考慮將這些草稿就是計劃的想法錯誤了，因為字跡太過潦草，而且思想很跳躍，留下的
草稿沒有辦法給其他人瞭解。
 其次就是如果有測試先行的功能模組，的確可以不需要太多的設計，寫測試程式碼就象寫設計一樣，但
是如果有功能模組沒有寫測試程式碼的話，就需要更詳細的設計。
 因此，在第二次迭代中要求簡單設計的過程需要寫電子文件，同時，如果沒有進行測試先行的模組，
設計需要多花些時間以彌補。
 4、結對程式設計
 結對程式設計的確增加了效率，一個素材原本估計需要6D實際工作日/單人，在結對的情況下，4D的實際工
作日就完成了，即使算上結對者，好像也只是用了8個工作人日，不過從這一個素材上並不能看出全
部，還需要日後在其他的迭代中反覆檢查。
 但結對程式設計的結對要求實在太高了，特別在我們目前的專案中（專案實施到中後期），Bugfix，聯
調，電話支援等等，一旦某個程式設計師中間有其他事情的打擾，結對就經常中斷，這樣會明顯影響結對的
效果。可能PP可能在專案的開發階段實施比較合適，在中後期實施PD可能更好，我會在後期的迭代中觀
察，如果需要，可以用PD代替PP。
 結對程式設計後其他感受是，程式人員會自覺的經常更換鍵盤，並大量的討論；結對程式設計更容易讓開發人
員感到疲勞；結對程式設計的開發人員最好是互補的，或者水平不要相差過多；對哪些應該結對，哪些不應
該結對開發，還有分歧，例如，在畫介面的時候是否需要結對？目前來說認為需要。總的來說，對結
對，結對者還是認為有效果的，但是無法說明有多大的效果。
 至於第一次迭代的結對程式設計是否真的可以顯著提高軟體的質量，具體還要等測試完成所提交的報告才
能給出更全面的分析。
 5、測試先行
 第一次迭代中，並沒有真正意義上做到測試先行。在所有程式碼中，測試先行的程式碼只有100多行，相比
開發程式碼要少得多。這主要是因為測試需要有大量得資料庫操作，所以在第一次迭代中僅完成了非資料
庫操作的測試先行程式碼。在第一次迭代後，已經專門花時間將這些資料庫的測試程式碼單獨抽取出來進行
了編寫，方便日後的重用，因此真正意義上的測試先行需要在第二次迭代中才能看到效果。
 但是在第一次迭代的程式碼檢查中已經發現了問題，開發人員所些的測試案例和相應的程式碼沒有突出重
點，部分測試案例根本不是主路徑或者煙霧測試案例，而是一些第三測試級別的容錯性測試。
 6、程式碼規範
 程式碼規範做得還算可以，雖然在後來的程式碼評審中看到一些問題，但是問題不大。
 7、8小時工作制
 因為其他工作可能的影響，在我制訂的“XP人的一天”中，每天結對的時間為6.5小時，程式人員是完
全按照其執行的。但下班後他們往往不願離開，對這個問題上，以他們的意願為主。
 8、重構
 結對開發人員會比個體開發人員進行更多有意識的重構行為，而且也會在相應的討論中互相學習，而
且這完全是自發的，非常棒！
 9、持續整合
 目前正在進行持續整合的第一步環境的搭建，也就是自動定時編譯釋出環境，計劃月內完成，等第一
步完成後，再搭建自動單元、黑盒測試的環境。附帶說下，CruiseControl這個持續整合工具用起來真
的麻煩，而且主要用於Java的開發環境上。
 10、CRC卡片
 說實話，我不知道如何書寫CRC卡片，我所見過不同的文章所描述的CRC卡片的描述方法也不同，第一
次迭代中我們採用平鋪直述的方式描述素材，但這好像不如用例模式的方式書寫，這讓程式人員有相當
的問題需要詢問“在場客戶”，在第三次迭代中，將採用用例模式來書寫素材。

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-582354/，如需轉載，請註明出處，否則將追究法律責任。