XP迭代的計劃和運作

領測軟件測試網

XP迭代的計劃和運作

LinuxAid.com.cn axing 2001-12-17

    在步入新千年的時候，我們迎來了一個有趣的XP項目。說它有趣，不僅僅是因為它是我們在ThoughtWorks的第一個XP項目，還因為它的龐大：大約有50人。在這里我們將討論我們如何為每一次單獨的迭代建立“必要活動計劃表”，如何僅僅圍繞它開展項目，以及各個子團隊如何圍繞著迭代工作。

簡介

    ThoughtWorks公司位于芝加哥，是一個系統集成和顧問公司，擁有300名員工。我們擅長利用工業中的新的、具有戰略性的技術開發有較高難度的商業應用。我們也做復雜商業應用。這通常需要整合各種組件，擴大組件應用和改變商業邏輯。我們在出租業方面做了大量的工作。這個行業通常不會有那些簡單、清楚的合約。如果你看過一份租用協議，你就會明白我的意思了。
我們已經在建立要求苛刻的租用系統方面花了很長的一段時間了。我們采用EJB來構建系統。這是個非常大的系統，那些賣主們已經花了十年的時間來建立他們的系統。在我們徹底改進我們的方法之前，我們花了18個月的時間來收集需求，創建原型，以及著手開發。我們遇到了很多的問題，這種項目所特有的問題。需求很難理解，不停的變化�？刂七@么一個龐大的項目對開發方和客戶關系來說簡直就是嚴苛的考驗。在這時，我們開始接觸Extreme Programming（XP）的一些思想。我們感覺到它正好適合我們這個項目的特性。同時，XP也很適合我們公司的文化。所以8個月前，我們就開始以XP的方式工作。

    不過，適合歸適合，卻沒必完美。XP是為那些不超過20人的團隊設計的。我們的團隊卻有整整50人，其中一半是開發人員。XP鼓勵頻繁的發布產品版本，而我們面對的是要建立一個新系統來替代原先的復雜系統，這就意味著我們在發布用戶能夠真正使用的東東之前必須要經歷老長的一段時間。所以我們一開始就知道有這些因素在，我們就不可能按書照學XP的做法。（不過我們也沒有按書照做，雖然那本書是我們寫的�。┧�以我們的流程中很重要的一個部分就是每個月對流程進行一定改進，并在全團隊中分享經驗，重新設計我們的XP方法以適應我們的需要。

    當我們開始XP的時候，我們先制訂了一個計劃，包括了18個月的素材卡片（大致上相當于功能），以及把這些素材分成多次迭代。XP運作項目的方法是將項目分成多次的迭代，每一次的迭代交付一個通過質量檢驗、可投入使用、包含了一些新實現的素材卡片的軟件。我們每次迭代的時間花差不多一個月。（比XP建議的稍長一些。）這樣每個月顧客都可以看到系統都會增加一些新的功能。

    這篇文章就是討論我們現在怎么做這個項目的。我們打算周期性的改造我們的流程，而且會騰出手來更新這篇文章。我們還會討論我們作出的一些改變以及我們為什么要改變它們。

團隊結構

    我們的團隊有50個人。項目的管理辦公室包括了兩個發布經理，他們主要負責和客戶及發起人的會面和溝通。日常的計劃工作由版本經理和迭代經理負責。版本經理負責較長時間的產品發布計劃，這通常是不穩定的，時間跨度從六個月到一年。迭代經理則專注于迭代計劃――每次單個迭代的具體細節部分。
