迭代和科學的方法
在爲一個問題開發解決方案的過程中包括很多活動行爲。我們需要理解待解決的問題，爲一個潛在的解決方案收集需求，將這些需求轉換至設計中，構建解決方案，並對方案進行測試。這個順序非常自然，並且在一般情況下是正確地。然而，當我們試圖將規模擴大時－也就是說，當我們按照一個嚴格的線性流程試圖蒐集所有的需求，並完成所有的設計，所有的開發，進行所有的測試時，一些問題就悄悄地出現了。
因此，我們需要更像科學家一樣進行工作。現代的，科學的解決方案建立在如下直接觀測準則上：提出理論，然後設計實驗以驗證這些理論。從這些標準的結果中，我們或者拋棄或者確認這些理論。
如何將這種方法應用於軟件開發中？在某種意義上，在軟件開發項目中的很多事物都是理論，或者更精確的說，論斷是需要被評估的。計劃本身是由許多關於事物需要多長時間以完成的論斷組成。甚至需求也是關於適宜的解決方案特徵的一種論斷。正是因爲即使一些涉衆或是問題領域的專家表示需求是有效的也並不能代表他們是正確地。我們甚至需要評估需求以論斷它們是否對手邊的問題定義了正確的解決方案。
這引導我們採用這樣的一種軟件開發方式，計劃內固有的論斷通過系統演示版本的設計或開發進行重複的驗證與評估，每一個均被客觀的演示，以減少項目風險及建立另一個完整的解決方案。
這種開發方式通常被理解爲迭代的增量開發過程，我們對其進行如下的定義：
- 一種包括對一系列活動的重複應用以對一系列論斷進行評估，解決一系列風險，達成一系列開發目標，並逐步增量地建立並完善一個有效的解決方案 。
- 由於它通過對核心開發活動的重複應用，包括了對問題，解決方案定義以及解決方案實現的連續的細化，因此，它是一個迭代的過程。 2
- 由於在一次迭代運行的週期中，對問題的理解以及解決方案提供的功能均會增長，因此，它是一個增量的過程。
- 在迭代中，其中數個或更多的應用被連續地組織起來以構成一個完整的項目。
不幸的是，開發可以不包含增量而迭代地進行。例如，在一個迭代化的方式中，活動可以一遍又一遍地被採用，而並不能增長對問題的理解或是擴展解決方案，從迭代開始前的位置有效地進行分離。
它也可以實際上不包含迭代的，增量的過程。例如，一個大型解決方案的開發可以被分解爲數個增量，而不包含對核心開發活動的重複應用。
要在實際意義上更有效，開發必須同時採用迭代與增量。對於迭代化的，增量開發的需求要求我們在未知的世界中可預測地產生結果。既然我們不能寄希望於未知事物的消失，因此我們需要一種技術來控制它。迭代化的增量開發爲我們提供了一種技術，這種技術使得我們可以控制這種未知，或至少可以從系統級別上將其充分地至於控制之下以達到我們所期望的效果。
  |
