敏捷成熟度評估模型-AMM評估管理實踐與技術實踐

 

管理實踐AgileMaturity Model

實踐一：SharedResponsibility–職責共享

Theme	Level	State Description	Reference Implementations
	3+	組織級結對 Organizational Pairing	與業務人員實時結對；跨團隊協作 Real time pairing with the business; cross-team collaboration
	3	跨域結對 Cross-Discipline Pairing	跨角色結對以實現需求 Cross-role pairing on requirements execution
	2	有管理的結對 Pairing is Managed	使用結對階梯表以確保結對被經常輪換，整個團隊以結對方式工作 Pair stairs are used to ensure rotation; pair teams sign up for requirement execution
	1	鼓勵結對 Pairing is Encouraged	有機會結對並且結對是受鼓勵的 Opportunities to pair are identified and encouraged
	0	不受限訪問 Unencumbered Access	開發人員可以不受限制地訪問開發產物 Developers have unrestricted access to change development artifacts
	-1	制度化，專業化 Institutionalized Specialization	開發人員角色固定並且能力受限 Developers are in specified roles with limited ability to make changes

• 評估指引：

• -1：高度制度化下的分工體系，每人負責一塊，並只對這塊負責

• 0：員工只對自己團隊的工作負責，但可訪問其他團隊代碼

• 1：員工依然負責自己東西，但鼓勵適當的跨團隊結對開發

• 2：團隊成員因內部團隊間協作需要開展有管理的跨團隊水平結對開發，內部團隊責任界限不構成障礙

• 3：不同角色的垂直結對開發，進一步擴大跨團隊職責共享，角色界限模糊

• 3+：不同項目，不同組織的互相串通開發，組織級團隊職責共享

• 注：不同組織：跨產品線、部門

• • 垂直結對，是指需求、設計、開發、測試等上下游角色之間的結對

  • 水平結對，是指需求角色之間、設計角色之間、開發角色之間、測試角色之間的結對

實踐二：Requirements–需求

Theme	Level	State Description	Reference Implementations
	3+	獨立 Independent	需求描述了交付團隊需要完成的事項，是獨立的，可執行的。估計和協商的方式可以改變。
	3	可協商 Negotiable	需求是關注業務的，是在與業務人員溝通時獲取的，而不是從正式的文檔或流程提取的。並且需求是可以協商的。
	2	增量價值，可測試	敏捷故事：需求是業務價值的體現，而不是待完成的技術任務。
	1	短小，可估計 Short, estimable	需求會被進一步分解成可互相依賴的任務（技術需求）以提高估計的準確性。
	0	概要，模糊，業務導向的表達	需求過大，表述概括。估計不準確，需求描述過於概括導致難以協商
	-1	詳細的，高度耦合	冗長的用例，缺乏完整背景的大段描述

• 評估指引：

• -1：缺乏完整背景的大段描述需求

• 0：需求的描述比較模糊，概況而難以協商討論

• 1：有相對詳細的步驟、任務來描述需求

• 2：各內部團隊接受的需求是獨立的，可被拆成若干可實現的動作/任務。建立穩定的跨團隊/角色的協作流程。

• 3：建立面向用戶價值的高效需求開發和管理過程

• 3+：自發的與業務討論出來的需求，而不是單純從文檔出來的需求

實踐三：Responsiveness–快速響應

Theme	Level	State Description	Reference Implementations
	3+	持續變更管理	流暢的變更決策 實現軟件產品的持續交付 用戶需求得到及時有效的響應，用戶高度滿意
	3	持續業務參與	業務人員積極參與交付的每個階段 用戶代表能夠積極協調研發團隊、市場和用戶的業務關係，用戶滿意度較高
	2	迭代變更管理	新特性和優先級可在每個迭代調整
	1	短交付週期	新特性和優先級可在每次發佈調整
	0	應激式變更控制，風格不統一	非正式的變更控制
	-1	缺乏靈活性，長交付週期	極爲正式的變更控制。變更控制導致或反映了對變更的抵抗。規範是凍結的。

• 評估指引：

• -1：長交付週期，計劃一定就不好修改，市場和研發極少溝通，處於割裂狀態

• 0：應激式變更控制，已有變化就倉促應對，調整計劃。團隊可以接受市場反饋，但反饋滯後，缺乏有效管理，交付具有不確定性

• 1：短交付週期，將變化控制在一個短週期內，建立市場反饋的有效管理，有基本可信的交付承諾

• 2：迭代變更管理，將變化控制在一個迭代，建立起用戶基本滿意的溝通和交付機制

• 3：業務人員參與到迭代中，掌握市場和研發兩邊情況，調整變更優先級，積極協調研發、市場和用戶的業務關係，用戶滿意度較高

