团队规模与代码质量的关系


在过去的几年里,我有机会观察了很多软件团队。俗话说,这些团队形形色色。毫不奇怪,它们产生的输出覆盖了软件质量的整个范围。

把团队成员的集体技能水平和培训作为决定质量水平的一个突出因素,这几乎不会成为头条新闻...但是还有什么影响它呢?团队规模?最近,我发现自己在开会前的一段休息时间里思考这个问题。

某个团队的规模能优化代码质量吗?如果能,一个团队有多少人?这种思路让我把自己的经历作为例子。

大型团队功能障碍案例研究

多年以前,我和一个大团队呆了一段时间。对于它的方法,这家商店毫不含糊地选择了瀑布,尽管我想象,像许多这样的商店一样,他们称它为“软件开发生命周期”或类似的东西。无论如何,需求和设计文档都在实现阶段之前。

除了大量的前期规划,代码库几乎没有什么有意义的抽象来从架构上划分它。结果,你有了一个庞大团队的完美孵化器。庞大的前期规划确保了资源分配的合理性。然后,错综复杂的代码库确保了“幻觉”是描述这样一种概念的最佳方式,即人们可以被分配任务,在这些任务中他们不会严重地影响彼此。

最重要的是,整个软件组织都有法规遵从性的代码审查任务。这意味着需要有人检查提交的每一行代码。如果没有更好的计划,这通常意味着最长任期的团队成员要进行审核。同样是最长任期的团队成员,他们创建了一个没有有意义的分区抽象的架构。

这一大堆情况弄得一团糟。当代码蔓延、腐烂和纠缠在一起时,团队成员为细节争吵不休。仅基于这一经验,少即是多。

大团队和谐案例研究

然而,后来我想到了几年后我看到的其他东西。那时,我已经习惯了在一家真正的大企业里冷静下来,帮助各个软件部门和程序推动软件工艺。这意味着利用我的经验来教他们一些东西,比如测试驱动开发、持续集成、持续重构等等。

通常,这类事情的交付机制有两个组成部分:小组研讨会和个人实践(我会与他们配对)。小组研讨会通常包括演示,然后小组练习使用a technique called Randori。这包括一对参与编码的人,而其他人观察。每隔一段时间,一对中的一个会去花生画廊,而另一个人会开车。

我们可以把兰多里概括为“的概念mob programming,其中整个团队或一组人都在处理同一个问题。有时候,这个客户站点上的团队正是这样做的,要么是尝试一种新技术,要么是解决一个特别困难的问题。

采用这种方法的团队可能看起来滑稽地过度分配。八到十个人花一整天的时间学习一门课程,甚至一种方法。尽管撇开效率考虑,这些团队生产出了高质量的代码。

这都是关于互动的

那么,什么给了?我们有两个开发人员对代码比率很高的团队。其中一个生产缺陷工厂,而另一个生产高质量的代码。

我们可以假设瀑布和敏捷有所不同,但是我不相信。这些方法更多地处理适应变化和反馈循环,而不是源代码的实际组成。此外,移动团队正在向敏捷方法过渡,所以它不那么简单。我们也可以为团队设定不同的技能水平,但是从理论上讲,第一个团队的平均经验远远超过第二个团队。

答案来自互动的本质。第一组每个人都离开,在真空中一次工作几周或几个月。然后,他们在代码审查时绕回来就细节问题争吵,任期的长短是最终的争议仲裁者。

第二个团队在没有一套角色概念的情况下走到了一起。从这种平等主义的立场出发,他们第一次出现的时候就产生了哲学分歧。这并没有让团队成员在几周或几个月的时间里对他们的想法保持依恋和防御。

因此,在质量谱的一端,我们有单独的贡献者筒仓和政治性的论坛来把他们聚集在一起。在另一端,我们相对最小化了群体政治,并提供了一个论坛,让最好的想法迅速涌现出来。

团队扩展时的代码质量

现在让我们进行一些归纳推理。考虑一个单人团队,这个人有多年编写高质量代码的经验。考虑到一个人的技能,有人可能会认为这是质量的最佳团队规模。

假设现实是一种不受欢迎的入侵。一个人不能按照必要的时间表交付,所以项目需要更多的团队成员。归纳起来,我们可以在以下两种情况下保持团队产出的高质量。

  • 我们雇佣技术相当熟练的团队成员。
  • 我们创建富有成效的协作模型。

如果这些都成立,更多的人意味着更多的质量,正如暴徒编程故事所证明的那样。更多的人合作意味着更多的眼睛去捕捉错误,更多的头脑有更多的机会产生最好的想法。

团队规模和代码质量的答案

在对团队规模进行了所有这些分析之后,我不得不将成本纳入到讨论中以结束讨论。毕竟,不管是谁掌握着财权,都会对“最佳团队规模”有很多看法。

你的团队的代码质量只会和团队成员的技能水平以及他们互动的效率一样好。因此,如果成本无关紧要,最佳团队规模的答案应该是“定义生产协作,然后越多越好。”获得足够的熟练开发人员来涵盖所需的功能,然后继续添加。如果你用完了“房间”,让他们配对。如果两人的房间不够了,就让他们“三人一组”等等。

然而,成本进入讨论。你不能雇佣地球上的每一个开发者(事实上,围攻最终会达到收益递减的程度),因为你最终会有有限的预算。相反,建立良好的协作实践,然后在预算允许的情况下雇佣尽可能多的有技能、兼容的人。

简而言之,相对于vis代码质量而言,最佳团队规模是“尽可能多的人在一起工作。”