敏捷很火，也讓人迷惑

　　敏捷軟件開發(fā)方法受到越來越多的關(guān)注。圖（一）是來自Google 趨勢的數(shù)據(jù)，它反映了近年來Scrum（敏捷開發(fā)方法的典型代表）和 CMMI（傳統(tǒng)開發(fā)方法的典型代表）的相對搜索量變化趨勢比較。在2004年CMMI的搜索量還是Scrum 的接近3倍，2007年Scrum的搜索量第一次超過CMMI。時(shí)至今日，Scrum的搜索量已超過CMMI三倍。

圖1 Scrum 和　CMMI相對搜索量的趨勢比較

　　這只能說明一個(gè)問題 —— 敏捷很火！問題是，它應(yīng)該是你的選擇嗎？先聽聽別人怎么說，培訓(xùn)機(jī)構(gòu)說：“它是兩天的培訓(xùn)”；咨詢公司說：“你需要貼身輔導(dǎo)”；工具提供者說：“你out了，該升級(jí)啦”； PMI說：“我們也敏捷了，第一期敏捷項(xiàng)目管理認(rèn)證馬上開始”^[1]；SEI說：“CMMI也敏捷了，我們已經(jīng)在CMMI 1.3版中為重要的KPA（關(guān)鍵過程域）添加了敏捷的標(biāo)簽”^[2]；還有人說：“敏捷是神馬？”。

　　敏捷被賦予了太多的含義，甚至承載了利益，有時(shí)還讓人迷惑。本文并不試圖去定義敏捷。但，我們會(huì)分別從外部（業(yè)務(wù)視角）和內(nèi)部（開發(fā)模式及組織視角）觀察正在發(fā)生的敏捷，并提交觀察報(bào)告。

　　從外部（業(yè)務(wù)視角）看敏捷

　　離開用戶的價(jià)值、離開組織的業(yè)務(wù)目標(biāo)去談開發(fā)模式的轉(zhuǎn)變只有兩種可能——“自以為是”或“別有用心”。我們對敏捷的觀察將首先從業(yè)務(wù)目標(biāo)出發(fā)——從外部看敏捷。

　　1. 反摩爾定律 ⇒ 速度關(guān)乎生死，增量交付價(jià)值

　　IT從業(yè)者都知道“摩爾定律”——同樣的錢所能買到的產(chǎn)品性能，將每隔18個(gè)月翻兩倍。Google的前CEO 埃里克·施密特在一次采訪中指出，如果你反過來看摩爾定律，一個(gè) IT 公司如果今天和十八個(gè)月前賣掉同樣多的、同樣的產(chǎn)品，它的收入就要降一半，在IT領(lǐng)域這被稱為“反摩爾定律”。反摩爾定律告訴我們，同樣的產(chǎn)品所能獲得的價(jià)值，隨時(shí)間按一定斜率下降。更有甚者，錯(cuò)過了一個(gè)時(shí)間窗口，產(chǎn)品可能就不再有任何價(jià)值。產(chǎn)品推出的遲早，不僅影響獲得回報(bào)的時(shí)間，還影響到獲得價(jià)值的多少，甚至是有無。

　　在競爭激烈和復(fù)雜多變的市場環(huán)境中，快速把概念轉(zhuǎn)化為產(chǎn)品推向市場的能力事關(guān)組織的生死。然而，做到這一點(diǎn)并不容易。增加人手？受資源制約。而且，因溝通復(fù)雜度的增加可能反使項(xiàng)目延期，這一點(diǎn)在《人月神話》中早有論述。提高開發(fā)效率？那不是一朝一夕的事情，敏捷開發(fā)實(shí)施也不直接帶來開發(fā)效率的提高。

