在敏捷軟件開發方法上中下系列的最后一篇文章里，我們將探討開發小組如何與客戶交互，如何讓其參與到開發過程里來。

在《敏捷軟件開發》上中下系列的上篇里，我們了解了開發人員做法以及技術優勢如何帶來質量的顯著提高。在中篇里，我們探討了開發小組做法以及如何建立一個效率最高的開發小組，并重點研究了代碼編寫標準、連續集成和用于描述系統的通用語言?，F在，我們要看看最外面的圓環——“統一小組做法（one team practice）”，這其中包括開發人員、測試人員和客戶——并幫助更好地協調業務和IT。

協調業務和IT——“統一小組”做法
敏捷軟件開發里的統一小組指的是敏捷開發小組和所有的利益相關人為了一個共同的目標結成一個團隊工作。盡管小組里的每個成員都必須把各自主要精力放在具體的任務上，但是小組更喜歡開放的、真誠的和頻繁的溝通，而不是暗地里的操作。

統一小組強調由開發人員作出技術決定而由客戶作出業務決定，一貫如此，毫無例外。高度的交流，例如每日例會以及項目輻射（在《中篇》里討論過）會幫助增加交流并不斷持續下去，以確保及時獲得頻繁的反饋信息。

這一概念對于將敏捷開發的所有元素集中到一起是必需的。

創建背景并取得需求——第一步
在你開始敏捷開發的這一部分之前，從客戶、業務方和用戶取得需求信息；他們才是定義需求的人。由于業務方在這些做法中扮演了至關重要的角色，所以他們必須完全理解自己在敏捷開發環境里的角色是什么，以及他們能夠做到什么。讓其高速運轉起來肯定需要進行討論會和其他培訓工作。

在解釋敏捷開發的時候，需要向業務人員闡明的重要優勢有：

1. 能夠，在任何時候，改變其對最小成本的觀點。
2. 能夠根據來自市場或其他地方的反饋進行調整和應變。
3. 在任何時候都知道項目的狀態，并具備可預見能力。
4. 能夠從業務的角度參與項目的指導工作。

重要的成功因素

• 理解——客戶將需要某種程序的培訓才能確切地理解他們在敏捷開發環境里扮演的角色。
• 溝通——以協作的形式與客戶進行交談和溝通是十分重要的。在整個項目過程中都應該這樣，但是從一開始就堅持這樣顯得尤其重要。

客戶／業務方介入——第二步
在這一步驟里，我們要通過用戶的素材和驗收測試讓客戶參與到開發過程里來。很多客戶可能在編寫用戶素材或者驗收測試上經驗不多或者完全沒有經驗；再強調一次，可能需要某種程度的討論會或者培訓來幫助其完成任務。

用戶的素材
用戶的素材就是“需求”。每個素材都代表系統需要如何解決某個特定的問題。然而，用戶的素材不是大量的寫滿需求的文檔，而是寫在素材卡上，應該作為實現更進一步談話的引子。

好的素材需要什么？
客戶，或者更加常見的客戶小組，需要聚在一起，在一張5x3寸的素材卡上為系統編寫用戶素材。我們用財物管理軟件公司3Q Solutions來作為例子：

“客戶希望能夠獲得一個規則引擎，從而可以用規則來評估顧客的經濟狀態。”

這一要求或者素材存在的問題是太不明確。編寫好素材卡的正確規則應該是INVEST：

獨立的（Independent）
可協商的（Negotiable）
垂直的（Vertical）
可估計的（Estimable）
短小的（Small）
可測試的（Testable）

面的素材顯然是不可估計的（很難判斷它需要花多長時間）、不短小的（這是一個非常巨大的、不明確的要求），也是不可測試的（你如何能夠對像這樣的要求進行由測試驅動的開發工作？）。所以下面這樣一個素材可能會更好：

“客戶希望能夠分析顧客當前擁有的現金量——太多、太少，還是剛剛好（取決于生活方式的成本和對風險的態度）?！?/p>

