敏捷开发成熟度评估模型-AMM评估实践
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• Adaptive自适应 – 当前团队的过程已经足够成熟，能够良好地 响应变化 – 各维度形成内部良性循环，并彼此促进
• Operating正常运转 – 通过对相关技术的掌握和相应的纪律支持敏 捷软件开发持续实施
• Collaborative协作 – 具备实施敏捷软件开发的基础
• Neutral中立 – 即不阻碍也不有利于敏捷软件开发
• AMM不是一套事先制定和强制习性的治理 框架
AMM的结构
6
• AMM从十个维度进行评估，每个维度有六 个级别，这些维度的级别揭示了组织的 “敏捷成熟度”
• AMM是ThoughtWorks对全球敏捷组织转型 经验的一个提炼
• AMM评估帮助项目关键涉众取得一个队当 前状态和未来目标的统一理解
• AMM是一个不断演化的框架
评估时间
TeΒιβλιοθήκη Baidum Size Small（<15） Medium（15,50） Large（50 to 100） Bigger than large
Interview Time 0.5days 1.5days 2 to 3 days 3-4days
14
Reporting Time 1.5days 1.5days 2days 2days+
十个维度
7
• 管理实践
– 共享职责Shared Restponsibility – 需求Requirements – 快速响应Responsiveness – 项目管理ProjectManagement/Assurance交付保障 – 沟通Communication – 自组织团队SelfOrganization/Governance治理
AGILE MATURITY MODEL
Build – 软件构建
19
Theme
Level State Description
3+ External Gatekeeper 对外防御
3
Internal
Gatekeeper
对内防御
2
Constant
频繁执行
1
Repeating
重复执行
0
Repeatable
具备重复执
行能力
-1
Custom
不可重复
Reference Implementations
Functional testing tools (Watir, Selenium, Marathon Man) are integrated as gatekeeper events to the build. Integration tests with external tools and products. 在构建过程中集成功能测试工具，并将其作为构建成功的条件。对与外部工 具和产品的集成进行测试。
• 技术实践
– 构建Build – 测试Testing – 简单性Simplicity – 配置管理Configuration Management
六个级别
8
• Innovating改革创新 – 当前团队有能力发明新的技术和实践解决前 所未遇的问题。一个典型特点是团队能够积 极贡献和回馈更广大的软件开发社区。
• 小规模成果展示，收集客户反馈，修正交 付物
• 全团队成果展示
交付物
17
• 评估结果总结陈述
• 以不同形式展现的当前成熟度、推荐的未 来目标和中间阶段性目标
• 描述对每个维度上的改善所带来的预期收 益
• 一系列关于如何达到下一阶段目标的推荐 措施（通过优先级排序）
• 评估过程产物（访谈记录等）
技术实践
Iteration 0
15
• 识别评估对象 • 制定访问计划 • 评估团队培训
• 让所有评估团队成员在开始评估前清楚什 么时候、对什么人、如何进行评估
评估流程
16
• 理想状态下，被评估团队成员集中在一起 • Kick-off meeting（启动会议），根据团队规
模 • 评估团队进行访谈和调研，辅以实地考察 • 纪要和交付物整理
Unit tests and code characteristics are implemented as gatekeeper events that will prevent a build from completing. 在构建过程中集成单元测试和代码特征检查，并将其作为构建成功的条件。
程 – 是一个动态的了解团队当前动态的过程 – 不同的评估者的评估过程可能不同 – 评估小组有能力覆盖管理、技术各项实践 – 一个评估小组至少三位成员
避免
12
• 为了评级而评估
• 逐条检查各个维度的问题单来确定各维度 级别
• 评估过程变成自评过程
对谁进行评估
13
• PO • SM • 分析师/SE • 开发人员 • 测试人员 • QA • ……
敏捷
Agile Maturity Model 敏捷开发成熟度评估模型
黄河敏捷开发
什么是AMM？
WHAT IS AMM？
AMM简介
3
• AMM 全称Agile Maturity Model，是一套用 来评估软件开发团队或者整个开发组织的当前 敏捷状态和将来的目标状态的框架，评估的结 果用来帮助团队识别改善点。
– 可以评估一个IT组织的敏捷程度，其评估结果可以 用来设定该组织敏捷实施的未来阶段性目标。
AMM简介
4
• AMM关注于敏捷方法的具体展现形式，即软件开发过程。因此 AMM只评估软件开发团队的开发过程和实践，并不能用来评估 一个组织的所有方面。
Is not
5
• AMM不是一个标准
• AMM不是一个级别认证或者一套规章制度
– 允许我们：
• 清晰展示当前状态和期望 状态之间的差距
• 展示不同阶段的状态演变 • 识别出我们的努力方向
• 按照维度评估
– 识别出各个维度上的当前 状态和未来阶段性目标
– 识别出各维度上的目标和 具体行动计划
谁来进行评估
11
• 由有足够敏捷实践经验的敏捷实践者组成 AMM评估小组
– 不是checklist驱动，而是经验驱动 – 使用AMM帮助评估者描绘和勾划团队的当前过
• Regressive阻碍 – 当前的过程限制了敏捷实践开展
状态评估
9
• 评估当前状态和未来的阶段 性目标
• 显示每一阶段目标的关注焦 点和对人员、技能以及角色 的影响和要求
• 帮助我们识别每一阶段的改 变程度和相应影响
• 帮助我们识别出应该改变的 方面
评估模式
10
• 按照类别评估
– 按照管理实践和技术实践 组织评估结果
• Operating正常运转 – 通过对相关技术的掌握和相应的纪律支持敏 捷软件开发持续实施
• Collaborative协作 – 具备实施敏捷软件开发的基础
• Neutral中立 – 即不阻碍也不有利于敏捷软件开发
• AMM不是一套事先制定和强制习性的治理 框架
AMM的结构
6
• AMM从十个维度进行评估，每个维度有六 个级别，这些维度的级别揭示了组织的 “敏捷成熟度”
• AMM是ThoughtWorks对全球敏捷组织转型 经验的一个提炼
• AMM评估帮助项目关键涉众取得一个队当 前状态和未来目标的统一理解
• AMM是一个不断演化的框架
评估时间
TeΒιβλιοθήκη Baidum Size Small（<15） Medium（15,50） Large（50 to 100） Bigger than large
Interview Time 0.5days 1.5days 2 to 3 days 3-4days
14
Reporting Time 1.5days 1.5days 2days 2days+
十个维度
7
• 管理实践
– 共享职责Shared Restponsibility – 需求Requirements – 快速响应Responsiveness – 项目管理ProjectManagement/Assurance交付保障 – 沟通Communication – 自组织团队SelfOrganization/Governance治理
AGILE MATURITY MODEL
Build – 软件构建
19
Theme
Level State Description
3+ External Gatekeeper 对外防御
3
Internal
Gatekeeper
对内防御
2
Constant
频繁执行
1
Repeating
重复执行
0
Repeatable
具备重复执
行能力
-1
Custom
不可重复
Reference Implementations
Functional testing tools (Watir, Selenium, Marathon Man) are integrated as gatekeeper events to the build. Integration tests with external tools and products. 在构建过程中集成功能测试工具，并将其作为构建成功的条件。对与外部工 具和产品的集成进行测试。
• 技术实践
– 构建Build – 测试Testing – 简单性Simplicity – 配置管理Configuration Management
六个级别
8
• Innovating改革创新 – 当前团队有能力发明新的技术和实践解决前 所未遇的问题。一个典型特点是团队能够积 极贡献和回馈更广大的软件开发社区。
• 小规模成果展示，收集客户反馈，修正交 付物
• 全团队成果展示
交付物
17
• 评估结果总结陈述
• 以不同形式展现的当前成熟度、推荐的未 来目标和中间阶段性目标
• 描述对每个维度上的改善所带来的预期收 益
• 一系列关于如何达到下一阶段目标的推荐 措施（通过优先级排序）
• 评估过程产物（访谈记录等）
技术实践
Iteration 0
15
• 识别评估对象 • 制定访问计划 • 评估团队培训
• 让所有评估团队成员在开始评估前清楚什 么时候、对什么人、如何进行评估
评估流程
16
• 理想状态下，被评估团队成员集中在一起 • Kick-off meeting（启动会议），根据团队规
模 • 评估团队进行访谈和调研，辅以实地考察 • 纪要和交付物整理
Unit tests and code characteristics are implemented as gatekeeper events that will prevent a build from completing. 在构建过程中集成单元测试和代码特征检查，并将其作为构建成功的条件。
程 – 是一个动态的了解团队当前动态的过程 – 不同的评估者的评估过程可能不同 – 评估小组有能力覆盖管理、技术各项实践 – 一个评估小组至少三位成员
避免
12
• 为了评级而评估
• 逐条检查各个维度的问题单来确定各维度 级别
• 评估过程变成自评过程
对谁进行评估
13
• PO • SM • 分析师/SE • 开发人员 • 测试人员 • QA • ……
敏捷
Agile Maturity Model 敏捷开发成熟度评估模型
黄河敏捷开发
什么是AMM？
WHAT IS AMM？
AMM简介
3
• AMM 全称Agile Maturity Model，是一套用 来评估软件开发团队或者整个开发组织的当前 敏捷状态和将来的目标状态的框架，评估的结 果用来帮助团队识别改善点。
– 可以评估一个IT组织的敏捷程度，其评估结果可以 用来设定该组织敏捷实施的未来阶段性目标。
AMM简介
4
• AMM关注于敏捷方法的具体展现形式，即软件开发过程。因此 AMM只评估软件开发团队的开发过程和实践，并不能用来评估 一个组织的所有方面。
Is not
5
• AMM不是一个标准
• AMM不是一个级别认证或者一套规章制度
– 允许我们：
• 清晰展示当前状态和期望 状态之间的差距
• 展示不同阶段的状态演变 • 识别出我们的努力方向
• 按照维度评估
– 识别出各个维度上的当前 状态和未来阶段性目标
– 识别出各维度上的目标和 具体行动计划
谁来进行评估
11
• 由有足够敏捷实践经验的敏捷实践者组成 AMM评估小组
– 不是checklist驱动，而是经验驱动 – 使用AMM帮助评估者描绘和勾划团队的当前过
• Regressive阻碍 – 当前的过程限制了敏捷实践开展
状态评估
9
• 评估当前状态和未来的阶段 性目标
• 显示每一阶段目标的关注焦 点和对人员、技能以及角色 的影响和要求
• 帮助我们识别每一阶段的改 变程度和相应影响
• 帮助我们识别出应该改变的 方面
评估模式
10
• 按照类别评估
– 按照管理实践和技术实践 组织评估结果