什么是AMM - cruisetraining
advertisement
Agile Maturity Model 敏捷成熟度评估 © ThoughtWorks 2009 1 Agenda • • • • • 什么是AMM 为什么做AMM? AMM的结构 如何做AMM评估 AMM维度介绍 © ThoughtWorks 2009 2 AMM简介 • AMM（敏捷成熟度模型）是一套用来评估软件开发团队或者整个开发 组织的当前敏捷状态和将来的目标状态的框架，评估的结果用来帮助 团队识别改善点。 什么是AMM • AMM关注于敏捷方法的具体展现形式即软件开发过程。因此，AMM只评 估软件开发团队的开发过程和实践，并不能用来评估一个组织的所有 方面。 What benefits is our organization realizing from agile adoption? Benefits Platforms Are our software platforms amenable to rapid change? Do they hinder or support agile practices? People To what extent do our staff and partners possess the skills and expertise required for effective agile development? Process To what extent do our processes leverage and exploit agile best practices? © ThoughtWorks 2009 4 什么是AMM • AMM从若干个维度进行评估，每个维度有若干个级别，这些维度的级 别一起揭示了组织的“敏捷成熟度” © ThoughtWorks 2009 5 The Agile Maturity Model is • AMM是ThoughtWorks对全球敏捷组织转型经验的一个提炼 • AMM评估帮助项目关键涉众取得一个对当前状态和未来目标的统一理 解 • AMM是一个不断演化的框架 • AMM易于理解和使用 Is not • • • • AMM不是一个标准 AMM不是一个级别认证或者一套规章制度 AMM不是一套事先制定和强制执行的治理框架 AMM不是一个庞然大物 © ThoughtWorks 2009 7 为什么要使用AMM • AMM用来评估一个IT组织的敏捷程度，其评估结果可以被用来设定该 组织敏捷实施的未来阶段性目标。 © ThoughtWorks 2009 8 维度 • 管理实践 – – – – – – Shared Responsibility – 职责共享 Requirements – 需求 Responsiveness – 快速响应 Assurance – 交付保障 Communication – 沟通 Governance - 治理 • 技术实践 – – – – Build – 软件构建 Testing – 测试 Simplicity – 简单性 Configuration Management – 配置管理 Levels - 级别 • Innovating – 当前团队有能力发明新的技术和实践 解决前所未遇的问题。一个典型特点 是团队能够积极贡献和回馈更广大的 软件开发社区。 • Adaptive – 当前团队的过程已经足够成熟，能够 良好地相应变化 • Operating – 通过对相关技术的掌握和相应的纪律 支持了敏捷软件开发的持续实施 • 3+ Innovating 3 Adaptive 2 Operating 1 Collaborative 0 Neutral -1 Regressive Neutral – 既不阻碍也不有利于敏捷软件开发 • State Description Collaborative – 具备实施敏捷软件开发的基础 • Level Regressive – 当前的过程限制了敏捷的实行 状态评估 • • • • 评估当前状态和未来的阶段性目标 显示每一阶段目标的关注焦点和对人 员、技能以及角色的影响和要求 帮助我们识别每一阶段的改变程度和 相应影响 帮助我们识别出应该改变的方面 AMM Assessment - By Practice Area Shared Responsibility 3 Governance Build 2 1 Communication 0 Requirements -1 Configuration Management Testing Simplicity Responsiveness Assurance TW Deep TW Wide Current State 按照类别评估 • 按照管理实践和技术实践组织评估结 果 允许我们： – 清晰展示当前状态和期望状态之间的 差距 – 展示不同阶段的状态演变 – 识别出我们的努力方向 AMM Assessment Technical • Management Current State Stage 1 Stage 2 AMM Level 3 按维度评估 • 识别出各个维度上的当前状态和未来阶段性目标 • 识别出各维度上的目标和具体行动计划 如何进行AMM评估 © ThoughtWorks 2009 14 谁来进行评估 • 由有敏捷实践经验的ThoughtWorks敏捷实践者进行评估 – – – – 不是checklist驱动，而是经验驱动 使用AMM帮助评估者描绘和勾划团队的当前过程 是一个动态的了解团队当前动态的过程 不同的评估者的评估过程可能不同 © ThoughtWorks 2009 15 避免 • 为了评级而评估 • 逐条检查各个维度的问题单来确定个维度级别 • 评估过程变成自评过程 © ThoughtWorks 2009 16 对谁进行评估 • • • • • • PM/PL 分析师/SE 工程师/首席工程师/架构师 测试人员 QA Etc. © ThoughtWorks 2009 17 评估时间 Team Size Interview Time Reporting Time Small(<15 people) 0.5 days 1.5 days Medium(15 to 50 people) 1.5 days 1.5 days Large(50 to 100) 2 to 3 days 2 days Bigger than Large(100+) 3 to 4 days+ 2 days+ © ThoughtWorks 2009 18 Iteration 0 • 识别评估对象 • 制定访问计划 • 评估团队培训 让所有评估团队成员在开始评估前清楚什么时候，对什么人，如何进行评估 © ThoughtWorks 2009 19 评估流程 • • • • • • 理想状态下，被评估团队集中在同一地点 Kick-off meeting，根据团队规模 评估团队进行访谈和调研，辅以实地考察 纪要和交付物整理 小规模成果展示，收集客户反馈，修正交付物 全团队成果展示 © ThoughtWorks 2009 20 交付物 • • • • 评估结果总结陈述 以不同形式展现的当前成熟度、推荐的未来目标和中间阶段性目标 描述对每个维度上的改善所带来的预期收益 一系列关于如何达到下一阶段目标的推荐措施（通常经过优先级排序 ） • 评估过程产物（访谈记录等） © ThoughtWorks 2009 21 Agile Maturity Model 技术实践 Build – 软件构建 Theme Level 3+ 3 2 1 0 -1 State Description Reference Implementations External Gatekeeper Functional testing tools (Watir, Selenium, Marathon Man) are integrated as gatekeeper events to the build. Integration tests with external tools and products. 对外防御 在构建过程中集成功能测试工具（Watir、Selenium、Marathon Man），并将其作为构 建成功的条件。对与外部工具和产品的集成进行测试 Internal Gatekeeper Unit tests and code characteristics are implemented as gatekeeper events that will prevent a build from completing. 对内防御 在构建过程中集成单元测试和代码特征检查，并将其作为构建成功的条件。 Constant Build velocity is maximized - that is, build is happening with the maximum frequency. State of the build the responsibility of the team. 频繁执行 尽快构建－即保持最高的构建频率。整个团队对构建状态负责。 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. 重复执行 构建过程是自动化的、可重复的，但受限于技术原因不能保持最高的构建频率；整 个团队对构建状态负责。 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 具备重复执行能力 构建流程是可重复的，但并不活跃，往往手动触发，而且频率较低。构建由团队中 某个特定的成员负责。 Custom Build is manually performed, custom every time, and infrequently performed; it may be owned by a specific member of the team 不可重复 构建必须手动执行，每次执行都需要专门做一些配置，执行频率较低；构建由团队 中某个特定的成员负责。 Testing – 测试 Theme Level 3+ State Description Comprehensive, Integrated 全面的、集成的 Analysts are part of test planning 分析师会参与制定 测试计划 3 TDD, Integrated TDD、集成的 Reference Implementations Owned by QA/Dev/Analyst, complete integration with build, non-functional and integration testing in an advanced state 测试由测试人员和Dev以及Analyst共同负责。非功能测试和集成测试均完整地集成进构 建过程中。 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共同负责。非功能测试和集成测试由完整的审查过程 来保障。功能测试被集成进构建过程中。 2 Developers are part of testing 开发人员会参与测 试 1 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负责。非功能测试和集成测试由完整的审查过程来保障；功能测 试则被集成进构建过程中。 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负责。功能测试未集成进构建过程，由完整的审查过程来保障。 非功能测试和集成测试可能是增量集成的，或者是在软件开发周期的末尾阶段执行的。 0 Independent, Inspection 独立的，审查 测试由测试人员负责。功能测试是一次完整的检查，而未集成进构建过程中。增量的非 功能测试和集成测试中仅包含基本的审查测试，或者这些检查仅在软件开发周期的末尾 阶段执行。 Testing is a QA problem 测试只是测试人员 的事情 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. 测试由测试人员负责。功能测试、非功能测试和集成测试仅在软件开发周期的末尾阶段 执行。 Simplicity – 简单性 Theme Advanced technology risk mitigation – externally focused Level 3+ JIT Re-use 即时重用 高级技术风险降低— —关注外部 Advanced technology risk mitigation – internally focused State Description 3 JIT Design 即时设计 2 1 0 预先假想所有技术风 险 Ad-hoc design 临时设计 忽视技术风险 Assume all technology risk upfront Refactoring introduced 引入重构 技术风险降低雏形 Ignores technology risk Mature refactoring 成熟的重构 有效的技术风险降低 Embryonic technology risk mitigation 组件超市：“组件在可重用之前必须可用。” Component supermarket: “a component must be usable before it can become reusable” YAGNI文化 关注简单性；可工作、交流、无重复、尽量少的晦涩片段 YAGNI culture Focus on simplicity: works, communicates, no duplication, fewest moving parts 高级技术风险降低— —关注内部 Effective technology risk mitigation Reference Implementations -1 有效地应用设计模式；支持重构的测试实践。 Effective application of design patterns; testing practices support refactoring 无纪律的重构，重构不充分；结对编程、每日站立会议、迭代回顾。 Undisciplined refactoring is not sufficient; indicators of discipline include pair programming, daily stand-ups, iteration retrospectives 应激性设计（“工作即可”）；拼凑组件。 Reactive design (‘whatever works”); component “bazaar” 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); leads to highly coupled and brittle implementations that reduce responsiveness) Configuration Management – 配置管理 Theme Level State Description Reference Implementations 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纪律。原 子提交。 3+ 1 0 -1 自动化配置管理 Integrated CM 集成配置管理 The “code fairy does not run free” state – automation of CM rules. Optimistic locking. Build/test enforces CM discipline. Atomic commits. 配置管理与IDE集成在一起。手动的代码管理方式意味着代码很难控制，（如果未遵守 纪律，就可能出现意外） CM integrated with the IDE. Manual discipline means “the code fairy runs free” (unexpected changes are possible when manual discipline not maintained) Rudimentary CM Strategy 基本的代码版本管理 基本的配置管理策略 Basic code versioning CM is an impediment 无规矩 配置管理是一项负担 版本信息只保存在每个人的心里 Wild west Gatekeeper approach (“pay the CM troll”) Tacit knowledge in lieu of versioning Agile Maturity Model 管理实践 Shared Responsibility – 职责共享 Theme Level 3+ State Description 组织级结对 Organizational Pairing 3 2 1 0 -1 Reference Implementations 与业务人员实时结对；跨团队协作 Real time pairing with the business; cross-team collaboration 跨域结对 跨角色结对以实现需求 Cross-Discipline Pairing Cross-role pairing on requirements execution 有管理的结对 使用结对阶梯表以确保结对被经常轮换，整个团队以结对方式工作 Pairing is Managed Pair stairs are used to ensure rotation; pair teams sign up for requirement execution 鼓励结对 有机会结对并且结对是受鼓励的 Pairing is Encouraged Opportunities to pair are identified and encouraged 不受限访问 开发人员可以不受限制地访问开发产物 Unencumbered Access Developers have unrestricted access to change development artifacts 制度化，专业化 开发人员角色固定并且能力受限 Institutionalized Specialization Developers are in specified roles with limited ability to make changes Requirements – 需求 Theme Level 3+ 3 适时获取需求 增量价值，可测试 Incrementally valuable and granularly testable 1 0 预先需求分析 Requirements are elicited upfront 可协商 Negotiable 2 Requirements are explored / defined at time of need 独立 Independent 持续获取需求 Requirements are continuously expressed State Description -1 Reference Implementations 需求描述了交付团队需要完成的事项，是独立的，可执行的。 估计和协商的 方式可以改变。 Requirements are independent, actionable statements of things to be done by a delivery team. The nature of estimation and negotiation will change. 需求是关注业务的，是在与业务人员沟通时获取的，而不是从正式的文档或流 程提取的。并且需求是可以协商的 Requirements are not derived / extracted from formal documentation or process but are captured at time of expression by the business in a business-focused manner 敏捷故事：需求是业务价值的体现，而不是待完成的技术任务 Agile Stories: requirements are expressions of business value, not technical tasks that need to be performed 短小，可估计， 需求会被进一步分解成可互相依赖的任务（技术需求）以提高估计的准确性。 Short, estimable Requirements are further decomposed to have greater estimation accuracy. This will consist of a number of “tasks” promoted as “technical requirements,” among which there will be interdependencies 概要，模糊，业务导向的表达 需求过大，表述概括。估计不准确， 需求描述过于概括导致难以协商 High-level, vague, businessoriented expressions of need Requirements are decomposed into high-level expressions (“epics”) of what the business needs done. Estimation accuracy is unreliable; the statement of need is too high level to negotiate 详细的，高度耦合 冗长的用例， 缺乏完整背景的大段描述 Detailed, highly coupled specifications Verbose use cases; large expressions / statements without complete context Responsiveness – 快速响应 Theme Level 3+ State Description 持续变更管理 Continuous Change Management 3 持续业务参与 Continuous Business Involvement 2 迭代变更管理 Iterative Change Management 1 短交付周期 Short Delivery Cycle 0 应激式变更控制，风格不统一 Reactive Change Control, Inconsistent Style -1 缺乏灵活性， 长交付周期 Change Inflexibility, Long Delivery Cycle Reference Implementations 流畅的变更决策 Change decisions are fluid 业务人员积极参与交付的每个阶段 The business is actively involved in each phase of delivery 新特性和优先级可在每个迭代调整 Iterative cycle enables new features and re-prioritization with each iteration 新特性和优先级可在每次发布调整 Release cycle enables new features and re-prioritization with each release 非正式的变更控制 Low ceremony change control “Pile-it-on” 极为正式的变更控制。 变更控制导致或反映了对变更的抵抗。规范是冻结的。 High ceremony change control. Change control contributes to or reflects change resistance. Specifications are frozen. Assurance – 交付保障 Theme Level 3+ 流畅的计划内和计划外 风险管理 Fluid on-plan and offplan risk containment 3 State Description 项目管理最大程度支持业务 Project management maximizes business impact 自适应项目管理 Adaptive Project Management 2 项目状态报告反映项目路径？ On-plan and off-plan risk awareness current with decision horizon 1 决策视角是迭代长度 应激式风险应对（对执 行的关注胜过风险意识） 0 计划内和计划外风险在 决策视角内得到关注 Risk reactive (execution focus trumps risk awareness) 计划内风险受管理，不 容许计划外风险 On-Plan risks are mapped, no tolerance for off-plan -1 Status reporting reflects project path taken Decision horizon is iteration length 决策视角是发布长度 Decision horizon is release length 固定的项目计划， 决策视角是项目长度 Fixed project planning, decision horizon is project length Reference Implementations 存在统一机制以报告项目是否满足业务需求（Business Case） A consistent mechanism for reporting whether project are meeting their business case is applied across the portfolio. 项目计划是有业务人员参与的协作过程， 每个迭代都会进行并可能得到更新 。项目计划 能够指明当前期望在哪个迭代交付哪些业务功能。 Project planning is a collaborative process with the business, done as frequently as each iteration, meaning the project plan may be refreshed with each iteration. The project plan communicates the current expectation to the iteration level of when specific business functionality will be delivered 项目状态报告反映了项目路径，在业务层面传达目前为止已交付的功能 Project status reporting is an expression of the project path taken, communicating in business terms the functionality delivered to date. 决策视角是一个较短的时间窗，通常不超过3个星期。需求以能在此时间窗内完成的方式 表达。 The decision horizon spans a shorter time-box, typically no longer than 3 weeks. Requirements are expressed in such a way that they can be completed in this time box. 决策视角是一个较短的时间窗，通常不超过3个月。需求以能在此时间窗内完成的方式表 达。 The decision horizon spans a shorter time-box, typically no longer than 3 months. Requirements are expressed in such a way that they can be completed in this time box. 项目时间表作为计划，决策视角是项目长度，有可能几年。项目状态是以执行与计划的匹 配程度来报告的。 Project schedule acts as a plan. The decision horizon is the length of the project or program, potentially spanning years. Status is reported as compliance with or exception to the plan. Communication – 沟通 Theme Communication are the social system 流畅沟通 Level 3+ 3 Communication are fluid 沟通自动化 Communication are automatic 结构化沟通体系 2 1 Communication are structured 双向沟通 Bidirectional communication is possible 0 -1 单向沟通 Communication is unidirectional State Description Reference Implementations 企业级协作 与业务相关的活动对团队无侵入性；业务和开发组成统一团队 Enterprise Collaboration Business participation is non-invasive to the team 协作执行 跨角色结对 Collaborative execution Pairing across team roles 协作基础设施 面向所有涉众的交流（主动的、被动的）均有工具支持 Collaborative Infrastructure Tools facilitate active and passive communications to multiple stakeholders 协作式专题讨论 有结构化、有规律的沟通和会议支持协作 Collaborative Forums Regular meeting events structured to facilitate collaboration 定期会议 定期（通常是每周）小组会议以供团队成员讨论 Regular Meetings Regular (typically weekly) team meetings provide a forum that allows team collaboration 单向沟通 管理层向团队通报进度 Unidirectional communication Progress updates from management to the team. 不定期小组会议 Irregular team meetings 各执一词的吵架会议 Death-by-meetings, participants state their objectives and priorities. Governance – 治理 Theme Level 3+ 3 强化原则，弱化 规则 Increasing extent of principles in favor of rules. 缺乏明确的规则 或原则 Prescriptive, Rules based Reference Implementations 巩固 与业务成果挂钩 Consolidated Linkage to business results 平衡 连通各个维度 Balanced Connectedness across dimensions 指标可支持详细分析， 没有繁琐的收集和报告 2 Enabling; drives action Metrics that support detailed analysis; non-burdensome collection and reporting 1 Grass-roots multi-disciplined reporting Pragmatic – proposed by delivery leaders. Multi-disciplined (e.g., it is more than just development metrics); delivery people are responsible, accountable and empowered 0 应激性的 临时的，甚至是混乱的 Reactionary Ad-hoc, possibly chaos 文过饰非 重量级的，障碍性的，便于出错时好有借口 CYA Heavy-weight, gets in people’s way, focused on providing cover in case something goes wrong. The absence of rules or clear principles 规定的， 基于规 则的 State Description -1
