当一个产品团队采用敏捷开发模式时，如何来确认这个团队是否真的已经敏捷了呢？这个是非常重要的，在日常工作过程当中，团队的工作模式很大程度上会受团队负责人或者服务性领导的影响，有时候会因为这个负责人的一些个人工作风格，而使团队的敏捷模式偏离了方向，没有让团队真正的敏捷起来。前面一篇文章也介绍过，在敏捷开发模式团队内部，Product Owner和Scrum Master这两个角色非常重要，他们是带领整个团队前进的，下面的评估参考标准其实基本上是围绕这两个角色展开的。
一个团队花了很多钱请来了外部的培训师和教练，同时雇佣5个员工组成“敏捷办公室”为新的Scrum团队提供建议和帮助。他们失败是因为他们认为实施Scrum仅限于开发团队。发起敏捷转型的管理层认为，只给开发人员提供培训和支持就足够了。他们没有考虑到Scrum对产品经理、测试人员、UED等人员的工作带来的影响。如果这些地方没有改变，组织惰性会把整个团队带回原点。
Scrum简单但并不容易，原因如下：
1、成功的变革不是完全的自上而下或者自下而上；
2、结束状态是不可预知的，Scrum需要持续的改进；
3、Scrum在整个组织中是无处不在的；
4、Scrum和传统培训/教育是截然不同的；
5、变化来的比以往更快；
6、最佳实践是危险的，要找到适合自身的方法；
Scrum不仅是技术层面的转型，更意味着理念的革新，整个团队都要参与进来
1、团队要学会在没有大而全的计划的情况下开始工作；
2、团队要学会在没有详细需求文档的情况下，通过用户故事和交流分析和理解需求，开始设计和编程；
3、团队要习惯于频繁递交代码和持续集成；
4、团队是在高度透明的环境下工作，每个人的进展被所有人都了如指掌；
5、团队需要进行结对编程，需要频繁的沟通和讨论；
初级敏捷团队
1、Team内PO角色清楚，PO负责管理Product Backlog；
2、PO是需求的主要来源，并负责并从各方收集需求，并对需求负责；
3、PO负责Product Backlog优先级的确定，当变动发生时也是如此；
4、Team中有一个人可以承担Scrum Master这个角色的工作，基本上由此人长期承担Scrum Master的工作；
5、基本能够协调Team解决在Sprint内遇到的问题。但是对跨Domain的问题解决推动能力弱；
6、由Scrum Master协助团队成员进行维护Sprint Backlog，并培养团队成员自行维护Sprint Backlog的习惯；
7、Scrum Master负责主导和主持站会，站会在固定地点和固定时间，在标准时长内结束，Scrum Master对团队每个成员的工作内容都很清楚，可以通过站会发现大部分问题和风险；
8、Scrum Master负责各种会议的如期进行，如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等；
9、Scrum Master负责主导和主持plan meeting，给出工时的评估方式，给出本次sprint的计划内容和优先级别，引导大家进行sprint内容的拆分，引导大家完成工时的评估；
10、Scrum Master负责主导和主持总结会议，主要由Scrum Master负责总结本次迭代的优点和缺点，并针对缺点制定出改进措施并进行跟进；
11、Scrum Master负责监控风险和进度，并能知会给利益相关人；
12、Team大部分情况下能够完成对DOD的承若；
中级敏捷团队
1、PO负责管理Product Backlog，Team认可Product Backlog内容；
2、Team会协助PO收集需求，也会积极提出需求，Team认可需求并对需求负责；
3、PO协助Team进行Product Backlog优先级的确定，当变动发生时也是如此；
4、Team中Scrum Master这个角色的工作有Backup，当Scrum Master不在时，Backup可完全承担该角色的工作；
5、完全能够协调Team解决在Sprint内遇到的问题。对跨Domain的问题解决推动能力较强，但对跨部门的问题解决推动能力较弱；
6、团队成员自行维护Sprint Backlog的习惯已形成，Scrum Master只需监督和提醒；
7、Scrum Master协助站会有效进行，站会在固定地点和固定时间，在标准时长内结束，团队成员对于其他成员的工作内容都很清楚，团队成员可以协助Scrum Master发现一些问题和风险，大部分问题和风险还是由Scrum Master发现；
8、Scrum Master协助各种会议的有效进行，如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等；
9、Scrum Master协助plan meeting有效进行，和团队成员共同商讨确定工时的评估方式、本次sprint的计划内容和优先级别，进而共同完成sprint内容的拆分和工时的评估；
10、Scrum Master协助总结会议有效进行，和团队成员共同商讨总结本次迭代的优点和不足，能够针对不足制定出有效的改进措施并进行有效的改进，而优点能够继续保持；
11、Scrum Master主导，团队成员参与监控风险和进度，并能定期通知给利益相关人；
12、Team共同完成对DOD的承若；
高级敏捷团队
1、Product Backlog由PO发起管理，由Team共同参与讨论完善；
2、Team共同提出和收集需求，共同对产品负责；
3、Team共同对Product Backlog优先级进行确定并负责，当变动发生时也是如此；
4、Team中任何一个人都可以承担Scrum Master这个角色的工作；
5、可以帮助Team跨越Sprint中遇到的一切障碍，对跨Domain和跨部门的问题解决推动能力均较强，保障DoD按约定完成；
6、团队成员自觉维护Sprint Backlog，Scrum Master定期检查团队成员维护Sprint Backlog的情况；
7、团队成员积极地参加站会，站会高效地效进行，站会在固定地点和固定时间，在标准时长内结束，团队成员对于其他成员的工作内容都很清楚，团队成员积极提出问题与风险，和Scrum Master共同发现所有问题和风险；
8、Scrum Master辅助，团队成员主导各种会议的有效进行，如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等；
9、Scrum Master辅助，团队成员主导plan meeting，Team共同对工时评估的结果，本次sprint的计划内容及拆分结果，优先级别确认结果负责；
10、Scrum Master辅助，团队成员主导总结会议，Team共同对本次迭代的结果负责，能够共同认识到不足的根本原因所在，后期所有团队成员都积极有效的改进，将不足逐渐转变为优点，而优点能够越做越好；
11、Team共同积极监控风险和进度，并能及时通知给利益相关人；
12、Team从专注功能实现专为专注产品实现，Team有能力识别产品的正确路线，共同促使产品不断被完善；
同样都是十二条参考评估标准，越成熟的敏捷团队，不光对PO和SM的要求越高，还对团队成员的要求也逐渐提高。在敏捷开发团队内部，是一个互相学习，互相进步的过程，可以促进整个团队的能力和水平的提升，因此对团队的发展是非常有好处的，特别是团队内部职场新人比较多的时候，化大成本去培训、去传帮带，还不如让他们在团队工作当中去学习和成长，这样可以更加快速的帮助他们提高，也提高了团队整体的实力。
评估敏捷团队的4个平衡指标
无论你对度量标准有什么看法，公司都会期望以此来评估你的团队。你不想只衡量一个方面而忽略其他信息，但你也不希望评估太多的东西，以至于分散了团队的焦点。以下四个指标可以均衡地评估敏捷团队的生产力，工作质量，可预测性和健康状况。
评估项目的指标数量与构建项目的指标数量一样多。不幸的是，这些指标中的很多都没有用。埃里克里斯称他们为“虚荣指标”，因为他们看来不错，让你感觉良好，但没有可操作性。
无论你你对度量标准有何看法，在（项目）结束那天，企业都会期望获得评估结果。以“帮助团队自我反思和提高”为标准，并提醒你“你的里程可能会有所不同”，以下是我对敏捷团队的四项指标，以及一些有效经验。
1四个联锁小组度量
为什么有四个？如果你只是衡量一个指标的话，就很容易陷入到狭窄的认知中。无论是团队专注于制定指标（通常是通过改变原有体系）还是管理层使用这些措施来推动所有决策，你最终只能得到一个看起来不错，但实际上已经处于悬崖边上的产品或组织。
同样，有多达10个指标，更可能导致团队的不同部分聚焦不同的指标，从而影响团队的架构。人类最好每次处理三到五个概念，因此四个主要度量标准看起来就像是最佳的仪表板。
周期时间
周期时间是你与生产力的直接联系。周期时间越短，给定时间盒中的事情越多。你可以从工作开始到功能完成时进行测量。在软件开发的背景下，我更想把这个时间看做是大家实际工作在软件开发上的时间。
测量周期时间最好是通过你选择的敏捷生命周期工具自动完成，即使使用物理任务板进行度量也能为你提供有用的数据。
缺陷逃逸
这项措施是客户满意度与团队之间的联系。缺陷率越低，客户对该产品的满意度越高。缺陷率很高，即使是最棒的产品也会有很多不满意的客户。
你可以通过产品发送给用户后发现的问题（bug，缺陷等）数量来衡量。在一个故事完成之前，它仍在进行中，所以关注故事的执行比追踪正在进行的缺陷更可取。
计划与完成比率
此度量标准是衡量可预测性的一种方式。如果一个团队承诺30个故事并且只交付了9个故事，那么PO就有30％的机会获得他们想要的东西。另一方面，如果团队承诺10个故事并交付9个，则PO有大概90％的机会获得他们想要的东西。
衡量是一个简单的运用，记录团队在sprint开始时承诺的工作量，以及结束时他们完成的工作量。
幸福感
这是团队的“健康”指标。它创造了将其他三个指标置于更好环境中的意识。如果其他指标都是完美的，而幸福感很低，那么团队可能会很快就筋疲力尽了。
把它建立到你的sprint回顾中。在每次回顾会上（无论规模）都让大家协商自己的幸福指数。从一个sprint到另一个sprint的过程中观察这些数据的趋势。
为什么选择这些指标？
周期时间和缺陷逃逸是高度量化的，并且在各个行业都很好理解。较小的数字意味着你可以更快地提供更高质量的产品。我原本增加了计划完成比率，主要是因为这是团队可以立即产生实际影响的因素，所以这实现了“早期获胜”的想法。它在绘制可预测性方面长期有用。幸福指标是“人为因素”，它让我们衡量整个团队的健康状况。
前三项措施形成一个自我支撑的三角形。如果你的周期时间缩短，那么缺陷几乎肯定会增加。高计划完成比例可能非常好，除非周期时间已经过去了，这表明在每次sprint中团队完成得很少。最后，通过将幸福感与其他人分享，你可以看到等式中的人的一面。低幸福分数几乎总是潜在问题的标志，并且可能是其他事物的主要指标。
你可能想知道速率。我也跟踪速率，但我认为它有一个非常具体的地方。这四个指标是为了让团队在回顾中进行反思并关注改进的。
另一方面，速率是团队在sprint计划中使用的度量。它的唯一用处是粗略衡量下一次sprint需要做多少工作。如果分享管理链，它也可能被误用 - 有更好的方法可以预测一个团队何时完成或者其效果如何。
测量速度时，我测量故事点和故事计数速度。通过这样做，我发现该团队已经对其工作负载进行了内置的检查和平衡。举例来说，假设团队有三个sprint平均50个故事点和10个故事。如果他们的下一次sprint是48个点和9个故事，那么他们可能会完成所有的工作。如果他们超过了其中一个数字 - 比如说，做48个点但是20个故事（一堆小的） - 那么sprint可能会有风险，因为这是很多情境切换。如果他们超过这两个数字 - 比如说，达到70个点和15个故事 - 那么这是一个明确的警告标志，而一位优秀的教练可能希望与团队保持联系，以确保他们相信自己能比平均成绩好。
3行动中的指标
这些图表基于真实数据，并且是敏捷转型18个月左右的写照。我倾向于坚持1个为期六个月的滚动窗口，因为如果你远远超出这个范围，事情就会发生改变，并且与团队正在做的事情无关。
周期时间
峰值代表团队转向一个新项目，并且随着一系列组织变更，他们也快速的适应了新项目的工作。
缺陷逃逸
此图显示了一个相当典型的，已转移到跨职能角色和自动化测试团队的曲线。由于团队中的每个人都对故事和质量负有共同责任，并更加关注测试自动化，我们发现产品发布后的缺陷急剧下降。
计划到完成率
这个团队失去了ScrumMaster，这影响了它的整体性能，如第一个sprint的数据所反映的那样。在第二次冲刺中，有经验的ScrumMaster进来帮忙。早期的下跌代表团队习惯了一套新的规范，后来的下降是由于程序变化导致团队积压清晰度降低的结果。
幸福感
这些数据显示了ScrumMaster的支持如何改善了团队的整体健康状况。该图还反映了产品和组织的流失影响了团队以后的幸福感。
根据这些图表，我计划的第一件事就是与团队进行交流，并听取前几次sprint中发生的事情。计划完成率和幸福指标的下降足以告诉我可能会发生一些事情。低周期时间和缺陷逃逸会让我怀疑问题是团队外部因素造成的。
真正的挑战来自混乱的产品战略，这导致团队在优先级事项中来回切换。积压变化的波动导致低质量的故事。当他们挖掘出一个他们不明白的故事并转向他们所做的工作时，该团队的发展足够让他们停下来。这降低了计划完成比，因为并非所有承诺的工作都可以完成，而周期时间很短，因为他们处理了他们已经很好理解的事情。
