文/何勉
敏捷已成爲軟件開發領域的潮流，但單純爲迎合潮流去實施敏捷是不負責任的。開發方法和實踐必須服務於業務成功，作爲業務導向的敏捷實施成功的前提，首先必須問的問題是：通過敏捷實施要達成的業務目標是什麼？爲達成這些目標需要做到什麼？如何做到？本文將從業務目標出發，分別從這三個方面展開討論。
提高組織的響應能力
每一次軟件產品的開發都是一個創造的過程，預知一切是不可能完成的任務。
首先，商業環境和市場的需求處於變化之中。Jonathan Rasmusson在The Agile Samurai一書中陳述了三個關於需求的簡單事實：一、不可能在項目開始的時候收集到所有的需求；二、不管你收集到什麼樣的需求，它一定會發生變化；三、要做的功能，一定會超過時間和金錢允許的範圍。加之，商業環境的不斷變化，在項目的初始階段固定所有需求，只是一個有害無益的幻覺。
其次，技術環境以及團隊對技術的認識處於變化之中。軟件產品的開發是一個探索和發現的過程。項目啓動時，團隊不可能建立對業務領域、遺留代碼、實現技術、工具等方面的完整認知，處於對項目最無知的狀態。隨着開發的進展，團隊不斷積累關於業務和技術的知識，並做出相應調整，加之技術環境的不斷變化，使得在項目的初始階段就確定所有的技術方向和實現方案，既不合理也不經濟。
不確定性是軟件開發的固有屬性。這既是一個挑戰，也是一個機會。傳統的管理和技術手段不再適用，不能把握不確定性，適應用戶的需求，就會被市場拋棄；同時，不確定性也意味着無限的可能性，掌控不確定性就意味着把握了贏得市場競爭的機會。敏捷軟件開發正是要構建組織適應不確定性的能力。《精益和敏捷開發大型應用指南》一書的作者Bas Vodde曾經這樣定義敏捷軟件開發的完美願景—“構建組織能夠隨時在沒有額外成本的前提下、交付產品或改變方向的能力”。在本文中，這被稱作“響應能力”，並把它定義爲：
響應能力—軟件開發組織在儘量小的額外開銷的前提下，通過隨時交付，或改變方向來準確、即時地響應市場變化的能力。
“響應”是組織對外部（市場和用戶）所做出的反應，具體包括：交付產品，當市場需要時向客戶交付已完成的工作；改變方向，當市場需要，或組織策略發生變化時，做出針對性的調整。
“響應能力”指做出這種反應的能力，具體指標有：即時，在用戶需要時隨時做出反應；準確，應對市場的真實需求；低額外開銷，不應該產生過多正常開發之外的成本，如返工和額外測試或犧牲產品質量等。
在網絡社會，話語權越來越多地爲用戶所掌握，不確定性正在從事物背後的規律，變成被市場供需雙方普遍接受的事實。面對不確定性，拒絕和避免它不再是一個選項，唯有打造適應它的響應能力，對於軟件開發這類創造活動尤其如此。從業務角度來看，實施敏捷軟件開發的首要目標正是要打造組織的響應能力。
改善協作
想象一個軟件開發組織，它和市場緊密連接，可以隨時交付完成的工作或調整方向，對市場做出準確的反應，這樣的組織必然會在市場競爭中佔據優勢。響應能力是所有軟件開發組織所期望具備的，但真正能做到的卻很少。究竟是什麼影響了組織的響應能力。從內部看，主要是堆積的“在製品”，和技術及學習“債務”。從外部看主要是和市場的連接程度，也即研發團隊和業務人員、用戶的協作。以下將分別分析這三個方面對組織響應能力的影響。
“在製品”是響應外部變化的負擔
所謂“在製品”（Work In Progress，WIP），是指已經開始但未完成（可以向最終用戶交付）的工作。主要包括：未實施的決策、未實現的設計、未集成的編碼和未驗證的系統。
圖1是一個典型的瀑布開發模型，需求階段產出系統的全部需求規格說明；分析設計階段產出整個系統的架構和詳細設計；測試驗證前完成所有的代碼。這些都屬於不可交付的“在製品”，在整個開發過程中，都無法交付軟件以響應客戶的需求。另外，在項目開發過程中，任何需求的變更，都意味着對“在製品”的返工，例如在編碼結束時需求發生了變化，意味着前期的需求分析、架構和詳細設計，以及編碼都要進行返工，這引入了需求變更的額外成本。因爲這些原因，團隊無法在較低額外開銷的情況下，隨時向客戶交付產品或改變方向，其響應能力必然是受限的。
圖1 瀑布模型下的在製品及其影響
如圖2所示，理想的迭代模式下，“在製品”僅僅存在於迭代之內。團隊在迭代開始時，計劃一部分需求，迭代結束時產生可交付的軟件，清空所有的“在製品”。這樣的模式爲提升組織的響應能力提供了可能，1）迭代結束時軟件是可交付的，可以通過交付它們來響應市場的需要。2）每個迭代開始前，都可以對產品的功能需求和規劃做出調整，響應市場、用戶及相關各方的反饋。而且因爲迭代結束時“在製品”的數量爲零，不存在對“在製品”的返工成本。
圖2 理想的迭代開發模型
即使是迭代開發，大部分團隊並不能做到迭代產出物的直接可交付。如圖3所示，在一個典型的迭代開發中，每個迭代產生可運行的軟件。但可運行不等於可交付，由於技術手段等的限制，迭代結束時會有遺留未完成工作。隨着迭代的進展，未完成工作不斷累積，形成迭代開發模式下的“在製品”，它們損害了組織響應能力。首先，可運行的軟件加上未完成的工作，才構成可交付的軟件。也就是交付軟件前必須完成這些工作，組織無法隨時交付以響應客戶的需求。其次，這些“在製品”也意味着風險，未完成工作的不確定性，使得交付更加不可控，損害響應能力。
圖3 現實迭代模型的WIP
技術和學習“債務”（debts）加大響應的難度
“債務”是指將來某個時刻要償還的負擔。如圖4所示，如果沒有適當技術實踐的支持，隨着迭代的進行，既有代碼的單元測試工作增加；功能迴歸測試工作量變大；代碼質量因頻繁變更而變差；系統越來越複雜，團隊成員卻缺乏對系統的理解。這些構成了軟件開發中的“債務”，它們加大了將來系統修改、測試的難度，因而降低了系統的響應能力。
圖4 技術債務和學習債務的積累
“債務”又可以分爲技術“債務”（tech. Debts）和學習“債務”（learning Debts）。技術“債務”是指因系統的不良設計、實現和測試，導致系統在需要變更時，難以被理解，難以改變；改變後，難以驗證代碼的正確性；難以對既有功能進行迴歸測試。學習“債務”是指，在開發過程中，團隊成員未能及時分享和掌握業務及實現相關的知識，加大系統變難度，而且更容易引入質量問題，甚至新的技術“債務”。“債務”對系統的影響，並不會立刻顯現。但長期來看，它會使系統響應變化時，耗費時間更長，成本更高，引入質量問題的可能性更大，嚴重損害組織的響應能力。
有效的協作決定響應及時性和準確
“在製品”數量、“債務”水平決定了軟件開發組織的內部響應性，與之同樣重要的是響應的準確性。它取決於組織與外部的連接程度，也就是團隊與用戶及業務人員有效協作，以及團隊內部有效協作，即時獲取、整合市場信息，並準確傳遞至開發團隊，有效地落實到開發活動當中。
綜上所述，只有降低“在製品”，維持低“負債”，併合理協作，才能保證準確、即時地響應，達成目標。敏捷開發的實踐正是在構建這樣一個系統。
實施敏捷
從一定程度上說，敏捷軟件開發就是通過系統的實踐，減少“在製品”數量，降低“債務”水平和改善協作來提高組織的響應能力。表1列舉常見的敏捷實踐，並分析了它們對於以上三個方面的貢獻。我們將這些實踐分成了三類—管理實踐、團隊技術實踐和個人技術實踐，下面將分別對這些實踐加以總結。
表1 敏捷實踐分
管理實踐
- 用戶故事：用戶故事是端到端的，足夠小需求單元。用戶故事應該是具備用戶價值和可交付的。它作爲敏捷開發中計劃的單位，爲減少“在製品”提供了可能。同時，它是從用戶的角度出發，以用戶的語言描述需求，是用戶、業務人員和開發團隊溝通的起點和工具，改善了他們之間的協作。
- 短迭代開發，小版本發佈：短迭代開發模式下，每個迭代產生可交付的軟件，“在製品”始終控制在迭代內，處於較低的水平。小版本發佈，即時獲取用戶的反饋，爲調整產品的方向提供了最可靠的輸入，使開發團隊與用戶的協作變得具體和有效。
- 自組織的多功能團隊：多功能的團隊，避免了工作在各個功能團隊間的傳遞和等待，極大降低了“在製品”產生的可能，和維持的時間。同時，多功能團隊成員間的知識共享和學習也降低了學習的“債務”。團隊的自組織，使決策可以在團隊層面迅速做出，減少了等待和批准的時間，避免 “在製品”的累積。
團隊技術實踐
- 持續集成：持續集成作爲一個開發實踐，強調小步地增加功能，並隨時集成、驗證，始終維持可運行的軟件系統，使“在製品”數量控制在一個低水平。同時，持續集成作爲一個團隊紀律，保證被集成的代碼能達到定義的質量標準，如通過代碼規則檢查，自動測試等，屏蔽特定類型的技術“債務”。
- 統一語言：使用領域專家的語彙（領域語言）作爲開發團隊、業務人員以及用戶之間的溝通語言，減少溝通中產生誤解的可能，提高溝通效率。代碼中出現的概念也應該與領域語言保持一致，這進一步確保了實現和領域之間的一致，既改善了合作，也降低了因系統理解難度而帶來的技術“債務”。
接收測試驅動開發：在開發活動前，由業務、開發人員和測試人員共同參與，用實例對需求進行細化和澄清，確保大家的一致理解。這首先是一個良好的溝通工具，使三方的合作變得有序和有效。另一方面這些實例將成爲功能測試自動化的起點，降低了測試相關的技術“債務”；這些實例同時還會成爲理解系統的依據，降低了學習“債務”。
個人技術實踐
- 整潔代碼：代碼僅實現功能是不夠的，整潔的代碼清晰的表達意圖，易於理解和改變。整潔的代碼降低了技術“債務”。
- 設計原則和實踐：不管是Robert.C.Martin的S.O.L.I.D.原則，還是其它一些耳熟能詳的設計原則，如消除重複、分離關注點和向穩定依賴等，其目的都是要產生一個高內聚、低耦合的系統，使系統易於變更和維護，減少技術“債務”。
- 持續重構：隨着變更的引入，即使是好代碼也有變壞的傾向，產生技術“債務”。持續重構正是要消除這些技術“債務”，維持代碼的整潔，並使之符合基本的設計原則。持續重構應該是團隊和個人的工程習慣，而非一次性的行爲。
- 簡單設計：過度設計帶來的複雜性，本身就會成爲未來變更的負擔（債務）。另一方面，超越當下功能要求的設計無法得到充分的功能驗證，會成爲“在製品”。簡單設計在實現功能、消除重複，以及清晰表達的前提下，力求用最少的元素實現系統。
- 自動單元測試， 測試驅動開發：單元測試是系統健壯性的基石，設計良好的自動化單元測試是系統最有效的防護網，它確保代碼發生變更時，原有意圖不被破壞。也只有有了單元測試的保護，重構纔可能持續安全地進行。測試驅動開發則是產生良好設計的手段，同時它往往能生成最優和最及時的單元測試用例。
- 結對編程：結對編程有機綜合了兩個程序員的思維能力，更容易產生設計和實現良好的代碼。同時，通過持續的代碼檢查，減少錯誤引入，並在開發人員之間有效傳遞了知識，降低了技術和學習“債務”。
以上，我們從響應能力出發，梳理了敏捷軟件開發中的主要實踐，這些實踐並非爲敏捷軟件開發所專享。其實施，也非一蹴而就，需要以團隊整體技術和管理水平的提高作爲支撐。否則反而可能會帶來新的“在製品”和“債務”，特別是“債務”。比如，引入單元測試自動化是爲了減少技術“債務”，但如果單元測試自動化本身設計不良，測試用例過分依賴於實現細節。這樣，對實現細節的改變，會影響到測試用例的正確運行，反而使單元測試成爲負擔，提高變更的成本，降低響應能力。
敏捷的實踐之間是相互關聯的，成爲一個有機系統，才能發揮效益。管理實踐之間是相互支持的。例如，離開多功能的團隊，開發任務就必須在多個功能團隊之間傳遞，無法做到短迭代開發。 技術實踐之間是相互支持的。例如，沒有單元測試自動化的保障，持續重構的風險將激增，在操作上變得不現實；有了持續重構保障，維持一個最簡單的系統設計，需要時再通過重構，使設計適應新的變化要求，簡單設計才更可能得以實施。技術實踐和管理實踐也是相互支持的。例如，短迭代開發中沒有技術實踐支持，就會不斷積累技術“債務”，產品質量和開發效率不斷下降；而，短迭代內全生命週期的反饋，也爲各類技術實踐的部署提供了便利。
綜上，敏捷實踐的應用和團隊技術水平的提高，相輔相成，在應用中不斷總結提高，構建和完善實踐體系，加強客戶、業務人員和團隊的合作，以及團隊內部的合作，持續、有效地減少“在製品”，以及技術和學習“債務”，提升組織的整體技術和管理水平，只有這樣才能構建可持續的響應能力。
敏捷開發的最新實踐
敏捷開發的思想並非在一夜之間產生，有些實踐，如迭代開發幾乎和軟件開發的歷史一樣久遠。上世紀90年代各類系統的敏捷開發框架和方法被相繼提出，2001年敏捷宣言的發佈，敏捷的概念正式形成，敏捷開發方法迅速普及。早期的敏捷實踐，雖然也會涉及到業務和用戶，但往往還是以開發團隊爲核心，重點關注團隊內部實踐。
隨着敏捷實踐的普及和完善，團隊內部技術和管理實踐作爲組織響應能力的瓶頸被突破。近年來敏捷社區的關注重點更多地向團隊前端和後端轉移，一些新敏捷實踐應運而生。
前端是指團隊的輸入，也即需求（包含用戶體驗）的獲取、挖掘、澄清、整理和設計。得到比較多應用的新實踐有SBE（Spec by Example）和 Agile UX。嚴格意義SBE和驗收測試驅動開發（ATDD）屬於同一實踐的不同表述，它突出強調了，業務、開發和測試在前期通過表格化的實例對需求進行充分地溝通和協作，澄清和概念及一致性驗證，並確保各方對業務和需求理解的一致。Agile UX把用戶體驗設計，更早和更緊密地融入敏捷軟件開發過程，確保團隊在迭代模式下，能持續交付具備良好用戶體驗的產品，同時加強與用戶體驗相關的響應能力。
後端是指團隊的輸出，也即產品的交付、運營和維護。得到比較多應用的新實踐有持續交付和 DevOps。持續交付是持續集成的延伸，它的目標不僅是使軟件始終處於可運行和通過適當驗證的狀態，它致力於確保整個開發週期中，軟件都處於可交付的狀態，從而降低交付風險，並縮減從概念形成到軟件交付的時間週期。DevOps則進一步拓展，加強軟件開發和IT運營之間的溝通、合作及整合，彌補兩者之間的信息鴻溝，更快地交付軟件產品，提供軟件服務。
總結
在激烈競爭和充滿無限可能的今天，技術、應用都在飛速發展，用戶對體驗的要求也前所未有的提高，響應變化的能力成爲組織的核心生存能力。就這一點而言，敏捷對於軟件開發組織是一個必然的選擇，而非一個可有可無選項。
通過敏捷開發實踐的系統運用，減少“在製品”數量、降低技術和學習“債務”，改善團隊與用戶及市場的協作，構建了組織的靈活響應能力。然而，敏捷對於軟件開發，也絕非一個銀彈，軟件開發沒有因之變得更加容易，甚至因響應性要求，團隊和個人都面臨更大的挑戰。敏捷實踐的正確實施，響應能力的建設，最終還是依賴與在實踐中不斷總結、提高，依賴於個人和團隊總體能力的提升。
