AMM敏捷成熟度评估框架介绍

业界关于敏捷的认证有很多,Scrum、SAFe、Devops等流派都有自己的认证体系,但都是关于个人的,对于团队/项目的敏捷开展状态则比较少见,借用CMMI的说法叫成熟度。这里介绍由ThoughtWorks提出的敏捷成熟度评估框架。当然评估的目的是为了找出不足,识别改善点,并非一定要认证。

AMM简介

•     AMM 全称Agile Maturity Model,是一套用来评估软件开发团队或者整个开发组织的当前敏捷状态和将来的目标状态的框架,评估的结果用来帮助团队识别改善点。

–    可以评估一个IT组织的敏捷程度,其评估结果可以用来设定该组织敏捷实施的未来阶段性目标。

•     AMM关注于敏捷方法的具体展现形式,即软件开发过程。因此AMM只评估软件开发团队的开发过程和实践,并不能用来评估一个组织的所有方面。

7318d69dd3183e22661d360cd6697dd3.jpeg

Is not

•     AMM不是一个标准

•     AMM不是一个级别认证或者一套规章制度

•     AMM不是一套事先制定和强制习性的治理框架

AMM的结构

•     AMM从十个维度进行评估,每个维度有六个级别,这些维度的级别揭示了组织的“敏捷成熟度”

•     AMM是ThoughtWorks对全球敏捷组织转型经验的一个提炼

•     AMM评估帮助项目关键涉众取得一个队当前状态和未来目标的统一理解

•     AMM是一个不断演化的框架

十个维度

•     管理实践

–    共享职责Shared Restponsibility

–    需求Requirements

–    快速响应Responsiveness

–    项目管理ProjectManagement/Assurance交付保障

–    沟通Communication

–    自组织团队SelfOrganization/Governance治理

•     技术实践

–    构建Build

–    测试Testing

–    简单性Simplicity

–    配置管理Configuration Management

六个级别

•     Innovating改革创新

–    当前团队有能力发明新的技术和实践解决前所未遇的问题。一个典型特点是团队能够积极贡献和回馈更广大的软件开发社区。

•     Adaptive自适应

–    当前团队的过程已经足够成熟,能够良好地响应变化

–    各维度形成内部良性循环,并彼此促进

•     Operating正常运转

–    通过对相关技术的掌握和相应的纪律支持敏捷软件开发持续实施

•     Collaborative协作

–    具备实施敏捷软件开发的基础

•     Neutral中立

–    即不阻碍也不有利于敏捷软件开发

•     Regressive阻碍

–    当前的过程限制了敏捷实践开展 

0637201d8349794e19cea20d33af831a.png

状态评估

•     评估当前状态和未来的阶段性目标

•     显示每一阶段目标的关注焦点和对人员、技能以及角色的影响和要求

•     帮助我们识别每一阶段的改变程度和相应影响

•     帮助我们识别出应该改变的方面

5853f1e098efec8afe9ae0d214fdff2f.jpeg

评估模式

•     按照类别评估

–    按照管理实践和技术实践组织评估结果

–    允许我们:

•     清晰展示当前状态和期望状态之间的差距

•     展示不同阶段的状态演变

•     识别出我们的努力方向

•     按照维度评估

–    识别出各个维度上的当前状态和未来阶段性目标

–    识别出各维度上的目标和具体行动计划

7d9fc0fd71ccae93968c26c6515b9d1c.png

谁来进行评估

•     由有足够敏捷实践经验的敏捷实践者组成AMM评估小组

–    不是checklist驱动,而是经验驱动

–    使用AMM帮助评估者描绘和勾划团队的当前过程

–    是一个动态的了解团队当前动态的过程

–    不同的评估者的评估过程可能不同

–    评估小组有能力覆盖管理、技术各项实践

–    一个评估小组至少三位成员

避免

•     为了评级而评估

•     逐条检查各个维度的问题单来确定各维度级别

•     评估过程变成自评过程

对谁进行评估

•     PO

•     SM

•     分析师/SE

•     开发人员

•     测试人员

•     QA

•     ……

评估时间

Team Size

Interview  Time

Reporting Time

Small(<15)

0.5days

1.5days

Medium(15,50)

1.5days

1.5days

Large(50 to 100)

2 to 3 days

2days

Bigger than  large

3-4days

2days+

Iteration 0

•     识别评估对象

•     制定访问计划

•     评估团队培训

•     让所有评估团队成员在开始评估前清楚什么时候、对什么人、如何进行评估

评估流程

•     理想状态下,被评估团队成员集中在一起

•     Kick-offmeeting(启动会议),根据团队规模

•     评估团队进行访谈和调研,辅以实地考察

•     纪要和交付物整理

•     小规模成果展示,收集客户反馈,修正交付物

•     全团队成果展示

交付物

•     评估结果总结陈述

•     以不同形式展现的当前成熟度、推荐的未来目标和中间阶段性目标

•     描述对每个维度上的改善所带来的预期收益

•     一系列关于如何达到下一阶段目标的推荐措施(通过优先级排序)

•     评估过程产物(访谈记录等)

 下文将详细介绍十个维度六个级别。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值