这是鼎叔的第一百二十一篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社），文末有链接。
敏捷团队从转型初始期到完全成熟期的发展并不是一蹴而就的。除了理解成熟度评估指标，敏捷团队也要分阶段把控提升的侧重点，逐步向高成熟度靠拢。本文也针对一线特性团队（Scrum team) 的敏捷管理成熟度提供了一套调查问卷。
不同成熟度发展阶段的目标达成
在不同的发展阶段，敏捷转型应该关注的达成状态应该是什么样子？为此，我们应该做到的最重要的事情有哪几件？
我们简单划分为三个阶段来阐述。
第一阶段，敏捷准备期（迭代 1 正式开始之前）
在敏捷真正启动运作之前，务必要关注这几件准备事项的落实：
划分好特性团队，规模适中，明确全职角色，尤其是铁三角 PO，SM，TL 的人员。
完成团队的敏捷基础知识和流程的导入培训。
PO 和 TL 带领团队清晰同步产品的愿景和中长期目标，梳理本产品和基础系统或其他产品的依赖关系，以及可能的重大风险。
团队协同工作的相关工具、平台、物资到位，比如研发全生命周期的工作平台和数据看板、知识库，物理看板，团队公共空间的各种信息布置等。
通过对历史的回顾，盘点之前的主要问题，明确可落实的改进行动项。
团队共创协同工作的准则，包括 DoR，DoD 规则，准入准出流程规则等等。
第二阶段，敏捷启动初期（迭代 1 开始的多个迭代，时间约 3-6 个月）
正式启动的前期，目标是确保团队运作的规则形成，逐步养成迭代中的好习惯。
基于产品愿景，PO 给出未来半年的路线图，包括里程碑。团队充分理解后，确认未来几个月的迭代交付和发布计划，保障交付的效果可量化。
PO 创建了产品 backlog（待办事项），整体梳理了产品需求列表，和团队进行了优先级排期和细化。TL 也带团队梳理了能支撑技术架构和预研的技术故事。
迭代目标清晰，能够成功发布 1-2 个 MVP 版本，尽早验收价值。
基本测试策略和质量基线得到明确，并能逐步按计划落实单元测试和自动化测试等。
针对团队情况，确认代码管理和分支策略，成功搭建持续集成流水线。
团队搭建了适合自己的可视化看板，建立了关键指标度量的仪表盘。
每次发布后能梳理分析遗留 BUG 并制定修复计划，也梳理了技术债偿还计划。
能高效进行每日站会，能让工作项及时流动。
第三阶段，敏捷稳定成熟期（6 个月以后）
敏捷运行稳定，开始逐步向着更高效，更成熟的组织形态稳步迈进。
形成稳定的发版节奏，团队对迭代速率的预测准确，验收标准严格落实。
定期更新团队学习成长计划，每个迭代结束都能做真诚的自我剖析，并准确找到下一阶段的改进痛点。团队能够形成产品业务全面视图，及时更新知识共享库。
所有用户故事都能进行充分的质量内建活动。需求颗粒度大小适中且流转顺利。
交付过程中的阻碍风险能够在极短时间被识别和处理。
干系人可以通过看板准确获取团队所有关键信息。团队成员能够被持续激励，主动协作。
敏捷成熟度调查问卷
对于希望成为全面的效能专家或者敏捷教练，仅仅推动开发在高效工程上的左移效果还是不够的，软件需求的本源在需求定义阶段，而需求的产生过程是否 “精益”，导致开发和测试阶段是否有返工和浪费现象。因此，建立一套驱动产品需求更加精益的管理框架就非常重要，涉及的知识在聊聊测试的左移和右看（合辑共 13 篇）也有相关描述。
需求精益成熟度和软件工程成熟度相辅相成，互相影响，共同提高整个团队的敏捷水平，且容易通过 Scrum 迭代复盘会来持续落地。
针对一个产品研发团队进行敏捷管理水平的度量，可以从源头拉动团队把需求设计得更精益。对需求优先级的梳理，需求合理估算和拆分，需求规格的基础质量检查（数值边界，性能，第三方依赖，兼容，资金安全等风险项），团队的 DoR 纪律，这些动作都有很好的持续促进作用。建议敏捷成熟度度量可以采用定期问卷方式，针对一个特性团队，让一线成员做直觉式评估即可。
以下给出鼎叔设计的敏捷成熟度调查问卷（示范），供读者参考，对不同业务团队基本都适用，问卷内容也是对本公众号之前介绍知识的回顾，可以理解是团队敏捷实践水平调查的一个聚焦子集。
问卷说明：本问卷不针对特定某个需求做调查，也不是针对一个项目做调查，而是对特定一线特性团队（Scrum team) 的敏捷成熟度做调查。
本问卷由一线特性团队成员自愿填写（2 人或以上），针对近一段时期在团队中的感受，诚实打分。本问卷评分与考核和惩罚无关，仅提供一面镜子，帮助一线特性产品研发团队自主修炼，提高需求品质，减少技术侧信息讨论不足导致的浪费活动。
问卷结果仅作团队内调查，或者公司改进参考，可以匿名填写。最终成熟度得分由各个问题的权重得分累加而得。
通用评分标准：
5 分 - 本团队在该行为项能完成做到位，一贯保持高水准，团队形成默认纪律（文化）
4 分 - 本团队在大多数情况下能有意识进行相关实践，效果良好，局部有待改进
3 分 - 本团队有时会进行相关实践，但效果一般或水平不稳定，有两项或以上表现需要明显改进
2 分 - 本团队刚开始（或偶尔）进行相关实践，还没有完整掌握，或者运行不顺利，或者仅有个人实践没有团队实践
1 分 - 本团队没有关注到该项内容，基本没有相关实践
问卷内容：
请先填写个人姓名，所属特性团队，问卷针对的业务（产品）。然后对下列问题基于第一直觉评分。
1、是否清楚本产品的愿景？
5 分 - 过去一年有过关于产品愿景深入讨论，对其长期目标达成共识，并在日常工作中经常有所体现，清晰知道产品的市场定位和满足用户的哪些价值。
4 分 - 有关于产品愿景的宣导和讨论，理解产品聚焦的用户价值。但是不太清楚愿景从何而来，对于市场定位模糊。日常工作有时会体现愿景目标。
3 分 - 有关于产品愿景和达成用户价值的宣导，但是没有具体讨论，愿景及长期目标一直没有更新，也没有体现在日常工作体现中。
2 分 - 有过针对产品愿景的探讨，但是没有形成共识
1 分 - 本团队没有关注到该项内容，基本没有相关实践
2、是否有明确的用户画像？
5 分 - 通过丰富的用户数据分析和用户访谈，综合利用定量分析和定性分析，梳理出典型的用户画像，给出了每一类典型用户的产品使用偏好描述
4 分 - 有基于真实用户调研得到的用户画像内容，有典型用户的产品使用行为分析，但是描述质量一般，数据刷新慢，或者分析手段单一
3 分 - 有简单的用户画像内容和典型行为特征，但是调研数据少，分析信服程度不高
2 分 - 没有给出完整的用户画像内容，或者严重缺乏背后的分析数据和逻辑
1 分 - 本团队没有关注到该项内容，基本没有相关实践
3、是否有用户故事实践？
5 分 - 针对核心复杂功能，召开用户故事的研讨会，利用用户故事卡片进行高效交流。团队能熟练地把需求拆解为用户故事，基本上能明确用户角色和故事场景，并能通过对话澄清大多数需求的误解
4 分 - 大部分需求熟练应用用户故事方法进行安排，角色和场景明确。对用户故事的深度研讨比较少
3 分 - 有时会进行用户故事的规范化实践，但是不普及，对相关知识没有形成团队习惯
2 分 - 团队没有进行过完整的用户故事实施，只是学习过相关知识
1 分 - 本团队没有关注到该项内容，基本没有相关实践
4、是否定期有上下游需求研讨对齐会议？
5 分 - 重要发布前（至少 3 个月一次）和上下游的一线业务团队会有深度研讨，明确互相之间的各种发布依赖风险（包括接口稳定性，性能，资金安全等），并给出风险缓解措施并执行到位，上下游清楚彼此未来一段时期的发布特性
4 分 - 有上述研讨和较好的共同产出，但是节奏不固定，研讨还不够深入，或者上下游风险梳理不够完善，缓解措施产生效果不突出
3 分 - 偶尔有上下游需求对齐研讨，但是产出成果有明显风险缺失，或者拿出的缓解措施没有严格执行
2 分 - 按需和上下游对齐风险，以部分专项为主，没有梳理完整风险策略和缓解意识
1 分 - 本团队没有关注到该项内容，基本没有相关实践
5、是否为核心需求（其开发量较大）设定了价值的衡量指标？
5 分 - 针对核心需求上线带来的核心价值，采用客观模型或数据分析，预测商业（或用户体验）价值衡量指标，可具体衡量，大部分能自动统计，并在上线后按约定规则统计，并给出反馈分析
4 分 - 针对核心需求上线带来的核心价值，针对历史数据分析，能给出预测商业（或用户体验）价值的基本衡量指标，上线后能进行统计和反馈。在指标分析的专业度和上线后的专业分析上，有所不足
3 分 - 针对核心需求上线带来的核心价值，能给出衡量指标和线上监控。但是缺乏足够的分析手段，上线后是否达成既定目标，也缺乏进一步的分析和同步
2 分 - 没有针对核心需求刻意衡量价值指标，除非管理/考核要求。只有产品的整体经营指标
1 分 - 本团队没有关注到该项内容，基本没有相关实践
6、是否合理估算需求（或用户故事，下同）？
5 分 - 能用团队都接受的方法快速合理的估算需求大小（故事点），大家基本无异议。对于团队一个迭代能完成的总故事点，有比较一致的理解，能够根据故事点和依赖关系合理进行需求排期
4 分 - 大部分需求能用团队接受的方法合理估算，团队基本认可，对于每个迭代能完成的总故事点估计有一定的偏差，多数情况下能根据故事点调整需求的合理排期
3 分 - 能针对部分需求进行团队估算，但是方法比较单一，准确度一般。团队对于迭代能完成的故事点总数不是很一致，对于放入需求的数量和大小没有刻意优化
2 分 - 团队没有例行进行需求大小的估算（或者准确率低），也不太清楚迭代完成的总故事点数量。需求评估工作量由个人主导完成
1 分 - 本团队没有关注到该项内容，基本没有相关实践
7、是否合理拆分较大的需求（或用户故事，下同）？
5 分 - 团队能掌握多种拆分技巧，针对较大需求（超过 5 天以上）进行拆分，确保迭代内安排的需求都能完成且可以工作（测试验收），大部分需求开发量都在 2-3 个工作日内
4 分 - 大部分情况下，较大需求能用团队接受的方法合理拆分，并大多能在本迭代内完成可交付。但是拆分手段还不能应对一部分需求情况
3 分 - 能针对部分较大需求进行合理拆分，但是手段比较单一，拆分后仍然有偏大的子需求，或者不能保证本迭代内完成开发并测试验收
2 分 - 团队没有形成成熟的需求拆分实践手段，不知道如何拆分出可独立验收的需求。需求拆分工作由个人主导完成
1 分 - 本团队没有关注到该项内容，基本没有相关实践
8、是否设置需求优先级（或用户故事，下同）？
5 分 - 产品负责人维护完整的需求 backlog，有明确的优先级确定手段，团队按需求大小和优先级给迭代合理排期，遇到插入需求，按优先级决策是否替换迭代中需求
4 分 - 产品负责人维护完整的需求 backlog，优先级确定因素比较单一。团队按需求大小和优先级给迭代合理排期，但遇到插入需求，由产品负责人决定如何取舍
3 分 - 由需求清单和简单的优先级，但是没有严格的优先次序管理及其逻辑。团队排期会参考优先级，遇到插入需求，通常是加班或者缩短测试周期搞定
2 分 - 对团队而言，优先级聊胜于无，经常是所有需求都很重要，插入需求也很重要。由个别人管理上线优先顺序
1 分 - 本团队没有关注到该项内容，基本没有相关实践
9、是否有需求验收标准和验收用例实践？
5 分 - 针对每个子需求（或用户故事），在需求评审完成前都给出明确的验收标准和验收用例，数量适度，开发结束时确保验收通过，团队已形成集体习惯
4 分 - 大部分需求或用户故事，都能给出验收标准和验收用例，质量上达到预期，但是给出时间偏晚，或者开发提测时可能并不关注验收用例
3 分 - 会针对部分需求/用户故事明确验收标准或者验收用例，但是质量一般，完成时机偏晚，也没有要求开发作为完成标准
2 分 - 团队并没有严格要求验收标准和验收测试用例，只是个别人员和高风险需求有相关实践
1 分 - 本团队没有关注到该项内容，基本没有相关实践
10、需求评审是否有质量关注清单？
5 分 - 团队有完整的质量评审项清单，形成了适合自己的评审纪律，在质量和效率中取得平衡，对于核心需求能严格执行，对于做得不佳的评审项，能够提供优秀范例给团队参考
4 分 - 团队有质量评审项清单，对于核心需求能默认执行，但是质量清单的项目过于繁琐，或者有时会遗漏低级问题，缺乏优秀范例参考
3 分 - 需求评审有重点关注质量风险，但是评审清单不够完整，质量也不高。有时因为要赶时间（或者被质疑）就放过该项，整改不到位
2 分 - 需求评审时没有完整的质量风险关注清单，主要凭骨干员工个人检查质量风险清单。
1 分 - 本团队没有关注到该项内容，基本没有相关实践
11、是否有进入开发阶段的准入标准- DoR（Definition ofReadyness)
5 分 - 团队制定了适合自己的 DoR 并持续改进，能够把各种质量共建要求在进入开发阶段之前完成，例如：验收条件，showcase 要求，需求文档要求，交互设计要求，测试排期等，开发阶段后的低级质量问题发生概率低
4 分 - 团队制定了 DoR 并确保执行，大部分质量共建要求都有涵盖并落实。但是 DoR 没有完全考虑本团队的实际，少量要求不合理，或者难以执行
3 分 - 团队制定了 DoR,执行效果一般，有一定的作用，但是持续时间不长，或者不能保证共建质量的效果，开发阶段后依然有不少的低级质量问题
2 分 - 团队没有制定能执行到位的 DoR 共识，主要凭骨干员工个人把关准入质量标准
1 分 - 本团队没有关注到该项内容，基本没有相关实践
当特性团队不断迈向高满意度的协作状态，成为了真正的 one team，其中发挥了重要推动价值的人就可以成为团队中的 scrum master，或者成为受大家欢迎的敏捷教练。