英国政治家，温斯顿.丘吉尔 说过一段话：
如果你让我说2分钟，我需要3周的时间准备。
如果你让我说半小时，我需要1周的时间准备。
如果你让我说1小时，我现在就准备好了。
达芬奇 留下了6000多页的手稿，其中包含了一句话：
简单就是终极的复杂。
今天，让我们来聊聊不一样的度量。
对于一个敏捷团队，怎样说明团队做得很好？
以终为始，我们希望团队达到怎样的状态？
1.拥有稳定的迭代速率
2.拥有接近100%的迭代故事完成率
3.达成迭代目标
4.交付的产品质量高，问题少，用户体验佳
5.系统稳定运行
6.达成业务目标
想要达到这样的结果，我们需要关注哪些指标？
1.迭代速率
2.迭代计划完成率
3.迭代目标达成率
4.业务目标达成率
5.线上产品缺陷数
6.产品体验用户反馈
其他：
功能发布后，系统性能数据变化趋势
系统连续运行无故障时间
核心的六个指标，外加两个系统性能（防微杜渐，关注趋势变化）和稳定性（稳定大于一切）指标。
你也许会问，为什么DevOps的核心指标：吞吐量，流动效率 都没有包含在内？
因为前面假设了，这是敏捷团队，假设团队以固定的迭代周期（1-2周）交付需求，并采用了点数估算的方式。这种情况下，这两个指标的作用减弱，属于非核心指标。
敏捷不应该追求尽可能快么？
敏捷追求的快，不是开发动作的快，而是价值交付的快。
将需求价值从高到低排列，始终遵循二八原则，优先交付价值最高的需求。
敏捷讲究的是以价值为中心，以持续稳定的迭代节奏，高质量的交付价值。
为什么是这6个指标？
迭代速率
-- 衡量团队的真实交付能力，便于对后续需求进行估算和排列交付计划。
迭代计划完成率
-- 迭代计划完成率代表着迭代前期的准备工作是否充足，代表着团队对承诺的兑现。
曾经有产品研发团队，因为这一项做的很好，并且在迭代过程中严格控制需求变化，而对业务产生了巨大的正面影响，带来了产品数据的巨大增长。因为迭代计划完成率倒逼着产品人员在迭代前期完善好产品需求，控制好自己迭代过程中修改和插入需求的欲望，促使产品经理进一步的去思考产品功能。并且也代表着研发团队对承诺的兑现，这是整个团队执行力的表现。（迭代周期通常为1-2周，时间已经很短了，要尽可能做好前期准备工作，有时候盲目追求快，会带来非常多的副作用。）
迭代目标达成率
-- 每一个敏捷迭代，都会有迭代目标，就像每一场球，都有进球目标。团队做了很多事情，但是最终因为个别故事、问题或资源，导致迭代目标未完成，这会导致穷忙的状态，目标却未达成，导致团队士气低落。
SCRUM GUIDE中提到，迭代（SPRINT）过程中不能做出有害于迭代目标的变化，如果迭代目标过时，可以取消迭代。迭代过程中的各种活动，都是围绕迭代目标进行，确保迭代结束时目标达成。
业务目标达成率
-- 产品上线了某些功能模块，上线后的效果和最初的设计是否一致，有多少偏差？有哪些值得我们思考的地方？以及后续如何改进和设计？
做到这一点很重要，需要配合数据埋点的效果统计分析，并且将分析结果，定期在团队内部沟通和讨论。
例如：
1）业务目标：XX功能上线，用户量在一周内新增10万。（功能上线一周后，新增了几千人。远未达到目标，然后就没有然后了，无人反思和追踪产品功能的设计初衷，而继续开始开发新的功能。）
2）业务目标：XX功能上线，交付业务团队使用。（功能上线了，业务团队却因为部分功能或种种原因，迟迟未使用起来，系统功能的业务价值并未得到体现。）
这些情况，本质上造成了大量的浪费，业务目标并未实际达成。
线上产品缺陷数
-- 衡量产品上线后，有无质量问题。将开发和测试融为一体，共同为产品质量负责。团队共同为质量负责的同时，也可以进一步分析缺陷类型和情况，进行系统思考和根因分析，找到改善质量的根本问题，并解决掉。
产品体验用户反馈
-- 产品功能上线后，需要建立产品功能用户体验的反馈和收集渠道。真正听听用户的声音，用来对我们规划的产品功能模块上线后的实际效果获得反馈。
例如：
1）小米的产品功能上线后，会在米粉社区获得产品功能的反馈，并且根据反馈调整产品功能。
2）蔚来汽车，也建立了类似的用户体验反馈渠道，来获得用户的反馈，并且持续改进产品体验。
一个迭代一个迭代，团队共同做出了努力，那么我们努力实现的成果，是否最终产生了实际的业务价值？
这应该是所有团队需要重点关注的事情。
需要建立需求复盘机制，在开放包容的环境下，大家仔细讨论需求上线后实际效果和前期规划时的偏差，讨论分析研究后，持续改进，并且对改进效果跟踪分析。
可惜很多团队，实际上都处于一直赶进度的状态下，团队持续付出了很多努力，最终却带不来业绩的增长，造成团队士气低下。作了一个功能，又做一个功能，产品也变成了功能的堆砌。
好的产品绝不是功能的堆砌，微信的成功，一直秉承了少即是多的原则。
乔布斯一直提倡“极简主义”，他相信“少即是多”的哲学思想，极简主义渗透到他苹果产品的设计以及他个人的生活，他一生都在践行这极简主义。
好的团队绝不会让自己陷入长期持续忙碌的状态，SCRUM的迭代名叫SPRINT（冲刺），为什么要这起这个名字？
我思考下来，全力以赴的冲刺后，会有短暂的休息、调整、思考改进。
这就像是比赛，一场比赛全力以赴达成目标，然后休息调整、思考改进，最终向总冠军的奖杯迈进。
我国古语云：一张一弛，文武之道。
以上是我对敏捷团队度量指标的思考，虽零散不成体系，但也希望可以关注真正应该解决的问题，最终可以给团队带来些许帮助。
