发布时间:2018-04-13
今天在与一个客户沟通的时候,谈到了对于敏捷开发团队的一些衡量标准的问题。怎么对团队进行有效的衡量,成了一个比较大的问题。
在我看来,这里的衡量指标,分成两种类型。
一类是衡量团队的工作情况与产出的,一般的衡量指标有,每个迭代的完成的故事点数,即团队速率的变化情况,还有就是团队的质量等,比如bug的情况,以及漏网缺陷等。
另一类是指团队的良性运转。比如说每次仪式团队的配合程度啊,团队成员对实行敏捷的满意度啊等衡量指标。
首先我们来谈一下关于衡量团队工作情况与产出的指标。这里的指标是实实在在讨论团队的工作情况的。其中的最典型也是最常用的一个度量是:团队的完成的故事点数,而最典型的度量方法就是通过燃尽图,如下图:
我们可以通过燃尽图了解到每个迭代我们完成了多少个故事点数,在有了几个迭代中的每个迭代完成的故事点数的数据之后,我们可以根据每个迭代完成的故事点数得到如下图所示的“速率图”,即横坐标表示有多少个迭代,竖坐标体现每个迭代完成了多少故事点数。
上面的这种度量主要是检查产品的生产力,我们也叫这个数字为“吞吐量”。
另一种测量团队能力的维度,为产品上线后发现的缺陷。这种类型的缺陷与问题非常直观地体现了这个团队对于问题的容忍度以及检测bug的细致程度。是一种非常直观地衡量团队能力能力的指标。
除了上面我们说的这种衡量指标之外,另一种衡量指标,其实更加重要,就是探讨团队成员对于整个敏捷过程的满意度。
要注意,这类指标通常都比较空泛和抽象,且需要长期与团队成员进行沟通才能得到比较靠谱的反馈。
这里有一个比较重要的指标是针对回顾会议的“ROTI”,全称是:return on time invested,主要探讨团队成员对于这次回顾会议的时间花费是否觉得值得。其实不论是回顾会议还是其他的仪式,都可以用这个度量来获得团队成员对这场会议的感觉。
另一种是做为敏捷教练,可以体会团队中的成员的冲突程度。在一个团队中,尤其是敏捷团队这种天天在一起工作的团队,冲突是难以避免的。敏捷教练需要及时调节这种团队内部产生的冲突,努力不要让这样的冲突升级。
在这里我们要明确的是,冲突本身是不会不存在的,如果你每天都发现你的团队江山一片大好没有任何问题,可能暗地里就已经波涛汹涌。
Copyright © 2020 All Rights Reseverd Designed by 5thspace.net 备案号:沪ICP备15017019号-1