這一素材就滿足了我們INVEST標準的所有要求。當這個素材在小組（客戶和開發方）中討論的時候，它很明顯地就傳達了客戶真正需要的是具備說明規則引擎的能力。上面的例子表明，一條規則就足夠說明用戶的需要。這就是編寫素材的方法。重要的是，素材要引發產生對話，而對話帶來對客戶需求的明確和真正理解。

溝通
要記住，素材的主導思想是，它們是發生更進一步對話的引子。其原因是語言要以上下文和理解為基礎。沒有提問，沒有對話，我們將無法體會其中微妙的含義。我們就以Matt Cohn’s Buffalo這個短語為例子。Buffalo（布法羅市）是美國紐約州的一座城市，是野牛（bison）的同義詞，還有動詞“欺騙和困惑”的意思。所以這樣一個句子“Buffalobuffalobuffalobuffalo”是成立的?；蛘吒用鞔_一點就是來自（紐約州）布法羅市的野牛欺騙了其他的野牛（bison from Buffalo (NY) intimidate and confuse other buffalo）。所以如果沒有上下文，這個短語就是毫無意義的。

在每張素材卡的背面，我們建議客戶快速記下任何有關驗收測試的想法。

驗收測試
驗收測試用來保證：

1. 客戶確信給定的功能能夠滿足設計的要求。
2. 給予開發人員一個明確的停止點：當驗收測試通過的時候，功能就被實現了。

在敏捷開發項目里，客戶要編寫所有的驗收測試。在項目初期，開發人員可能需要與客戶緊密合作，以編寫驗收測試的內容。

我們還建議你使用AT框架并將測試自動化。開人員人需要能夠隨著他們不斷加入新功能而反復地運行這些測試。

下面就是與上述素材相關的AT框架的例子。

交互測試（示例）

//概述
“分析顧客的現金收支狀況，考察他們在給定的生活方式成本和對風險的態度的條件下是否握有過多的現金?！?/p>

在3Q公司，客戶會編寫驗收測試，并以電子文本的形式每天提交給開發小組。所有的驗收測試都會被盡早地提供給開發小組。這一過程與測試－編碼－重整循環配合得相當好，它使得開發人員可以在進行驗收測試失敗之后，運行通過測試－編碼－重整循環，然后重新運新驗收測試，直到看到其通過測試。每個素材都可能多次進行驗收測試，但是一旦所有的驗收測試都通過了，那么該素材／功能的實現就完成了。

重要的成功因素

• 不慌不忙——用戶素材不容易寫好，所以在進行首批任務和討論任務的時候給自己充裕的時間。
• 驗收測試幫助——開發人員可能需要從一開始就與客戶一起編寫驗收測試。專門為這一任務撥出時間——好的驗收測試將帶來不同尋常的收獲。
• 尋求幫助——如果意識到你和你的小組需要幫助——去尋求幫助吧，不要猶豫！
• 已有的需求文檔——如果有現成的需求文檔，你要將它用作編寫素材的基礎。要記住，把這些文檔當作“新的”素材。它們是對話的要點，而不是定好的要求。

策劃——第三步
敏捷軟件開發有三個層次的策劃：

1. 高層次的發布策劃，在這里策劃項目的所有發布。這通常取決于項目的規模，但是某些項目的多次發布要求對長達18個月的期限的高層次策劃。
2. 發布策劃，第一次發布在這里被策劃。每次發布之間的間隔為3個月。
3. 反復策劃，通過其來策劃下兩個星期的工作。

這一三級策劃過程的目的是讓小組首先理解最終的目標，但是只詳細策劃他們現在所知的內容——未來兩周的工作。

發布策劃
在高層次發布策劃階段，客戶和開發人員應該在一起共同討論和理解整個系統。通常已經存在的需求文檔能夠用于啟動這一討論。在理想狀況下，客戶應該在開會的時候帶上含有即將發布的大多數內容的素材卡。