版本經理和迭代經理的區分體現了兩個不同的人做事的風格。原來他們只是交替的擔任每次迭代的迭代經理。但是我們發現Matt比較適合跟蹤正在進行的迭代，而Cara更善于長遠版本計劃的制定。所以他們就調整了相互的角色以適應他們的能力和興趣。當然，我們的項目采用這種方法并不意味著大家都要人云亦云。XP的一個重要部分就是所有人都必須對他參與的工作感興趣，這一點也同樣適用于管理者。

    在這個XP團隊中，我們的客戶團隊有12個人。包括了我們內部的領域專家和將會使用軟件Beta發布版本的客戶。

    團隊中的開發人員大約是25人，分為兩個小組。領域小組獨自負責編碼實現每次迭代中新的功能。SWAT小組負責修正bugs，建立流程，測試自動化以及那些和新的功能沒有太大關系的事務。我們之所以這樣劃分團隊，是因為我們希望設計能夠一氣呵成，避免人們因為相互交錯而導致的進度緩慢。有13個人來負責在給定的時間中給代碼庫增加新的功能是足夠的。我們在每次迭代中，一部分的開發人員會輪流在兩個小組間工作，這樣，每一個開發人員都隸屬于過這兩個小組。

    我們的品保人員是8個人的團隊，負責每日的回歸測試。決定每次的迭代結束時應該交付哪些素材卡片，準備每次交付的版本記錄。

    從領域開發者的視角來看，迭代過程非常的簡單。每一次迭代開始時確定一批新要實現的素材，交給品保人員，然后開始下一次的迭代。然而圍繞著這簡單的素材有很多的工作要做。團隊的每個部分都有他們自己的工作周期。大多數的團隊都要花費差不多一個月的時間來處理資料，這些資料來自于三個給定的迭代周期：當前迭代、前次迭代、下次迭代。

    為了示例我們的XP方法，我們把重點放在一次特定的迭代所必須的工作上。為了簡化描述，我們選用數字6來示意迭代。我們所描述的工作其實要比我們真正迭代中要多。（我們可沒打算每次在更新文章時候更新所有的迭代。）迭代6原本安排在6月，不過部分的工作會安排在5月和7月。當我們在討論項目的時候，會把注意力集中在團隊正在工作的此次迭代上。于是我們常常說，“在迭代5的第一周，計劃者就會準備好迭代6的素材卡片清單�！泵總�小組都會有自己的周期表，列出了他們在迭代5、6、7中要做的事情。為了清楚的的看出表中的活動流，我們隱藏了迭代6的所有活動，這樣你可以清楚的看見在真正的迭代開發的前后，都會有哪些活動。你也可以查看consolidated cycle table 來了解所有小組的活動。

計劃周期

    在版本計劃尚處于一片薄霧之中的時候，簡略的第一版迭代計劃就要準備好。版本計劃根本不穩定，非常易變，在我們了解客戶需要和開發人員的工作的過程中，版本計劃在不斷的改變。版本計劃中包括了迭代6的一系列素材和大堆的功能。雖然版本計劃在不斷的改變，但并不妨礙它成為一個基本的工具。它給我們指出了一條路，告訴我們要結果怎樣，如何改進，和評估事件對我們的影響。

    5月初，在迭代5開始一段時間后，版本經理就開始熱切的尋找迭代6的內容�？蛻粜〗M和迭代經理共同確定哪些素材應該在6月交給開發人員。隨著迭代5的開始，我們知道迭代5會實現和不會實現的功能。有了這些信息，你就知道在當前的迭代中，哪些素材不會被實現。除此之外而且你要準備評估下一階段的工作�，F在版本經理就可以收集整理迭代6的所有信息了。

    首先要調整優先級，以確定下一階段的素材卡片清單。只要開發人員的周計劃已被評估，且已經加入到這次迭代的周計劃中，客戶就可以任意選擇素材卡片。這就叫做周轉率。在這個案例中，我們安排了28個星期的理想開發時間，這個決定是根據我們在迭代4中所花費的時間得到的。

    客戶有權利提出沒有排在當前計劃中的新功能，把延后的功能排入計劃，去掉當前迭代中的安排好的功能，或是重新調整卡片上的優先級。用素材卡片的話來說，客戶根據他們目前的商業需求和策略，可以創建新的卡片，把他們加入計劃，或是完全移出計劃，或是把他們分成多個卡片排出他們的優先級。我們會要求開發人員詢問客戶，重新評估這次迭代需要考慮的素材。對項目更多的了解和對素材更多的關注有利于精確的評估，這樣我們就可以準確的評估下一次的迭代了。

    計劃導致版本計劃的再次開展。通產需要花費一個星期的時間來討論下個月的功能性的過程。這個工作一結束，分析周期就開始了。

    在準備迭代6的計劃會議的過程中，版本經理必須要確定這個月中的開發人員的開發天數。這意味著，要計算人們的假期和培訓時間，本月開發人員的有效時間，將上一次迭代的周轉率的時間轉化為這一次即將到來的迭代的理想的開發時間。

    迭代6一開始，迭代經理就必須做好迭代的計劃工作。在迭代計劃會議上，開發人員提出一個迭代計劃。迭代經理就會跟蹤這個迭代計劃，調整附近時間內的一些迭代，以及考慮這次迭代給客戶的交付版本。



    迭代6開始前兩周，領域專家會開會討論即將到來的迭代所需的功能。在對新功能應該如何運作的細節有了共同的意見之后，他們會把精確描述功能的責任分割為工作產品，我們稱之為敘述。每個素材都有一個本次迭代的敘述。一個敘述類似于一個用例，但沒有用例那么正式。我們用比用例中更散文性的語氣來精確描述一個新功能。

    在敘述的最后，必須準備好相關的測試場景的草圖。至少，測試場景具有充分的關聯性，讓開發人員能夠估計素材卡片相關的具體編程任務。這個測試場景會展開成為最終測試，必須來充分的測試素材卡片的功能。如果時間容許，這些測試場景的擴展工作應該優先于迭代6的計劃會議。在實際中，一般最后都會生成測試腳本，貫穿迭代6的整個過程。

    領域專家會議同樣應該先于迭代6的計劃會議，會議要審查敘述，簽署素材卡片。簽署素材卡片表示：同意在迭代計劃會議中提出該項敘述，做為迭代中開發人員的接觸點，保證卡片測試腳本的質量和完整性，在迭代結束的時候把功能提交給QA小組。



