下面是我對CSDN上面一個學生寫的《學生使用極限編程進行團隊開發的方案》的評論： 原文地址：http://blog.csdn.net/AimarC/archive/2005/06/01/385279.aspx 我的評論如下： 與其討論XP的開發方法，我更願意討論敏捷開發。 敏捷最終要的是什麼，就是擁抱變化，所以在沒有具體項目的情況下，定出的原則 或是方案都有點之上談兵的感覺。一定要時時刻刻記得，不管採用什麼辦法，客戶 需要的，纔是我們應給貢獻的。爲敏捷而敏捷或者爲極限而極限都不是一個好的開始。 不要一味的去否定傳統的瀑布模型。正如Martin Fowler在演講中說的那樣，CMMI 對敏捷也是友好的。採用什麼樣的開發方式必須取決於所做產品的本身。如果“不 知道如何組織一個團隊，不知道如何分工合作，以及如何開始一個項目”那麼不管 採用什麼樣的開發方式都是失敗的。在敏捷開發社團裏，很強調coach的作用，一 個好的導師或者一本好的手冊，都是團隊取得成功的巨大因素。 下面再具體說說你所劃分的四個階段所存在的問題： 系統規劃階段：在敏捷開發過程中，我更願意把這個階段稱之爲需求開發，這不應 該成爲一個獨立的階段，而應該貫穿於開發的整個生命週期。因爲在敏捷開發原則 中認爲，客戶的需求總是不斷變化的。現場客戶是個不錯的主意，不過UML並不是 必須的。採用用例分析的方法不一定要參考什麼書，關鍵點在於必須使用用戶能夠 理解的語言。比如說使用story card，把功能點從用戶提出的概念分解成用戶能夠 理解的具體操作流程。我想強調的是必須始終進行需求的開發，在每一次版本構建 完畢後，都必須取得用戶的積極響應和支持，與用戶交流，採納或者修改用戶的意 見和想法。 迭代設計階段：Oops，其實這個階段只需要做一件事情，把前面蒐集的用戶需求整 理優先度，首先去完成那些最緊急的部分 迭代編碼階段：很可惜對於測試，你只是一句話帶過。如果你使用XP的話，最好使 用結對編程，這樣可以發揮出XP的最大優勢和潛力，尤其是當你們的編碼能力不太 強的時候，結對編程有一種互補的效應。如果使用你所謂的“接力棒”的方法，那麼 完整註釋和高度一致的編碼規範就是必須的，其實這兩點其實比結對編程更加難以 實施——接力棒缺乏簡單有效的溝通——反而容易變成推卸責任的好藉口。然後說說測 試，要使用好的敏捷開發，必須測試先行，光測試用例是不夠的，最好先寫出你的 自動化的單元測試類（這就是我說爲什麼過程語言很難實現敏捷的原因），並在測 試類運行的前提下進行重構和增量開發。 系統整體測試階段：這個時候，應該是至少alpha版或者beta版了吧，如果還需要 在代碼級的基礎上做重構的話，我只能說“恭喜你，你的項目失敗了”。 歡迎討論。
