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