敏捷方法學
這些年以來，已經有一些敏捷方法陸續浮出水面：極限編程（Extreme Programming，XP）、Scrum、Crystal、精益開發方法（Lean Development，LD）、動態系統開發方法（Dynamic System Development Method，DSDM）和特性驅動開發（Feature Driven Development，FDD）等等。盡管這些方法所強調的地方各有千秋，但是它們之間存在一些共同主題：成功完成開發，使設計能夠演進，創建健壯的代碼，還有，最重要的是通過與客戶的交互尋求反饋。
不同的方法對于不同的人來說，意義各有不同。某些人認為，假如你不照本宣科地遵循XP的所有核心實踐，那么你就不是在實踐XP。XP有一些重要實踐，Scrum也有自己的重要實踐。此外，還有其它的重要實踐可供使用，并取得成功。
開發者們會問：“我應該遵循哪個方法？”“我應該用 XP，還是 Scrum？對于項目出現的不利局面，我該做些什么才能扭轉乾坤呢？”這些問題都非常具有實質性，我們將在本文中逐一解決。
為失敗的項目引入敏捷特性
方法學常常伴隨著一些規程（ceremonies）而來。一些重量級的開發過程會非常規程化（或者說正規化）——它們會要求你遵循一系列的步驟，編寫某些文檔，等等。假如它真的能為你的成功帶來影響的話，一定程度的規程是很好的。通常，敏捷方法會期望你去實踐單元測試，舉行站立會議（standup meetings）等等。這些同樣也是規程，并且敏捷方法支持者們（包括你謙恭的作者）都會表示，這是一些應當遵從的好規程。但是，這些是你應當第一順序采用的實踐方法嗎？你應當采用所有提供給你的實踐方法嗎？你應該立刻全部采用它們嗎？不必，當然不必。
讓我們打個比方。我們會同意，健康飲食加上鍛煉是保持強健體魄的好習慣。然而，如果一個病人患了嚴重的胸痛，你肯定不會（也不想）聽到醫生說：“如果你飲食健康并且加強鍛煉的話，你就不用到這兒來了。所以說現在給我爬起來，馬上來跑步機上鍛煉！”這么做著實荒唐可笑，弄不好還可能把病人的性命搞丟。我們必須先將病人穩定下來，直到病情得到改善，才能用強化訓練的方法進行調整。
假如你想在出現麻煩的項目中全盤引入敏捷方法，其結果也有可能是全盤皆輸。在引入其它優秀的實踐之前，讓我們先探討一些能幫助我們重建項目，并使其恢復元氣的實踐吧。
采用迭代的步伐邁向敏捷
假定你只有幾個月時間來完成你的項目，然而項目團隊仍遠遠地落在計劃之后。此外，假設你的團隊并不熟悉諸如單元測試和持續集成之類的大多數重要的敏捷實踐。為這樣的團隊引入單元測試，可能需要時間理解和熟練應用。盡管單元測試可以帶來顯著的益處，但是對你的團隊來說，目前卻可能并非合適的時間。
比較穩健的做法，可以是一個漸進的（迭代且遞增的）方式，使你的團隊邁向敏捷。在入手解決問題之前，第一件事情應該是去了解問題到底是什么。為什么你的團隊會落后于計劃？有哪些東西在妨礙他們？至少，世界上所有的好方法都無法馬上見效。了解首要和迫切問題是什么，并且解決它們，是很重要的。一旦你解決了首要問題，你就可以繼續前進，進行改進和調整。
使用迭代式敏捷方法的嘗試
我曾有這樣一個機會參與到一個處于危機狀態的項目中——一位翹首企盼的客戶在為他行將崩潰的項目緊急求援。這個項目進行了很長時間，卻成效甚微。整個項目團隊并沒有采取任何敏捷方法，他們沒有進行交流，項目沒有迭代周期。他們痛苦地掙扎著，以期能跟上進度，并努力嘗試在編寫新代碼和修正 bug 之間尋找平衡。
他們只剩下很短的幾個月來完成這個項目；整個團隊陷于一片恐慌之中，項目經理幾近絕望。要求團隊采取例如單元測試的方法，在當時看起來并不是一個穩當的做法。那么我能盡可能少地采取哪些敏捷方法實踐，來為這個項目逆轉乾坤呢？根據當時項目和團隊的現狀，我們決定以其時看來最合乎邏輯的三個方法開始：每周迭代并提交演示版本，每天舉行站立會，以及劃分優先級和回溯。
每周迭代并提交演示版本
整個團隊埋頭苦干，發了瘋似地想把事情做好。他們看到的項目范圍和任務列表上的任何時間滿得讓人腦袋發暈。團隊成員中存在一些合理的顧慮：我應該修改這些 bug 嗎？我應該添加新特性嗎？該是哪些新特性？那上周我開始著手的東西又該怎么辦呢？還有兩周前的呢？你要我一口氣處理所有這些東西？就在現在？！
如果項目團隊能夠清楚地專注于他們應該做的工作，那么結果肯定是頗有裨益的。通過確定按照以周為單位的迭代進行工作（不同的敏捷方法推薦一至六周的時間作為迭代周期），我們可以每次定義出一周的工作范圍。這樣就為團隊的每個成員和項目經理提供了一個讓大家坐下來制定當前一周工作目標的機會。一旦用于迭代的任務列表被制定下來以后，團隊的每個人參與評審。誰也不想搞出一個失敗的計劃——整個團隊都必須統一口徑，決定哪些要完成的東西是合理的。
每個周末，我們向可能為項目提供關鍵性反饋的核心客戶進行項目演示。項目團隊進行這些演示的目標，就是為了符合客戶的期望，每周進行一次。在演示中，項目團隊展示哪些東西已經被實際構建出來，闡明他們完成的特性，并且尋求反饋，從而了解哪些可以改進，哪些需要更改。我們也決定哪些任務應當在下周優先執行。
每天舉行站立會議
團隊的成員們抱怨說，他們能聽到的，僅僅是行軍號角聲，但沒有人知道其他人到底走到了那兒。他們之間缺乏有效的交流。
我們在這個項目中引入的第二個方法就是每天舉行站立會（最先在 Scrum 方法中提出，并在 XP 中被采用）。每個團隊成員都有機會進行一個簡短的演講。他們被要求集中討論三件事情：前一天他們做了些什么，今天他們打算做些什么，還有哪些東西在妨礙他們（如果有的話）。
這樣做使整個團隊得以了解每個人在做哪些東西。而且，這對當天的準備也起到幫助作用，促使每個開發人員把重心放在自己當天的任務上。
劃分優先級和回溯
一個困擾項目團隊的問題是，他們很難將注意力集中在他們應當完成的工作上。開發工作就像玩“抓螃蟹”游戲一樣——他們被修復那些看似毫無規律地不斷冒出的問題，搞得手忙腳亂。他們主要使用電子郵件報告問題。不幸的是，這些郵件常常丟失，或者被其他堆積成山的正常郵件和垃圾郵件所掩埋。通過使用一個簡單的追蹤系統，我們可以輸入問題和錯誤，為它們分配優先級，并且檢查開發人員的進度。這樣也為項目帶來了一些好處。
其他實踐方法
在這個項目中，我們又進一步引入了其他有用的實踐方法，但并不是一蹴而就的。這么做的目的，不是為了變得敏捷，而是為了成功。我們采取了一種為項目團隊帶來自信的方式進行工作，并且讓大家明白項目在前進。我們否決或者推遲了不會帶來即時收益的方法，把帶來長期收益的方法保留到之后進行。通過遵循一些經過選擇的有意義的方法，以及團隊的幫助和對成功的懇切追求，項目提前于計劃完成了——這在以前是不可想象的。
結語
Ron Jeffries 明智而又貼切地表達了這樣一個觀點：“采用XP本身并不能帶來任何獎勵。真正的獎勵來自使用正確的實踐組合做事，那就是成功�！蹦阋龅�，是把注意力集中在如何取得成功上，而不是照本宣科地去實踐敏捷。首先，選好能實際解決你問題并且帶來進展的實踐方法。然后，繼續采用其他使你和你的團隊變得更好的方法。你怎么知道你做的是正確的呢？除了成功，沒有更好的證明方式。
參考文獻
Kent Beck and Cynthia Andres, "Extreme Programming Explained: Embrace Change", Addison-Wesley Professional.
Ron Jeffries, nn Anderson, and Chet Hendrickson, "Extreme Programming Installed", Addison-Wesley Professional.
Ken Schwaber and Mike Beedle, "Agile Software Development with SCRUM", Prentice Hall.
Venkat Subramaniam and Andy Hunt, "Practices of an Agile Developer", The Pragmatic Bookshelf.
關于作者
Venkat Subramaniam 博士（venkats@agiledeveloper.com）是 Agile Developer, Inc.的創始人。他培訓并指導了美國、加拿大、歐洲和印度的3000多名軟件開發人員。Venkat幫助他的客戶有效地在軟件項目中實施敏捷方法并取得成功，并且他本人多次在大會上進行演講。同時他是休斯頓大學的助理教員（在那里他獲得了2004年計算機系教學優秀獎），此外他還在萊斯大學繼續教育學院教授專業軟件開發人員系列課程。他是《.NET Gotchas》的作者，以及《Practices of an Agile Developer》的共同作者。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