　　敏捷軟件開發(fā)的應(yīng)對之道是改變價(jià)值的交付模式。如圖（二）所示，在以瀑布模型為代表的傳統(tǒng)開發(fā)模式下，只在項(xiàng)目開發(fā)完成時(shí)一次性交付全部的價(jià)值，在此之前的產(chǎn)出都是半成品。敏捷軟件開發(fā)倡導(dǎo)迭代和增量的價(jià)值交付模式，如圖（三）所示，在敏捷軟件開發(fā)模式下，產(chǎn)品開發(fā)進(jìn)程被劃分成固定時(shí)長的短迭代周期，每一個(gè)迭代產(chǎn)出潛在可交付的產(chǎn)品增量，產(chǎn)品的一部分價(jià)值得以實(shí)現(xiàn)。

圖2 瀑布模型下的價(jià)值實(shí)現(xiàn)

圖3 敏捷模式下的增量價(jià)值實(shí)現(xiàn)

　　為了做到價(jià)值的增量交付，需求要被拆分成小的端到端可交付單元。同時(shí)，小的需求便于溝通，團(tuán)隊(duì)、業(yè)務(wù)人員以及客戶，更容易對特定需求進(jìn)行深入、具體的討論和澄清。小的需求也便于管理，可以靈活地安排迭代計(jì)劃，在圖（三）的價(jià)值實(shí)現(xiàn)的階梯中，越是靠前的迭代，交付的價(jià)值越大。優(yōu)先實(shí)現(xiàn)高價(jià)值的需求，在迭代開發(fā)模式下，是一個(gè)很自然的選擇，這樣組織可以在最短的時(shí)間獲取盡可能多的價(jià)值。

　　后面我們還會(huì)看到，迭代和增量開發(fā)模式影響的不僅是價(jià)值交付的模式，它還是很多其它敏捷實(shí)踐（如及時(shí)的策略調(diào)整，風(fēng)險(xiǎn)消除等）的前提。

　　我們可以開始交付我們的觀察報(bào)告了，當(dāng)然，它也會(huì)是增量交付的。

　　2. NETscape之死 ⇒ 增量交付還不足夠，可持續(xù)才有意義

　　NETscape（網(wǎng)景）死了， 2007年AOL宣布將停止對NETscape的支持。90年代的互聯(lián)網(wǎng)用戶還會(huì)懷念它，它最高時(shí)占據(jù)了瀏覽器市場86%的份額。NETscape 的衰落有很多原因，眾所周知的是微軟利用了它在操作系統(tǒng)市場的優(yōu)勢。回顧這段瀏覽器大戰(zhàn)的歷史，特別是最關(guān)鍵的1997年到2001年，會(huì)有一些其它的發(fā)現(xiàn)。

　　1997年6月NETscape推出了NETscape 4.0，其后差不多三年半的時(shí)間里，NETscape沒有推出過一個(gè)主要版本，而微軟先后推出了突破性的IE4.0和IE5.0，取得完勝。圖（四）來自“Practices for Scaling Lean & Agile Development”一書，很好地展示了在這段時(shí)間瀏覽器版本的推出和市場份額變化的關(guān)系。

圖4 瀏覽其市場份額及其版本

　　難以置信，在1997 - 2001這三年多的時(shí)間里NETscape在做什么？微軟在1997年底推出了IE4.0，1999年推出IE5.0，在功能上全面超越了NETscape 4.0，而此時(shí)NETscape 4.0卻不得不面對越來越多的奇怪的Bug。更嚴(yán)重的是，NETscape的代碼是如此之糟糕，以至團(tuán)隊(duì)認(rèn)為，再也無法基于它做重大的修改了。為此，NETscape 做出了一個(gè)重大決定 —— 重寫代碼。2001年初NETscape 終于推出了6.0（從來沒有過5.0），但這時(shí)NETscape的市場占有率已經(jīng)降到了5%以下，這場瀏覽器大戰(zhàn)勝負(fù)已決。

