|
一、敏捷团队成熟度的目的项目管理者联盟
这里参考CMMI的相关内容并结合敏捷特点可知，使用敏捷团队成熟度的目的是通过某种建模方式(敏捷团队成熟度模型)来描述其敏捷能力的分级，从而让团队知道其当前能力(as is)，以及在敏捷团队成熟度模型的定义范围内，找到未来的发展方向和目标(to be)。项目管理者联盟
简而言之，敏捷团队成熟度的目的是为了帮助团队定位其在其所处环境下的能力。项目管理者联盟
二、敏捷团队成熟度的特殊性项目管理者联盟
这里的特殊性，其实是敏捷自身的特殊性带来的──敏捷本身不是流程、框架、方法论，更多的是一种理念(mindset)，因此，在度量敏捷团队成熟度时候，无法绝对的通过文档、流程、交付物来进行定义，毕竟在实施敏捷的过程中，情景(context)起到的作用非同凡响。项目管理者联盟
因此在度量敏捷团队成熟度的时候，我们需要回归到敏捷自身的特点，而不能寄希望于所谓的“标准”、“流程”、“方法论”。项目管理者联盟
这里还有一个需要注意，定义敏捷团队成熟度的时候，最好不要将其约定到某种框架或者方法，比如Scrum 或者Kanban或者XP，我们没有能力或者必要为他们分别建立一个成熟度模型。这里我们要定义的是敏捷团队成熟度。项目管理者联盟
既然定义的是敏捷团队成熟度，那么此时就需要回归到敏捷的自身特点，这也是下面我在设计某个敏捷团队成熟度模型中的主要思考方向。blog.mypm.net
三、一种成熟度模型初步构想项目管理者联盟
结合敏捷特点，以及ITIL 4中给我的一些启示，这里做了一个简单的敏捷团队成熟度模型。项目管理者联盟
这里的模型思考点从PPTV 四个角度出发：项目管理者联盟
• P，People，人的因素转自项目管理者联盟
• P，Process，过程因素项目管理者联盟
• T，Tool，工具因素项目管理培训
• V，Value，价值因素项目管理者联盟
这里有一点需要注意，敏捷本身不是流程，以及该模型需要兼容不同的框架，所以第二个流程P会被机制Mechanism 代替，所以最后的模型就会变成PMTV。项目管理者联盟
V，Value，价值因素项目管理者联盟
把价值因素放到最前面，相信没有人会反对，毕竟敏捷一直在强调“交付价值”。项目管理者联盟
但“统一价值度量”基本上是不可能完成的任务，而且如同我们前面所说，敏捷需要严格考虑情景，所以这里我们放弃对价值的直接度量，转而开始度量“是否具有完备的价值交付度量体系”，即确保团队的交付物是具备价值并且可以度量，避免团队进入一种浑浑噩噩只知道做事，不知道做的怎么样以及价值在哪里的情况。club.mypm.net
至于敏捷自身的价值，我个人并没有将其思考在内。毕竟敏捷是否有价值，必须是依赖于敏捷是在团队交付过程中提供帮助，否则就会变成“为了敏捷而敏捷“。项目管理者联盟
M，Mechanism，机制因素项目管理者联盟
这里机制所代替的基本上都是对敏捷强调的一些原则相关，具体包括：项目管理者联盟
交付周期是否足够短──每个故事(或者需求、任务、Bug)流动时间是否满足组织对团队的诉求，具体数值可以根据不同环境自行定义;项目管理者联盟
是否具备持续交付能力──每个交付物，是否可以持续的被验收，甚至被发布上线(这里其实是已经是持续部署了，根据不同团队情况可选)，这里可以通过百分比的方式进行定义，有多少需求是开发完成后就可以交付或者发布，通过不同的百分比来进行本项的评分;项目管理者联盟
是否具备持续改善的机制──团队是否会在开发过程中对团队的绩效表现进行反思并提出改进方案。
|