迭代計劃會議

    迭代計劃會議是一個大規模的會議，囊括了全部的團隊成員，迭代過程中的需要實現的所有功能。所有的開發人員和分析人員都必須參加。（這時，QA人員正處于他們的周期中的關鍵時刻，所以只有代表列席。）會議需要一個大的房間，墻上貼著大幅的素材卡片。這里有一些基礎規則：使用麥克風，關閉手機，不要帶筆記本電腦，也不要有抱怨。

    所有與會者都會得到一份敘述文檔、一份范圍文檔。范圍文檔把系統分為多個大范圍功能性區域，每個區域都指出哪些素材卡片需要實現，這個迭代中要實現的和以后的迭代中要實現的。我們發現這對于分辨這個迭代該做什么和不該做什么的時候特別有用。

    在享用過甜餅和咖啡之后，按照議程，分析員會對在敘述中描述的功能展開討論。我們討論場景。分析員闡述功能，而開發人員則會對應到具體的編碼。開發人員會對每一張卡片擬出完整的開發人物列表提綱。當提綱做好后，會被記錄到一張大的貼紙上，粘到素材卡片上。

    午飯后，我們結束功能討論，把素材卡分為多個任務。開發人員會分成多個小組評估每項任務。對大多數的項目來說，開發人員在目標卡片上的開發時間往往會超過原先團隊估計的時間。所以客戶會在開發人員的建議下，提煉出整個的卡片或是部分的任務，放入迭代中。在商討哪些任務需要放在計劃之外的過程中，那些獨立的任務或是整個的卡片實際上都已經成熟了。

    雖然這種提煉已經成為項目的日常特色了，不過在最后幾次的迭代中通常不會發生這種提煉。這是因為我們的版本計劃在不斷改進，我們能夠相當精確的估計出一個迭代計劃會議中需要討論多少的素材。這里有一點很重要：在討論迭代計劃之前讓開發人員先進行較精確的評估。你評估的次數越多，評估的結果就越精確。



    一旦功能選定之后，開發人員需要在任務上簽字。這里有幾個基本原則：每個開發人員負責的任務應該不要跨越了大量的卡片，一個卡片業不要太多的人來負責實現它的任務。每個卡片都要有一個分析員和一個品保員，他們要在會以前先在卡片上簽字。一個開發人員同樣要在卡片上簽字，那些負責這個卡片下的任務的開發人員也一樣。

    這樣，會議的結果包括了：一個迭代的功能列表，體現了關聯性，分配了職責；一個開發人員自己擬定的充分的開發計劃評估列表；給每個素材卡片、每項計劃分配了資源。這樣，團隊中的所有人都參與了這個過程，熟悉了下一個月的迭代中要實現的新功能計劃，這些都在墻壁上的招貼上畫著呢。
歷史經驗表明，我們的迭代計劃簡直是難以置信的精確。很少會發生無法完成那些在迭代計劃中簽好字的素材卡片的情況，這提高每個參與者的信心。迭代計劃可以說是對一個月內的未來的最穩定的預測了。

    在如何把功能展現給開發人員這個問題上我們覺得還有很多的工作要做。一個關鍵之處是敘述并不是最終結論。在迭代中，開發人員會頻繁的和分析人員討論功能的細節。在迭代計劃中，開發人員并不需要所有的信息，但他們需要足夠的信息來將素材分為多項任務以形成迭代計劃。這個步驟需要一些初始的設計工作。

    可是問題在于分析人員能不能確保把所有重要的事情全部告訴開發人員�？蓪τ陂_發人員來說，他只需要知道今天的工作所必須的信息就足夠了。所以我們的難點就是開發人員希望簡潔，可是分析人員更關心能夠把那些影響客戶期望值的東西略去。

    我們嘗試著不需要敘述來做事，或是讓版本經理代替分析人員來負責展現敘述。效果都不是很好。我們最后的嘗試是開一個預備會議，會上部分的開發人員會檢查相關的部分敘述。這可以解決前面提到的一些問題。

