本節書摘來自異步社群《軟體工程（第4版?修訂版）》一書中的第2章2.2節《軟體工程（第4版?修訂版）》—第2章2.2節軟體過程模型，作者【美】shari lawrence pfleeger , 【加】joanne m.atlee，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
2.2 軟體過程模型
軟體工程（第4版•修訂版）
軟體工程文獻描述了很多軟體過程模型。有些模型是規定性的（prescription），說明軟體開發應該進行的方式；而另一些是描述性的（description），說明軟體開發實際進行的方式。從理論上講，兩種類型的模型應該是相似或相同的，但事實并非如此。建立過程模型并讨論它的子過程有助于開發團隊了解開發過程的理想情況與實際情況之間的差距。
對過程進行模組化的原因還有很多。
當一個小組記錄下開發過程的描述時，就會形成對軟體開發中的活動、資源和限制的共同了解。
建立過程模型有助于開發團隊發現過程及其組成部分中存在的不一緻、備援和遺漏的地方。當注意并改正了這些問題以後，過程會變得更加有效并且集中在建構最終産品上。
模型應該反映開發的目标，例如建構高品質的軟體、在開發的早期發現故障以及滿足必需的項目預算和開發進度的限制。由于建立了模型，開發團隊可以根據目标評估候選活動是否合适。例如，開發團隊可能引入需求評審，這樣可以在設計開始之前發現和修複需求中的問題。
應當根據具體情況對每一個過程進行裁剪。建立過程模型有助于開發團隊了解應該在哪裡對過程進行裁剪。
每一個軟體開發過程模型都将系統需求作為輸入，将要傳遞的産品作為輸出。多年來，人們提出了很多模型。這裡探讨幾種最流行的模型，以了解它們之間的共性和差別。
2.2.1 瀑布模型
研究人員提出的第一個模型是瀑布模型（waterfall model），如圖2-1所示，它将開發階段描述為從一個階段瀑布般地轉換到另外一個階段（royce 1970）。如該圖所提示的，一個開發階段必須在另一個開發階段開始之前完成。是以，當從客戶引發的所有需求都已經過完整性和一緻性分析，并形成需求文檔之後，開發團隊才能夠開始進行系統設計活動。瀑布模型從一種非常高層的角度描述了開發過程中進行的活動，并且提出了要求開發人員經過的事件序列。
瀑布模型一直被用來規範軟體開發活動。例如，美國國防部标準2167-a規定，瀑布模型是多年來國防部合同中軟體開發傳遞的依據。每一個過程活動都有與其相關聯的裡程碑和可傳遞産品，以便于項目經理能夠用模型判斷在某一時刻項目離最後完成還有多遠。例如，在瀑布模型中，“單元測試和內建測試”階段結束的裡程碑是“編寫完經過測試和內建的代碼子產品”，其中間可傳遞産品是測試過的代碼的副本。接着，代碼被移交給系統測試人員，這樣它可以與其他系統構件（硬體或軟體）合并，并作為一個整體進行測試。
在幫助開發人員布置他們需要做的工作時，瀑布模型是非常有用的。它的簡單性使得開發人員很容易向不熟悉軟體開發的客戶做出解釋。它明确地說明，為了開始下一階段的開發，哪些中間産品是必需的。很多其他更複雜的模型實際上是在瀑布模型的基礎上的潤色，如加入回報循環以及額外的活動。
瀑布模型的很多問題已經在計算機文獻中讨論過，補充材料2-1總結了其中的兩個問題。瀑布模型最大的問題是它并不能反映實際的代碼開發方式。除了一些了解非常充分的問題之外，實際上軟體是通過大量的疊代進行開發的。通常情況下，軟體用于解決以前從未解決過的問題，或者其解決方案需要更新以反映業務情況或操作環境的變化。例如，一個飛機制造商需要一種關于新型機體的軟體，它要比目前的型号更大、更快。對于這種情況，即使軟體開發人員在開發航空軟體方面積累了大量的經驗，他們仍然面臨很多新的挑戰。使用者和開發人員都不完全了解影響期望結果的所有關鍵因素，并且在需求分析過程中花費的大量時間都用在了了解受系統及其軟體影響的項和過程上，以及系統及其運作環境之間的關系上，就像在第4章将要看到的那樣。是以，如果不對實際的軟體開發過程加以控制，開發過程可能看起來會像圖2-2那樣：當開發人員試圖搜集關于問題以及提議的解決方案如何解決該問題的有關資料時，他們會翻來覆去地從一個活動轉向另一個活動。
補充材料2-1 瀑布模型的缺點
自從瀑布模型提出以來，招緻了衆多的批評。例如，mccracken和jackson指出，瀑布模型在系統開發之上強加了一種項目管理結構（mccracken and jackson 1981）。“主張任何一種生命周期方案（即使它具有各種變種）能夠适用于所有的系統開發顯然是違背現實的，或者由于假定一個過于簡陋的生命周期而顯得毫無意義。”
注意，瀑布模型說明了每一個主要開發階段是如何終止于某些制品（例如需求、設計或代碼）的，但并沒有揭示每一個活動如何把一種制品轉化為另外一種制品，例如，從需求轉化為設計。是以，對于如何處理在開發過程中可能出現的産品和活動的變化，模型并沒有向管理者和開發人員提供相關指導。例如，當在編碼活動的過程中發生需求變化時，随之帶來的設計和編碼的變化并沒有在瀑布模型中加以強調。
curtis、krasner、shen和iscoe指出，瀑布模型的主要缺點是沒有把軟體看作一個問題求解的過程（curtis, krasner, shen and iscoe 1987）。瀑布模型産生于硬體領域，它是從制造業的角度看待軟體開發的。但是，制造業是重複生産某一特定的産品，而軟體并不是這樣開發的，相反，随着人們對問題的逐漸了解和對候選方案的評估，軟體在不斷演化。是以，軟體是一個創造的過程，而不是一個制造的過程。瀑布模型并沒有說明我們建立最終産品過程中所需的往返活動的任何特有資訊。尤其是創造通常包含不同的嘗試、開發和評估原型、評價需求的可行性、比較若幹種設計以及從失敗的教訓中學習，進而最終決定問題令人滿意的解決方案。
通過引入加強了解的活動和子過程，軟體開發過程有助于控制活動之間的往返。原型化就是這樣的一個子過程。原型（prototype）是一個部分開發的産品，它使客戶和開發人員能夠對計劃開發的系統的相關方面進行檢查，以決定它對最終産品是否合适或恰當。例如，開發人員可以建構一個系統來實作一小部分關鍵需求，以確定需求是一緻、可行和符合實際的。否則，在需求階段就要進行修正，而不是在測試階段（測試階段代價會更高）進行修正。同樣，設計的某些部分也可以進行原型化，如圖2-3所示。設計的原型化有助于開發人員評價可選的設計政策以及決定對于特定的項目，哪一種政策是最好的。正如我們将在第5章中看到的，設計人員可能用幾種完全不同的設計來處理需求，看一看哪一種具有最好的特性。例如，可以在一個原型中把網絡設計為環形的，而另一個設計為星形的。然後評價其性能特性，看一看哪一種結構能更好地滿足性能目标或限制。
通常，開發人員會建構使用者界面，并把它作為原型進行測試，以便使用者能夠了解新系統将會是什麼樣子的，并且設計人員也能夠更好地了解使用者希望如何與系統進行互動。是以，在系統測試進行正式确認之前，主要的需求應該都已經過處理和确定。确認（validation）確定系統實作了所有的需求。每一個系統功能可以回溯到系統規格說明中的一個特定需求。系統測試也對需求進行驗證，驗證（verification）確定每一項功能都是正确的。也就是說，确認保證開發人員構造的是正确的産品（根據規格說明），而驗證檢查實作的品質。原型化對于驗證和确認都很有用。但是，我們将在後面的章節中看到，這些活動也可以出現在開發過程的其他部分中。
2.2.2 v模型
v模型是瀑布模型的變種，它說明測試活動是如何與分析和設計相聯系的（german ministry of defense 1992）。如圖2-4所示，編碼處于v形符号的頂點，分析和設計在左邊，測試和維護在右邊。正如我們将在後面的章節中看到的那樣，單元測試和內建測試針對的是程式的正确性。v模型提出，單元和內建測試也可以用于驗證程式設計。也就是說，在單元和內建測試的過程中，編碼人員和測試小組成員應當確定程式設計的所有方面都已經在代碼中正确實作。同樣，系統測試應當驗證系統設計，保證系統設計的所有方面都得到了正确實作。驗收測試是由客戶而不是開發人員進行的，它通過把測試步驟與需求規格說明中的每一個要素關聯起來對需求進行确認。這種測試檢查在接受系統和付款之前，所有需求是否都已經完全實作。
該模型中連接配接Ｖ形符号左邊和右邊的連線意味着，如果在驗證和确認期間發現了問題，那麼在再次執行右邊的測試步驟之前，重新執行左邊的步驟以修正和改進需求、設計和編碼。換言之，Ｖ模型使得隐藏在瀑布模型中的疊代和重做活動更加明确。瀑布模型關注的通常是文檔和制品，而Ｖ模型關注的則是活動和正确性。
2.2.3 原型化模型
我們已經看到如何使用原型化活動修正瀑布模型以改進對系統的了解。但是原型化不僅僅是附屬于瀑布模型的，如圖2-5所示，它本身也是一種有效的過程模型的基礎。由于原型化模型允許開發人員快速構造整個系統或系統的一部分以了解或澄清問題，是以，它與工程化原型具有同樣的目的，其中需要對需求或設計進行反複調查，以確定開發人員、使用者和客戶對需要什麼和送出什麼有一個共同的了解。依據原型化的目标，可以取消原型化需求、設計或系統中的一個或多個循環。但是，總體目标保持不變，即減少開發中的風險和不确定性。
例如，系統開發可能以客戶和使用者提出的一組需求為起點，然後，讓相關各方一起探讨各種方案，檢視可能的螢幕顯示、表格、報表以及使用者和客戶直接使用的其他系統輸出。當使用者和客戶對需要什麼做出決定時，對需求進行修正。一旦對需求應該是什麼達成了共識，開發人員就可以進行設計了。再次通過同樣的過程，開發人員與客戶和使用者協商來探讨不同的設計。
對初始設計不斷修正，直到開發人員、使用者和客戶對結果滿意為止。實際上，考慮不同的設計方案有時會暴露需求中的問題，此時開發人員就需要退回到需求階段，重新考慮和變更需求規格說明。最後，對系統進行編碼并讨論不同的編碼方案，還可能對需求分析和設計進行疊代。
2.2.4 可操作規格說明
對許多系統來說，需求的不确定性導緻了後期開發的變化和問題。zave提出了一種過程模型，它允許開發人員和客戶在開發的早期檢查需求及其隐含含義，在這個過程中，他們可以讨論和解決某些不确定性（zave 1984）。在可操作規格說明模型（operational specification model）中，通過示範系統行為的方式來評估或執行系統需求。也就是說，一旦指定了需求，就可以用軟體包進行示範。這樣，在設計開始之前就可以評價它們的隐含含義。例如，如果規格說明要求計劃建構的系統能夠處理24個使用者，規格說明的可執行形式就能夠幫助分析人員确定使用者數目是否給系統增加了太多的性能負擔。
這種模型的過程與諸如瀑布模型這樣的傳統模型有很大的不同。瀑布模型把系統的功能與設計分離（即把系統要做什麼與系統如何做分離開），目的是把客戶的需要與實作分開，而可操作規格說明模型允許把功能和設計合并起來。圖2-6說明了可操作說明模型是如何運作的。注意，可操作規格說明模型與原型化模型類似，該過程允許使用者和開發人員在早期檢查需求。
2.2.5 可轉換模型
balzer的可轉換模型（transformational model）通過去除某些主要開發步驟來設法減少出錯的機會。利用自動化手段的支援，轉換過程使用一系列轉換把需求規格說明變為一個可傳遞使用的系統（balzer 1981a）。
轉換的樣例有：
改變資料表示；
選擇算法；
優化；
編譯。
由于從規格說明到可傳遞系統可以采取很多途徑，它們所表示的變換序列和決策都儲存為形式化的開發記錄。
轉換方法具有很好的前景。然而，如圖2-7所示，應用轉換方法的主要障礙在于需要一個精确表述的形式化的規格說明，這樣才可以基于它進行操作。随着形式化規格說明方法的普及，轉換模型将會被更廣泛地接受。
2.2.6 階段化開發：增量和疊代
在早期的軟體開發中，客戶願意為軟體系統的最後完成等待很長時間。有時，從編寫需求文檔到系統傳遞使用會經過若幹年，稱為循環周期（cycle time）。但是，今天的商業環境不會再容許長時間的拖延。軟體使産品在市場上引人注目，而客戶總是期待着更好的品質和新的功能。例如，1996年，惠普公司80%的收入來自過去兩年開發的産品，因而，他們開發了新的過程模型來幫助縮短循環周期。
一種縮短循環周期的方法是使用階段化開發，如圖2-8所示。使用這種方法設計系統時使其能夠一部分一部分地傳遞，進而在系統其餘部分正在開發的同時，使用者已經獲得了一部分功能。是以，通常會有兩個系統在并行運作：産品系統和開發系統。運作系統（operational system）或産品系統（production system）是目前正在被客戶和使用者使用的系統，而開發系統（development system）是準備用來替換現行産品系統的下一個版本。通常，用它們的釋出代号表示一個系統：開發人員建構釋出1，進行測試，然後把它交給使用者作為第一個可運作的釋出。然後，當使用者使用釋出1的時候，開發人員正在建構釋出2。進而，開發人員總是在開發釋出n+1，而與此同時釋出n總是正在運作的。
開發人員可以用多種方法決定如何将開發組織為釋出。增量開發（incremental development）和疊代開發（iterative development）是兩種最常用的方法。在增量開發中，需求文檔中指定的系統按功能劃分為子系統。定義釋出時首先定義一個小的功能子系統，然後在每一個新的釋出中增加新功能。圖2-9的上半部分顯示了增量開發是如何在每一個新的釋出中逐漸增加功能直到構造全部功能的。
而疊代開發是在一開始就送出一個完整的系統，然後在每一個新的釋出中改變每個子系統的功能。圖2-9的下半部分說明一個疊代開發的3個釋出。
為了了解增量開發和疊代開發之間的差別，我們來看一個用于文字處理的軟體包。假設這個軟體包要具有3種類型的功能：建立文本、組織文本（即剪切和粘貼）以及格式化文本（例如使用不同的字型大小和類型等）。要使用增量開發模型建構這樣一個系統，我們可能在釋出1中僅提供建立功能，然後在釋出2中提供建立群組織功能，最後在釋出3中提供建立、組織和格式化功能。但是，使用疊代開發方法時，我們要在釋出1中提供簡單的3種類型的功能。例如，可以建立文本，然後剪切并粘貼文本，但是剪切和粘貼功能可能不夠靈活快捷。在下一次疊代（即釋出2）中，提供相同的功能，但是系統的功能增強了：剪切和粘貼功能變得友善和快捷。每一個釋出都在前一個釋出的基礎上進行了某些改進。
實際上，許多組織都将疊代開發和增量開發方法結合起來使用。一個新的釋出版本可能包含新的功能，并且對已有功能做了改進。這種形式的階段化開發方法是人們想要的，原因如下。
(1) 即使還缺少某些功能，但在早期的釋出中就可開始進行教育訓練。教育訓練過程可以使開發人員觀察某些功能是如何執行的，并為後面的釋出提供了改進的建議。這樣，開發人員能夠很好地對使用者的回報做出反應。
(2) 可以及早為那些以前從未提供的功能開拓市場。
(3) 當運作系統出現未預料到的問題時，經常性的釋出可以使開發人員能全面、快速地修複這些問題。
(4) 針對不同的釋出版本，開發團隊将重點放在不同的專業領域技術上。例如，一個釋出可以利用使用者界面專家的專業知識将系統從指令驅動的界面改為指向—點選式（point-and-click）的圖形使用者界面，另外一個釋出可集中于改進系統性能。
2.2.7 螺旋模型
boehm根據系統包含的風險看待軟體開發過程并提出了螺旋模型。它把開發活動和風險管理結合起來，以将風險減到最小并控制風險（boehm 1988）。圖2-10所示的螺旋模型在某種意義上類似于圖2-9所示的疊代開發模型。它以需求和一個初始的開發計劃（包括預算、限制、人員安排方案、設計和開發環境）為起點，在産生“操作概念”文檔（它從高層描述系統如何工作）之前，該過程插入一個評估風險以及可選原型的步驟。在操作文檔中，一組需求被指定并進行詳細檢查，以確定需求盡可能完整和一緻。是以，操作概念是第一次疊代的産品，而需求則是第二次疊代的主要産品。在第三次疊代中，系統開發産生設計，而第四次疊代能夠進行測試。
螺旋模型的每一次疊代都根據需求和限制進行風險分析，以權衡不同的選擇，并且在确定某一特定選擇之前，通過原型化驗證可行性或期望度。當風險确認之後，項目經理必須決定如何消除風險或使風險降到最低。例如，設計人員不能确定使用者是否更喜歡某一種界面（相比較于另一種界面）。使用者有可能會選擇阻礙高效率使用新系統的界面，要把這種選擇的風險最小化。設計人員可以原型化每一個界面，并通過運作來檢驗使用者更喜歡哪一種界面。甚至可以在設計中選擇包含兩種不同的界面，這樣使用者能夠在登入的時候選擇其中一個。像預算和進度這樣的限制有助于确定要選擇哪一種風險管理政策。第3章将更詳細地讨論風險管理。
2.2.8 靈活方法
從20世紀70年代到90年代提出并使用的許多軟體開發方法都試圖在軟體構思、文檔化、開發和測試的過程中強加某種形式的嚴格性。在20世紀90年代後期，一些抵制這種嚴格性的開發人員系統地闡述了他們自己的原則，試圖強調靈活性在快速有效的軟體生産中所發揮的作用。他們将他們的思想整理為“靈活宣言”，概括為以不同的方式思考軟體開發的4條原則（agile alliance 2001）。
相對于過程和工具，他們更強調個人和互動的價值。這種觀點包括給開發人員提供他們所需的資源，并相信他們能夠做好自己的工作。開發團隊将他們組織起來，讓他們進行面對面互動式的溝通而不是通過文檔進行溝通。
他們更喜歡在生産運作的軟體上花費時間，而不是将時間花費在編寫各種文檔上。也就是說，對成功的主要測量名額是軟體正确工作的程度。
他們将精力集中在與客戶的合作上，而不是合同談判上，進而，客戶成為軟體開發過程的一個關鍵方面。
他們專注于對變化的反應，而不是建立一個計劃而後遵循這個計劃，因為他們相信不可能在開發的初始就能預測到所有的需求。
靈活開發的總體目标是通過“盡可能早地、持續地傳遞有價值的軟體”使客戶滿意（agile alliance 2001）。很多客戶都有一些随着時間變化的業務需求，不僅表現在新發現的需求上，也表現在對市場變化做出反應的需求上。例如，當軟體正在設計和構造的時候，某一個競争對手釋出了一個新的産品，是以，需要在已經計劃好的功能上做一些改變。類似地，政府機構或标準制訂機構可能會強制推行一項規則或标準，而它可能影響到軟體的設計或需求。人們認為，通過在軟體開發過程中加入靈活性，靈活方法使使用者能夠在開發周期的後期增加或改變需求。
在目前的文獻中，有很多靈活過程的典型方法。每一種方法都基于一套原則，這些原則實作了靈活方法所宣稱的理念（靈活宣言）。具體方法有以下幾種。
極限程式設計（xp）：在下面會對它進行較長的描述。它是激發開發人員創造性、使管理負擔最小的一組技術。
水晶法（crystal）：它認為每一個不同的項目都需要一套不同的政策、約定和方法論。水晶法正是基于這一理念的一組方法。cockburn是水晶法的建立者（cockburn 2002）。他認為，人對軟體品質有重要的影響，因而随着開發人員素質的提高，項目和過程的品質也随之提高。通過更好的交流和經常性的傳遞，軟體生産力得以提高，因為它較少需要中間工作産品。
并列争球法（scrum）：該方法由對象技術公司于1994年建立，随後schwaber和beedle将它産品化（schwaber and beedle 2002）。它使用疊代的方法，其中把每30天一次的疊代稱為一個“沖刺”（sprint），并按需求的優先級别來實作産品。多個自組織和自治小組并行地遞增實作産品。協調是通過簡短的日常情況會議（稱為“scrum”）來進行的，就像橄榄球中的“并列争球”（scrum）。
自适應軟體開發（asd）：它有6個基本的原則。在自适應軟體開發中，有一個使命作為指導，它設立項目的目标，但并不描述如何達到這個目标。特征被視作客戶價值的關鍵點，是以，項目是圍繞着構造的構件來組織并實作特征的。過程中的疊代是很重要的，是以“重做”與“做”同樣關鍵，變化也包含其中。變化不被視作改正，而是被視作對軟體開發實際情況的調整。确定的傳遞時間迫使開發人員認真考慮每一個生産的版本的關鍵需求。同時，風險也包含其中，它使開發人員首先解決最難的問題。
通常，“極限程式設計”是描述靈活方法最普遍的概念。實際上，xp是靈活過程的一種具體形式，提供靈活方法最一般原則的指導方針。xp的支援者強調靈活方法的4個特性：交流、簡單性、勇氣以及回報。交流是指客戶與開發人員之間持續地交換看法；簡單性鼓勵開發人員選擇最簡單的設計或實作來處理客戶的需要；xp建立者将勇氣描述為盡早和經常傳遞功能的承諾；在軟體開發過程的各種活動中，都包含回報循環。例如，程式員們一起工作，針對實作設計的最佳方式，互相提供回報；客戶與開發人員一起工作，以完成計劃的任務。
這些特性都包含在xp的12個實踐操作中。
規劃遊戲：在xp的這一方面，由現場的客戶定義價值的含義，以便對于每個需求，可以根據實作該需求所增加的價值對其進行評價。使用者就系統應該如何運轉來編寫故事，然後，開發人員估算實作該故事所必需的資源。這些故事描述所涉及的演員和情節，很像在第4章和第6章定義的用例。每一個故事針對一個需求：隻需要兩三個句子足夠詳細地解釋需求的價值，以便開發人員指定測試用例，估算實作需求所需的資源。故事編完之後，預期的使用者對需求劃分優先級，不斷地拆分、合并需求，直到就需要什麼、什麼可測試、利用可用資源能夠完成什麼這些事項達成一緻為止。然後，計劃人員生成釋出圖，将釋出的内容和傳遞的時間記錄在文檔中。
小的釋出：系統的設計要能夠盡可能早地傳遞。功能被分解為若幹個小的部分，這樣，可以盡早地傳遞一些功能。然後，在後面的版本中對這些功能加以改進和擴充。這些小的釋出需要使用增量或疊代生命周期的階段化開發方法。
隐喻：開發團隊對于系統将如何運作的設想取得一緻意見。為了支援這個共同的設想，開發團隊選取共同的名字，并就處理關鍵問題的共同方法達成一緻意見。
簡單設計：隻處理目前的需求，使設計保持簡單。這種方法展現這樣一個基本思想：對将來的需求進行預測可能導緻不必要的功能。如果系統的某個特定部分是非常複雜的，那麼開發團隊可能要建構一個試驗性解決方案（spike）（一個快速、有限的實作）以幫助決定如何繼續進行。
首先編寫測試：為了確定客戶的需要成為開發的驅動力，首先編寫測試用例，這是一種強迫客戶需求在軟體建構之後可以被測試和驗證的方法。xp使用兩種測試：功能測試和單元測試。功能測試由客戶指定，由開發人員及使用者測試；而單元測試由開發人員編寫和測試。在xp中，功能測試是自動執行的，并且在理想情況下，每天都執行。功能測試被認為是系統規格說明的一部分。在編碼前後都要進行單元測試，以驗證每一個子產品都符合設計規格說明。第8章将詳細讨論這兩種測試。
重構：随着系統的建構，很可能需求将發生變化。因為xp方法的一個主要特征是隻針對目前的需求進行設計，是以，經常出現這樣的情況：新的需求迫使開發人員重新考慮他們現有的設計。重構（refactoring）是指重新審視需求和設計，重新明确地描述它們以符合新的現有的需要。有時，重構是指重組（restructure）設計和代碼，而不擾亂系統的外部行為。重構是以一系列小的步驟完成的，輔之以單元測試和對程式設計，用簡單性指導工作。我們将在第5章讨論重構的難點。
對程式設計：如第1章指出的，将軟體工程視作藝術和将軟體工程視作科學這兩種觀點之間存在着緊張關系。對程式設計試圖強調軟體開發的藝術性這一方面，承認學徒－師父這樣的隐喻，對于教會軟體開發初學者如何逐漸具有熟練開發人員的能力是很有用的。使用一個鍵盤，兩個結成對的程式員，根據需求規格說明和設計開發系統，由一個人負責完成代碼。但是，配對是靈活的：一個開發人員在一天中可能與多個夥伴配對。傳統的開發方法是個人單獨工作，直到他們的代碼經過單元測試。第7章會将對程式設計與傳統方法進行比較。
集體所有權：在xp中，随着系統的開發，任何開發人員都能夠對系統的任何部分進行改變。在第11章，我們将讨論管理變化過程中的難點，包括當兩個人試圖同時改變同一個子產品的時候引入的錯誤。
持續內建：快速傳遞功能意味着可以按日為客戶提供可運作的版本，有時甚至可以按小時提供。重點是多個小的增量或改進，而不是從一個修正到下一個修正這樣的巨大跳躍。
可以忍受的步伐：疲勞可能産生錯誤。是以，xp的支援者提出每星期工作40個小時的目标。逼迫程式員投入很長的時間來滿足最後期限，就表明最後期限不合理，或者是缺乏滿足最後期限的資源。
在現場的客戶：理想情況下，客戶應該在現場與開發人員一起工作以确定需求，并提供如何對它們進行測試的回報。
代碼标準：很多觀察者認為xp和其他靈活方法提供了不受限制的環境，在其中可以做任何事情。但是實際上，xp倡導清晰的代碼标準定義，以利于團隊改變和了解他人的工作。這些标準支援其他的實踐，例如測試和重構。其結果應該是代碼整體看起來就像是由一個人編寫的，并且其方法和表述一緻。
極限程式設計和靈活方法是比較新的方法（補充材料2-2）。其有效性的證據很少，但卻呈增長趨勢。在後面的章節讨論其相關活動的時候，我們将再次讨論很多靈活方法和概念，以及它們的實證性評估。
本章出現的過程模型僅僅是實際使用或讨論的模型中的一小部分。其他過程模型可以根據使用者、客戶和開發人員的需要進行定義和剪裁。正如在補充材料2-3中指出的那樣，實際上，我們應該用一組過程模型描述軟體開發過程，而不是集中于單個模型或視圖。
補充材料2-2 什麼時候極限程式設計顯得過于極端？
就像大多數軟體開發方法一樣，靈活方法也招緻了一些批評。例如，stephens和rosenberg指出，很多極限程式設計的實踐是互相依賴的，如果其中一個被修改，其他的都會受到影響（stephens and rosenberg 2003）。要了解其中的原因，我們假定一些人對于對程式設計是不滿意的。那麼，就可能需要更多的協調和文檔來解決當人們各行其是時失去的共識。類似地，許多開發人員喜歡在程式設計之前進行設計。scrum通過建立每月沖刺來處理這種喜好。elssamadissy和schalliol指出，在極限程式設計中，需求被表示為一系列必須能通過軟體審查的測試用例（elssamadissy and schalliol 2002）。這種方法可能促使客戶代表關注測試用例而不是需求。因為測試用例是需求的詳細表述，并且可能是面向解決方案的，是以，将重點放在測試用例上可能會将客戶代表的注意力從項目的目标轉移開，并且可能導緻這樣一種情形：系統通過了所有測試，但是卻不是客戶認為他們應該得到的系統。正像我們将在第5章中看到的，重構可能是靈活方法的要害，很難做到重做一個系統而不降低體系結構的品質。
補充材料2-3 過程模型的集合
我們在補充材料2-1中看到，開發過程是一個問題求解的活動，但是流行的過程模型很少會包含問題求解。curtis、krasner和iscoe對17個大型項目進行了現場研究，以确定過程模型中應擷取哪些問題求解的因素，以幫助我們了解軟體開發（curtis, krasner and iscoe 1988）。尤其是，他們考慮了影響項目結果的行為因素群組織因素。他們的研究結果提出了一個關于軟體開發層次的行為模型，其中包含5個關鍵視角：業務環境、公司、項目、開發團隊和個人。個人視圖提供關于認知和動機的資訊，項目和開發團隊的視圖告訴我們團體動态的相關情況。公司和業務環境提供了可能影響生産率和品質的組織行為的資訊。這個模型并不是要替換傳統的過程模型，它與傳統模型是正交的關系，提供的資訊是行為如何影響建立和生産活動，它是對傳統模型的補充。
随着開發人員和客戶對問題了解的加深，他們把彼此的領域知識、技術和業務結合起來，以得到一個合适的解決方案。通過把開發看作是一組互相協作的過程，我們可以看到學習、技術交流、客戶互動和需求協商的效果。不過，目前描述一系列開發任務的模型“對下述問題的分析是沒有幫助的：項目成員必須了解多少新資訊，如何協商那些有分歧的需求，設計團隊如何解決體系結構的沖突以及類似因素對項目内在的不确定性和風險有何影響”（curtis, krasner and iscoe 1988）。然而，當我們引入認知的、社會的、組織的和過程的相關模型時，我們就開始了解瓶頸和低效率的原因。正是這樣的認識使得管理人員能夠了解和控制開發過程。而通過總體考慮跨越各個模型層的行為，可以了解每個模型對另一個模型因素的效果所産生的影響。
不論使用哪一種過程模型，許多活動都是所有模型所共有的。在後面章節中對軟體工程進行探讨的時候，我們将研究每一個開發活動，了解它包含的内容，并找出什麼樣的工具和技術能夠使我們的工作更加有效、生産率更高。
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。