团队研发的本质
我们曾经接触到一家企业,它一开始只有8个人,那个时候每个月都可以发一两个版本出去,客户都可以用到,因为他们是做医院的信息管理HIS系统。他们觉得做得还不错。后来团队发展比较快,规模到了80人左右,却半年没发一个版本。这导致实施团队没脸见客户,因为客户说半年前提的需求怎么还发不出来。
这个时候悖论就来了:我们以为团队规模越大,研发效率就会越高,可以做越多的东西,但是我们发现团队规模大到一定程度,整个研发效率是会下降的,甚至降得非常快。
站在团队的角度来说,因为人多,协作越来越慢,协作的成本也越来越高。我们发现团队的研发模式,人越多越会有问题,因为冲突更多,等待更多。这里冲突是指代码集成发布过程中的冲突,而等待也是集成和开发过程中代码彼此的等待。
以下是两个具体的场景。
假设有两个程序员A和B一起工作,A一开始每次提交都把工作逐渐成功提交到线上去,然后B提交了一个版本,导致编译失败了。这时,A就无法提交,因为提交就会挂,要等待B修复问题才能提交,这时A的提交和B的工作就产生了冲突。
第二种情况,多个分支往同一个分支合并,FeatureA先合进主干,FeatureB晚了一点结果发现无法合并,因为基线不一样了,这时候必须先解决掉代码冲突才能合进去。
如上图,假设现在有3个人,A、B和测试C,每个人的点代表它做的任务,比如A一直在做自己的事情,每完成一个事情就开始做下一个事情,做完第三个事情的时候他觉得需要去找B联调一下,就给B发了一个ping,但是B有自己的节奏,在忙他自己的任务,所以并未马上响应A的请求。他发现有一个任务可以提测了,他就告诉了C,C发现有问题就马上Pong了回去,但是这时B在忙另外一个任务,没有响应。C发现B无响应,又发了一次Pong,这时B看到了A和C的消息,他先处理了A的事情,给A回复了一个Pong的消息。
我们发现,程序员和程序员,测试人员和开发人员之间,在整个的开