OOPAA

敏捷實踐

下面，我們從“個人－團隊－組織”的不同層次分別選取幾個突出實踐簡要解釋它們是如何提供頻繁、直接的反饋。

l        個人層級

測試驅動開發能給開發人員提供最直接也是最快捷的反饋：先寫測試，再用最簡單的方式實現，再重構代碼以符合簡單設計的原則。如此短間隔的反饋能很快地告訴開發人員剛才增加的代碼是否破壞了已有的功能。而且，已完成test case的列表能很清晰地告訴其他人開發任務的完成情況。對比著用戶故事的驗收條件，開發人員很容易評估剩余的工作量，并不至于破壞已有的功能。

l        團隊層級

敏捷實踐中的持續集成，強調盡可能快盡可能頻繁地提交代碼，與系統的其他部分進行集成。在提交新代碼之前，必須保證本地的構建過程是成功無誤的。誰提交代碼使得持續集成服務器構建失敗，必須立即停下手中的活，負責修復構建直到成功。下班之前必須要保證持續集成服務器上的集成構建狀態是成功的。這樣，開發人員和團隊很容易檢查新功能與其他模塊的集成，另外也把未來的集成風險降到最低。

l        組織層級

用戶故事是開發團隊與客戶之間討論需求的基礎。用戶故事必須對客戶有真實可見的業務價值，并且必須包含對該需求完成的驗收條件。用戶故事作為業務分析人員、測試人員、項目經理與客戶一起確定的用戶需求，具有經過驗證的確切性。開發人員開發故事之前，必須和業務分析人員、測試人員溝通理解需求；開發完故事之后，必須要由業務分析人員與測試人員根據驗收條件進行驗收。組織和客戶之間可以針對達成共識的故事列表來分析項目狀態，從而驗證或者修改項目計劃。

上面只是從“個人－團隊－組織”的層次分別挑出了測試驅動開發、持續集成，以及用戶故事的實踐闡述了敏捷實踐如何在不同的層次提供頻繁的反饋，一孔窺豹，還有其他若干實踐在這里就不再贅述。總之，敏捷眾多的實踐就像組成了一張全面立體的安全網，時時刻刻從各個角度給項目成員、團隊，以及組織提供短周期的反饋，幫助團隊成員不僅感受到開發過程中的同伴約束，而且也可以感受到來自整個團隊的約束，甚至是來自組織之間的約束。這些外來約束也像是纏繞在個人周圍的催化劑，糾正或改善個人的行為，達到提升個人的紀律性。

實際團隊

經過幾天魔鬼般的技術實踐培訓，我們在第三天給學員們安排了全天的模擬項目演練。在演練中，由學員自行組織自己的團隊：選出自己的團隊名稱和口號、推選出項目經理、各自分配開發任務，所有人都信心滿滿。在剛開始接觸開發任務的時候，他們還是有一些不好的習慣，這時候，我們鼓勵他們把前幾天學到的敏捷實踐都用起來。于是就出現了這樣的形式：當結對中的一人先寫實現，而不是先寫測試時，另一個人會指出問題，然后重新使用測試驅動的方式；在提交代碼時，會有培訓講師監督著他們按照正確的方式來提交；開發用戶故事，要求開發人員必須跟分析人員溝通清楚細節，驗收故事時，開發人員必須與分析人員和“現場客戶”同時參與驗收......雖然有些磕磕碰碰，但整體上團隊還是有條不紊地進行下去，而且每個人只需要關注自己手頭的那部分工作，也易于讓他們把事情做得正確。

到了下午，隨著學員對技術和業務理解的加深，他們也開始自覺地維護起開發過程，使其保持順暢。開發過程中，結對的兩人激烈地討論實現的方法，達成一致后又一起開懷大笑；碰上了問題，主動招手找業務分析師詢問需求細節，如果業務分析師也弄不清楚，再找現場客戶來解答，直到三方都滿意；多人開發遇上了沖突，主動找到對方，商量溝通解決方案，實在不行，就找項目經理進行溝通協調；當有人提交了代碼使得持續集成服務器構建失敗，所有人會善意地提醒犯錯的人，督促他們修復；誰遇上了技術問題，有人聽見了他們的討論就會自發上前提供自己的信息；項目經理因為團隊自組織也就從繁雜的管理工作里面脫身而出，饒有興趣地與開發人員一起結對干起了開發的活......整個團隊像一列火車一樣，前輪帶動后輪，后輪推動前輪，井然有序，毫不停歇地往前行進。

最后，我們作為模擬客戶參加了這個團隊的show case會議，驚訝地看到這個團隊的士氣和活力，以及他們完成的工作。特別是他們表現出來的團隊集體感，讓人會以為他們是一個磨合很久的團隊。項目經理還在為沒有完成更多的工作任務覺得惋惜，但對于“如果給更多時間，是否有信心這個團隊可以更好地完成更多的任務”這一問題，他表達了明確的認同。然后再問“為什么”，他說，這個團隊的士氣和紀律讓他刮目相看，目前完成任務的質量讓他對未來的任務充滿信心。最后問“愿意率領這樣的團隊么？”，答案是“為什么不？”

作者簡介：金明，ThoughtWorks咨詢師，InfoQ中文社區編輯，SCJP，系統分析師。他在機械模具、數字安全證書，以及海洋航運等行業擁有超過4年的企業應用開發經驗。他對敏捷方法學，特別是敏捷咨詢和項目管理，以及面向對象分析和架構設計等方面有濃厚的興趣。

－－完－－