你的位置:首页 > ASP.net教程

[ASP.net教程]如何衡量一个团队的敏捷程度


随着敏捷开发方法越来越流行,如何衡量一个团队的敏捷程度变成了老板和经理们看重的一个东西,那么,我们如何衡量一个团队的敏捷程度呢?
“守 破 离”源自于日本剑道学习方法,后发展到其他武术与其它行业。这是百度百科上的一句话,同样,“守 破 离”也适用于敏捷的衡量标准,让我们看看守破离在敏捷上的运用。

守, 即团队是否能按照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. 团队成员每天的工作是否大都工作在一件事情上?
在敏捷里,我们提倡每一位成员只干一个任务,因为这样成员可以将更多的精力关注一个任务上,而且这样更高效。

怎么样?你的团队敏捷吗?我的团队还在敏捷的路上.