　　這是一個(gè)悲情的故事，NETscape的工程師們絕望地看著NETscape的市場份額急劇萎縮，卻無法在產(chǎn)品上采取任何行動(dòng)。一定程度上NETscape死于自己糟糕的系統(tǒng)質(zhì)量 —— 在發(fā)展時(shí)期所欠下的技術(shù)債務(wù)。在軟件行業(yè)，這絕不是個(gè)案。NETscape的故事告訴我們，忽視長期質(zhì)量的價(jià)值交付最終將無法持續(xù)。敏捷軟件開發(fā)遵循迭代和增量的開發(fā)模式，價(jià)值得以更快的實(shí)現(xiàn)，但如果忽略了質(zhì)量，這也會(huì)意味著更快的積累問題。以下是在迭代交付過程中忽視質(zhì)量所引發(fā)的一些典型問題。

• 前期迭代留下的爛攤子，始終沒能清理，問題越積越多。
• 既有功能越來越多，迭代中的測試工作量越來越大。
• 既有功能總被新的發(fā)布破壞。
• 代碼越來越復(fù)雜，添加一個(gè)功能需要的工作量越來越大。
• 客戶開始抱怨，不再愿意接受增量交付。

　　可持續(xù)的價(jià)值交付才能給組織帶來長期的效益，為實(shí)現(xiàn)價(jià)值交付的可持續(xù)，“內(nèi)建質(zhì)量”是敏捷軟件開發(fā)的必然選擇，它體現(xiàn)在兩個(gè)方面：

1. 預(yù)防問題的發(fā)生

   在敏捷軟件開發(fā)中，檢查和測試的目的是防止問題的發(fā)生，而不是發(fā)現(xiàn)問題。Mary Poppendieck曾經(jīng)這樣形容測試的作用，她說：“測試人員的作用不是揮舞拍子趕走蚊子，而是裝上紗窗”，為此要做到更早和更頻繁地測試（test early, test often），自動(dòng)化是必然的選擇。及時(shí)和有效的自動(dòng)化測試是系統(tǒng)的安全屏障，從源頭上防止缺陷的注入。對于問題的預(yù)防還體現(xiàn)在一些其它的敏捷管理和技術(shù)實(shí)踐中，如 “持續(xù)集成”和“結(jié)對編程”等。

2. 不讓問題積累

   為了不積累問題，每一個(gè)迭代的交付都要達(dá)到特定的質(zhì)量標(biāo)準(zhǔn)，質(zhì)量標(biāo)準(zhǔn)同時(shí)包含用戶可見的外部質(zhì)量，和系統(tǒng)的內(nèi)部質(zhì)量。外部質(zhì)量，如是否通過集成測試和性能測試等，直接影響用戶的當(dāng)下體驗(yàn)；內(nèi)部質(zhì)量，如不良的代碼設(shè)計(jì)是否被重構(gòu)，是否包含必要的自動(dòng)化測試覆蓋等，影響系統(tǒng)的可擴(kuò)展、可維護(hù)性以及將來的開發(fā)效率。為迭代交付的軟件定義明確的質(zhì)量標(biāo)準(zhǔn)，這在敏捷實(shí)踐中被稱為Definition of Done(DoD)。定義合理的DoD，并確保每個(gè)迭代交付的軟件都達(dá)到DoD的標(biāo)準(zhǔn)，是團(tuán)隊(duì)維持迭代交付節(jié)奏的前提。

   即使在迭代之內(nèi)，也應(yīng)盡早暴露系統(tǒng)中的問題。尚未集成和測試的代碼隱藏溝通、設(shè)計(jì)和實(shí)現(xiàn)的問題，應(yīng)該盡量早的進(jìn)行集成和測試。通過“持續(xù)集成”技術(shù)實(shí)踐的實(shí)施，做到每天至少一次或多次的代碼集成和驗(yàn)證。如果多個(gè)團(tuán)隊(duì)共享一個(gè)代碼庫，那么持續(xù)集成實(shí)踐就需要拓展到所有這些團(tuán)隊(duì)。

　　好了，第二次交付觀察報(bào)告。