• 3+：持續變更管理，將變更變成常態，成爲可規劃可管理的流暢過程。用戶需求得到及時有效的響應，甚至引領用戶需求，用戶滿意度高

實踐四：ProjectManagement–項目管理

Theme	Level	State Description	Reference Implementations
流暢的計劃內和計劃外風險管理	3+	項目管理最大程度支持業務	存在統一機制以報告項目是否滿足業務需求
	3	自適應項目管理	項目計劃是有業務人員參與的協作過程，每個迭代都會進行並可能得到更新。項目計劃能夠指明當前期望在哪個迭代交付哪些業務功能。
計劃內和計劃外風險在決策視角內得到關注	2	項目狀態報告反映項目路徑？	項目狀態報告反映了項目路徑，在業務層面傳達目前爲止已交付的功能
	1	決策視角是迭代長度	決策視角是一個較短的時間窗，通常不超過3個星期。需求以能在此時間窗內完成的方式表達
應激式風險應對（對執行的關注勝過風險意識）	0	決策視角是發佈長度	決策視角是一個較短的時間窗，通常不超過3個月。需求以能在此時間窗內完成的方式表達
計劃內風險受管理，不容許計劃外風險	-1	固定的項目計劃，決策視角是項目長度	項目時間表作爲計劃，決策視角是項目長度，有可能幾年。項目狀態是以執行與計劃的匹配程度來報告的。

• 評估指引：

• -1：非常固定的項目計劃，時間長，只關注計劃內風險

• 0：通常可以3個月爲單位知道項目進度，並制定基本的風險管理對策

• 1：通常在3~4周內知道項目進度，並制定風險管理對策

• 2：可快速根據項目報告得到項目具體進度，建立基本的可視化項目管理視圖（如燃起圖）

• 3：隨時可得到項目進度狀況，建立成熟的可視化項目管理（所有角色能夠成熟地使用）

• 3+：隨時知道項目進度是否滿足業務需求，持續交付

• 注：

• • 敏捷項目管理以估算爲基礎，以客戶合作爲重要保障

  • 對項目的關鍵要素S（需求）、Q（質量）、R（成本）、T（時間）進行細分的、量化、可視化管理

  • 風險是指所有SQRT相關的可能影響項目輸出的不確定因素，風險管理質量是敏捷項目管理成熟度的重要參考

實踐五：Communication–溝通

Theme	Level	State Description	Reference Implementations
系統性溝通	3+	企業級協作	與業務相關的活動對團隊無侵入性；業務和開發組成統一團隊
流暢溝通	3	協作執行	跨角色結對
溝通自動化	2	協作基礎設施	面向所有涉衆的交流（主動的、被動的）均有工具支持
結構化溝通體系	1	協作式專題討論	有結構化、有規律的溝通和會議支持協作
雙向溝通	0	定期會議	定期（通常是每週）小組會議以供團隊成員討論
單向溝通	-1	單向溝通	管理層向團隊通報進度 不定期小組會議 各執一詞的吵架會議

• 評估指引：

• -1：管理通報進度，佈置任務，下級無反饋和溝通

• 0：定期項目級會議討論團隊間協作問題

• 1：團隊間定期討論+專題討論，但因人員工作地點、積極性、會議資源等問題使得會議成本和效率有待改進

• 2：高質量的會議資源支持團隊間頻繁溝通，比如：視頻會議，基本無客觀環境因素限制溝通質量和效率

• 3：團隊不同角色結對，由團隊成員自發形成

• 3+：組織型結對

實踐六：SelfOrganization–自組織能力

Theme	Level	State Description	Reference Implementations
強化原則，弱化規則	3+	鞏固	與業務成果掛鉤
	3	平衡	連通各個維度
	2	操作	項目團隊充分理解敏捷價值觀和實踐原則，並在部分項目級工作中得到有效遵循，以減少浪費 項目級團隊有意識地減少或避免管理規範和要求對團隊的侵入和干擾 研發活動、文檔、度量、會議等得到簡化或自動化，例如：自動收集的度量數據和指標，減少方所的手工收集和報告 記錄、獎懲、考覈、學習和分享等工作逐步由團隊自主制定和執行
	1	初始	項目工作開始接受敏捷實踐原則，各團隊根據自身情況反饋對項目的工作訴求，並可能獲得支持 項目團隊制定的工作要求得到各成員認可和支持的，以保證項目交付的質量和效率
缺乏明確的規則或原則	0	應激性的	項目層面工作無規範，團隊間沒有共同認可的紀律，經常因爲工作混亂導致項目工作無法預測
規定的，基於規則的	-1	文過飾非	項目內各項工作表現爲重量級的，障礙性的，便於出錯時好有藉口

• 評估指引：

