|
本项考核点在于团队教练对敏捷框架的认知、研发流程的认知、教练技术、引导技术以及相关敏捷领导力的表现。项目管理者联盟
本项取决于组织对团队教练的期待，可以根据实际情况增删考核点。项目管理者联盟
本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议;项目管理者联盟
产品人员能力──这一项关注的是产品人员(包括但不限于PO、产品经理、BA等角色)在敏捷开发过程中能力与价值体现。项目管理者联盟
本项考核点集中在行业知识、需求编写(包括用户故事)、与业务方沟通表现、优先级排序等方面。项目管理者联盟
本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议;talent.mypm.net
T，Tool，工具因素项目管理者联盟
目前来说工具因素只考虑一项，即对信息发射源的使用。项目管理者联盟
是否正确使用信息发射源──信息发射源可以由团队自行选择与使用，但是需要确认团队是否正确认知了信息发射源，并且正确的使用了相关的信息发射源。项目管理者联盟
本项无法通过绝对的客观指标进行评分，需要询证并给出改进建议。项目管理者联盟
四、写在最后项目管理者联盟
这个模型肯定是有不适用的地方，包括但不限于缺失、错误等情况，这只是我针对现在看到的场景进行一些思考，以及在实践中做的一些尝试。有问题欢迎讨论，如果喷我，那么你就是对的🤣blog.mypm.net
在设计这个模型的时候，我的原则包含了几项：项目管理者联盟
减少对”技术动作“的要求。项目经理博客
比如对是否开站会、回顾会等内容完全不在意，追到这些事件背后的目的并具有相关的方案即可;项目管理者联盟文章
减少对团队工作模式的改变。项目管理者联盟
比如团队氛围不可以作为直接的要求，团队与团队之间就是会有不同，无法一刀切。项目管理培训
只有当其他的指标有问题，比如”交付周期过长“的时候，才会将团队氛围当做考虑因素进行思考，并作为改进建议提出即可;项目管理者联盟
成熟度评估不可以过于频繁，一般认为最少也需要6个月时间才可以评估一次，甚至一年评估一次也是可以接受的。项目管理者联盟文章
评估者与被评估者都需要明确知道，成熟度目的不是为了评估而评估，真正重要的是通过评估过程，得到团队改进的建议。项目管理者联盟
而这些建议的追踪与改善应该交由团队教练跟踪与执行;项目管理者联盟
这个模型肯定有问题，比如定量因素太少、定性偏多、访谈偏多导致的评估时间过长等。项目管理者联盟
这些在对敏捷团队成熟度评估中，目前来看都是无法回避或者解决的问题，只能在评估过程中，逐步将工作交付给团队级教练，由团队级教练日常追踪，最后由PMO 或者企业级敏捷教练抽查或者评审即可;项目管理者联盟
这个过程中必然会有弄虚作假，因此一定量的抽查也是有必要的;项目管理者联盟
该模型本质上是从不同层面来对团队进行检查，而这些指标最终还是需要结合团队实际情况进行修订，所以评估成熟度的过程，本身也是一个敏捷的过程。项目管理者联盟
|