　　* 一個(gè)題外話：后來Firefox基于NETscape重寫的代碼起家，勢頭很不錯(cuò)，說明那次重寫技術(shù)上是成功的。但又如何，只能印證前面的一點(diǎn)，錯(cuò)過時(shí)間窗可能意味著失去全世界。

　　3. 應(yīng)時(shí)而變 ⇒ 抗拒不可預(yù)知的變化，還是打造適應(yīng)變化的靈活性

　　在“The Agile Samurai”一書中，作者陳述了軟件項(xiàng)目的三個(gè)簡單事實(shí)，并指出接受并正確對待這些事實(shí)可以避免軟件項(xiàng)目中很多誤區(qū)。這三個(gè)事實(shí)是：

1. 不可能在項(xiàng)目開始的時(shí)候收集到所有的需求。
2. 不管你收集到什么樣的需求，它一定會(huì)發(fā)生變化。
3. 要做的功能，一定會(huì)超過時(shí)間和金錢允許的范圍。

　　每一次軟件開發(fā)都是對未知領(lǐng)域的探索，無法預(yù)知一切。問題是，面對不可預(yù)知的變化，組織應(yīng)采取什么樣的策略，是“抗拒不可預(yù)知的變化”還是“打造適應(yīng)變化的靈活性”？傳統(tǒng)軟件工程的思路更接近于前者 —— 在項(xiàng)目開始時(shí)去預(yù)測用戶的需求，然后凍結(jié)需求，制定相應(yīng)的開發(fā)計(jì)劃，再按照計(jì)劃執(zhí)行，這一過程被稱為“預(yù)測性的過程”；敏捷軟件開發(fā)通過不斷的反饋和調(diào)整，動(dòng)態(tài)地達(dá)成目標(biāo)，這一過程被稱為“自適應(yīng)過程”。

圖5 傳統(tǒng)的預(yù)測性軟件過程和敏捷自適應(yīng)過程比較

　　圖（五）從概念上比較了傳統(tǒng)的預(yù)測性過程和敏捷的自適應(yīng)過程。不管你如何預(yù)測和計(jì)劃，最后的實(shí)際目標(biāo)總會(huì)發(fā)生變化，執(zhí)行過程也會(huì)出現(xiàn)偏差，面對軟件開發(fā)這樣復(fù)雜的活動(dòng)，預(yù)測性過程很難奏效。相對應(yīng)的，敏捷的自適應(yīng)過程強(qiáng)調(diào)反饋和調(diào)整，在開發(fā)過程中不斷修正方向和行動(dòng)計(jì)劃，在復(fù)雜的市場環(huán)境和技術(shù)環(huán)境中把握和實(shí)現(xiàn)業(yè)務(wù)目標(biāo)，打造適應(yīng)變化的靈活性，與價(jià)值的交付速度一樣，它們都是應(yīng)對激勵(lì)競爭和復(fù)雜多變的業(yè)務(wù)環(huán)境的核心競爭力。

　　敏捷軟件開發(fā)過程承認(rèn)軟件開發(fā)的復(fù)雜性，致力于構(gòu)建更加靈活應(yīng)變的軟件開發(fā)過程。在迭代開發(fā)模型的基礎(chǔ)上，每一個(gè)迭代完成時(shí)，團(tuán)隊(duì)更加深入的理解了產(chǎn)品及其構(gòu)建技術(shù)，用戶也更加清楚自己的需求。團(tuán)隊(duì)根據(jù)這些新獲取的知識(shí)和獲取的用戶反饋，調(diào)整產(chǎn)品方向、需求定義以及技術(shù)路線，這些調(diào)整將直接體現(xiàn)在接下來的迭代的開發(fā)活動(dòng)中。通過這一過程，團(tuán)隊(duì)能夠更準(zhǔn)確的把握用戶需求，適應(yīng)技術(shù)和市場環(huán)境的變化。

　　觀察報(bào)告的第三次交付。

