敏捷项目中的团队管理

当我管理一个开发团队的时候，其中一个头痛的问题就是如何度量团队中个人的表现，以便在年底公司正式的Performance Review时能够公平地对员工作出评价，这对公司，经理和员工都是一个很实际的问题，与员工的经济与职业前途都密切相关。

虽说软件开发是属于创造性的行业，但其中还是有不少体力活的成分在里面，不是人人都那么争先恐后地去干的。于是我们挖空心思地去找一些可测量的参数用以衡量这个劳动强度，但可找到的不多，能找出来的有点也很难量化。比如，各程序员解决Defects的个数。在实践中，如果你的团队中有一个人能持之以恒地解决比其他人多的Defects，你心里知道他的表现是最好的，你也很愿意年终评定时给他高奖金和升工资，但作为一种机制，你不能够很科学地说Defects的个数是一个绝对的参数，也就是，你不能在年初就跟你的下属员工说，你们中解决Defects最多的人就是最好的，到年底肯定会升职长工资。最简单的理由就是Defect的复杂程度各有不同，很难将其归一化。

其实用什么参数才是最好可能并没有一个肯定的答案。选择和判断最佳表现其实也是一个“可能性的艺术”，是在动态中根据情况决定的。因此，在敏捷 实践中，对员工的评价也应该是化整为零，在每个Sprint中对员工的表现作出评价，以各个领域内积分的形式，使员工自己知道自己的客观表现。如果认为这些参数不能充分反应，员工也有机会及时向领导反映，而做领导的，也可以马上根据实际情况对记分进行加权修改，在第一时间解决问题，而不是留到年底再来慢慢回忆。