大型項目的XP(極限編程)

大型項目的XP(極限編程)

作者：Amr Elssamadisy 著，simaetin 譯
本文選自：UMLCHINA  
2002年05月13日 

我們在ThoughtWorks這樣的大型項目中應用XP方法的時間超過了15個月。這個項目開始于三年前，那時它有大量的需求文檔和幾個獨立的功能小組。從2000年1月起，我們決定應用XP，雖然當時我們已經知道XP并不適用于大型項目。那時，我們需要向客戶提交功能演示，并要通過提交一個工作子集而不僅僅是原型來贏得他們的信心（我們在團隊中有超過25名開發人員和大約15名分析員）。但我們并未準備好功能，各個組都使用自己的代碼框架，一個完整的應用無從談起。簡短地說，就是客戶想要看到點什么，但我們還沒有真正的功能。應該說開發的第一迭代期是成功的：我們給客戶提交了一個真正的應用子集。成功的首要原因是我們讓來自Asset, AR 和GUI組從事不同工作的開發者融合在一起。當然，其間也有"成長的煩惱"：在分析員和開發者之間發生某些個人沖突，但我們成功跨越了這些障礙。那時一切都很美好：我們以飛快的速度成功地提交了功能演示，但隨著時間的流逝和項目的繼續，有些事情卻不如我們所愿。這就是這篇文章要講述的內容：我們真正的收獲在"蜜月"期后，關于我們如何在一年半中管理一個50人的項目開發并及時完成階段性的提交（盡管有時并不成功），關于我們經歷的痛苦，我們后續的工作，我們最終學到的以及作為改進要用到下一個項目中的經驗。

首先，我們給出我們開始的狀況：15個月前我們是如何應用XP的，然后展示我們現在的XP應用情況。也就是說，下面將討論我們改變技術的原因。這是一個自然選擇的過程，它剔除了許多不好的想法，或把它們改造成更有效的方法，使之更適于大型項目。最后我們將總結并給出在大型項目中使用XP的謹慎建議。

大型項目中XP的元素

好吧，讓我們來進入正題。我們開發和分析的隊伍由大約35名開發人員、15名分析人員和10名QA組成。開發人員依賴分析人員作為項目的客戶。盡管有實際的客戶，分析人員還是要協同工作以便有選擇地做出客戶決策。下表演示了[1]所討論的XP基本元素并簡要介紹了這些方面如何應用到項目的各個階段。我們用這個表來分析我們團隊自然選擇的實踐，以及書本上的XP如何應用到一個超過50人的大型項目中。

結對編程

首先我們說說結對編程的體會。多數情況下，我們在某個迭代期間有兩個開發人員同時為一個故事卡片（或幾個迭代期的相關卡片）工作。在大型項目中開發人員需要投入更多的關注，因為開始新領域的編碼的熱身時間是不容忽視的。開發人員間良好的溝通和周期性的計劃會議讓每個人都具有誰在做什么的整體概念。這使得經典教科書中開發者甲找到開發者乙要求共同解決問題的結對編程方式成為可能。

結對編程當然很好，但并非任何時侯都適用。最通常的情況是，在改錯和維護時開發人員并不愿結對，并且這種情況下許多眼睛盯著調試代碼也確實沒什么好處。再有就是迭代期間的重復工作，這種情況下，問題的解決方案已經確定，不必再結對了。

還有，開發人員有不同的個性：有些人需要間歇性的結對編程，而有些人更加出色，結對編程會妨礙他們才能的發揮而最終成為他們的負擔。

單元測試和集成構造

單元測試和集成構造絕對是必要的，這意味著如果我們沒有測試，我們就不能提交任何代碼。當應用程序變得越來越大時，沒有測試我們就不能加入任何新功能或進行重構。我們現在在新代碼進庫時會有集成構造和測試。關于這些構造及測試的細節，負責人員會及時放在內部網頁上，這樣每個開發人員都能知道當前的構造狀態，事務分析員和QA能拿到最近構造的信息來測試新的功能。

組內所有和信息共享

對于這樣一個大型的項目，為了防止被分為孤立的部分而使整個系統做出不適當的假設，信息的發布和不同部分的代碼輪作非常重要。溝通是必需的（但我們無法強迫一個沉默的人開口）于是我們試圖在每兩周一次的短會上給每個人發言的機會，以使沉默寡言的人能說出他們的要求。而最終我們取消了這樣的會議，因為大多數開發人員認為這種把每件事都蜻蜓點水地提一下的會議只是浪費時間。這也是這個團隊的優點之一??我們總能象一個共同體般地工作，如同結對編程一樣地合作。