• 關注敏捷價值觀和原則如何應用到敏捷團隊工作中

• • 任何一項團隊工作（決策準則）都表現爲規範性和原則性之間的平衡，這種平衡體現出團隊自組織能力的成熟度

  • 可考察團隊工作的任何領域，研發活動、文檔、度量、獎懲、考覈等

  • 自組織能力的目標是發揮團隊和成員的創造性，提升團隊凝聚力，建立積極向上的敏捷研發文化

• -1：基於重量級文檔、規程、檢查單等規範性工作產品，作爲驗證、追責標準

• 0：應激性管理

• 1：主要由領隊決定，團隊成員意見可供參考

• 2：在部分領域，團隊基於對活動的價值分析進行決策。領隊提供支持，必要時進行決策。最大限度降低相關活動對團隊工作的侵入和浪費。

• 3：幾乎在所有領域，團隊都能夠正確地運用敏捷價值觀和原則進行價值分析和決策，及時回顧和修正團隊決策

• 3+：端到端的雙向追蹤：實現從市場需求到產品交付全流程的自組織團隊管理

• 注：即使到3+，團隊工作的規範也是需求的，關鍵是規範的產生和執行是否符合敏捷價值觀。

技術實踐AgileMaturity Model

實踐七：Build–軟件構建

Theme	Level	State Description	Reference Implementations
	3+	External Gatekeeper 對外防禦	Functional testing tools (Watir, Selenium, Marathon Man) are integrated as gatekeeper events to the build. Integration tests with external tools and products. 在構建過程中集成功能測試工具，並將其作爲構建成功的條件。對與外部工具和產品的集成進行測試。
	3	Internal Gatekeeper 對內防禦	Unit tests and code characteristics are implemented as gatekeeper events that will prevent a build from completing. 在構建過程中集成單元測試和代碼特徵檢查，並將其作爲構建成功的條件。
	2	Constant 頻繁執行	Build velocity is maximized - that is, build is happening with the maximum frequency. State of the build the responsibility of the team. 建立良好的項目團隊構建紀律並得到團隊的認同和認真執行。 儘快構建即保持最高的構建頻率。整個團隊對構建狀態負責。
	1	Repeating 重複執行	Build is repeatable and automated, but doesn‘t happen with maximum frequency as permitted by the technology. State of the build is a responsibility of the team. 構建過程是自動化的、可重複的，但受限於技術原因不能保持最高的構建頻率：整個團隊對構建狀態負責。
	0	Repeatable 具備重複執行能力	Build process is repeatable and static, but still likely performed manually and infrequently; the build may be owned by a specific member of the team. 構建流程是可重複的，但並不活躍，往往手動觸發，而且頻率較低。構建由團隊中某個特定的成員負責。
	-1	Custom 不可重複	Build is manually performed, custom every time, and infrequently performed; it may be owned by a specific member of the team 構建必須手動執行，每次執行都需要專門做一些配置，執行頻率較低，構建由團隊中某個特定的成員負責。

• 評估指引：

• -1：項目級構建頻度低於一週一次，集成構建無規律

• 0：項目級構建頻度做到一週至少兩次，每週至少有一次整體集成構建

• 1：項目級構建頻度做到每天一次，構建每天一次

• 2：項目級構建做到完成一塊提交一次，CI工具支持每次提交出發增量構建

• 3：所有內部開發團隊達到構建3級，基本的功能冒煙測試加入到每次構建中，用以保證內部質量

• 3+：自動化集成測試加入到構建中，自動化部署和驗收測試保證外部質量

實踐八：Testing–測試

Theme	Level	State Description	Reference Implementations
Analysts are part of test planning 分析師會參與制定測試計劃	3+	Comprehensive, Integrated 全面的、集成的	Owned by QA/Dev/Analyst, complete integration with build, non-functional and integration testing in an advanced state 測試由需求規劃、測試和開發人員共同負責。大部分測試集成進構建過程中。與產品應用場景基本一致的測試設計，且高度自動化（不一定完全自動化），故障泄露數量底，滿足持續發佈需要。
	3	TDD, Integrated	Owned by QA/Dev/Analyst, non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Developers practice TDD. 測試由測試人員和Dev以及Analyst共同負責。非功能測試和集成測試由完整的審查過程來保障。功能測試被集成進構建過程中。
Developers are part of testing 開發人員會參與測試	2	Shared by QA and Development, Integrated 測試與開發共享、集成的	Owned by QA/Dev. Non-functional and integration testing undergo complete inspection tests, functional testing is integrated with the build. 測試由測試人員和Dev負責。非功能測試和集成測試由完整的審查過程來保障。功能測試則被集成進構建過程中。
	1	Shared by QA and Development測試與開發共享	Owned by QA/Dev. Functional testing is not integrated with the build and may still be a full inspection process. Non-functional and integration tests might be incrementally integrated or End of Lifecycle 測試由測試人員和Dev負責。功能測試未集成進構建過程，由完整的審查過程來保障。 非功能測試和集成測試可能是增量集成的，或者是在軟件開發週期的末尾階段執行的。
