現在再來看迭代和遞增類別。很明顯，團隊協作類別的實踐支持該類的實踐，由于團隊的參與，針對目前的情況選用正確artifact的機會就增大了，你就可以根據需要來切換使用不同的artifact。驗證類實踐能夠賦予你使用遞增方法的勇氣，特別是在你用代碼驗證的時候。保證你想法的易測性，你就更有把握同時操作多個artifact，并在它們之間切換，因為測試問題要求你從多個方面來看待它。文檔類實踐同樣可以促進遞增方法，特別是非到萬不得已不更新。但是合同模型要正式這個實踐抑止了遞增方法的應用，因為你總是希望能夠盡早的建立和其他系統間的接口標準。切換到另外的artifact和丟棄臨時模型之間也能產生正面的效果，因為一個模型完成目的之后就把工作切換到另一個模型上去。簡單類實踐對這個類別也很重要，通過使用最簡單的工具，你在不同的artifact間來回切換就變得更容易了，你節省了熟悉工具的時間，只把精力集中在簡單的內容和描述上，你也可以較容易記住模型要傳達的信息。最后，動機類實踐可以令你同時進行多個建模工作，因為對于復雜的系統，你需要從多個方面去溝通，去理解，因此你需要在適當的artifact間來回切換，這樣才能有效的做到這一點。
驗證類實踐可由簡單類實踐來支持－－創建簡單的內容和簡單地建模能使你更容易進行測試性思維。迭代和漸增類實踐也能提高驗證類實踐。例如，在你切換到另外的Artifact時，就可能切換到源代碼，這樣你就可以看到模型確實可以運行。
簡單類實踐可以推進生產力類實踐。當你使用簡單模型工作時，逐漸應用模式就更容易一些；當你簡單地建模時，使用建模標準也會容易一些，而模型的簡單、易懂，也會使你比較容易的重用現有的資源，例如企業需求模型或通用的架構模型。
簡單類實踐以及迭代和漸增類實踐可以支持文檔類實踐的進行。文檔越簡單就越容易使用－－如果你的文檔容易理解，這樣你就有把握萬不得已才更新你的文檔，因為你知道做到這一點很簡單；文檔如果很復雜，你的項目風險就很大，因為沒有把握什么時候文檔需要更新。很明顯，非到萬不得已不更新和丟棄臨時模型的運作環境可以其它的實踐來改善，例如切換到另外的artifact、小增量建模。
那，你想成為一個敏捷建模者嗎?
個性通才還是專才?
敏捷建模者的個性
Alistair Cockburn指出：很多的方法學都定義了軟件開發項目中開發人員所擔任的角色，同時還定義個各個角色執行的任務，盡管入席，這些方法并沒有定義這些角色最適合的人選。一個人要想成功的擔任某個角色，他應當很好的適應它－－雖然這并不需要人們掌握所有的技能，但人們必須要慢慢的熟悉這些技術。我的經驗告訴我，要成為一個成功的敏捷建模者，下面的列出的個性是必要的：
團隊競賽 第一點，也是最重要的一點，敏捷建模者總是積極的尋求協作，因為他們意識到他們不是萬事通，他們需要不同的觀點，這樣才能做到最好。軟件開發可不是游泳，單干是非常危險的。在敏捷的字典中沒有“我”這個詞。
暢所欲言 敏捷建模者都有良好的溝通技巧－－他們能夠表達出他們想法，能夠傾聽，能夠主動獲取反饋，并且能夠把需要的寫出來。
腳踏實地敏捷建模者應當腳踏實地。他們的精力都集中在滿足用戶的需求上，他們不會在模型上畫蛇添足，即便那雙足是多么的好看。他們滿足于提供可能的方案中最簡單的一種，當然，前提是要能夠完成工作。
好奇 敏捷建模者樂衷于研究問題，解決問題。
凡是都問個為什么 敏捷建模者看問題從不會至于表面，而是會打破沙鍋問到底。他們從不會就想當然的認為一個產品或一項技術和它們的廣告上說的那樣，他們會自己試一試。
實事求是 敏捷建模者都非常的謙遜，他們從不認為自己是個萬事通，所以他們會在建立好模型之后，用代碼來小心的證明模型的正確。
勇氣 敏捷建模者應當愿意去計劃一個想法，然后做出模型，再想辦法用代碼來驗證。如果結果不理想，他們就會返工，檢查他們的方法，或是放棄原先的想法。把你的想法告訴你的同伴，再來驗證它的正確，這是需要很大的勇氣的。
根據實驗 敏捷建模者應當愿意嘗試新的方法，例如一項新的（或是已有的）建模技術。一般而言，他們也會接受敏捷建模開發技術，必要時，為了驗證想法，他們愿意同傳統的思想做斗爭，例如在一個項目中減少文檔數量。
有紀律 要堅持不懈的遵循敏捷建模的實踐。對你來說，你可能會在不經意間說，“加上這個功能吧，無傷大雅�！被蚴�，“我比project stakeholder更了解�！痹贏M的道路上要想不偏離方向，是需要一定的紀律性的。
如果你不具有上面列出的所有個性，那該怎么辦呢，你是不是還想成為一個敏捷建模者呢？不用擔心，你只需要少量的努力就能夠勝任。相信我，我也沒有辦法做到100%的腳踏實地和實事求是，我也經常遇到溝通問題。沒有人能夠擁有所有的個性，大部分人都只能擁有一些個性。每個人都有不同點，這些不同點正是敏捷團隊力量的源泉。某些人可能生來就好奇，另一些人的工作積極性可能比較強。人無完人嘛。
通才還是專才?
當你要增加團隊成員時，所要處理的一個至關重要的問題是你希望保持的通才和專才的比率。要回答這個問題，你需要考慮現代軟件開發環境。圖1是企業統一過程（Enterprise Unified Process EUP） 的生命周期。（譯注：原文中并沒有提供這副圖，根據我的猜測，應該就是RUP的概述部分的那張生命周期圖，但是因為沒有取得瑞理公司的授權，所以我暫時也不便引用這張圖，大家可以參閱RUP的相關資料。）圖左邊的EUP的工作流程暗示著軟件開發的復雜－－你需要進行業務建模，收集需求，分析和設計系統等等－－而這還只是冰山一角。就像圖中列出的那樣，從先啟到產品化的各個階段，預示著在項目的過程中，不同的時間需要你集中于不同的地方，這需要不同的技能。有一個觀點是很明確的，軟件開發非常的復雜，任何一項工作都需要高超的技能和豐富的經驗。首要的，要認識到這種復雜性是軟件開發與身俱來的，而不是EUP使然的，即便你的團隊采用的是XP方法，抑或是DSDM（Stapleton, 1997）方法，或是SCRUM （Beedle & Schwaber, 2001）方法，這種復雜性也還是存在的。盡管這些方法的生命周期看上去并不像EUP那樣的復雜，但它們仍然需要配置管理活動，需要管理活動等等，只是它們處理問題的態度不同而已。
很多的組織對此的第一反應就是建立一個專才的團隊。專才的最基本的含義是指那些特別精通某一項任務的人，因此他們的效率也特別的高。這樣一支團隊，要想高效率的運作，你需要組合這些專才，讓每人負責一塊任務，解決之后就把手頭的工作傳給另一個人。這個概念就類似于“流水線”的想法，如果你是在大量的生產汽車，這種方式會非常的有效，但是以我的經驗，在手工的軟件中采用這種方式并不是太合適。而且，這種方式需要一個大團隊的支持－－如果軟件開發中有N中不同的任務，你至少就需要N位專才才能滿足這種方法的要求。但N是多大？20？50？100？這取決于你對專業定義的細節程度，是吧？如果你傾向于每位開發人員只處理一種artifact，那單單處理建模工作，就需要20多位的專才，在modeling artifacts essay列出了各種的artifact。如果你傾向于每位開發人員只負責一種角色，那再一個EUP的項目中也需要11中角色才能完成所有的工作流程。專才通常都很難同人合作，他們缺少謙遜的品質，意識不到其它人的專項技能能夠為他的工作增添價值，他們也意識不到他們的所作所為可能為給后續的工作造成麻煩，也許他們需要返工，也許他們現在的努力會白費。關于專才的另一個問題是，即使是在他們擅長的領域，他們的技能也可能根本就沒有那么精熟。IT產業的技術高變動率，導致了開發人員使用了幾個月的新技術，開始熟悉它，就聲稱自己已經是這方面的專家了，因為和他具有同樣層次經驗的人畢竟不多。要建立一個專才組成的團隊，這也是一個很明顯的問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