　　4. 與熊共舞 ⇒ 面對風(fēng)險(xiǎn)，需要的不僅僅是勇氣；積極和系統(tǒng)性的應(yīng)對風(fēng)險(xiǎn)

　　“與熊共舞”來自關(guān)于項(xiàng)目風(fēng)險(xiǎn)管理的同名著作，“熊”指的是項(xiàng)目中的風(fēng)險(xiǎn)。“風(fēng)險(xiǎn)與收益共存，通過掌控風(fēng)險(xiǎn)獲取相對競爭對手的優(yōu)勢”，這是“與熊共舞”背后的含義。拒絕風(fēng)險(xiǎn)，會(huì)使組織喪失競爭優(yōu)勢；承擔(dān)風(fēng)險(xiǎn)，但在操作上忽略它，同樣會(huì)把項(xiàng)目帶向失敗。

　　風(fēng)險(xiǎn)來自復(fù)雜系統(tǒng)開發(fā)的不確定性，敏捷軟件開發(fā)接受并應(yīng)對不確定性，自然也必須面對風(fēng)險(xiǎn)。掌控風(fēng)險(xiǎn)體現(xiàn)在敏捷軟件開發(fā)的方方面面，可以說在某種程度上敏捷開發(fā)過程就是風(fēng)險(xiǎn)掌控的過程。以下是敏捷開發(fā)過程中應(yīng)對各類風(fēng)險(xiǎn)的策略。

1. 業(yè)務(wù)風(fēng)險(xiǎn)

   開發(fā)錯(cuò)誤的產(chǎn)品是最關(guān)鍵的項(xiàng)目風(fēng)險(xiǎn)。通過敏捷軟件開發(fā)方法，更早和更頻繁的交付產(chǎn)品，獲取反饋，及時(shí)調(diào)整產(chǎn)品開發(fā)方向，極大地降低了開發(fā)錯(cuò)誤產(chǎn)品的可能。更緊密地與用戶協(xié)作，現(xiàn)場客戶參與開發(fā)過程，定期向用戶演示產(chǎn)品等實(shí)踐都有助于對產(chǎn)品的方向作出及時(shí)的修正。

   不確定性并不意味著范圍的無限蔓延，敏捷軟件開發(fā)包容不確定性，同時(shí)為不確定性的設(shè)置邊界。例如在典型的敏捷方法Scrum中，通過產(chǎn)品待辦事項(xiàng)（Product Backlog）管理需求，產(chǎn)品負(fù)責(zé)人(Product Owner)對產(chǎn)品待辦事項(xiàng)最終負(fù)責(zé)；根據(jù)業(yè)務(wù)價(jià)值設(shè)定需求的優(yōu)先級(jí)，并依照優(yōu)先級(jí)的次序?qū)崿F(xiàn)和交付需求；需求的變更只在迭代之間發(fā)生，在一個(gè)迭代之內(nèi)，一般不增加或變更需求；需求的變更，必須以符合業(yè)務(wù)目標(biāo)為前提。通過這些邊界的設(shè)定，團(tuán)隊(duì)可以更加有序的掌控不確定性。

