团队纪律–不能忽视的基础

当我从学校毕业成为一名程序员时,我所在的工作环境以令行禁止而闻名的,这对我的工作风格产生了深刻地影响,在我理解中纪律是工作本身的一个天然的组成部分。作为团队的一员,就应该积极地遵循团队的规则(或者说团队纪律)。

然而我的理解不代表他人的理解,在接触了很多的团队中,我看到了大量违反基本规则的行为,包括在最初严格的环境下这种行为也依然大量存在。

慢慢的我发现很多表现良好的团队都有一个共同的地方:他们都有一套自己的团队规则,并且在每天的工作中直觉地遵守。相对比于普通团队,不在于他们有什么特别好的方法和工具,而在于他们会去做,而且坚持做。他们在每次迭代之前一定会把需求细节讨论一遍,把问题点都列出来并且有责任人。他们开会时总是不迟到,并且当有人过分陷入细节时,主持人就会跳出来打断他。构建失败时,代码提交人一定会马上查看并尽快修复构建问题,同时通过即时消息周知到大家。而在另外一个团队:老是听到队员在抱怨需求在开发的时候还没有细化,可是迭代前需求文档发出来时他却没有提什么问题。开会10分钟了,关键的开发人员还没有到,哦,我在解决一个紧急Bug。构建失败了,哦,我知道,这个特性我这两天马上开发完,很快就会构建通过的。

很多队员曾问过:“实施敏捷方法对团队有什么特别的要求吗?”对于这个问题,在以前我会鼓励他们不要顾忌太多,立即动手尝试敏捷方法。现在我的看法有一些改变,也许是看到了有些团队在实施敏捷实践后取得了一定成效,但是过了一段时间后出现倒退,最后甚至慢慢退回到原始状态。我不知道这样的经历对团队是好是坏,我很担心的是当他们再听到敏捷的时候,他们会想:哦,那种方法我们试过,没有什么神奇,看来不适合我们。如果有人再问我这个问题,也许我的答案会变成:“是的,实施敏捷方法对团队是有要求的。首先你要有勇气做出改变,而且要有勇气坚持。另外引入的团队新规则(团队纪律)要在日常工作中不断地被团队遵守。”

团队纪律可能过于基础,针对它的讨论并不多。我承认以前低估了它的重要性,现在团队纪律成为我判断一个团队成熟度高低的一个重要基础条件。

敏捷是一个过程,不是一个状态。不是说这个迭代你做好了,你就敏捷了,你就可以放松一下,下个迭代就可以省略迭代规划或者迭代回顾。就像学习一样,不是说你大学毕业拿到证书开始工作挣钱了,就不用学习。学习是活到老学到老。

要让团队是敏捷的,团队纪律是不能忽视的基础。

发表评论

电子邮件地址不会被公开。 必填项已用*标注