【正文】 12. Paulk, 2020. M. Paulk, Extreme programming from a CMM perspective. IEEE Software 18 6 (2020), pp. 1– 8. 13. Boehm, B. and R. Turner (2020). Using Risk to Balance agile and Plan Driven Methods. Computer, IEEE Computer Society. 14. Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum, CMMI174。 7. 倡議 — 借助敏捷運(yùn)動(dòng)，培育中國(guó)軟件業(yè)“豐田生產(chǎn)模式” 基于報(bào) 告調(diào)研，提出如下倡議： 業(yè)界 高度 重視敏捷給企業(yè)所帶來的價(jià)值； 借助敏捷運(yùn)動(dòng)的聲勢(shì)，提煉適合中國(guó)企業(yè)的敏捷軟件開發(fā)實(shí)踐，如同當(dāng)年 “ 豐田生產(chǎn)方式 ” 助力日本汽車業(yè)崛起一樣，逐步培育中國(guó)軟件業(yè)的 “ 豐田生產(chǎn)方式 ” 。 另一方面，軟件過程改進(jìn)的成效、過程能力的提高往往取決于所有干系人 （包括客戶、管理者和開發(fā)者）的思想認(rèn)識(shí)和觀念的契合程度。 敏捷的價(jià)值觀和原則雖然加起來只有幾百字，但是這套理論體系涉及到的面非常廣泛， 涉及到了商業(yè)目標(biāo)、客戶溝通、團(tuán)隊(duì)溝通、需求管理、開發(fā)方法、 團(tuán)隊(duì)建設(shè)、組織文化、 團(tuán)隊(duì) 激勵(lì)、 管理策略 等等 。 6. 敏捷軟件開發(fā)未來展望 縱觀敏捷軟件開發(fā)的發(fā)展歷程， 敏捷方法體現(xiàn)出多樣化，流派紛呈，各顯特色的局面 。隨著國(guó)外的廠商逐步轉(zhuǎn)向敏捷，他們也會(huì)對(duì)其供應(yīng)商有明確的敏捷應(yīng)用的要求。這對(duì)于我國(guó)軟件產(chǎn)業(yè)來說意味著什么呢？ 第一、我國(guó)的本土軟件企業(yè)需要通過敏捷軟件開發(fā)模式所帶來的質(zhì)量和生產(chǎn)力的大幅度提升， 迅速提高民族品牌的國(guó)際競(jìng)爭(zhēng)力。 5. 敏捷軟件開發(fā)對(duì)我國(guó)軟件產(chǎn)業(yè)的意義 敏捷軟件 開發(fā)是我國(guó)軟件產(chǎn)業(yè)趕超國(guó)際發(fā)達(dá)國(guó)家的一次新的發(fā)展契機(jī)，它必將助力我國(guó)軟件業(yè)的騰飛。 ? 推動(dòng)力量還不夠強(qiáng)大。大部分企業(yè)導(dǎo)入敏捷軟件開發(fā)方法的主要?jiǎng)右蚴怯捎谑袌?chǎng)及客戶的要求，還不是直接來自于企業(yè)間成本和效率競(jìng)爭(zhēng)的要求。 30 與國(guó)際上的差距 在調(diào)查中以及來自于行業(yè)中的觀察，目前我國(guó)軟件行業(yè)的 敏捷與國(guó)際上還存在著一定的差距，主要表現(xiàn)在以下幾個(gè)方面： ? 導(dǎo)入面還比較窄，導(dǎo)入程度還不深。 28 8. 敏捷實(shí)施面臨的主要挑戰(zhàn) 缺乏敏捷經(jīng)驗(yàn)和傳統(tǒng)開 發(fā)模式根深蒂固是敏捷實(shí)施以來最主要的挑戰(zhàn)。 27 6. 主要采用敏捷哪種形式 目前的主流方法為 Scrum。 3. 公司目前實(shí)施敏捷的團(tuán)隊(duì)規(guī)模 40%左右的企業(yè)中，實(shí)施敏捷團(tuán)隊(duì)規(guī)模已超過 30個(gè)團(tuán)隊(duì)。參與調(diào)查的企業(yè)包括互聯(lián)網(wǎng)企業(yè)，電信服務(wù)商及產(chǎn)品供應(yīng)商，企業(yè)應(yīng)用提供商，平臺(tái)企業(yè)，以及外包服務(wù)企業(yè)。 4. 國(guó)內(nèi)敏捷發(fā)展現(xiàn)狀 現(xiàn)狀 經(jīng)過近十年的發(fā)展 ，敏捷方法已經(jīng)在我國(guó)的軟件行業(yè)得到了廣泛的傳播和應(yīng)用。 下表顯示了高比例的受訪者對(duì)如下幾個(gè)方面表示認(rèn)同： 提升 顯著提升 管理優(yōu)先級(jí)變化的能力增強(qiáng) 41% 51% 24 項(xiàng)目可見性增強(qiáng) 42% 41% IT人員和商業(yè)人員目標(biāo)的一致性增強(qiáng) 39% 27% 項(xiàng)目風(fēng)險(xiǎn)降低 48% 17% 數(shù)據(jù)表明項(xiàng)目干系人對(duì)敏捷感到滿意主要體現(xiàn)在如下幾個(gè)方面： 敏捷可以更好地使技術(shù)團(tuán)隊(duì)和商業(yè)團(tuán)隊(duì)達(dá)成統(tǒng)一。另外， 84%的受訪者認(rèn)為敏捷降低了 10%甚至更多的軟件缺陷； 30%人認(rèn)為降低了25%甚至更多。大多數(shù)服務(wù)通過一個(gè)很強(qiáng)大的 Web應(yīng)用程序提供。 David Rico的研究證實(shí)了敏捷團(tuán)隊(duì)能制造出高質(zhì)量產(chǎn)品的觀點(diǎn)。 更高的質(zhì)量 如果問一個(gè)敏捷團(tuán)隊(duì)是什么使他們比使用敏捷之前更有效率，大多數(shù)人會(huì)說他們的成功至少部分歸功于他們能不斷地產(chǎn)出高質(zhì)量的工作。通過對(duì)整個(gè)行業(yè)范圍的調(diào)查， VersionOne發(fā)現(xiàn)， 74％的受訪者認(rèn)為士氣得到改善（占 44％）或顯著改善（占 30％）。實(shí)施 Scrum 15個(gè)月之后， ，調(diào)查發(fā)現(xiàn) 86%的員工認(rèn)為在公司工作快樂或者很快樂。該指數(shù)會(huì)考慮到工作量、進(jìn)度、技術(shù)難度等方面。 近幾年來國(guó)外敏捷應(yīng)用發(fā)展呈高速增長(zhǎng)趨勢(shì)， DDJ 的調(diào)查數(shù)據(jù)表明2020 年有約 41%的軟件企業(yè)使用敏捷， 而到 2020 年已經(jīng)有約 69%的軟件企業(yè)使用敏捷。在這種情況下，敏捷被認(rèn)為是最有效的解決 的這些挑戰(zhàn)的新思維與方法。通過適當(dāng)?shù)倪^程體系規(guī)劃，能使兩者在過程目標(biāo)和子過程的具體實(shí)踐層面有機(jī)結(jié)合起來，充分發(fā)揮兩者的優(yōu)點(diǎn)，提升組織的過程改進(jìn)。 2020 年 7 月， Cindy Shelton（ CSM， CSP）在 Scrum Alliance 發(fā)表《 Agile and CMMI: Better Together》， 描述了很多 CMMI 和敏捷對(duì)應(yīng)的實(shí)踐，清楚的展 21 示了 CMMI 和敏捷如何協(xié)同工作。 CMMI 的誤用給敏捷的支持者帶來負(fù)面印象 20 年的經(jīng)歷，先是 CMM，后是 CMMI，在其中有些實(shí)踐有時(shí)被誤用，或者應(yīng)用到（或強(qiáng)用）一些對(duì)于開發(fā)活動(dòng)中，這些活動(dòng)被一些軟件開發(fā)團(tuán)隊(duì)識(shí)別為對(duì)開發(fā)效率沒有幫助 CMMI 方和敏捷方曾經(jīng)都缺少對(duì)方的正確的信息。 CMMI 提供了過程管理和支持的實(shí)踐，這些在任何組織都幫助了敏捷的部署，維護(hù)和持繼提高。到 2020年年底，許多采用 CMMI 的組織已經(jīng)有了敏捷開發(fā)團(tuán)隊(duì)了。 or Agile:Why Not Embrace Both!》的報(bào)告，作者是如下 5位： Hillel Glazer,Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum。 也有人認(rèn)為 CMMI 與敏捷可以結(jié)合使用 2020 年， 發(fā)表《 Extreme programming from a CMM perspective》深入地探討了為何這兩種方法并非絕對(duì)沖突，并闡述了一個(gè)開發(fā)小組如何在遵循極限編程原則的同時(shí)擁抱 CMM 第 三 級(jí)。這也就是為什么 CMM 這種理論體系比較難于執(zhí)行的根本原因。這一系列現(xiàn)已成為全球的軟件質(zhì)量標(biāo)準(zhǔn)。 ISO9000 簡(jiǎn)要回顧 近年來，國(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ó)。雖然這些模型在許多組織都得到了良好的應(yīng)用，但對(duì)于一些大型軟件企業(yè)來說，可能會(huì)出現(xiàn)需要同時(shí)采用多種模型來改進(jìn)自己多方面過程能力的情況。 CMMI 是 CMM 模型的最新版本。 自 2020 年左右引入我國(guó)，經(jīng)過近 8 年的實(shí)施，目前已 經(jīng)有大量 軟件企業(yè) 按照 CMMI 開展過程改進(jìn)。這些方法都是增量和迭代開發(fā)過程，并且重視人多過于整個(gè)過程。其中，容易接觸專家用戶實(shí)際就是敏捷方法中提到的客戶持續(xù)參與，但 Crystal 方法集 對(duì)此要求比較寬松。據(jù)稱這種方法更適合于較小規(guī)模的開發(fā)小組（由 28 個(gè)人組成）和非關(guān)鍵項(xiàng)目。與 DSDM 方式一樣， FDD 仍然會(huì)在項(xiàng)目初期 對(duì)整個(gè)項(xiàng)目做較大的規(guī)劃和建模，以獲得對(duì)該系統(tǒng)的全面了解。它們包括項(xiàng)目前期活 動(dòng)（ preproject activities），項(xiàng)目可行性研究，功能建模，設(shè)計(jì)和開發(fā)，實(shí)施或部署，項(xiàng)目后期維護(hù)（ postproject maintenance），等等。 和其它敏捷方法相比，精益軟件更重要的是不斷完善開發(fā)過程的一種思維方式。精益開發(fā)強(qiáng)調(diào)整體優(yōu)化的系統(tǒng)。激勵(lì)團(tuán)隊(duì)并讓所有團(tuán)隊(duì)成員自我管理始終是所有敏捷方法獲得成功的基本因素之一。這樣可以避免在可能改變的事情 上做無謂的努力，從而有效的避免浪費(fèi)。精益開發(fā)的其它原則包括 : ? 強(qiáng)調(diào)學(xué)習(xí)。 2020 年， Mary Poppendieck和 Tom Poppendieck 的書籍《 Lean Software Development: An Agile Toolkit》出版，這標(biāo)志著精益原則開始用于軟件開發(fā)。調(diào)整工作必須盡快實(shí)施 ， 以減少進(jìn)一步的偏差。當(dāng)規(guī) 15 定的檢驗(yàn)頻率超出了過程檢驗(yàn)所能容許的程度，那么就會(huì)出現(xiàn)問題。 管理生產(chǎn)成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內(nèi)容。在每個(gè)迭代結(jié)束時(shí)， Scrum 團(tuán)隊(duì)將 遞交 潛在可交付的產(chǎn)品增量。在 Scrum 中，使用產(chǎn)品 Backlog來管理產(chǎn)品的需求，產(chǎn)品 backlog 是一個(gè)按照商業(yè)價(jià)值排序的需求列表，列表?xiàng)l目的體現(xiàn)形式通常為用戶故事。因此，每個(gè)人的代碼質(zhì)量必須過關(guān)。極限編程提倡團(tuán)隊(duì)合作，相互尊重。這意味著重新審查現(xiàn)有系統(tǒng)并完善它會(huì)使得以后出現(xiàn)的變化需求更容易被實(shí)現(xiàn)。 極限編程理論中的 “ 系統(tǒng)開發(fā)中的勇氣 ” 最好用一組實(shí)踐來詮釋。極限編程提倡簡(jiǎn)單的設(shè)計(jì)，簡(jiǎn)單的解決方案。反饋是一種信息的交流，能使系統(tǒng)更加完善。它具有以下的價(jià)值觀或原則： ? 互動(dòng)交流 。同時(shí)，極限編程推薦采用結(jié)對(duì)編程（ pairprogramming）的方式。在這樣的團(tuán)隊(duì)中工作，每個(gè)團(tuán)隊(duì)成員的技術(shù)、交流、社交、表達(dá)和領(lǐng)導(dǎo)能力也都能得以提高。在敏捷開發(fā)過程中，最具價(jià)值的功能總是優(yōu)先被開發(fā)，這樣能給客戶帶來最大的投資回報(bào)率。敏捷提倡逐步完善的計(jì)劃。這為敏捷項(xiàng)目的整個(gè)開發(fā)周期提供了可靠的質(zhì)量保證。而敏捷方法則采用小步的方式前行，每走完一步，都需要及時(shí)調(diào)整并確定下一步的方向，直到抵達(dá)真正的終點(diǎn)。 采用敏捷開發(fā)方式將會(huì)給企業(yè)和用戶帶來諸多好處： 11 ? 交付用戶需要的軟件。在這種情況下，需求從一開始就在變，而且在系統(tǒng)投入使用后幾乎每天都會(huì)延續(xù)。即便是我們了解了所有的細(xì)節(jié)，大多數(shù)人還是不能很好地處理這些細(xì)節(jié)，特別是在項(xiàng)目開發(fā)初期。盡管瀑布式的優(yōu)勢(shì)是在項(xiàng)目的確定性很高的時(shí)候，能夠早期進(jìn)行合理的計(jì)劃和預(yù)算，但是，在如何管理需求變化面前，瀑布模式卻顯得無能為力。經(jīng)過兩天的討論， “ 敏捷 ” 這個(gè)詞為全體聚會(huì)者所接受，用以概括一套全新的軟件開發(fā)價(jià)值觀。在經(jīng)歷了多次有“瀑布心態(tài)”（ ‘waterfall mentality’ ）項(xiàng)目的失敗之后，美國(guó)國(guó)防部開始“要求”而不是像 80 年代那樣僅僅是“建議”他們的軟件開發(fā)商使用IID 開發(fā)模式。美國(guó)國(guó)防部一直以來都要求其軟件開發(fā)商在開發(fā)過程中使用嚴(yán)格的瀑布開發(fā)模型。敏捷的一些典型做法，如使用八周迭代以及用反饋循序漸進(jìn)推動(dòng)開發(fā)等都在該項(xiàng)目中得以應(yīng)用。迭代和增量開發(fā)從此開始穩(wěn)步發(fā)展，越來越多的項(xiàng)目開始使用這種開發(fā)模式。一些研究人員甚至在關(guān)于瀑布開發(fā)模式的最早的論 文中發(fā)現(xiàn)了敏捷開發(fā)的線索。但是，實(shí)際上敏捷方法，特別是迭代和增量開發(fā)方法（ IID）起源于 20世紀(jì) 30 年代的一些非軟件項(xiàng)目。 11. 最佳的架構(gòu)、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)。項(xiàng)目方、開發(fā)人員和用戶應(yīng)該能夠保持持續(xù)穩(wěn)定的進(jìn)展速度。 5. 要善于激勵(lì)項(xiàng)目人員，給他們以所需要的環(huán)境和支持，并相信他們能夠完成任務(wù)。 2. 歡迎對(duì)需求提出變更 —— 即使是在項(xiàng)目開發(fā)后期。這些價(jià)值觀和原則由 17 位軟件開發(fā)領(lǐng)域的領(lǐng)軍人物在 2020 年通過《敏捷宣言》傳遞給世界，也在那個(gè)時(shí)候宣告了全球敏捷開發(fā)運(yùn)動(dòng)的開始。敏捷方法給這些企業(yè)也已帶來了巨大的收益。它不僅被許多中小公司青睞，在全球一百強(qiáng)的企業(yè)中，敏捷也已大行其道，受到許多資深項(xiàng)目管理者和開發(fā)人員的推崇。 為此，中國(guó)軟件行業(yè)