2. 技術(shù)風(fēng)險(xiǎn) 

   在開發(fā)過程中，盡可能早的驗(yàn)證和暴露問題，是應(yīng)對技術(shù)風(fēng)險(xiǎn)的最有效手段。

   • 架構(gòu)的可行性會(huì)給項(xiàng)目帶來極大風(fēng)險(xiǎn)，在考慮客戶價(jià)值的同時(shí)，盡量在前幾個(gè)迭代中安排對架構(gòu)影響比較大的用戶需求，以此來盡早地移除架構(gòu)風(fēng)險(xiǎn)。對一些不確定的技術(shù)點(diǎn)，也可以采取類似的策略。
   • 很多技術(shù)問題往往在集成時(shí)才能暴露。持續(xù)集成的技術(shù)實(shí)踐，讓團(tuán)隊(duì)在第一時(shí)間集成代碼、自動(dòng)構(gòu)建和驗(yàn)證軟件版本，始終保持一個(gè)符合質(zhì)量標(biāo)準(zhǔn)的可用版本。通過持續(xù)集成，使過去在項(xiàng)目后期才能暴露的風(fēng)險(xiǎn)得以盡早的被發(fā)現(xiàn)和修正。
   • 每個(gè)迭代都要交付用戶可用的需求，可以盡早的暴露團(tuán)隊(duì)在能力方面的不足。

   技術(shù)上的風(fēng)險(xiǎn)永遠(yuǎn)存在，它甚至可能會(huì)使項(xiàng)目根本不可行。敏捷軟件開發(fā)容忍失敗，但通過不斷的反饋，敏捷開發(fā)可以做到盡早失敗（fail fast)，一方面造成的浪費(fèi)比較有限，另一方還有時(shí)間尋找替代方案或?qū)嵤浹a(bǔ)措施，在這一次的失敗中孕育下一次的成功，這也是業(yè)務(wù)和技術(shù)創(chuàng)新的重要源泉。

3. 執(zhí)行風(fēng)險(xiǎn)

   對于軟件開發(fā)這樣復(fù)雜的活動(dòng)，估計(jì)和計(jì)劃的偏差在所難免，它會(huì)帶來項(xiàng)目執(zhí)行和交付的問題。敏捷軟件開發(fā)并不否認(rèn)計(jì)劃的重要，但在實(shí)踐上提倡分層次和滾動(dòng)式的計(jì)劃。

　　計(jì)劃是基于對未來的預(yù)測，根據(jù)離現(xiàn)在的時(shí)間長短，未來的可預(yù)測程度是不同的，基于它們的計(jì)劃也應(yīng)該有所區(qū)別。

圖6 可預(yù)測性和時(shí)間關(guān)系

• 近期的將來是可以預(yù)測的。
• 稍遠(yuǎn)的將來可以預(yù)測但并不確定。
• 遠(yuǎn)期的將來則很難預(yù)測。

　　相應(yīng)的，敏捷計(jì)劃也是分層次的， InfoQ的另一篇文章，《敏捷項(xiàng)目的多層面規(guī)劃》，把敏捷計(jì)劃的層次分為為：產(chǎn)品愿景、產(chǎn)品路線圖、發(fā)布計(jì)劃、迭代計(jì)劃和每日承諾，并總結(jié)了每一個(gè)層次的規(guī)劃包含怎樣的詳細(xì)程度，越是針對近期的計(jì)劃包含越多的細(xì)節(jié)，而遠(yuǎn)期的計(jì)劃則更是方向性和總體性的。

　　敏捷開發(fā)的計(jì)劃并不是一次性完成，隨著開發(fā)進(jìn)度的推進(jìn)，團(tuán)隊(duì)會(huì)逐步細(xì)化接下來的工作計(jì)劃，如在迭代開始前，對任務(wù)做具體規(guī)劃。這種計(jì)劃方式被稱為滾動(dòng)式的計(jì)劃，它降低的計(jì)劃不能適應(yīng)最新情況的風(fēng)險(xiǎn)，同時(shí)減少了不合理計(jì)劃對執(zhí)行形成的負(fù)面約束。

　　計(jì)劃執(zhí)行的度量和跟蹤同樣會(huì)影響風(fēng)險(xiǎn)的發(fā)現(xiàn)和管理，傳統(tǒng)上基于任務(wù)完成百分比的度量方式，會(huì)隱藏計(jì)劃執(zhí)行的潛在風(fēng)險(xiǎn)。比如一個(gè)項(xiàng)目的進(jìn)度是100%設(shè)計(jì)完成，加80%編碼完成，與原計(jì)劃相符。但實(shí)際又如何呢？設(shè)計(jì)可能不合理，代碼質(zhì)量可能未達(dá)到要求，到了集成和測試階段突然出現(xiàn)進(jìn)度的巨大落后。在敏捷軟件開發(fā)中把可工作的軟件作為進(jìn)度度量的基本指標(biāo)，在團(tuán)隊(duì)遵循明確的迭代完成標(biāo)準(zhǔn)的前提下，這樣的進(jìn)度度量是更實(shí)際和可靠的，進(jìn)度和交付的潛在風(fēng)險(xiǎn)得以盡早暴露。

