一、敏捷团队成熟度的目的

这里参考CMMI的相关内容并结合敏捷特点可知，使用敏捷团队成熟度的目的是通过某种建模方式(敏捷团队成熟度模型)来描述其敏捷能力的分级，从而让团队知道其当前能力(as is)，以及在敏捷团队成熟度模型的定义范围内，找到未来的发展方向和目标(to be)。

简而言之，敏捷团队成熟度的目的是为了帮助团队定位其在其所处环境下的能力。

二、敏捷团队成熟度的特殊性

这里的特殊性，其实是敏捷自身的特殊性带来的──敏捷本身不是流程、框架、方法论，更多的是一种理念(mindset)，因此，在度量敏捷团队成熟度时候，无法绝对的通过文档、流程、交付物来进行定义，毕竟在实施敏捷的过程中，情景(context)起到的作用非同凡响。

因此在度量敏捷团队成熟度的时候，我们需要回归到敏捷自身的特点，而不能寄希望于所谓的“标准”、“流程”、“方法论”。

这里还有一个需要注意：定义敏捷团队成熟度的时候，最好不要将其约定到某种框架或者方法，比如Scrum 或者Kanban或者XP，我们没有能力或者必要为他们分别建立一个成熟度模型。这里我们要定义的是敏捷团队成熟度。

既然定义的是敏捷团队成熟度，那么此时就需要回归到敏捷的自身特点，这也是下面我在设计某个敏捷团队成熟度模型中的主要思考方向。

三、一种成熟度模型初步构想

结合敏捷特点，以及ITIL 4中给我的一些启示，这里做了一个简单的敏捷团队成熟度模型。

这里的模型思考点从PPTV 四个角度出发：

P，People，人的因素

P，Process，过程因素

T，Tool，工具因素

V，Value，价值因素