|
迭代的經驗
如果你曾經瀏覽過方法學中描述的各種不同迭代化軟件開發過程的文獻，你就會發現對迭代的含義以及如何作出適宜的增量存在着各種不同的理解。這些趨向反應了作者在他們的項目中所處的角色以及在他們的項目團隊，企業或同組中，被認爲是最重要的，迭代化開發的各個獨特方面。
各種潛在的不同的闡述是對各種工作於迭代化項目中的，不同的經驗，對於在項目中不同的團隊成員，它表現的極爲不同。讓我們來考慮對迭代化開發的採用是如何在軟件開發項目中對常規準則發生影響的。
爲了對原始材料進行組織，我們將準則分爲三組進行探討是極爲有益的：
- 核心開發團隊。他們集中於對需求所確認的解決方案進行明確表述與開發，包括對核心架構開發準則的應用，分析，設計，實現， 3 以及測試，以便開發出高質量的的組件及方案。
- 客戶團隊。 他們集中於對需要解決的問題進行定義，並構建（包括業務的修正）解決這些問題的事情。他們必須確保任何構建處的解決方案對組織都是充分有效的。
- 管理團隊。 它們集中於確保客戶，業務以及開發目標的保持一致，正確地解決問題，爲這些問題構建適合的解決方案並且保證開發在一個正確的，高效的，可控的方式下進行。
在本文的剩餘部分以及接下來的兩篇文章中，我們將從上面所概述的三個方面對迭代化開發過程做更進一步的闡述，並探討迭代是如何幫助項目達到所有的目標以及它如何對項目所關聯的所有人員產生作用。
|
|
從核心開發團隊角度的迭代
讓我們從核心開發團隊的角度考慮項目動力。這個團隊負責應用關於架構，分析，設計，實現，單元測試以及集成測試等方面的開發準則，以建立能夠滿足客戶需求的系統發行版本。即使存在客戶代表，或被永久指派爲直接與開發團隊協同工作的業務分析師，需求仍然被認爲是客戶團隊的職責。（我們將在下一篇文章中探討從客戶團隊角度的迭代）
開發人員視角
對迭代化的增量式開發的看法通常來自小型開發團隊中的各個開發者的角度。畢竟，這是來自技術團體的觀點，這類觀點構成了關於迭代化，增量式開發的大部分文獻。同時，它們也爲這些實踐方法的採用提供了很大推動力。
我們中的一位同事近來參加了一個關於軟件開發的研討會。主題是關於使用特定迭代開發環境的迭代化開發。
很顯然的，報告者探討了對迭代化應用的一種迭代方式，一遍又一遍重複地採用“編寫測試部分，編寫程序代碼，測試程序代碼，修正程序代碼”的週期，直至完成各個部分，並使單元測試代碼可用，以使其能夠包含到一個發佈版本中。雖然這些“開發”活動包含了許多被迭代化開發支持者所建議的，最好的實行方式（例如測試優先，頻繁測試等），然而他們所描述的這種應用將會導致一個非常緊密的迭代，這種迭代的持續時間通常以分鐘來測量。
將迭代看作一個單一開發人員“編寫測試部分，編寫程序代碼，測試程序代碼，修正程序代碼”的生命週期似乎與經典管理學的，將迭代看作一個由一組開發人員的小型項目的觀點相牴觸。它代表了一種很自我的迭代開發觀點，僅關注單獨個體的貢獻而忽略了團隊的作用。它也與我們下面將要討論的，更廣闊的團隊領導者的觀點角度相沖突。
正如研討會中報告者所描述的那樣，這種緊密的，迭代的週期闡明瞭開發者在迭代化增量開發項目中所採用的，最自然的方式。單獨的開發人員遵從他們自己的節奏，使得傳統的分析，設計及實現階段開始變得模糊，並且，他們的日常活動在他們自己的方式下進行。在任何一個時間，各個開發者做出無數戰術上的決定以作爲系統軟件組成或改寫的一部分。各個開發者的活動試圖在共享事件周圍被同步起來，例如日常構建或是系統集成點。團隊活動試圖集中在架構工作，接口定義以及組件的再分解上。
一旦開發者正確理解了他們職責的限制以及他們當前的目標，典型地，他們將挽起袖子，開始進行他們可以做的任何工作以完成他們的責任，並交付將一個或數個工作組件以將其集成入發佈版本中。每個單獨的開發人員（或一對開發者，如果採用對偶程序設計的方式）將在項目所採用的流程框架中發展自己的工作方式。
進展以及產品堆積
單獨的開發者很少會對非技術性事物感興趣，例如效益實現，投資回報或是風險管理。他們以構建出實際可運行的產品來完成自己的工作。開發者通過選擇一組需求並變更請求以進行分析，設計，實現，構造，單元測試，然後將其集成入產品發行中以進行自己的工作。開發者對分析，設計，實現，準則應用的重疊特性顯示於圖1-1 中。開發人員的迭代過程的時間及規模從數個小時，數日，直至數週而不同，這取決於所進行工作的規模與複雜度。
圖1-1：從開發人員角度進行的迭代
開發人員將繼續依照這種方式進行工作，選擇並實現一小部分的需求，從他們的顯要任務列表中對請求做出改變，直至他們已經完成了分配給他們的所有工作條目。
從開發人員的角度，迭代化增量開發中的增量部分在所發行產品中持續增長的完整性以及功能的豐富方面表現的很明顯。有希望地是，這與被等待實現的需求或請求變更的數量變得越來越小形成對比。重要的需求以及變更請求列表經常會在產品堆積中被找到， 4 －－這代表了等待被完成的堆積的工作。每天，開發人員從產品堆積中取走更多的條目，每天，產品構造包括更多的實現條目，並且每天都有一些新的工作會被添加到產品堆積中。這種日常的，通過產品堆積進行工作的增量過程示於圖1-2中。
圖1-2：增量地處理產品堆積
這種以開發者爲中心的解決方案對那種開發者能夠緊密的協作，並且所開發組件間的交互極爲鬆散的小型團隊，或是基於公用代碼基礎進行開發，例如開源項目的大型團隊來說可以很好地運行。當規模上升至對於組件間具有強交互性的大型項目來說－在大型開發項目中是很典型的－額外的考慮視角是必須的。
開發團隊領導者視角
與單獨的開發人員不同，開發團隊的領導者關注於多個開發人員的協作以及優化，爲了完成整個團隊公共的目標，每個開發者均要修正或實現多個將要集成到發行產品中的組件。
從開發團隊領導者的角度來看，迭代並不僅僅是一個包括分析，設計以及實現的核心開發活動的週期。迭代是一個有代表性的小型項目，以得到軟件產品的有意義的新發布版本。
圖1-3說明了如何利用一組獨立的開發人員的工作來製造一個完整的發行產品，並使得所產生的改進請求以及需求定型的反饋對下一次迭代發生作用，並將其包含到下一次發行版本中。
圖1-3：從開發團隊領導者角度的迭代(引自Agile and Iterative Development, A Manager's Guide, by Craig Larman, Addison-Wesley, 2004.)
迭代的目的是將整個開發團隊的工作集成到一個穩定的，完整的，可測試的系統發行版本中。對大多數迭代來說，這些發佈版本爲內部發布－主要爲開發團隊所建立的基線，並且爲迭代以及對所做出的進展進行度量提供關閉條件。這些只是內部發布版本，而並不是爲用戶所開發的。
典型地，在軟件公共發佈版本之前，存在着三次或更多次的迭代。在此序列中的每次迭代過程審查系統發佈產品，從第一次迭代中的小型的，部分實現的系統，通過一次又一次地迭代，逐次增長地實現更多需求，直至產生出最終地客戶發佈版本。圖1-3距離說明了代表產品發佈的每次循環中的增長幅度。
將開發者及團隊領導者視角相關聯
對於許多開發者來說，迭代的增量開發是一個通過無窮級數的迭代進展過程，每一次迭代都會是系統變得更龐大，直至客戶對其滿意，或是決定停止對後續開發的投資。從這個角度來說，只要工作在持續進行，並且能夠對產品做出持續改正，項目就在繼續發展中。
從團隊領導者角度來說，爲了能夠有所進展，數個開發者的工作必須被聯合並集成在一起，或者可以成功的協同工作。圖1-4表明了這種整體的，在多個迭代中對於項目進展的開發團隊的觀點。
圖1-4：每次迭代與前一次迭代相比，均生成了更完整的發佈版本。
在圖1-4中，項目進展以開發團隊對完整的，可運行的發佈版本的完成情況所度量，而不是採用對規範說明或其他文檔的完成情況。在每一迭代中，應用軟件的完成情況通過對完整應用中可以被展示的已完成的需求條目來計算，着重於對一個可運行的產品發佈版本，而並不是一組項目文檔或是還未被集成的組件。
對團隊的進展需要對完整的發佈版本作爲一個整體來考慮，這一點是極爲重要的。我們見證了着數個這樣的真實項目，其中大量的組件被開發者所建立並測試，然而卻不能被集成進一個甚至僅僅是部分完成的產品。在這些案例中，顯示於圖1-4中的項目視圖從未發生過，因爲並不存在任何客觀憑證以證實對這種已完成的的項目做出了任何進展。
計劃制定的需要
爲了集成多個開發人員的工作，需要完成數個計劃編制。首先，需要將工作以最小化開發人員間相互依賴的方式分配給開發者，採用這種方式，即使開發者確實需要依賴於另外一個開發人員，他們也可以在一定程度上獨立地進行開發工作。
第二，他們必須採用一種方案以對他們的相互依賴關係達成一致；例如他們必須對組件，函數調用以及參數等的命名保持一致。隨着依賴關係數目的增長，團隊最終會達到這樣一個點，在這個點上團隊成員間非正式溝通也許需要使用開發人員間一致約定的記錄。
當複雜性增加時，並且，隨着爲了使團隊間成員有效協作而需要做出的努力變得越來越複雜，團隊領導將需要一種能夠確定什麼工作需要完成以及以什麼順序完成的方法。這帶動了對更規範的計劃制定的需求，這也依次導致了對預算的需求。由於時間計劃不能再簡單的通過對非常複雜的組件（這種情況中，所有組件都是不互相依賴的）預估開發時間，或是對所有組件（這種情況中，所有組件相互依賴，他們僅可以依次的對其進行工作）的開發時間求和的方式所決定，在不同開發者的組件間存在着相互依賴，這也導致了對更規範計劃制定的需求。必須要理解組件之間的依賴關係以建立一個有效的時間計劃方案。
迭代化的開發有時被認爲在很短的時間上執行，以至於不需要進行計劃制定或預估。這種觀點是不正確的；這有點像既然說我們在一個時刻僅僅進行一步活動，我們完全可以對下一步應該轉向哪裏做出連續的決定，因此我們沒有必要計劃我們的路線。如果你並不關心你將會在哪裏結束，這種策略可以很好的運行，然而人們對項目有所付出時，他們當然對項目將要達成的目標有所期望。
計劃以及預估基本上是這樣一種機制，首先，決定項目值得去做，然後作爲一種方案，保持項目始終處於軌道中。至少，在某種程度上，很少有人會在不知道花費或是不知道持續時間的情況下僱傭某人以修整他們的房屋。軟件開發項目也沒有區別，爲項目投資的人需要知道這個項目的開銷以及結束時間。這都需要計劃與預估。在下兩篇文章中，當我們從客戶以及團隊管理的角度進行探討時，我們還將返回到這個主題。
|
|
結論
爲了理解如何能夠達到迭代化的，增量的開發過程所保證的優點，正確認識它是如何影響到項目相關的所有人是很重要的。在本篇文章中，我們可以看到迭代化開發是如何影響到軟件生產人員，即核心開發團隊成員的，但是這僅僅是項目所關聯的一部分人員。如果你們想使迭代化項目真實地產生效果，你們還必須理解迭代化的，增量的開發過程是如何影響到其他成員的，同樣重要的，還要包括項目的其它領域：客戶以及管理者。
