随着敏捷开发方法越来越流行，如何衡量一个团队的敏捷程度变成了老板和经理们看重的一个东西，那么，我们如何衡量一个团队的敏捷程度呢？
“守 破 离”源自于日本剑道学习方法，后发展到其他武术与其它行业。这是百度百科上的一句话，同样，“守 破 离”也适用于敏捷的衡量标准，让我们看看守破离在敏捷上的运用。
守， 即团队是否能按照scrum的流程去实施敏捷，如团队中是否有三个角色，团队是否能按照敏捷的方法去开四会（早会，计划会，检视会，回顾会）等等。
破， 即团队是否能根据团队自己的状况，去突破敏捷原有的部分规则，去到更高的层次，比如是否根据敏捷的价值观去增加其它的一些东西，例如代码审查会议。
离， 即团队的成员已经非常熟悉敏捷的流程和规范，团队成员已经能对敏捷的价值观驾轻就熟，团队根据自己的状况自己制定相关的实践，但所有的实践都是符合敏捷的价值观的。
看完上面的东西，是不是觉得很虚，很空幻？来点干的吧，谈谈我自己对衡量敏捷程度的看法。
1. 团队是否自组织？
一个团队的敏捷程度，我个人认为此项标准是最高要求，即如果SM或者Team Leader不在的话，团队是否能保质保量的开四会;如果TL或者SM不在的时候，是否有人去关注质量？
请看“一个成功敏捷团队的失败历程”这篇文章，这是一个相当典型的失败案例。当有成员不按照之前的实践走的时候，是否会有成员站出来提醒。比如开发任务的DOD是要写junit test的，但有一次因为production 有defect,有几个同事去救场去了，导致junit test没有写，在开检视会的时候，团队是否坚持原来的DOD（SM和TL都不在），尤其是当这种苗头出现的时候，是否有团队站出来提醒要坚持DOD？
2. 团队是否有持续改进？持续改进，我觉得可以从以下几个方面着手。
1）我们production上面的bug数量是否在逐渐减少?
2) 我们的测试覆盖率是否在逐渐增加？
3）我们开会的效率和质量是否有提高，就是开会的时长是否比以前短了（更高效了）。
4） devops的能力是否在逐渐增强，比如原先没有自动部署的，现在有自动部署了，原先没有自动化测试的，现在有了。
3. 团队是否具备周发布，日发布，随时发布的能力？
具备这样的能力，不代表一定要每天发布，这个可以根据每个公司和项目的具体情况，但只要用户或者公司允许，团队是否可以随时发布客户要求的更改。
4. 团队成员的能力是否有提高？
以前我一直觉得，玩敏捷就是让团队变得更忙，教练来了之后，让我对敏捷的看法有所改观，敏捷能让我们的生产率提高，就是我们干的活多了，但并不意味着团队要加班，反而是团队在单位时间内干的话多了，只要不是重复的工作，团队的能力一定会有提高。所以实施敏捷后，可以看看团队成员的能力是否有提高，从技术方面，学的技术是不是多了，解决问题的能力是不是快了， 这有时也会成为敏捷团队绩效考核的一个指标。
5. 团队成员每天的工作是否大都工作在一件事情上？
在敏捷里，我们提倡每一位成员只干一个任务，因为这样成员可以将更多的精力关注一个任务上，而且这样更高效。
怎么样？你的团队敏捷吗？我的团队还在敏捷的路上.
相关文章