領域開發周期

    領域開發人員在每次迭代中負責給基本代碼庫增加新的功能。在整個迭代周期中，他們將和領域專家以及其它的領域開發人員一起工作。領域專家將和開發人員呆在一起，面對面的解決問題，共同完成在計劃會議中簽署的任務。開發人員間的合作可以通過好幾種途徑。每隔一天，程序員都要開一個stand-up的短會（會上所有人都站立，以保證會議盡快結束，故稱“stand-up”），討論他們現在的工作，共同解決開發中的問題。



SWAT開發周期

    SWAT團隊將會負責迭代中那些和新增的功能沒有太大關系的事務。所以SWAT的工作就是除開發任務以外的其它事務。這樣可以保證領域開發人員的全心全意的開發新功能。他們的工作包括，修訂上一個版本的bug，自動化測試，理順構建過程，調整性能，升級等等。

    在迭代結束的時候，SWAT團隊將只會修正那些最緊急的bug，保證新版本的交付。一旦迭代結束，功能就一般不會修改了。所以，在編碼時實現過多的新功能是非常冒險的。比較好的解決方法是將未完成的功能放到下一個迭代中再來實現并交付給客戶。



品保周期

    在迭代周期中，品保人員通產采用執行回歸測試的方法來保證上一次迭代交付的產品。在迭代結束的時候，開發人員都匆忙結束那些功能，獲得該卡片相應領域專家的許可。而該卡片指派的品保人員就要負責“卡片通行”。這需要品保人員和領域專家、領域開發人員和SWAT團隊合作來保證每一項功能和該項功能的測試能夠緊密結合，并能夠通過有效的測試交付給客戶。一旦品保人員允許或拒絕迭代中每張卡片的“卡片通行”，我們就要構建一個最終的發布版本提交給客戶。品保人員、項目經理和領域專家會共同撰寫版本記錄文檔隨同最終版本發布。這個版本記錄給用戶大致描述了新的功能以及如何使用。這包括了素材卡片，敘述和測試，迭代過程（當前迭代和整個項目）。品保人員還要負責調整確切的交付日期。作為迭代經理的助手，品保人員同樣要負責提供新功能和培訓用戶。



成功之處

    至此，我們已經發現了一些行之有效的XP方法。

    關于我們在一個給定的迭代中所做的工作的估計一定要非常的精確。一次迭代中我們想要實現的所有卡片在這次迭代中幾乎都要能實現。

    迭代中的所有的卡片都要有實質的、可論證的過程。每個月我們都要進行一致的、快速的、可論證的過程。

    無所不在的交流：團隊間，團隊和客戶、發起人間的交流都得到改進。計劃會議使所有人都能相互了解。團隊、客戶和發起人都能夠清除的表述迭代目標。

    客戶也能夠分享這個制造過程�？蛻裟軌蚋淖兯麄兊闹饕�，而我們來實現。
由于團隊成員和應用都能夠落到實處，對于這個項目到底是什么的疑問也不再困惑著項目成員了。

    我們的項目方法自身經歷了迭代過程的改進。這種改進是全團隊發起的。
當我們第一次接受這個流程的時候，團隊的士氣空前高漲。并且，士氣一旦穩定下來，就不會再下落。

    而我們從這個項目中的最大受益就是我們已經發展出了優秀的高級開發人員。值得注意的是，一年前還屬于低級開發人員的那些人現在已經成為有力的技術領導者了。這歸功于我們的做法：所有人在一開始就要對項目負責，我們鼓勵人們相互交換職位進行輪訓。輪訓可能會有令人沮喪之處，例如一個系統分析員重新又作回開發人員。但是結果卻是我們擁有了很多能夠領導開發任務的技術領導者，這樣，即使項目失去多位高級開發人員，項目的技術領導團隊也非常的穩定。

文章來源于領測軟件測試網 http://www.kjueaiud.com/