在會議過程中，開發人員將需要估計素材的難度。這可以在會議過程中或者在會議之后進行。我們建議每個人相互比較各自素材，并把具有相同難度的素材集中到一起。然后，使用一個從最簡單到最難的測量表，你就可以開始估計每個素材（的難度了）。小組使用不同的方法來給素材評分，按照難度分別打上1到10分。

現在客戶能夠策劃最初的高層次發布計劃了。高層次發布并不一定要十分精確，優先順序和估計都不需要很可靠，但是它會為小組定下方向和提供決策的足夠信息。

小型發布
下一步，客戶需要拿走估計好的素材卡，并根據最近一個發布將素材的重要性的優先順序排列好。客戶需要考慮它們需要系統立即實現什么，因而這些素材將構成即將進行的發布。這些估計在這里變得十分重要，因為開發人員已經估計的是他們能夠給定的發布時間里完成什么；（這個給定的時間）在大多數情況下是3個月。

短期發布循環可以保證緊密的反饋循環，還能讓小組把精力放在與項目緊密相關的重要目標上。

反復策劃
現在小組需要為未來兩周制定具體的計劃。再強調一次，客戶必須將素材的優先順序排列出來，詳細說明他們希望在未來兩周里看到的功能。

這些素材卡然后就被放到兩周的反復（發布里）。最近的一次反復將是小組立即進行的工作。他們將交付這個反復，也就是全力工作、軟件測試和取得反饋（即再次為未來兩周策劃），然后再次開始。如果素材在一個反復之前就完成了，開發人員會要求獲得更多的素材。如果所有的素材都看起來是無法完成的，那么開發人員和客戶要共同將素材移到下一個反復里或者適當地分割一下素材。

兩周的反復讓客戶可以充分利用任何變化。例如，3Q公司碰到了一個很有預見能力的客戶。他意識到一個按計劃放在發布后期的素材事實上需要更早完成。在經過一個簡短的討論之后，小組用客戶要求的素材替換掉了當前發布里具有同等價值的素材。那么成本呢？只是一個15分鐘的對話。

以上只是對策劃過程如何工作的簡要概述。我們建議尋求對該過程這一部分的一些幫助或者指導，因為它可能會十分復雜，仔細調整常常也是必需的。

這一反復過程和發布策劃分別要每兩個星期和每三個月進行一次。

重要的成功因素

• 在反復中期進行一次檢查——盡早檢查小組在反復中期的進展情況。
• 估計就是這樣——小組一開始的估計常常會偏離甚遠——開發人員都是樂觀主義者！但是隨著小組進展到新的反復并適應這一過程，估計（的準確性）或者速度（小組工作有多快）就會確定下來。
• 昨天的天氣——一旦完成了一個反復，你將對小組的速度有一個粗略的概念——兩個星期里可以交付多少素材。這就是小組認可的在未來兩周里的速度和小組工作量。隨著小組的成熟，具備更好地進行估計的能力，你的速度可能會提高，然后固定在一個穩定的速度上。
• 速度不是一根棍子——而是對管理者的提醒——速度不是用來鞭打小組的大棒；它是用來測量自然波動的。
• 決策——客戶或者客戶小組必須具有決策權，或者能夠迅速進行決策，尤其是在需要變化或者適應的時候。
• 協商的意愿——客戶必須愿意就范圍等內容進行協商。這才是敏捷開發的工作方式：就范圍進行協商，排列最具業務價值的功能的優先順序。

敏捷開發里的策劃可能會很困難，所以我們建議你去尋求一些幫助，并花時間來完成它。

保持高效——第四步
逐步推進這一過程的最佳方法之一是有一個在現場的客戶。最理想的方法是讓客戶坐在小組成員當中，這樣就可以隨時回答問題。這限制了開發人員的隨意猜想。此外，在現場的客戶能夠以最快的速度回答開發人員的疑問。

