【文章內(nèi)容簡(jiǎn)介】 責(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è)界公布。 目前 Scrum 是應(yīng)用最為廣泛的敏捷方法之一 SCRUM 理論基礎(chǔ) Scrum 是以經(jīng)驗(yàn)過(guò)程控制理論作為理論基礎(chǔ)，通過(guò)迭代、增量的方法來(lái)增強(qiáng)產(chǎn)品開(kāi)發(fā)的可預(yù)見(jiàn)性，并控制風(fēng)險(xiǎn)。 Scrum 經(jīng)驗(yàn)過(guò)程控制理論的實(shí)施由三大支柱支撐： 第一：透明 性 （ Transparency） 透明 度是指，在軟件開(kāi)發(fā)過(guò)程的各個(gè)環(huán)節(jié)保持高度的可見(jiàn)性，影響交付成果的各個(gè)方面對(duì)于參與交付的所有人、管理生產(chǎn)結(jié)果的人保持透明。 管理生產(chǎn)成果的人不僅要能夠看到過(guò)程的這些方面，而且必須理解他們看到的內(nèi)容。也就是說(shuō)，當(dāng)某個(gè)人在檢驗(yàn)一個(gè)過(guò)程，并確信某一個(gè)任務(wù)已經(jīng)完成時(shí)，這個(gè)完成必須等同于他們對(duì)完成 的 定義。 第二：檢驗(yàn)（ Inspection） 開(kāi)發(fā)過(guò)程中的各方面必須做到足夠頻繁地檢驗(yàn)，確保能夠及時(shí)發(fā)現(xiàn)過(guò)程中的重大偏差。在確定檢驗(yàn)頻率 時(shí)，需要考慮到檢驗(yàn)會(huì)引起所有過(guò)程發(fā)生變化。當(dāng)規(guī) 15 定的檢驗(yàn)頻率超出了過(guò)程檢驗(yàn)所能容許的程度，那么就會(huì)出現(xiàn)問(wèn)題。幸運(yùn)的是，軟件開(kāi)發(fā)并不會(huì)出現(xiàn)這種情況。另一個(gè)因素就是檢驗(yàn)工作成果人員的技能水平和積極性。 第三：適應(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)整。調(diào)整工作必須盡快實(shí)施 ， 以減少進(jìn)一步的偏差。 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è)。 精益軟件開(kāi)發(fā)（ Lean Software Development） 精益思想源自豐田公司的產(chǎn)品開(kāi)發(fā)方法。 它主要包括兩個(gè)部分：一部分是核心思想及原則，另外一部分由一些在相應(yīng)的工具構(gòu)成。 2020 年， Mary Poppendieck和 Tom Poppendieck 的書(shū)籍《 Lean Software Development: An Agile Toolkit》出版，這標(biāo)志著精益原則開(kāi)始用于軟件開(kāi)發(fā)。 精益思想的核心思想是查明和消除浪費(fèi)。在軟件開(kāi)發(fā)過(guò)程中，錯(cuò)誤（ bugs），沒(méi)用的功能，等待以及其他任何對(duì)實(shí)現(xiàn)結(jié)果沒(méi)有益處的東西都是浪費(fèi)。浪費(fèi)及其源頭必須被分析查明，然后設(shè)法消除。精益開(kāi)發(fā)的其它原則包括 : ? 強(qiáng)調(diào)學(xué)習(xí)。軟件開(kāi)發(fā)過(guò)程是一個(gè)不斷學(xué)習(xí)的過(guò)程。每個(gè)團(tuán)隊(duì)成員都需要從日常的失敗，互動(dòng)，交流以及信息反饋中學(xué)習(xí)，不斷改進(jìn)所開(kāi)發(fā)的產(chǎn)品和開(kāi)發(fā)效率。 ? 在最后時(shí)刻做決定。這樣可以避免在可能改變的事情 上做無(wú)謂的努力，從而有效的避免浪費(fèi)。 ? 用最快的速度交付用戶。較短的迭代周期能夠加速產(chǎn)品的開(kāi)發(fā)及交付，加快交流，提高生產(chǎn)力。 16 ? 給團(tuán)隊(duì)自主權(quán)。激勵(lì)團(tuán)隊(duì)并讓所有團(tuán)隊(duì)成員自我管理始終是所有敏捷方法獲得成功的基本因素之一。 ? 誠(chéng)信。確保整個(gè)系統(tǒng)正常工作，真正滿足客戶的需求是整個(gè)團(tuán)隊(duì)需要努力堅(jiān)持的誠(chéng)信和和對(duì)用戶的承諾。 ? 全局觀。精益開(kāi)發(fā)強(qiáng)調(diào)整體優(yōu)化的系統(tǒng)。無(wú)論開(kāi)發(fā)的組織還是被開(kāi)發(fā)的產(chǎn)品， 從整體上考慮優(yōu)化比從各個(gè)局部去優(yōu)化更高效。 對(duì)于上述的每個(gè)原則，都有一些相應(yīng)的實(shí)現(xiàn)工具。這些工具包括價(jià)值流圖（ Value Stream Mapping），基于集合的開(kāi)發(fā)（ setbased development），拉系統(tǒng)（ pull system），排隊(duì)論（ queuing theory），等等。 和其它敏捷方法相比，精益軟件更重要的是不斷完善開(kāi)發(fā)過(guò)程的一種思維方式。因此，將精益模式與其他敏捷開(kāi)發(fā)模式一起使用將會(huì)取得很好的效果。 其它敏捷方法 動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)方法（ DSDM）是由快速應(yīng)用程序開(kāi)發(fā)（ RAD）方法演變而來(lái)的敏捷開(kāi)發(fā)模式。 DSDM 在普遍的敏捷價(jià)值和原則的基礎(chǔ)上，定義了更加詳細(xì)的流程，以涵蓋更完整的項(xiàng)目生命周期。它們包括項(xiàng)目前期活 動(dòng)（ preproject activities），項(xiàng)目可行性研究，功能建模，設(shè)計(jì)和開(kāi)發(fā)，實(shí)施或部署，項(xiàng)目后期維護(hù)（ postproject maintenance），等等。同時(shí)，每個(gè)過(guò)程都定義了諸如如何將每個(gè)功能模型轉(zhuǎn)化為實(shí)際代碼，如何將原型交付最終用戶使用并審查，如何處理反饋信息等的詳細(xì)步驟。因此， DSDM 相比于其它敏捷方法在過(guò)程上顯得比較繁重。 特性驅(qū)動(dòng)開(kāi)發(fā)（ FDD）是將用戶的功能需求劃分成更小的功能特征，然后逐步地在每個(gè)迭代周期中開(kāi)發(fā)實(shí)現(xiàn)這些產(chǎn)品特征。與 DSDM 方式一樣， FDD 仍然會(huì)在項(xiàng)目初期 對(duì)整個(gè)項(xiàng)目做較大的規(guī)劃和建模，以獲得對(duì)該系統(tǒng)的全面了解。但是相比 DSDM 來(lái)說(shuō)， FDD 在這些方面簡(jiǎn)捷了一些。 Crystal 方法集 更專注于人。相比于其他的敏捷方法，它可使人獲得更大的解放。據(jù)稱這種方法更適合于較小規(guī)模的開(kāi)發(fā)小組（由 28 個(gè)人組成）和非關(guān)鍵項(xiàng)目。 Crystal 方法集 定義了七種屬性。前 3 個(gè)屬性 頻繁的交付（ frequent delivery），滲透交流（ osmotic munication），反思提高（ reflective 17 improvement） 反映出基本的敏捷開(kāi)發(fā)做法和價(jià)值 ，如周期較短的迭代式開(kāi)發(fā)，自我管理的開(kāi)發(fā)團(tuán)隊(duì)和反饋帶動(dòng)增量發(fā)展等等。另外的 4 個(gè)屬性分別是：個(gè)人安全（ personal safety），集中（ focus），容易接觸專家用戶（ easy access to expert users）和技術(shù)環(huán)境（ technical environment）。其中，容易接觸專家用戶實(shí)際就是敏捷方法中提到的客戶持續(xù)參與，但 Crystal 方法集 對(duì)此要求比較寬松。Crystal 方法集 也提供了一些通用的做法，比如，它提供了三種回顧分析的方法：訪談，問(wèn)卷調(diào)查和工作組。 Crystal 方法集 的過(guò)程也是相當(dāng)簡(jiǎn)單，其中涉及短的迭代周期，日常會(huì)議及持續(xù)集成等。 還有其他一些敏捷方法如敏捷統(tǒng)一過(guò)程（ Agile Unified Process），上下文驅(qū)動(dòng)開(kāi)發(fā)（ Context Driven Development）， Getting Real 等。這些方法都是增量和迭代開(kāi)發(fā)過(guò)程，并且重視人多過(guò)于整個(gè)過(guò)程。而各種敏捷方法的區(qū)別在于它們對(duì)敏捷的不同闡釋和不同側(cè)重。理解這些方法可以幫助我們從多個(gè)角度理解敏捷開(kāi)發(fā)，并且了解更多的最佳應(yīng)用。 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。 自 2020 年左右引入我國(guó)，經(jīng)過(guò)近 8 年的實(shí)施，目前已 經(jīng)有大量 軟件企業(yè) 按照 CMMI 開(kāi)展過(guò)程改進(jìn)。 截止到 2020 年 5 月，國(guó)內(nèi)已有 48 家軟件企業(yè)達(dá)到 CMMI 5 級(jí)，全球 349 家組織通過(guò) CMMI5。 近年來(lái)，隨著敏捷軟件開(kāi)發(fā)（ Agile Software Development， ASD）在國(guó)內(nèi)外大行其道， CMMI 模型是否兼容敏捷， ASD 是否滿 足 CMMI 實(shí)施 /評(píng)估要求等問(wèn)題，在業(yè)界一直是有爭(zhēng)論，備受人們關(guān)注。 CMMI 簡(jiǎn)要回顧 CMMI 的全稱為： Capability Maturity Model Integration，即能力成熟度模型集成。 CMMI 是 CMM 模型的最新版本。早期的 CMMI（ CMMISE/SW/IPPD） 版本是應(yīng)用于軟件業(yè)項(xiàng)目的管理方法， SEI 在部分國(guó)家和地區(qū)開(kāi)始推廣和試用。 18 隨著應(yīng)用的推廣與模型本身的發(fā)展，演繹成為一種被廣泛應(yīng)用的綜合性模型。 自從 1994 年 SEI 正式發(fā)布軟件 CMM 以來(lái)，相繼又開(kāi)發(fā)出了系統(tǒng)工程、軟件 采購(gòu)、人力資源管理以及集成產(chǎn)品和過(guò)程開(kāi)發(fā)方面的多個(gè)能力成熟度模型。雖然這些模型在許多組織都得到了良好的應(yīng)用，但對(duì)于一些大型軟件企業(yè)來(lái)說(shuō)，可能會(huì)出現(xiàn)需要同時(shí)采用多種模型來(lái)改進(jìn)自己多方面過(guò)程能力的情況。 CMMI 為組織提供了實(shí)現(xiàn)高效的 軟件交付 過(guò)程所需 要 的基本元素 ，關(guān)注于通過(guò)切實(shí)改進(jìn)過(guò)程域的成熟度，實(shí)現(xiàn)過(guò)程改進(jìn)的目標(biāo)。 它可以用來(lái)指導(dǎo)一個(gè)項(xiàng)目、一個(gè)部門(mén)甚至整個(gè)組織的過(guò)程改進(jì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)。 ISO9000 簡(jiǎn)要回顧 近年來(lái)，國(guó)際上影響最為深遠(yuǎn)的質(zhì)量管理標(biāo)準(zhǔn)當(dāng)屬國(guó)際標(biāo)準(zhǔn)化組織于 1987年公布的 ISO9000 系列標(biāo)準(zhǔn)，這一國(guó)際標(biāo)準(zhǔn)發(fā)源于歐洲經(jīng)濟(jì)共同體，但很快就波及美國(guó)、日本及世界各國(guó)。到目前為止，已有 70 多個(gè)國(guó)家在它們的企業(yè)中采用和實(shí)施這一系列標(biāo)準(zhǔn)。我國(guó)對(duì)此也十分重視，也采取了積極態(tài)度。 近期，國(guó)際標(biāo)準(zhǔn)化組織 積極促進(jìn)軟件質(zhì)量的制度化，提出了如下 ISO9000 軟件標(biāo)準(zhǔn)系列：ISO900 ISO9000 ISO9004 ISO9004 ISO9002。這一系列現(xiàn)已成為全球的軟件質(zhì)量標(biāo)準(zhǔn)。 目前 業(yè)界對(duì)于 ISO 和敏捷的關(guān)系和爭(zhēng)議較少，因此本文不再討論，重點(diǎn)分析敏捷和 CMMI 的關(guān)系。 有人認(rèn)為 CMMI 和敏捷是存在矛盾的 站在部分 CMMI 擁護(hù)者的角度看 敏捷 ，他們認(rèn)為，兩者的差距如下： CMMI 敏捷 √ 成體系的過(guò)程方法和最佳實(shí)踐集 零碎的實(shí)踐 √ 文檔化的可重復(fù)的過(guò)程 靠個(gè)人和團(tuán)隊(duì)能力維系過(guò)程和項(xiàng)目的成敗 √ 量化控制 缺乏必要的度量 √ 完善的監(jiān)控體系 缺乏過(guò)程透明度 19 √ 支持多特征的項(xiàng)目管理 僅適用于小型項(xiàng)目 同 時(shí)，一些敏捷 的擁護(hù)者對(duì) CMMI 這樣的 重量級(jí) 過(guò)程也有著種 種意見(jiàn)，他們認(rèn)為： 敏捷 CMMI √ 輕量級(jí)的過(guò)程 重量級(jí)的過(guò)程 √ 以客戶為導(dǎo)向 計(jì)劃驅(qū)動(dòng)， 客戶反饋?lái)憫?yīng)周期長(zhǎng) √ 逐步完善的計(jì)劃，及時(shí)響應(yīng)變更 線性控制， 變更成本高 √ 自律，高效 流程代價(jià)較高 √ 持續(xù)交付可用軟件 強(qiáng)調(diào)過(guò)程規(guī)范性 √ 團(tuán)隊(duì)自組織 命令與控制 有人認(rèn)為兩者的理論基礎(chǔ)是不同的，很難把基于兩種不同模型的方法論硬揉在一起。 CMMI 的理論基礎(chǔ)是一種 預(yù)定義