敏捷式軟體開發 (Agile Software Development)（下篇）

敏捷式軟體開發 (Agile Software Development)（下篇）

NetReptile推薦 [2005-7-17]
出處：ZDNet
作者：Brian Swan
 

在敏捷式軟體開發 (Agile Software Development)方法上中下系列的最後一篇文章裡，我們將探討開發小組如何與客戶互動，如何讓其參與到開發過程裡來。

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

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

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

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

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

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

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

重要的成功因素

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

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

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

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

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

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

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

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

“客戶希望能夠分析顧客當前擁有的現金量——太多、太少，還是剛剛好（取決於生活的成本和對風險的態度）。”

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

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

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

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

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

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

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

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

互動測試（樣本）

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

//設定顧客資料
UserClicksMainMenu	MenuFinancialObjectives
UserInputsText	FinancialObjectivesAttitudeToRisk	“3－低回報－長線投資”
UserClicksMainMenu	MenuCurrentBalanceSheet
UserInputsText	CurrentBalanceSheetTotalCash	30000
UserClicksMainMenu	MenuFinancialObjectives
UserInputsText	FinancialObjectivesLifestyleCost	25000
//現金規則
TestValueOfText	AnalyseObservation	“如果擔心風險，你應該維持不超過#12,500的現金結餘。”
TestValueOfText	AnalyseRecommendation	“考慮將#17,500從現金帳戶轉移到可投資的資產上。”
TestValueOfText	AnalyseDestination	“查詢投資本金總額，將多餘的現金轉移到現金儲存體帳戶，除非用現金購買資產。”
//hyperlink
UserClicksControl	AnalyseDestination
TestValueOfLabel	WorkAreaTitle	“本金總額”

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

重要的成功因素

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

策劃——第三步
敏捷式軟體開發 (Agile Software Development)有三個層次的策劃：

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

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

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

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

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

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

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

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

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

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

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

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

重要的成功因素

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

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

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

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

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

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

重要的成功因素

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

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

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

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

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

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

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

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

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