SCRUM节外生枝（三）

 

上接：SCRUM节外生枝（二） 

 

3.       一个程序员卡壳了

 

有了一些工作经验的程序员（也许可以扩展到所有的技术人员），都遇到过这样的情况：在一个本以为容易的技术实现上遇到未能预测到的难关，长时间无法逾越。本来一个小时能完成的Feature，可能因为一个Severe 0 的Bug，折腾得一天下来也无法完成，而后的一段时间，可能还在这个问题上绕来绕去，后续的工作都因此停滞，更糟糕的是，别人的任务也会因为依赖于他的任务而被拌住（Blocked）。

相对于程序员的“顺流”状态，我称这时候的程序员“卡壳”了。一个程序员卡壳了，是个微观问题。但是，你卡壳耽误3天时间，过两天他卡壳耽误2天时间，整个项目的交付在不知不觉中就被拖延了。在SCRUM开发中，如果因为一个人的卡壳，致使其本人的任务，甚至其他人的任务被拖延2到3天完成，在短至2周的Sprint中，是一种极其令人沮丧的体验。

在SCRUM的教科书中，很少有提到这种情况该如何办？（可能我读的书太少。如果有，请告诉我。）我们只有再读读SCRUM的原则，看看哪一条能给我们指条明路。还好，我们发现了“集体所有权（Collective Ownership）”这一条（见《SCRUM敏捷软件开发》第9章）：

 

“所有的开发人员共同负责开发过程中的所有产出内容，特别是代码和自动化测试。”

 

好吧，不要再让卡壳的程序员，看到自己和别人被拌住，而急得冒汗了。来吧，所有被绊住的人，或者此刻闲下来的人，都请聚过来，我们可以结对编程，一起分析代码，解决Bug。“我不太懂这部分代码。”那也没关系，了解出现的问题，打开一个Google，搜搜看有没有别人遇到过同样的问题。总之，不要在那里打游戏了，过来帮帮忙，咱们都是一条绳上的蚂蚱。不要将SCRUM理解为：在Sprint中每个人都有各自的任务。要理解为：所有人都有共同的目标。

集体所有权是个好东西，但是这个氛围的培养谈何容易。很多企业中，每个程序员都只负责各自管辖的那些代码，好学一点的，能看看别人的程序，大多数都是马路警察，懒得看其他人的“烂”代码。我们的经验是，每个成员加入团队的那一刻起，他的Manager或者Lead，就要要求他尽量多地熟悉每一个模块，每一个组件，每一个层次的代码，不断地分配给其不同部分代码的编写和修改任务，不让其在脑子里出现“哪段代码是他的，哪段代码是我的”的想法。我们还曾尝试经常交叉变换程序员负责开发的功能模块，以促使他们学习系统中的新东西。原来我们分Server和Client两个行政上的Team以分别负责2端的代码，后来这个也取消了，当一个程序员实现一个功能时，它既能改UI和客户端的逻辑代码，也能改服务器端对Request的处理代码。

要想不让“卡壳”影响进度，努力是从新人刚刚加入团队的那一刻开始的。

 

（待续……下一节：太多的外界干扰）