　　另一方面，在迭代交付模式下，如果項(xiàng)目在限期內(nèi)不能交付所有的用戶需求，但至少可以交付已經(jīng)完成的高優(yōu)先級(jí)需求，而不是“要么全有，要么全無”，降低了風(fēng)險(xiǎn)發(fā)生時(shí)所造成的影響。

　　總之：接受和掌控軟件開發(fā)的不確定性是敏捷開發(fā)的重要基礎(chǔ)，也是敏捷軟件開發(fā)應(yīng)對風(fēng)險(xiǎn)的出發(fā)點(diǎn)。風(fēng)險(xiǎn)管理體現(xiàn)在敏捷軟件開發(fā)的各個(gè)環(huán)節(jié)和方面，敏捷軟件開發(fā)中的風(fēng)險(xiǎn)管理是積極的和系統(tǒng)性的。承擔(dān)而不是躲避風(fēng)險(xiǎn)，并由此提升競爭能力，是其積極性的體現(xiàn)；風(fēng)險(xiǎn)應(yīng)對與開發(fā)過程有機(jī)集合，而不是僅依靠單獨(dú)的風(fēng)險(xiǎn)管理實(shí)踐進(jìn)行風(fēng)險(xiǎn)管理，是其系統(tǒng)性的體現(xiàn)。

　　至此，我們可以提交從外部（業(yè)務(wù)視角）看敏捷的完整的觀察報(bào)告了。

　　對以上四點(diǎn)可以總結(jié)為一句話：

　　可持續(xù)的快速交付，和穩(wěn)健的靈活性。

• 可持續(xù)來源于內(nèi)建質(zhì)量。
• 快速交付來源于迭代和增量的開發(fā)模式。
• 穩(wěn)健來源于對風(fēng)險(xiǎn)積極和系統(tǒng)的掌控。
• 靈活性來源于不斷反饋和調(diào)整的開發(fā)過程。

　　“可持續(xù)的快速交付，穩(wěn)健的靈活性”，要做到并不容易，它需要開發(fā)模式、團(tuán)隊(duì)組織和技術(shù)的變革，這也是我們在本文的后面的部分要帶大家去觀察的。

　　[1] SEI（軟件工程協(xié)會(huì)）是CMMI的主要開發(fā)者，相對敏捷開發(fā)方法，CMMI一直被認(rèn)為是傳統(tǒng)軟件工程的代表，關(guān)于CMMI與敏捷是否沖突在社區(qū)中也多有爭論。2010年10月發(fā)布的CMMI V1.3中增加了敏捷相關(guān)的內(nèi)容，比較突出的是為相關(guān)的KPA（關(guān)鍵過程域）增加了使用敏捷方法時(shí)的應(yīng)用指導(dǎo)。

　　[2] PMI（項(xiàng)目管理協(xié)會(huì)）旗下的項(xiàng)目管理認(rèn)證（PMP）在項(xiàng)目管理領(lǐng)域影響巨大，PMP所引用的方法學(xué)多為偏重量級(jí)的管理方法。2009年初PMI的CEO在他的博客On the Threshold of Agility中表現(xiàn)出對敏捷開發(fā)方法和敏捷項(xiàng)目管理極大關(guān)注。2011年初PMI宣布將在2011年第4季度推出PMI敏捷認(rèn)證，詳見：http://www.pmi.org/Agile.ASPx

it知識(shí)庫：由外而內(nèi)看敏捷軟件開發(fā)（上）——從業(yè)務(wù)視角看敏捷，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。