【正文】 值。 這份報(bào)告認(rèn)為： CMMI 和敏捷是可以 結(jié)合使用的 。 2020 年 11 月 SEI 發(fā)布了名為《 CMMI174。在第 三 級(jí)中，兩種 方法都可以衍生出不同的措施。這是兩種價(jià)值觀，沒(méi)法整合。 當(dāng)然 CMM 組織為了存活，繼續(xù)，它必須要做出轉(zhuǎn)變。 CMMI 的理論基礎(chǔ)是一種 預(yù)定義過(guò)程模型 ，而敏捷是一種 經(jīng)驗(yàn)性過(guò)程模型，軟件開(kāi)發(fā)從根本上是一種解決復(fù)雜的未知的問(wèn)題的過(guò)程，解決這種問(wèn)題 用使用經(jīng)驗(yàn)性過(guò)程會(huì)更加有效 。 目前 業(yè)界對(duì)于 ISO 和敏捷的關(guān)系和爭(zhēng)議較少，因此本文不再討論，重點(diǎn)分析敏捷和 CMMI 的關(guān)系。 近期，國(guó)際標(biāo)準(zhǔn)化組織 積極促進(jìn)軟件質(zhì)量的制度化，提出了如下 ISO9000 軟件標(biāo)準(zhǔn)系列：ISO900 ISO9000 ISO9004 ISO9004 ISO9002。到目前為止，已有 70 多個(gè)國(guó)家在它們的企業(yè)中采用和實(shí)施這一系列標(biāo)準(zhǔn)。 CMMI 能幫助我們整合以往各自為政的組織功能，建立過(guò)程改進(jìn)的目標(biāo)與優(yōu)先級(jí)，指導(dǎo)我們進(jìn)行質(zhì)量改進(jìn)，還提供了評(píng)價(jià)現(xiàn)有過(guò)程的參照點(diǎn)。 CMMI 為組織提供了實(shí)現(xiàn)高效的 軟件交付 過(guò)程所需 要 的基本元素 ，關(guān)注于通過(guò)切實(shí)改進(jìn)過(guò)程域的成熟度，實(shí)現(xiàn)過(guò)程改進(jìn)的目標(biāo)。 自從 1994 年 SEI 正式發(fā)布軟件 CMM 以來(lái)，相繼又開(kāi)發(fā)出了系統(tǒng)工程、軟件 采購(gòu)、人力資源管理以及集成產(chǎn)品和過(guò)程開(kāi)發(fā)方面的多個(gè)能力成熟度模型。早期的 CMMI（ CMMISE/SW/IPPD） 版本是應(yīng)用于軟件業(yè)項(xiàng)目的管理方法， SEI 在部分國(guó)家和地區(qū)開(kāi)始推廣和試用。 CMMI 簡(jiǎn)要回顧 CMMI 的全稱為： Capability Maturity Model Integration，即能力成熟度模型集成。 截止到 2020 年 5 月，國(guó)內(nèi)已有 48 家軟件企業(yè)達(dá)到 CMMI 5 級(jí)，全球 349 家組織通過(guò) CMMI5。 2. 敏捷與 CMMI 等等其它體系的關(guān)系 CMMI 模型是由美國(guó)的 SEI 開(kāi)發(fā)的，目前包 括了 3 個(gè)模型，但一般單提 CMMI時(shí)，指的只是 CMMI for DEV，而與敏捷關(guān)聯(lián)最密切的就是 CMMI for DEV，因此本文下文的 CMMI 指的就是 CMMI for DEV。而各種敏捷方法的區(qū)別在于它們對(duì)敏捷的不同闡釋和不同側(cè)重。 還有其他一些敏捷方法如敏捷統(tǒng)一過(guò)程（ Agile Unified Process），上下文驅(qū)動(dòng)開(kāi)發(fā)（ Context Driven Development）， Getting Real 等。Crystal 方法集 也提供了一些通用的做法，比如，它提供了三種回顧分析的方法：訪談，問(wèn)卷調(diào)查和工作組。另外的 4 個(gè)屬性分別是：個(gè)人安全（ personal safety），集中（ focus），容易接觸專家用戶（ easy access to expert users）和技術(shù)環(huán)境（ technical environment）。 Crystal 方法集 定義了七種屬性。相比于其他的敏捷方法，它可使人獲得更大的解放。但是相比 DSDM 來(lái)說(shuō)， FDD 在這些方面簡(jiǎn)捷了一些。 特性驅(qū)動(dòng)開(kāi)發(fā)（ FDD）是將用戶的功能需求劃分成更小的功能特征，然后逐步地在每個(gè)迭代周期中開(kāi)發(fā)實(shí)現(xiàn)這些產(chǎn)品特征。同時(shí)，每個(gè)過(guò)程都定義了諸如如何將每個(gè)功能模型轉(zhuǎn)化為實(shí)際代碼，如何將原型交付最終用戶使用并審查，如何處理反饋信息等的詳細(xì)步驟。 DSDM 在普遍的敏捷價(jià)值和原則的基礎(chǔ)上，定義了更加詳細(xì)的流程，以涵蓋更完整的項(xiàng)目生命周期。因此，將精益模式與其他敏捷開(kāi)發(fā)模式一起使用將會(huì)取得很好的效果。這些工具包括價(jià)值流圖（ Value Stream Mapping），基于集合的開(kāi)發(fā)（ setbased development），拉系統(tǒng)（ pull system），排隊(duì)論（ queuing theory），等等。無(wú)論開(kāi)發(fā)的組織還是被開(kāi)發(fā)的產(chǎn)品， 從整體上考慮優(yōu)化比從各個(gè)局部去優(yōu)化更高效。 ? 全局觀。 ? 誠(chéng)信。 16 ? 給團(tuán)隊(duì)自主權(quán)。 ? 用最快的速度交付用戶。 ? 在最后時(shí)刻做決定。軟件開(kāi)發(fā)過(guò)程是一個(gè)不斷學(xué)習(xí)的過(guò)程。浪費(fèi)及其源頭必須被分析查明，然后設(shè)法消除。 精益思想的核心思想是查明和消除浪費(fèi)。 它主要包括兩個(gè)部分：一部分是核心思想及原則，另外一部分由一些在相應(yīng)的工具構(gòu)成。 Scrum 中通過(guò)三個(gè)活動(dòng)進(jìn)行檢驗(yàn)和適應(yīng)：每日 例 會(huì)檢驗(yàn) Sprint 目標(biāo)的進(jìn)展，做出 調(diào)整 ，從而 優(yōu)化次日的工作價(jià)值 ； Sprint 評(píng)審和計(jì)劃會(huì)議檢驗(yàn)發(fā)布目標(biāo)的進(jìn)展， 做出 調(diào)整 ，從而 優(yōu)化下一個(gè) Sprint 的工作價(jià)值 ； Sprint 回顧會(huì)議是用來(lái)回顧 已經(jīng)完成的 Sprint，并且確定做出什么樣的改善可以使接下來(lái)的 Sprint 更加高效、更加令人滿意，并且工作更快樂(lè)。 第三：適應(yīng)（ Adaptation） 如果檢驗(yàn)人員檢驗(yàn)的時(shí)候發(fā)現(xiàn)過(guò)程中的一個(gè)或多個(gè)方面不滿足驗(yàn)收標(biāo)準(zhǔn)，并且最終產(chǎn)品是不合格的，那么 便需要 對(duì)過(guò)程或是材料進(jìn)行調(diào)整。幸運(yùn)的是，軟件開(kāi)發(fā)并不會(huì)出現(xiàn)這種情況。在確定檢驗(yàn)頻率 時(shí)，需要考慮到檢驗(yàn)會(huì)引起所有過(guò)程發(fā)生變化。也就是說(shuō)，當(dāng)某個(gè)人在檢驗(yàn)一個(gè)過(guò)程，并確信某一個(gè)任務(wù)已經(jīng)完成時(shí)，這個(gè)完成必須等同于他們對(duì)完成 的 定義。 Scrum 經(jīng)驗(yàn)過(guò)程控制理論的實(shí)施由三大支柱支撐： 第一：透明 性 （ Transparency） 透明 度是指，在軟件開(kāi)發(fā)過(guò)程的各個(gè)環(huán)節(jié)保持高度的可見(jiàn)性，影響交付成果的各個(gè)方面對(duì)于參與交付的所有人、管理生產(chǎn)結(jié)果的人保持透明。 Scrum 由三個(gè)角色 、 六個(gè)時(shí)間箱 和 四個(gè)工件組成： ? 三個(gè)角色 1. 產(chǎn)品負(fù)責(zé)人（ Product Owner） 2. Scrum Master 3. Scrum 團(tuán)隊(duì) ? 六個(gè)時(shí)間箱 1. Sprint 14 2. 發(fā)布計(jì)劃會(huì)議（ Release Planning Meeting） 可選 3. Sprint 計(jì)劃會(huì)議（ Sprint Planning Meeting） 4. 每日站會(huì)（ Daily Scrum Meeting） 5. Sprint 評(píng)審會(huì)議（ Sprint Review Meeting） 6. Sprint 回顧會(huì)議（ Sprint Retrospective Meeting） ? 四個(gè)工件 1. 產(chǎn)品 Backlog（ Product Backlog） 2. 發(fā)布燃盡圖（ Release Burndown Chart） 可選 3. SprintBacklog 4. Sprint 燃盡圖（ Sprint Burndown Chart） Scrum 最早由 Jeff Sutherland 在 1993 年提出， Ken Schwaber 在 1995 年OOPSLA 會(huì)議上形式化了 Scrum 開(kāi)發(fā)過(guò)程，并向業(yè)界公布。挑選的需求 在 Sprint 計(jì)劃會(huì)議上 經(jīng)過(guò) 討論 、 分析和估算得到 相應(yīng) 的任務(wù)列表，我們稱它為 Sprint backlog。 Scrum 團(tuán)隊(duì)總是先開(kāi)發(fā)對(duì)客戶具有較高價(jià)值的需求。在這個(gè)框架中，整個(gè)開(kāi)發(fā) 過(guò)程由 若干個(gè) 短的迭代 周期 組成 ， 一 個(gè) 短的迭代 周期稱為一個(gè)Sprint，每個(gè) Sprint 的建議長(zhǎng)度 是 2 到 4 周。 13 核心實(shí)踐： ? 小規(guī)模，頻繁的版本發(fā)布，短迭代周期 ? 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（ Testdriven development） ? 結(jié)對(duì)編程（ Pair programming） ? 持續(xù)集成（ Continuous integration） ? 每日站立會(huì)議（ Daily standup meeting） ? 代碼集體所有（ Collative code ownership） ? 系統(tǒng)隱喻（ System metaphor）。比如，為了尊重其他團(tuán)隊(duì)成員的勞動(dòng)成果，每個(gè)人不得將未通過(guò)單元測(cè)試的代碼集成到系統(tǒng)中。極限編程以建立并激勵(lì)團(tuán)隊(duì)為一項(xiàng)重要任務(wù)。 ? 團(tuán)隊(duì) 。另一個(gè)勇氣的例子是了解什么時(shí)候應(yīng)該完全丟棄現(xiàn)有的代碼。勇氣使得開(kāi)發(fā)人員在需要重構(gòu)他們的代碼時(shí)能感到舒適。其中之一就是 “ 只為今天的需求設(shè)計(jì)以及編碼，不要考慮明天 ” 這條戒律。 ? 勇氣 。 極限編程 總是從一個(gè)簡(jiǎn)單的系統(tǒng)入手，并且只創(chuàng)建今 天，而不是明天可能，需要的功能模塊。 ? 簡(jiǎn)單 。反饋也和交流密切相關(guān)，客戶的實(shí)際使用、功能測(cè)試、單元測(cè)試等都能為開(kāi)發(fā)團(tuán)隊(duì)提供反饋信息。 ? 反饋 。團(tuán)隊(duì)成員不是通過(guò)文檔來(lái)交流，文檔不是必須的。 像所有其 他敏捷方法一樣，極限編程預(yù)期并積極接受變化。這種方式是傳統(tǒng)的同行審查（ peer review）的一種極端表現(xiàn)，或者可以說(shuō)是它的替代方式。比如，為了能及時(shí)得到用戶的反饋，極限編程要求客戶代表必須每天都與開(kāi)發(fā)團(tuán)隊(duì)在一起。 主要的敏捷方法 極限編程（ eXtreme Prgramming） 極限 編程（ eXtreme Prgramming）的主要目的是降低需求變化的成本。敏捷要求團(tuán)隊(duì)成員必須積極主動(dòng)、自我管理。 ? 高效的自組織團(tuán)隊(duì) 。 ? 豐厚的投資回報(bào)率（ ROI） 。 敏捷團(tuán)隊(duì)只專注于開(kāi)發(fā)項(xiàng)目中當(dāng)前最需要的、最具價(jià)值的部分。因?yàn)楹芏囝A(yù)先的 計(jì)劃的東西都會(huì)發(fā)生改變，大而全的前期計(jì)劃通常是徒勞的。 ? 更快的將產(chǎn)品推向市場(chǎng) 。敏捷提倡使用測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（ testdriven development），即在正式開(kāi)發(fā) 功能代碼之前，先開(kāi)發(fā)該功能的測(cè)試代碼。 ? 更高的質(zhì)量。然而當(dāng)項(xiàng)目完成時(shí)，用戶通常會(huì)發(fā)現(xiàn)終點(diǎn)已經(jīng)不是他們真正的目的地。 它將帶給用戶其真正需要的軟件系統(tǒng)。每次迭代周期應(yīng)盡可能短，以便能及時(shí)頻繁地處 理需求變化和用戶反饋。 基于這些共同點(diǎn)，敏捷提出了不同于傳統(tǒng)方式的做法： ? 敏捷方法主要通過(guò)迭代過(guò)程來(lái)應(yīng)對(duì)需求和技術(shù)的變化。 ? 在互聯(lián)網(wǎng)時(shí)代，許多 Web 應(yīng)用程序的開(kāi)發(fā)都是基于對(duì)未來(lái)客戶的預(yù)期，而非當(dāng)前用戶的實(shí)際需求。 ? 外部環(huán)境如客戶的業(yè)務(wù)模式，技 術(shù)進(jìn)步，甚至是系統(tǒng)的終端用戶都有可能在開(kāi)發(fā)過(guò)程中不斷改變。 ? 對(duì)于某些項(xiàng)目，我們可以在一開(kāi)始很好地定義其所有的功能需求，但很多細(xì)節(jié)也許只能隨著項(xiàng)目進(jìn)度不斷深入才能被挖掘出來(lái)。而事實(shí)上，多數(shù)軟件項(xiàng)目都具有以下一些共同點(diǎn)： ? 在初始階段，最終用戶通常并不確切了解自身需要什么樣的軟件。 ? 2020 年，英國(guó)電信（ BT）宣稱全面推廣敏捷方法，規(guī)模達(dá)千人，標(biāo)志著大規(guī)模敏捷應(yīng)用逐漸被接受和認(rèn)可 ? 2020 年至今， Google、 Microsoft、 IBM、 Yahoo、 Amazon、諾基亞、愛(ài)立信等公司在大規(guī)模軟件開(kāi)發(fā)中開(kāi)始應(yīng)用敏捷，掀起敏捷應(yīng)用熱潮 我國(guó)關(guān)于敏捷發(fā)展的一些主要事件： ? 2020 年在中國(guó)軟件行業(yè)協(xié)會(huì)支持下，由國(guó)內(nèi) SPIN 社區(qū)組織翻譯，人民郵電出版社出版了國(guó)內(nèi)第一套敏捷書(shū)籍極限編程系列，是國(guó)內(nèi)大規(guī)模敏捷知識(shí)傳播的開(kāi)始 ? 2020 年，在中國(guó)軟件行業(yè)協(xié)會(huì)支持下，由 SPIN 社區(qū)主辦，國(guó)內(nèi)第一場(chǎng)敏捷沙龍研討會(huì)在北京嘉里中心召開(kāi) ? 2020 年， ThoughtWorks 創(chuàng)建并主辦第一屆敏捷中國(guó)大會(huì)，敏捷知識(shí)傳播以更大規(guī)模開(kāi)展 10 ? 2020 年，上海第一屆 Scrum 大會(huì)成功舉辦，標(biāo)志著國(guó)內(nèi) Scrum 方法廣泛傳播的開(kāi)始 敏捷的優(yōu)勢(shì) 為什么瀑布模式多數(shù)情況下總會(huì)失??？為什么我們需要敏捷開(kāi)發(fā)模式？這個(gè)問(wèn)題在社會(huì)和技術(shù)日新月異飛速發(fā)展的今天似乎很容 易解釋。這套價(jià)值觀 ，通過(guò)一份簡(jiǎn)明扼要的《敏捷宣言》，傳遞給世界，宣告了敏捷開(kāi)發(fā)運(yùn)動(dòng)的開(kāi)始。 2020 年 2 月 11 日到 13日， 17 位軟件開(kāi)發(fā)領(lǐng)域的領(lǐng)軍人物聚集在美國(guó)猶他州的滑雪勝地雪鳥(niǎo)（ Snowbird）雪場(chǎng)。 Rational 統(tǒng)一開(kāi)