這并不意味著這個客戶不去從事他的“日常”工作，而是說他就在周圍準備好回答問題。即使隔著一層樓也會影響溝通。要進行面對面的對話，而不是用電話或者電子郵件。

顯然，設置現場客戶并不總是可能的，在這種情況下，他應該盡可能地接近小組，并盡可能地參加每日例會。如果這也不可能，那么你就要讓他參加日常會議——至少一周一次——以確保你在不斷地去的反饋意見和溝通。

對反饋和溝通的增加也需要定期進行回顧。這最好應該在每個反復結尾的時候進行。這樣的回顧能夠讓小組有機會坐下來檢查上一個反復，并弄清楚什么做得好、什么做得不好，以及下一次能夠把什么做得更好。應該問三個問題：什么有用？什么沒有用？我們要改進什么？

重要的成功因素

• 現場與否？——現場客戶或許會帶來一些問題，但是如果可能的話還是要找一個現場客戶。如果無法實現，就要尋找其他的途徑來確保定期的溝通。
• 回顧——把在每次反復結束的時候進行回顧作為一條紀律定來下，并把人們的想法付諸行動。

我們剛剛更加仔細地探討了《上篇》里第一個圖表的外層圓環，它需要所有參與者的同意。這可能是敏捷開發里最困難的一部分，但是它能夠很好地協調業務和IT，而且其好處不僅對于業務而且對于IT也是很有價值的。

總結
盡管在本系列里我們向你講解了如何一步步地培養敏捷軟件開發的能力，以及如何從內到外樹立開發人員的信心，然后是開發小組的信心，最后是整個項目小組的信心。從在Exoftware公司的經驗可以看出，很多公司都選擇為某個項目建立一個完整的敏捷開發實驗小組，并讓一個指導老師手把手地幫助小組。如果你選擇這一方法，你將具有從所有做法直接獲得好處的優勢，此外，它將給你適應你具體環境的有價值的信息。簡單地說有：

實驗性的敏捷軟件開發——如何開始
你的目標是什么？
評估你現在所處的位置以及你想要去哪里，這對于使用敏捷開發做法來說是至關重要的。這將幫助你確定希望取得的預期成果。對其的外部評估常常也是很有用的，因為它們將為處理你的問題提供一個客觀的視角。

實驗性的敏捷開發
雖然我們已經敘述了開發敏捷開發的一種方法，但是在一個項目上引導實現敏捷開發是理解敏捷開發方法是否適用于你的機構的最佳方法，它還會幫助你了解如何適應自己的環境。

測量標準
如果可能的話，你要在項目開始前或者在實現敏捷開發做法之前收集一些測量標準。即使這些標準來自于其他的項目，它們也將有助于為敏捷開發已經實現的內容提供一個良好的基準。你還要確保能夠在敏捷開發項目過程中以及之后收集到一些高標準的測量標準。缺陷率、測試內容或者最終期限都是很好的且簡單易行的高標準測量標準。

環境
要明白實驗性的敏捷開發可能要求對你的物理環境進行一些改變。例如，開放的工作空間是敏捷開發真正起效的必要條件。

尋求幫助
外部的幫助能夠指導你的實驗性項目邁向成功。它能夠幫助你理解你在哪里以及你想去哪里，并且能夠向你指明如何讓敏捷開發適應你的環境，從而到達這一目標。此外，外部幫助可以確保小組集中精力回答隨時出現的問題。為將敏捷開發應用到其他工程小組里而樹立一個業務案例也是十分重要的。

Brian Swan是Exoftware公司教授敏捷開發的指導老師。他在敏捷開發的技術和管理方面具有相當豐富的經驗，曾經帶領很多小組成功地轉換到了敏捷開發，并以敏捷開發的思想和做法來培訓開發人員和管理人員。他在Exoftware公司和在敏捷開發方面的工作使他到過很多公司，并對其開發小組產生了持續的、積極的影響。Brian先前的經驗還包括擔任Napier大學的講師，講授軟件開發和人機互動。Brian可以通過電子郵件聯系上。

?