開始，我們采用了輪作的方法，也就是每個人對每件事都作一點，這使得我們在后來快到截止期限的時候都在從事己經了解的事情。但對于一段復雜的代碼，要做到這一點，時間投入非常巨大。最好采用折衷的辦法：也

就是在項目時間緊的時候只作每個人熟悉的工作，而在其它時候，比如改錯、研究或正在做一項熟悉的工作時，可以同時做一件不熟悉的事。我們現在的原則是，開發人員在幾個迭代周期中連續做一些相關的卡片，同時逐漸地轉向系統的其它部分。在同一個迭代期內簽入幾個不同卡片的做法己經不再用了。

代碼確實會越變越糟。是因為我們的項目有些大嗎？還是因為許多做代碼的人都是新手（是指這個功能領域中的新手，而非編程新手）？答案可能是二者皆有吧。但有時我們不接觸代碼，很難開始系統的其它部分，因此定期清理代碼是必須的。這樣引出我們下一個論題：重構。

重構

在應用XP的大型項目中，為了消除代碼的不一致性，重構是絕對必要的。即便對于那些對項目的應用領域很熟悉的人，也會面對重構的巨大工作量望而卻步。對于項目經理來說，必須認識到重構需要另行分配時間。我們做到了這一點，我們留出了時間來重構代碼的主要部分。

短迭代周期

迭代期及其期限是必須的，但長度一直是個問題。過去我們采用長迭代周期（如一個月），而每到月末就會很緊張并伴隨著一些不良代碼的加入，并且不可避免地在估計上出現問題。我們不得不接受一些未做的卡片（這對開發人員來說非常困難，并且難以滿足既定的期限）。

總結

下面把18個月中我們在這個50人項目的經驗和教訓列出如下：

1) 在每個迭代期開始時進行迭代計劃會議。每日客戶和開發人員討論最近的故事卡片并評估它們，在每天的討論結束后重新分組并演示這些評價和發現，然后讓開發人員簽入。這可以讓整個項目組知道項目的當前情況而不用讓每個人都卷入馬拉松式的會議。

2) 使提交版本周期盡可能短：我們是兩周一次，但在必要的時候也可以使提交跨多個迭代周期。允許在多個迭代周期簽入卡片，但要以每個周期為單位進行進度的監控。

3) 進行盡可能多的單元測試，這是不言而喻的。應當有一個自動進行功能測試的軟件包以保證測試的覆蓋范圍。但是QA組是不可替代的（無論開發人員寫過多少測試程序），因為我們對系統怎樣工作總是存在偏見。

4) 簡單的設計能幫助我們連續向客戶提供可工作的版本。頻繁的設計會議對于加入大量新功能時是很有用的，而午餐是一個召集整個項目組的好時候。這可以避免在系統的不同部分同時存在不兼容的解決方案。

5) 重構是能夠做到簡單設計的唯一方法。設計的重構與代碼的重構同等重要。盡管不進行重構而采用打補丁的解決方法往往是有吸引力的，但是如果一個系統的補丁太多，那就意味著今后它將進行更大的重構。

6) 在加入新功能時，要堅定不移地貫徹結對編程，而在改錯和做重復性工作時停止，因為問題已經在結對時解決了。

7) 集體所有和溝通密不可分。團隊必須有一種有效的溝通方式。也許不僅僅是非正式的討論，有時定期的10到15分鐘的發布會是很好的方式。

8) 在大型項目中，一些人要扮演客戶的角色，為大量開發人員產生足夠的工作。這和領域知識密切相關。

9) 編碼標準是十分非正式的，這不會損害你的進度。更重要的是一種通過演示的溝通。代碼不是文檔的全部，開發人員需要看到全貌，這是代碼不能提供的。

也有一些規則我們沒有實行：

1) 兩周一次的站立會議是低效的�？梢赃x擇每月一次的迭代團隊通氣會來替代。

2) 迭代計劃會議沒有必要讓全部人員參與。更好的方式是按更小的組進行研討，而在每天下班前用30到45分鐘對卡片進行討論。

3) 一個月的迭代期太長，不利于產生高質量的代碼。2周一次的迭代周期更容易跟蹤并使估計更準確。

4) 上一點在大代碼量時并不合適，特別是重構大規模系統時。這時一張卡片會影響到多個迭代期。

5) 比喻（Metaphor）對于大型系統是不適合的。

6) 每周40小時我們來說不成問題，40小時是最少的情況，超時工作并沒有給我們帶來不利的影響。要重申的是，我們不是100%的實行結對編程。

這就是XP，或者說我們的XP版本，在我們小組所做的工作。我們經歷了按時提交大型復雜應用的過程，也為每個開發人員提供了應對此類項目的寶貴經驗。

參考書目

1. Beck, K. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999; ISBN201-61641-6

2. Fowler, M. and Foemmel, M.; Continuous Integration