改善協作
想象乙個軟體開發組織，它和市場緊密連線，可以隨時交付完成的工作或調整方向，對市場做出準確的反應，這樣的組織必然會在市場競爭中佔據優勢。響應能力是所有軟體開發組織所期望具備的，但真正能做到的卻很少。究竟是什麼影響了組織的響應能力。從內部看，主要是堆積的「在製品」，和技術及學習「債務」。從外部看主要是和市場的連線程度，也即研發團隊和業務人員、使用者的協作。以下將分別分析這三個方面對組織響應能力的影響。
「在製品」是響應外部變化的負擔
所謂「在製品」（work in progress，wip），是指已經開始但未完成（可以向終端使用者交付）的工作。主要包括：未實施的決策、未實現的設計、未整合的編碼和未驗證的系統。
圖1是乙個典型的瀑布開發模型，需求階段產出系統的全部需求規格說明；分析設計階段產出整個系統的架構和詳細設計；測試驗證前完成所有的**。這些都屬於不可交付的「在製品」，在整個開發過程中，都無法交付軟體以響應客戶的需求。另外，在專案開發過程中，任何需求的變更，都意味著對「在製品」的返工，例如在編碼結束時需求發生了變化，意味著前期的需求分析、架構和詳細設計，以及編碼都要進行返工，這引入了需求變更的額外成本。因為這些原因，團隊無法在較低額外開銷的情況下，隨時向客戶交付產品或改變方向，其響應能力必然是受限的。
圖1 瀑布模型下的在製品及其影響
如圖2所示，理想的迭代模式下，「在製品」僅僅存在於迭代之內。團隊在迭代開始時，計畫一部分需求，迭代結束時產生可交付的軟體，清空所有的「在製品」。這樣的模式為提公升組織的響應能力提供了可能，1）迭代結束時軟體是可交付的，可以通過交付它們來響應市場的需要。2）每個迭代開始前，都可以對產品的功能需求和規劃做出調整，響應市場、使用者及相關各方的反饋。而且因為迭代結束時「在製品」的數量為零，不存在對「在製品」的返工成本。
圖2 理想的迭代開發模型
即使是迭代開發，大部分團隊並不能做到迭代產出物的直接可交付。如圖3所示，在乙個典型的迭代開發中，每個迭代產生可執行的軟體。但可執行不等於可交付，由於技術手段等的限制，迭代結束時會有遺留未完成工作。隨著迭代的進展，未完成工作不斷累積，形成迭代開發模式下的「在製品」，它們損害了組織響應能力。首先，可執行的軟體加上未完成的工作，才構成可交付的軟體。也就是交付軟體前必須完成這些工作，組織無法隨時交付以響應客戶的需求。其次，這些「在製品」也意味著風險，未完成工作的不確定性，使得交付更加不可控，損害響應能力。
圖3 現實迭代模型的wip
技術和學習「債務」（debts）加大響應的難度
「債務」是指將來某個時刻要償還的負擔。如圖4所示，如果沒有適當技術實踐的支援，隨著迭代的進行，既有**的單元測試工作增加；功能回歸測試工作量變大；**質量因頻繁變更而變差；系統越來越複雜，團隊成員卻缺乏對系統的理解。這些構成了軟體開發中的「債務」，它們加大了將來系統修改、測試的難度，因而降低了系統的響應能力。
圖4 技術債務和學習債務的積累
「債務」又可以分為技術「債務」（tech. debts）和學習「債務」（learning debts）。技術「債務」是指因系統的不良設計、實現和測試，導致系統在需要變更時，難以被理解，難以改變；改變後，難以驗證**的正確性；難以對既有功能進行回歸測試。學習「債務」是指，在開發過程中，團隊成員未能及時分享和掌握業務及實現相關的知識，加大系統變難度，而且更容易引入質量問題，甚至新的技術「債務」。「債務」對系統的影響，並不會立刻顯現。但長期來看，它會使系統響應變化時，耗費時間更長，成本更高，引入質量問題的可能性更大，嚴重損害組織的響應能力。
有效的協作決定響應及時性和準確
「在製品」數量、「債務」水平決定了軟體開發組織的內部響應性，與之同樣重要的是響應的準確性。它取決於組織與外部的連線程度，也就是團隊與使用者及業務人員有效協作，以及團隊內部有效協作，即時獲取、整合市場資訊，並準確傳遞至開發團隊，有效地落實到開發活動當中。
綜上所述，只有降低「在製品」，維持低「負債」，並合理協作，才能保證準確、即時地響應，達成目標。敏捷開發的實踐正是在構建這樣乙個系統。
實施敏捷
從一定程度上說，敏捷軟體開發就是通過系統的實踐，減少「在製品」數量，降低「債務」水平和改善協作來提高組織的響應能力。表1列舉常見的敏捷實踐，並分析了它們對於以上三個方面的貢獻。我們將這些實踐分成了三類—管理實踐、團隊技術實踐和個人技術實踐，下面將分別對這些實踐加以總結。
表1 敏捷實踐分
管理實踐
團隊技術實踐
接收測試驅動開發：在開發活動前，由業務、開發人員和測試人員共同參與，用例項對需求進行細化和澄清，確保大家的一致理解。這首先是乙個良好的溝通工具，使三方的合作變得有序和有效。另一方面這些例項將成為功能測試自動化的起點，降低了測試相關的技術「債務」；這些例項同時還會成為理解系統的依據，降低了學習「債務」。
個人技術實踐
以上，我們從響應能力出發，梳理了敏捷軟體開發中的主要實踐，這些實踐並非為敏捷軟體開發所專享。其實施，也非一蹴而就，需要以團隊整體技術和管理水平的提高作為支撐。否則反而可能會帶來新的「在製品」和「債務」，特別是「債務」。比如，引入單元測試自動化是為了減少技術「債務」，但如果單元測試自動化本身設計不良，測試用例過分依賴於實現細節。這樣，對實現細節的改變，會影響到測試用例的正確執行，反而使單元測試成為負擔，提高變更的成本，降低響應能力。
敏捷的實踐之間是相互關聯的，成為乙個有機系統，才能發揮效益。管理實踐之間是相互支援的。例如，離開多功能的團隊，開發任務就必須在多個功能團隊之間傳遞，無法做到短迭代開發。技術實踐之間是相互支援的。例如，沒有單元測試自動化的保障，持續重構的風險將激增，在操作上變得不現實；有了持續重構保障，維持乙個最簡單的系統設計，需要時再通過重構，使設計適應新的變化要求，簡單設計才更可能得以實施。技術實踐和管理實踐也是相互支援的。例如，短迭代開發中沒有技術實踐支援，就會不斷積累技術「債務」，產品質量和開發效率不斷下降；而，短迭代內全生命週期的反饋，也為各類技術實踐的部署提供了便利。
綜上，敏捷實踐的應用和團隊技術水平的提高，相輔相成，在應用中不斷總結提高，構建和完善實踐體系，加強客戶、業務人員和團隊的合作，以及團隊內部的合作，持續、有效地減少「在製品」，以及技術和學習「債務」，提公升組織的整體技術和管理水平，只有這樣才能構建可持續的響應能力。
軟體開發模式
軟體的開發模式包括 大棒開發法 邊寫邊改法 瀑布法 快速原型法和螺旋模式法，它們的定義及特點如下 第一，大棒開發法。它是源於能量爆發創造宇宙，萬物都由能量和物質積聚而成的理論，但如果不是遵循某種正確的排列和組合，形成的將不是預先期望的事物 大棒模式與上述理論一樣 一大堆能量 這裡指開發軟體所需的人力...
軟體開發模式
軟體開發模式大概有11種，如下所示 邊做邊改模型 build and fix model 瀑布模型 wate ll model 快速原型模型 rapid prototype model 增量模型 incremental model 迭代模型 stagewise model 螺旋模型 spiral m...
軟體開發模式
瀑布模型式嚴格遵循預先計畫的需求分析 設計 編碼 整合 測試 維護的步驟順序進行。瀑布模型是以每個步驟所取得的成果作為衡量進度的方法 由於它的嚴格分級，所以在專案前期需求不明確或者需求頻繁更改時代價高昂，是不可行的。所以在開發的前期，需求設計越完美，則損失越少。迭代式開發值每次只設計和完成產品的一部...