模型
解决的问题是对已经实施了敏捷的组织进行评估，并给出建议
每个维度具有 6 个级别，评估维度 5 个，以及参考基线，包括一些指标的最小集。
组织架构
交付迭代管理
技术实践
团队文化
沟通和协作
成熟度分级
- 5 理想，团队已经能自主持续优化
- 4 成熟，团队运行的非常好
- 3 良好，团队能稳定运行，但是还有改进空间
- 2 一般，团队满足部分敏捷要求，依然需要改进
- 1 不足，团队已经有一些敏捷工作方式，存在较多问题
- 0 初始，没有任何敏捷实践
诊断的方法
- 定量
- 人员访谈
- 实地实物考察
- 定性
- 问卷调查表
- 数据收集
- 定量
输出件
- 访谈日志
- 维度打分表
- 汇报 PPT
维度的特征
通过一些具体特征，描述敏捷实践的成熟度。
组织架构
- 团队
- 是否是特性团队
- 团队人数
- 团队不同角色人员职责是否清晰
- PM
- PO
- TL
- BA
- QA
- DEV
- UX
- 考核目标
- 团队成员的汇报路线是否一致
- 团队成员是否统一考核，有一致的目标
- 团队责任是否共通承担
- 人员梯队
- 人员建设是否具有梯队性，PM、Tech lead 调动是否有破坏性的影响
- 团队成员是否有明确的发展方向和路线
产品需求分析
- 产品是否有明确的调研分析实践
- 包括竞品分析
- 市场分析
- 客户群定位
- 痛点分析
- 用户画像
- 可量化和验证的目标
- 产品发展里程碑
- 是否对产品有反馈机制
- 用户测试
- 根据运营数据调整
- 是否会以 MVP 快速验证产品
- 是否有度量，是否以度量驱动开发
交付迭代管理
- 需求管理
- 业务方是否参与迭代过程，并及时给出反馈
- 使用用户故事传递需求，并有明确的验收条件
- 验收条件和测试对齐
- 使用电子工具管理
- 敏捷计划
- 是否以迭代的形式交付
- 每个迭代有明确的交付计划和目标
- 所有的需求（变更）都是通过单一的Product Backlog来管理
- 需求/任务按照业务价值排序，并可动态调整
- 迭代交付
- 以何种频率进行产品发布
- 迭代过程中有明确的 DoD，团队成员可以遵守 DoD 去协作
- 相对稳定的迭代速率
- 可视化
- 团队的工作目标，任务可视化，且在每个迭代更新
- 迭代中的风险、依赖等问题和图表可视化，且经常更新
- 迭代速率可视化
- 工程实践结果通过可视化方式进行展现
技术实践
设计和开发
- 团队已经制定了编码规范并且能够执行
- 定期列出技术债，并排优先级，在日常工作中偿还技术债
- 有明确的接口技术规范。例如RESTful
- 跨模块/团队开发时，有接口设计文档，并且有版本化管理
代码评审
- 有代码评审活动
- 代码检查单，用于自查
- 代码评审结果中的问题能够被及时修复
持续集成
- 代码静态分析工具是否整合在持续集成工具上
- 提交后进行自动的构建与测试
- CI 构建失败问题，开发团队能够第一时间修复
- 配置、脚本、测试代码等代码是否全部代码化
- 基础设施是否足够自动化
- 基于主干的开发，并小步提交
持续部署
- 滚动发布
- 金丝雀发布（蓝绿部署）
- 每个环节有健康检查，健康检查不通过自动回滚，部署失败
质量保证
- 代码静态分析
- 测试参与整个迭代周期
- 测试是否有用例产出
- 单元测试
- API 测试
- 自动 E2E 测试
- 性能测试
团队文化
- 持续改进
- 敏捷运作过程中有对浪费项的识别和分析
- 每个迭代执行回顾会，并识别改进措施
- 业务目标/研发效率/研发质量（JIT）度量并制定改进目标
- 进行周期性的目标设定和改进，例如缺陷密度值
- 交流分享
- 在部落内/小组内定期贡献话题分享
- 职责共享
- 成员明确自己和其他成员的任务瓶颈，并主动上报
- 团队成员主动参与各种日常活动，并积极提供建议
- 代码公有制，团队主动修复 CI
沟通和协作
- 会议
- 站会能否高效完成
- 回顾会议是否有明确改进项目，并被监督执行
- 计划会议是否提前准备
- 需求澄清会议是否关键角色都有参加
- 沟通
- 是否是以特性团队的方式沟通和协作，重沟通轻文档
- 面对面沟通，BA-DEV-QA 都坐在一起
- 知识传递
- 知识沉淀，通过 wiki 平台维护各种文档
- 是否有 onboarding 培训
- 测试用例是否能持续更新和维护
- 项目 readme 是否详细