|
|
敏捷很火，也讓人迷惑
敏捷軟件開發方法受到越來越多的關注。圖（一）是來自Google 趨勢的數據，它反映了近年來Scrum（敏捷開發方法的典型代表）和 CMMI（傳統開發方法的典型代表）的相對搜索量變化趨勢比較。在2004年CMMI的搜索量還是Scrum 的接近3倍，2007年Scrum的搜索量第一次超過CMMI。時至今日，Scrum的搜索量已超過CMMI三倍。
圖1 Scrum 和 CMMI相對搜索量的趨勢比較
這只能說明一個問題 —— 敏捷很火！問題是，它應該是你的選擇嗎？先聽聽別人怎么說，培訓機構說：“它是兩天的培訓”；咨詢公司說：“你需要貼身輔導”；工具提供者說：“你out了，該升級啦”； PMI說：“我們也敏捷了，第一期敏捷項目管理認證馬上開始”[1]；SEI說：“CMMI也敏捷了，我們已經在CMMI 1.3版中為重要的KPA（關鍵過程域）添加了敏捷的標簽”[2]；還有人說：“敏捷是神馬？”。
敏捷被賦予了太多的含義，甚至承載了利益，有時還讓人迷惑。本文并不試圖去定義敏捷。但，我們會分別從外部（業務視角）和內部（開發模式及組織視角）觀察正在發生的敏捷，并提交觀察報告。
從外部（業務視角）看敏捷
離開用戶的價值、離開組織的業務目標去談開發模式的轉變只有兩種可能——“自以為是”或“別有用心”。我們對敏捷的觀察將首先從業務目標出發——從外部看敏捷。
1. 反摩爾定律 ⇒ 速度關乎生死，增量交付價值
IT從業者都知道“摩爾定律”——同樣的錢所能買到的產品性能，將每隔18個月翻兩倍。Google的前CEO 埃里克·施密特在一次采訪中指出，如果你反過來看摩爾定律，一個 IT 公司如果今天和十八個月前賣掉同樣多的、同樣的產品，它的收入就要降一半，在IT領域這被稱為“反摩爾定律”。反摩爾定律告訴我們，同樣的產品所能獲得的價值，隨時間按一定斜率下降。更有甚者，錯過了一個時間窗口，產品可能就不再有任何價值。產品推出的遲早，不僅影響獲得回報的時間，還影響到獲得價值的多少，甚至是有無。
在競爭激烈和復雜多變的市場環境中，快速把概念轉化為產品推向市場的能力事關組織的生死。然而，做到這一點并不容易。增加人手？受資源制約。而且，因溝通復雜度的增加可能反使項目延期，這一點在《人月神話》中早有論述。提高開發效率？那不是一朝一夕的事情，敏捷開發實施也不直接帶來開發效率的提高。
敏捷軟件開發的應對之道是改變價值的交付模式。如圖（二）所示，在以瀑布模型為代表的傳統開發模式下，只在項目開發完成時一次性交付全部的價值，在此之前的產出都是半成品。敏捷軟件開發倡導迭代和增量的價值交付模式，如圖（三）所示，在敏捷軟件開發模式下，產品開發進程被劃分成固定時長的短迭代周期，每一個迭代產出潛在可交付的產品增量，產品的一部分價值得以實現。
圖2 瀑布模型下的價值實現
圖3 敏捷模式下的增量價值實現
為了做到價值的增量交付，需求要被拆分成小的端到端可交付單元。同時，小的需求便于溝通，團隊、業務人員以及客戶，更容易對特定需求進行深入、具體的討論和澄清。小的需求也便于管理，可以靈活地安排迭代計劃，在圖（三）的價值實現的階梯中，越是靠前的迭代，交付的價值越大。優先實現高價值的需求，在迭代開發模式下，是一個很自然的選擇，這樣組織可以在最短的時間獲取盡可能多的價值。
后面我們還會看到，迭代和增量開發模式影響的不僅是價值交付的模式，它還是很多其它敏捷實踐（如及時的策略調整，風險消除等）的前提。
我們可以開始交付我們的觀察報告了，當然，它也會是增量交付的。
2. NETscape之死 ⇒ 增量交付還不足夠，可持續才有意義
NETscape（網景）死了， 2007年AOL宣布將停止對NETscape的支持。90年代的互聯網用戶還會懷念它，它最高時占據了瀏覽器市場86%的份額。NETscape 的衰落有很多原因，眾所周知的是微軟利用了它在操作系統市場的優勢。回顧這段瀏覽器大戰的歷史，特別是最關鍵的1997年到2001年，會有一些其它的發現。
1997年6月NETscape推出了NETscape 4.0，其后差不多三年半的時間里，NETscape沒有推出過一個主要版本，而微軟先后推出了突破性的IE4.0和IE5.0，取得完勝。圖（四）來自“Practices for Scaling Lean & Agile Development”一書，很好地展示了在這段時間瀏覽器版本的推出和市場份額變化的關系。
圖4 瀏覽其市場份額及其版本
難以置信，在1997 - 2001這三年多的時間里NETscape在做什么？微軟在1997年底推出了IE4.0，1999年推出IE5.0，在功能上全面超越了NETscape 4.0，而此時NETscape 4.0卻不得不面對越來越多的奇怪的Bug。更嚴重的是，NETscape的代碼是如此之糟糕，以至團隊認為，再也無法基于它做重大的修改了。為此，NETscape 做出了一個重大決定 —— 重寫代碼。2001年初NETscape 終于推出了6.0（從來沒有過5.0），但這時NETscape的市場占有率已經降到了5%以下，這場瀏覽器大戰勝負已決。
這是一個悲情的故事，NETscape的工程師們絕望地看著NETscape的市場份額急劇萎縮，卻無法在產品上采取任何行動。一定程度上NETscape死于自己糟糕的系統質量 —— 在發展時期所欠下的技術債務。在軟件行業，這絕不是個案。NETscape的故事告訴我們，忽視長期質量的價值交付最終將無法持續。敏捷軟件開發遵循迭代和增量的開發模式，價值得以更快的實現，但如果忽略了質量，這也會意味著更快的積累問題。以下是在迭代交付過程中忽視質量所引發的一些典型問題。
- 前期迭代留下的爛攤子，始終沒能清理，問題越積越多。
- 既有功能越來越多，迭代中的測試工作量越來越大。
- 既有功能總被新的發布破壞。
- 代碼越來越復雜，添加一個功能需要的工作量越來越大。
- 客戶開始抱怨，不再愿意接受增量交付。
可持續的價值交付才能給組織帶來長期的效益，為實現價值交付的可持續，“內建質量”是敏捷軟件開發的必然選擇，它體現在兩個方面：
- 預防問題的發生
在敏捷軟件開發中，檢查和測試的目的是防止問題的發生，而不是發現問題。Mary Poppendieck曾經這樣形容測試的作用，她說：“測試人員的作用不是揮舞拍子趕走蚊子，而是裝上紗窗”，為此要做到更早和更頻繁地測試（test early, test often），自動化是必然的選擇。及時和有效的自動化測試是系統的安全屏障，從源頭上防止缺陷的注入。對于問題的預防還體現在一些其它的敏捷管理和技術實踐中，如 “持續集成”和“結對編程”等。
- 不讓問題積累
為了不積累問題，每一個迭代的交付都要達到特定的質量標準，質量標準同時包含用戶可見的外部質量，和系統的內部質量。外部質量，如是否通過集成測試和性能測試等，直接影響用戶的當下體驗；內部質量，如不良的代碼設計是否被重構，是否包含必要的自動化測試覆蓋等，影響系統的可擴展、可維護性以及將來的開發效率。為迭代交付的軟件定義明確的質量標準，這在敏捷實踐中被稱為Definition of Done(DoD)。定義合理的DoD，并確保每個迭代交付的軟件都達到DoD的標準，是團隊維持迭代交付節奏的前提。
即使在迭代之內，也應盡早暴露系統中的問題。尚未集成和測試的代碼隱藏溝通、設計和實現的問題，應該盡量早的進行集成和測試。通過“持續集成”技術實踐的實施，做到每天至少一次或多次的代碼集成和驗證。如果多個團隊共享一個代碼庫，那么持續集成實踐就需要拓展到所有這些團隊。
好了，第二次交付觀察報告。
* 一個題外話：后來Firefox基于NETscape重寫的代碼起家，勢頭很不錯，說明那次重寫技術上是成功的。但又如何，只能印證前面的一點，錯過時間窗可能意味著失去全世界。
3. 應時而變 ⇒ 抗拒不可預知的變化，還是打造適應變化的靈活性
在“The Agile Samurai”一書中，作者陳述了軟件項目的三個簡單事實，并指出接受并正確對待這些事實可以避免軟件項目中很多誤區。這三個事實是：
- 不可能在項目開始的時候收集到所有的需求。
- 不管你收集到什么樣的需求，它一定會發生變化。
- 要做的功能，一定會超過時間和金錢允許的范圍。
每一次軟件開發都是對未知領域的探索，無法預知一切。問題是，面對不可預知的變化，組織應采取什么樣的策略，是“抗拒不可預知的變化”還是“打造適應變化的靈活性”？傳統軟件工程的思路更接近于前者 —— 在項目開始時去預測用戶的需求，然后凍結需求，制定相應的開發計劃，再按照計劃執行，這一過程被稱為“預測性的過程”；敏捷軟件開發通過不斷的反饋和調整，動態地達成目標，這一過程被稱為“自適應過程”。
圖5 傳統的預測性軟件過程和敏捷自適應過程比較
圖（五）從概念上比較了傳統的預測性過程和敏捷的自適應過程。不管你如何預測和計劃，最后的實際目標總會發生變化，執行過程也會出現偏差，面對軟件開發這樣復雜的活動，預測性過程很難奏效。相對應的，敏捷的自適應過程強調反饋和調整，在開發過程中不斷修正方向和行動計劃，在復雜的市場環境和技術環境中把握和實現業務目標，打造適應變化的靈活性，與價值的交付速度一樣，它們都是應對激勵競爭和復雜多變的業務環境的核心競爭力。
敏捷軟件開發過程承認軟件開發的復雜性，致力于構建更加靈活應變的軟件開發過程。在迭代開發模型的基礎上，每一個迭代完成時，團隊更加深入的理解了產品及其構建技術，用戶也更加清楚自己的需求。團隊根據這些新獲取的知識和獲取的用戶反饋，調整產品方向、需求定義以及技術路線，這些調整將直接體現在接下來的迭代的開發活動中。通過這一過程，團隊能夠更準確的把握用戶需求，適應技術和市場環境的變化。
觀察報告的第三次交付。
4. 與熊共舞 ⇒ 面對風險，需要的不僅僅是勇氣；積極和系統性的應對風險
“與熊共舞”來自關于項目風險管理的同名著作，“熊”指的是項目中的風險。“風險與收益共存，通過掌控風險獲取相對競爭對手的優勢”，這是“與熊共舞”背后的含義。拒絕風險，會使組織喪失競爭優勢；承擔風險，但在操作上忽略它，同樣會把項目帶向失敗。
風險來自復雜系統開發的不確定性，敏捷軟件開發接受并應對不確定性，自然也必須面對風險。掌控風險體現在敏捷軟件開發的方方面面，可以說在某種程度上敏捷開發過程就是風險掌控的過程。以下是敏捷開發過程中應對各類風險的策略。
- 業務風險
開發錯誤的產品是最關鍵的項目風險。通過敏捷軟件開發方法，更早和更頻繁的交付產品，獲取反饋，及時調整產品開發方向，極大地降低了開發錯誤產品的可能。更緊密地與用戶協作，現場客戶參與開發過程，定期向用戶演示產品等實踐都有助于對產品的方向作出及時的修正。
不確定性并不意味著范圍的無限蔓延，敏捷軟件開發包容不確定性，同時為不確定性的設置邊界。例如在典型的敏捷方法Scrum中，通過產品待辦事項（Product Backlog）管理需求，產品負責人(Product Owner)對產品待辦事項最終負責；根據業務價值設定需求的優先級，并依照優先級的次序實現和交付需求；需求的變更只在迭代之間發生，在一個迭代之內，一般不增加或變更需求；需求的變更，必須以符合業務目標為前提。通過這些邊界的設定，團隊可以更加有序的掌控不確定性。
- 技術風險
在開發過程中，盡可能早的驗證和暴露問題，是應對技術風險的最有效手段。
- 架構的可行性會給項目帶來極大風險，在考慮客戶價值的同時，盡量在前幾個迭代中安排對架構影響比較大的用戶需求，以此來盡早地移除架構風險。對一些不確定的技術點，也可以采取類似的策略。
- 很多技術問題往往在集成時才能暴露。持續集成的技術實踐，讓團隊在第一時間集成代碼、自動構建和驗證軟件版本，始終保持一個符合質量標準的可用版本。通過持續集成，使過去在項目后期才能暴露的風險得以盡早的被發現和修正。
- 每個迭代都要交付用戶可用的需求，可以盡早的暴露團隊在能力方面的不足。
技術上的風險永遠存在，它甚至可能會使項目根本不可行。敏捷軟件開發容忍失敗，但通過不斷的反饋，敏捷開發可以做到盡早失敗（fail fast)，一方面造成的浪費比較有限，另一方還有時間尋找替代方案或實施彌補措施，在這一次的失敗中孕育下一次的成功，這也是業務和技術創新的重要源泉。
- 執行風險
對于軟件開發這樣復雜的活動，估計和計劃的偏差在所難免，它會帶來項目執行和交付的問題。敏捷軟件開發并不否認計劃的重要，但在實踐上提倡分層次和滾動式的計劃。
計劃是基于對未來的預測，根據離現在的時間長短，未來的可預測程度是不同的，基于它們的計劃也應該有所區別。
圖6 可預測性和時間關系
- 近期的將來是可以預測的。
- 稍遠的將來可以預測但并不確定。
- 遠期的將來則很難預測。
相應的，敏捷計劃也是分層次的， InfoQ的另一篇文章，《敏捷項目的多層面規劃》，把敏捷計劃的層次分為為：產品愿景、產品路線圖、發布計劃、迭代計劃和每日承諾，并總結了每一個層次的規劃包含怎樣的詳細程度，越是針對近期的計劃包含越多的細節，而遠期的計劃則更是方向性和總體性的。
敏捷開發的計劃并不是一次性完成，隨著開發進度的推進，團隊會逐步細化接下來的工作計劃，如在迭代開始前，對任務做具體規劃。這種計劃方式被稱為滾動式的計劃，它降低的計劃不能適應最新情況的風險，同時減少了不合理計劃對執行形成的負面約束。
計劃執行的度量和跟蹤同樣會影響風險的發現和管理，傳統上基于任務完成百分比的度量方式，會隱藏計劃執行的潛在風險。比如一個項目的進度是100%設計完成，加80%編碼完成，與原計劃相符。但實際又如何呢？設計可能不合理，代碼質量可能未達到要求，到了集成和測試階段突然出現進度的巨大落后。在敏捷軟件開發中把可工作的軟件作為進度度量的基本指標，在團隊遵循明確的迭代完成標準的前提下，這樣的進度度量是更實際和可靠的，進度和交付的潛在風險得以盡早暴露。
另一方面，在迭代交付模式下，如果項目在限期內不能交付所有的用戶需求，但至少可以交付已經完成的高優先級需求，而不是“要么全有，要么全無”，降低了風險發生時所造成的影響。
總之：接受和掌控軟件開發的不確定性是敏捷開發的重要基礎，也是敏捷軟件開發應對風險的出發點。風險管理體現在敏捷軟件開發的各個環節和方面，敏捷軟件開發中的風險管理是積極的和系統性的。承擔而不是躲避風險，并由此提升競爭能力，是其積極性的體現；風險應對與開發過程有機集合，而不是僅依靠單獨的風險管理實踐進行風險管理，是其系統性的體現。
至此，我們可以提交從外部（業務視角）看敏捷的完整的觀察報告了。
對以上四點可以總結為一句話：
可持續的快速交付，和穩健的靈活性。
- 可持續來源于內建質量。
- 快速交付來源于迭代和增量的開發模式。
- 穩健來源于對風險積極和系統的掌控。
- 靈活性來源于不斷反饋和調整的開發過程。
“可持續的快速交付，穩健的靈活性”，要做到并不容易，它需要開發模式、團隊組織和技術的變革，這也是我們在本文的后面的部分要帶大家去觀察的。
[1] SEI（軟件工程協會）是CMMI的主要開發者，相對敏捷開發方法，CMMI一直被認為是傳統軟件工程的代表，關于CMMI與敏捷是否沖突在社區中也多有爭論。2010年10月發布的CMMI V1.3中增加了敏捷相關的內容，比較突出的是為相關的KPA（關鍵過程域）增加了使用敏捷方法時的應用指導。
[2] PMI（項目管理協會）旗下的項目管理認證（PMP）在項目管理領域影響巨大，PMP所引用的方法學多為偏重量級的管理方法。2009年初PMI的CEO在他的博客On the Threshold of Agility中表現出對敏捷開發方法和敏捷項目管理極大關注。2011年初PMI宣布將在2011年第4季度推出PMI敏捷認證，詳見：http://www.pmi.org/Agile.ASPx
it知識庫：由外而內看敏捷軟件開發（上）——從業務視角看敏捷，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
