AMM让“伪敏捷”走向敏捷
一、敏捷 vs 伪敏捷
在实践敏捷的过程中经常听到团队自嘲自己是“伪敏捷“，分析其原因是因为他们只是采用了敏捷中的短迭代模式，更多地关注了敏捷的流程、工具和技巧，这种敏捷因在团队中并没有感受敏捷带来的实质变化，叫做敏捷又缺少自信，所以称之为“伪敏捷”。
事实上判断一个敏捷方法实践的真伪，并不依据有没有使用敏捷管理工具，也不依据是否引入了SCRUM流程。真伪敏捷方法的判断只有一条：是否符合并遵循了敏捷思想的价值观和原则，并获得实用效果。“伪敏捷”我理解是团队的敏捷成熟度水平低，对敏捷的认知还停留在形式没有领会其精髓。
接下来我会对在实行敏捷过程中遇到的真伪敏捷进行举例说明，大家可以参考评估你是“真敏捷”还是“伪敏捷”。
伪敏捷—敏捷成熟度低
以下一些常见的伪敏捷例子，你看看自己在敏捷实践中有没有遇到过，希望对你有所帮助：
☑抵触所有的文档，以“敏捷不需要文档”为借口
☑2周的冲刺(Sprint)完成了，只是在所有人强制把6周努力“塞到”这2周里面的情况下完成的
☑回顾会议变成吐槽会或者批斗会，对于回顾会议中识别的问题无跟进
☑最终用户被迫接受不达标的功能特性和忍受使用中的大量问题，并接受功能将会改进优化的承诺。
☑自组织团队退化，权威强加意愿到其余团队成员上
☑你看到积极的行为和产出，并认为都是你的敏捷实践的直接结果，然而忽视所有不好的行为和产出，并认为都是个人的问题。
☑团队不愿意做在他们职位的“工作描述”之外的事情（例如：开发人员测试，测试人员开发）。
☑已经计划好的Sprint不允许更改或者不考虑实际情况随意更改Sprint美其名曰“拥抱变化”
☑Project Manager兼职Scrum Master，Scrum Master时常习惯性的以领导自居，分配任务，安排优先顺序。
☑保持KPI的漂亮比什么都重要（Plan的点不能多不能少，Defect比例要稳定，Burndown不能过快或者过慢）
敏捷—敏捷成熟度高
随着团队的持续改进，敏捷成熟度越来越高，我们可能会从“伪敏捷”逐步走向真正的敏捷，你是否已经在走向敏捷的道路上了，可以参考以下敏捷的一些典型特征：
☑文档精简易迭代，重视文档的作用，也重视文档的维护
☑根据业务目标合理估时，遵循迭代交付内价值最大化原则
☑团队定期地反思如何能提高成效，并依此调整自身的举止表现
☑团队在需求的不断拆分中重新思考需求的价值
☑自组织团队，人人关注需求价值、产品质量，自发认领需求
☑团队一致的目标是通过持续不断地及早交付有价值的软件使客户满意
☑欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化
☑可工作的软件是进度的首要度量标准
二、为何要引入AMM模型
敏捷是一段旅程，没有哪个团队能够在第一天就实施敏捷的所有元素，掌握敏捷的各个方面需要时间。当团队处于敏捷旅程的早期阶段，由于敏捷成熟度低会过度依赖框架、方法、工具和技巧，这时需要正确的引导团队遵循敏捷思想的价值观和原则，团队才会逐步掌握真正的敏捷法则以及战略敏捷性使团队越来越成熟，而避免一直停留在“伪敏捷”阶段。AMM-敏捷成熟度模型就是用来指导团队完成敏捷的旅程。
?评估团队的敏捷成熟度处于什么样的水平，成熟度低的团队不仅会导致缓慢的进展，它还滋生了持续的怀疑和忿恨。应用这个模型来评估您的期望与团队水平是一致的。
?如果你没有看到期望的成熟度，这个模型能帮助你揭示什么地方出了问题。进行一次评估，来探知团队在哪些能力水平上遇到困难，然后提供培训和支持。如果多个团队都在同样的一些能力水平上遇到麻烦，那问题就可能是系统性的，需要考虑一下组织变革。
?最后，应用这个模型，来促进人们关于想达到什么以及如何使它成为可能的讨论。你可以使用及调整敏捷成熟度模型定制符合自己团队的成熟度模型。
三、AMM成熟度模型介绍
AMM 全称Agile Maturity Model，是一套用来评估软件开发团队或者整个开发组织的当前敏捷状态和将来的目标状态的框架，评估的结果用来帮助团队识别改进点。AMM可以评估一个IT组织的敏捷程度，其评估结果可以用来设定该组织敏捷实施的未来阶段性目标。
为了更好的遵循敏捷思想的价值观和原则，我们定制了符合部门实际情况的敏捷成熟度模型。模型分为5个等级6个维度，每一个等级对应的能力都有所不同，根据团队的实际水平来逐步提高。这里介绍一下每个等级的定义和一些典型特征以供参考。
六个维度
一、职责共享：打破部门业务壁垒，从自己负责的模块->关注团队负责的功能->关心整个业务实现
二、度量：有度量的意识，从编码->关注业务结果->控制波动，改善均值
三、需求：思考价值，从机械搬砖->价值驱动->联合创新
四、测试：质量内建，从研发提高自测质量->高度自动化->全员质量意识
五、自组织：激发团队关注业务成果，从执行敏捷流程->团队决策->关注业务成果
六、交付保障：逐步提升交付效率，从稳定的交付节奏->稳步提升->按需发布
五个等级
一、初始级：拥抱迭代，启动基础设施建设，零星尝试敏捷实践
二、基础级：迭代能够顺畅运转，开始系统地开展敏捷实践
三、成熟级：持续快速地迭代交付价值，建立起完善的防护网
四、优化级：端到端持续快速价值交付，敏捷实践深入团队
五、创新级：按需发布，客户协同开发和创新，输出创新成功影响业界
L1 初始级
刚刚开始敏捷之旅，倾向于从技术考虑（例如软件分层）的角度来思考，他/她们常常作为个体贡献者，工作在分配给个体的任务上。
典型特征：
?职责共享：员工只对自己团队的工作负责，但可以访问其他团队的代码
?度量：度量是事件触发，无体系
?需求：用户故事已拆分成story，优先级已排序
?测试：测试由测试人员负责，功能测试、非功能测试和集成测试仅仅在软件开发周期的末尾阶段执行
?自组织：敏捷团队临时组建，流程不清晰
?交付保障：交付节奏任意，不能保证统一的交付节奏
L2 基础级
有稳定的敏捷团队，践行敏捷的思想和流程，团队关注的重点是流程和交付保障。团队尝试使用Scrum, Kanban和XP非技术部分的实践来实现敏捷。用户故事是团队采用的最常见的方法。其他的方法包括待办事项列表、回顾会议、时间盒（例如Sprint）和团队任务板等。
典型特征：
?职责共享：员工依然负责自己的东西，但鼓励适当的需求结对开发，共同对同一个需求负责
?度量：有意识的建立长期或短期的度量体系，实时了解动态
?需求：需求可追踪而不是散乱的存放
?测试：测试用例共享，提交测试前研发已完成自测，但是大规模的测试还是在测试部门
?自组织：敏捷团队章程明确，敏捷流程清晰
?交付保障：有明确的交付节奏，基本不延期
L3 成熟级
作为一支有凝聚力的团队，团队拥有共同的目标，聚焦业务价值，他们会考虑干系人、客户和用户能够从软件中看到的收益，以此来思考和计划。
典型特征：
?职责共享：鼓励水平业务结对开发，从需求认领、代码审查、交叉测试完全由结对的人员负责到底，团队内部责任界线不构成障碍
?度量：团队有明确目标并且有度量体系衡量目标实现情况
?需求：团队开始关注价值，需求提出后，团队对需求的价值进行评估
?测试：功能测试有自动化验证机制并被集成进构建过程，非功能测试和集成测试由完整的审查过程来保障。
?自组织：在部门领域，团队基于对活动的价值进行决策，领导提供支持，必要时决策
?交付保障：团队已形成稳定的交付节奏，团队的交付能力上下浮动不超过10%
L4 优化级
团队不仅仅聚焦在业务价值上，他们还意识到根据市场的接收需要尽可能频繁交付的价值。这称为“基于市场节奏交付”。优化级团队不光在于他们交付的能力，更在于他们按需交付的能力。优化级的团队生产出低缺陷的软件，基于组织预期尽可能地频繁发布。
典型特征：
?职责共享：鼓励垂直业务结对开发，角色界线模糊不构成团队障碍
?度量：已具备建立关键过程能力技能/性能模型
?需求：业务上线后有预期价值和实际价值的比对，有反馈机制让团队及时了解所开发功能目前的使用情况
?测试：大部分测试（功能、非功能）都有自动化保证并集成进构建过程，测试部门只需少量保障性的手工测试
?自组织：团队已经能够运用敏捷的价值观进行价值分析和决策，及时回顾和修正团队决策
?交付保障：团队交付节奏稳步加快，团队的交付能力可上浮20%
L5 创新级
创新级团队理解业务目标是如何与其他团队的目标协同进而达成一个更大的战略。他/她们积极努力，来让这个战略更加成功。团队理解市场需要什么、业务需要什么、以及如何满足这些需要，创新级团队不仅有能力面向市场交付，他们也知道应该交付什么给市场。
典型特征：
?职责共享：当多个团队为了同一个项目开发时，组织级团队间同样可以实现结对，不限定业务和项目
?度量：在过程稳定的基础上改善均值，控制波动
?需求：业务模型、用户行为和喜好分析喜好
?测试：完整全面的测试，没有专职的测试工程师，PO +测试+开发共同完成所有测试，并大量自动化分析
?自组织：团队与业务成果挂钩
?交付保障：项目或者需求开发是否满足业务需求，有统一的标准和获取体系实时可看
以上是我们部门制定的用以指导团队敏捷成熟度的AMM模型，我们依据模型对团队进行评估，确认团队目前处于的成熟度等级，针对不同维度的问题进行引导改善，并以此模型确认未来目标。
四、AMM模型适合场景
敏捷研发取得成功的，大多是面向人的业务系统，或者toC的互联网产品。用户故事（User Story）里面的第一项内容就是“作为...角色的用户，她/他想要....，以至于....”。这种需求收集是以用户为中心的。因此，但凡遇到重交互的系统，敏捷方法都可以很好的工作，这个时候就适合引入AMM模型。
反之如果是中后台系统，或者数据采集和分析系统，大量的工作都是经过抽象的业务模型和数据计算逻辑，这种Story的需求分析的方式就不容易适用了。再加上中后台的产品技术团队往往并不接触业务前线，也很难判断业务价值，采取以瀑布为主的方式反而更加合适。
对于纯技术性质的探索和尝试通常的做法是采取小范围尝试，切入少量流量或系统进行快速验证和收集反馈，然后不断迭代重构以及扩大范围，这是典型的“经验型过程控制”（Empirical Process Control）—一种根据实际项目中的现实观测而做出决策的流程，这是符合人的自然认知规律的。无论你是否“敏捷”，你都会这么做。只是在当前，大家也把这个列入“敏捷”范畴。
我们推广AMM模型，如果像“推动”一个CMMI标准流程一样在全公司强制执行，It will never work ! 我们首先需要判断项目是否适合敏捷，确认适合敏捷后再开始设计一个适用于团队的“敏捷成熟度模型”， 在成熟度模型的基础上，初步形成了一套敏捷实施的方法论，从职责共享、度量驱动、高业务价值、可持续发展、自组织、快速交付6大目标出发，以团队成熟度雷达图为参照，以组织级支持为基础，成熟度评估与团队改进良性互动、持续进行。
我们可以通过以下几个步骤在敏捷团队中引入AMM模型：
第一步：划分敏捷成熟度维度
划分维度，即确定要从哪些方面来评估敏捷实施情况，在确定维度时，应注意各分类的明确定义和界限，满足不同维度之间相互独立、完全穷尽，不重叠，不遗漏。
第二步：制定敏捷成熟度的标准
确定维度相当于完成了基础骨架，制定标准是对各自维度内容的细化和丰富。在制定标准时需要注意以下两点：
1、标准涉及的范围主要反应当前组织的关注点，或正在执行的改进点
2、标准设定最好有实现难易、要求高低等方面的区别
第三步：组织评估
参与评估的人员应包括Team全体成员（开发、测试、ScrumMaster、Product Owner）。评估时应申明评估结果与Team荣誉及绩效完全无关，确保参与评估人员的安全度，以得到最真实的数据。
第四步：数据分析
参与评估的对象根据Team实际情况评估。将调查结果汇总整理后，可根据关注的侧重点自定义横向、纵向维度进行数据分析。
第五步：持续改进
根据数据分析的结果，定位现阶段敏捷实践中存在的问题、改进的方向，制定Action，建议间隔3-6个月重新进行一次成熟度评估，通过不同时期成熟度的对比，可以直观地反映各方面成熟度的变化，检验Action的合理性和执行效果，适时做出相应的调整。
五、AMM实践结果
从有做AMM模型的想法到团队的第一次评估完成，我们大概花了3个月的时间，ScrumMaster也从开始的懵懵懂懂到现在的以AMM为参考指导团队持续改进。整个团队的意识和氛围都在改变。
在这里选取Transformer团队的实践进行分析：
从雷达图中可以看出Transformer团队Q1第一次评估时度量是短板，当时度量也是部门整体性的问题，大部分敏捷团队都缺乏度量的意识，不能从度量出发去驱动出一系列的改进。通过评估发现这个问题后组织进行了变革，从原来的业务驱动改为目标驱动，明确各团队目标，Transformer团队目标是常规产品详情的UV到有效订单转化，并且建立度量要求。测试部门也建立了bug基线和自动采集机制，帮助团队建立质量度量意识。
评估结束后各团队确认了Q2持续改进内容，通过部门和团队的努力，我们Q2对Transformer进行了2次评估，我们发现该团队不仅在度量维度有了大幅度提升，职责共享、交付保障和需求维度都有了相应的提升，团队的成熟度在逐步的提升。
以度量维度为例，Transformer在Q2进行了度量维度的改善
以上是选取了一个案例进行了AMM模型的说明。
扫码关注我们
**途牛技术中心
**
期待与你相逢