这里有一点需要注意，敏捷本身不是流程，以及该模型需要兼容不同的框架，所以第二个流程P会被机制Mechanism 代替，所以最后的模型就会变成PMTV(完美逃开了苏宁的律师函。

V，Value，价值因素

把价值因素放到最前面，相信没有人会反对，毕竟敏捷一直在强调“交付价值”。

但“统一价值度量”基本上是不可能完成的任务，而且如同我们前面所说，敏捷需要严格考虑情景，所以这里我们放弃对价值的直接度量，转而开始度量“是否具有完备的价值交付度量体系”，即确保团队的交付物是具备价值并且可以度量，避免团队进入一种浑浑噩噩只知道做事，不知道做的怎么样以及价值在哪里的情况。

至于敏捷自身的价值，我个人并没有将其思考在内。毕竟敏捷是否有价值，必须是依赖于敏捷是在团队交付过程中提供帮助，否则就会变成“为了敏捷而敏捷“。

M，Mechanism，机制因素

这里机制所代替的基本上都是对敏捷强调的一些原则相关，具体包括：

交付周期是否足够短──每个故事(或者需求、任务、Bug)流动时间是否满足组织对团队的诉求，具体数值可以根据不同环境自行定义;

是否具备持续交付能力──每个交付物，是否可以持续的被验收，甚至被发布上线(这里其实是已经是持续部署了，根据不同团队情况可选)，这里可以通过百分比的方式进行定义，有多少需求是开发完成后就可以交付或者发布，通过不同的百分比来进行本项的评分;

是否具备持续改善的机制──团队是否会在开发过程中对团队的绩效表现进行反思并提出改进方案。本项无法通过绝对的客观指标进行评分，只能通过询证(找到对应的证据，包括但不限于参加改进过程、审查改进过程留下的文档、与团队进行访谈等方式)的方式进行评分，重要的是在询证的过程中给予改进建议;

是否具备研发过程信息同步机制──团队是否在开发过程中，有信息同步机制。信息同步机制不一定是站会，可以是团队认可的任意形式。同时本项还包括了对信息发射源的更新及时程度与更新机制的考量。本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议;

是否具备完备的工作计划机制──团队在开发过程中，是否使用了符合当前团队的计划方式，并尽可能的根据计划完成工作。这一项需要将计划的周期、计划完成率、计划透明度等考虑在内。本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议;

是否具备需求变更与应对机制──变更不可避免，团队是否选择了适当的变更与应对机制，对团队交付价值有着莫大的帮助。这里要注意，应对变更并非需要如同敏捷软件开发宣言第二条说的欣然接受变更，需要根据团队与开发工作自身特点来制定合适的方法。本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议;

是否具备完备的反馈机制──不论是日常工作中还是用户验收后给出的反馈，是否可以无障碍的传递给团队，并且团队可以根据实际情况对反馈即时调整(adapt)工作优先级。本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议。但是有一点需要注意，询证过程中，业务方的反馈至关重要，不可或缺;

团队是否使用了良好的研发实践──这里是较为少见的可以绝对度量的指标，包括是否使用TDD、测试代码覆盖率、是否使用自动化工具等。可以根据团队实际情况以及引导方向，进行适当的定制。一般认为没有TDD 的团队，本项得分必须是0分。

P，People，人的因素

人的因素应该是比较复杂的因素，大概率是因为人的因素太多。不过我们有办法做点事情：

研发人员能力──这一项的关注点在于研发人员是否有能力、按时按量的完成工作交付。这里将短交付周期剥去(在机制因素中体现过了)，单纯的关注团队能力是否足够。这里可以考虑的点是：技能覆盖面(是否包含了所有的能力)、T型人才占比、团队自我学习意愿等方面考虑。本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议;

团队教练能力──这一项关注的是团队教练(Scrum Master 或同等角色)在敏捷开发过程中能力与价值体现。本项考核点在于团队教练对敏捷框架的认知、研发流程的认知、教练技术、引导技术以及相关敏捷领导力的表现。本项取决于组织对团队教练的期待，可以根据实际情况增删考核点。本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议;

产品人员能力──这一项关注的是产品人员(包括但不限于PO、产品经理、BA等角色)在敏捷开发过程中能力与价值体现。本项考核点集中在行业知识、需求编写(包括用户故事)、与业务方沟通表现、优先级排序等方面。本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议。

T，Tool，工具因素

目前来说工具因素只考虑一项，即对信息发射源的使用。

是否正确使用信息发射源──信息发射源可以由团队自行选择与使用，但是需要确认团队是否正确认知了信息发射源，并且正确的使用了相关的信息发射源。本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议。

四、写在最后

这个模型肯定是有不适用的地方，包括但不限于缺失、错误等情况，这只是我针对现在看到的场景进行一些思考，以及在实践中做的一些尝试。有问题欢迎讨论，如果喷我，那么你就是对的。

在设计这个模型的时候，我的原则包含了几项：

减少对”技术动作“的要求。比如对是否开站会、回顾会等内容完全不在意，追到这些事件背后的目的并具有相关的方案即可;

减少对团队工作模式的改变。比如团队氛围不可以作为直接的要求，团队与团队之间就是会有不同，无法一刀切。只有当其他的指标有问题，比如”交付周期过长“的时候，才会将团队氛围当做考虑因素进行思考，并作为改进建议提出即可;

成熟度评估不可以过于频繁，一般认为最少也需要6个月时间才可以评估一次，甚至一年评估一次也是可以接受的。评估者与被评估者都需要明确知道，成熟度目的不是为了评估而评估，真正重要的是通过评估过程，得到团队改进的建议。而这些建议的追踪与改善应该交由团队教练跟踪与执行;

这个模型肯定有问题，比如定量因素太少、定性偏多、访谈偏多导致的评估时间过长等。这些在对敏捷团队成熟度评估中，目前来看都是无法回避或者解决的问题，只能在评估过程中，逐步将工作交付给团队级教练，由团队级教练日常追踪，最后由PMO 或者企业级敏捷教练抽查或者评审即可;这个过程中必然会有弄虚作假，因此一定量的抽查也是有必要的;

该模型本质上是从不同层面来对团队进行检查，而这些指标最终还是需要结合团队实际情况进行修订，所以评估成熟度的过程，本身也是一个敏捷的过程。