Testing is a QA problem 測試只是測試人員的事情	0	Independent, Inspection 獨立的，審查	Owned by QA. Functional testing is full inspection and not integrated with the build. Incremental non-functional and integration tests are rudimentary inspection tests, or performed only at End of Lifecycle. 測試由測試人員負責。功能測試是一次完整的檢查，而未集成進構建過程中。增量的非功能測試和集成測試中僅包含基本的審查測試，或者這些檢查僅在軟件開發週期的末尾階段執行。
	-1	Independent, End of Lifecycle 獨立的，位於軟件開發週期末尾階段	Owned by QA. Functional, Non-functional and Integration testing performed at End of Lifecycle. 測試由測試人員負責。功能測試、非功能測試和集成測試僅在軟件開發週期的末尾階段

• 評估指引：

• -1：測試部門統一測試，開發無測試，測試集中在項目後期

• 0：開發代碼回顧，並做部分功能測試，但大部分在後期測試部門測試

• 1：版本提交測試前，測試人員與開發人員共享測試資源（工具、用例、測試環境等），分工比較明確，共同完成部分開發測試，但大規模測試依然在測試部門執行，測試人員參與需求分析，並確定測試設計的輸入

• 2：項目內部軟件開發團隊達到測試2級，版本提交系統測試前代碼經過單元測試以及部分功能測試保護

• 3：項目內部軟件開發團隊達到測試3級，大部分測試集成到構建過程中，測試部門只需少量保障性手工測試，包括功能和非功能測試

• 3+：完整全面的測試，沒有專職的測試工程師，PO+測試+開發共同完成所有測試，並大量自動化

實踐九：Simplicity–簡單性

Theme	Level	State Description	Reference Implementations
高級技術風險降低	3+	JIT Re-use 即時重用	組件超市：“組件在可重用之前必須可用。” Component supermarket: ―a component must be usable before it can become re- usable‖
高級技術風險降	3	JIT Design 即時設計	YAGNI文化（YAGNI大概意思是隻需要將應用程序必需的功能包含進來） 關注簡單性：可工作、交流、無重複、儘量少的晦澀片段 YAGNI culture Focus on simplicity: works, communicates, no duplication, fewest moving parts
有效的技術風險降低	2	Mature refactoring 成熟的重構	有效地應用設計模式：支持重構的測試實踐。 Effective application of design patterns; testing practices support refactoring
技術風險降低雛形	1	Refactoring introduced 引入重構	無紀律的重構，重構不充分；結對編程、每日站立會議、迭代回顧。 Undisciplined refactoring is not sufficient; indicators of discipline include pair
忽視技術風險	0	Ad-hoc design 臨時設計	應激性設計（“工作即可”）；拼湊組件。 Reactive design (whatever works‖); component ―bazaar‖
預先假想所有技術風險	-1	Big up-front design 大規模預先設計	花費大量精力預先設計框架；傳統的企業級重用程序（如組件庫）；誤用SOA（如根據推理定義分類）；導致高耦合、脆弱的實現，降低響應能力。 Significant investment in up-front frameworks; traditional enterprise re-use program (e.g., component libraries); SOA done wrong (e.g., speculative taxonomy defined);

實踐十：ConfigurationManagement–配置管理

Theme	Level	State Description	Reference Implementations
	3+	Enterprise CM 企業級配置管理	可以在多個提供商提供的解決方案之間協調配置管理。 CM is coordinated across vendor supplied solutions
	3	Coordinated CM 協調的配置管理	在同一個程序內協調多個項目的配置管理。 CM is coordinated across projects within the same programme
	2	Automatic CM 自動化配置管理	自動化的配置管理流程意味着更少的意外。樂觀鎖。通過構建和測試保證CM紀律。原子提交。 The ―code fairy does not run free‖ state – automation of CM rules. Optimistic locking.
	1	Integrated CM 集成配置管理	配置管理與IDE集成在一起。手動的代碼管理方式意味着代碼很難控制，（如果未遵守紀律，就可能出現意外） CM integrated with the IDE. Manual discipline means ―the code fairy runs free‖
	0	Rudimentary CM Strategy 基本的配置管理策略	基本的代碼版本管理 Basic code versioning
	-1	CM is an impediment 配置管理是一項負擔	無規矩 版本信息只保存在每個人的心裏 Wild west Gatekeeper approach (―pay the CM troll‖) Tacit knowledge in lieu of versioning