第2章 组织团队

软件开发项目的一大挑战是如何将项目人员划分成多个大小适中的团队，并让这些团队相互紧密合作。

随着项目团队从30人增加到60多人，我们开始遇到严重的沟通和协调问题，这是成长之痛的典型症状。所幸我们都坐在同一层楼内，所有项目人员彼此之间最远走过去也就是半分钟的距离。所以，我们可以毫无困难地开始实验如何以最佳的方式组织项目团队。实际上，项目团队在一起办公也许是此项目成功的最重要因素。

我们的团队结构是逐渐演变成下图这样的。

我们有五个团队：一个需求团队、三个功能开发团队和一个系统测试团队。还有一些人不属于以上团队，他们负责处理专门事务和协调工作，这些人是项目经理、项目管理专员、配置经理、电子学习专家、性能测试专家、开发经理、教练等。

三个功能开发团队基本上都是Scrum团队，也就是说，每个团队都在一起工作，多职能，自组织，能够开发和测试完整的功能。关于Scrum的更多信息，请参见17.3节。

需求分析团队实际上是一个虚拟团队，所以团队成员并没有坐在一起，而是分散坐开，这样保证项目团队所有人都能够就近与需求分析人员沟通。该团队中有三个子角色。

❏ 一部分分析人员隶属于具体功能开发团队，从开发到测试全程跟进该团队负责的功能，全程回答问题并澄清需求。

❏ 一部分分析人员关注项目的大局，并不隶属于具体功能开发团队。他们着眼于未来，定义概要功能区域。

❏ 其余成员较为灵活，根据当前的实际需要承担上述职责。

测试团队的结构与虚拟团队类似，也有相应的子角色。

❏ 一部分测试工程师隶属于具体功能开发团队，帮助开发团队测试并调试功能。

❏ 另一部分测试工程师则关注项目大局，集中对发布候选版进行系统的整体测试和集成测试。负责协调这项工作的人被戏称为系统测试将军。

❏ 其余人员较为灵活，根据实际需要承担上述角色。

过去，项目团队都按专业角色划分。我们原先有彼此独立的一个需求团队、一个测试团队、三个开发团队，开发团队都没有配备测试人员或分析人员。这种模式不利于团队扩展，因为随着越来越多的人加入项目，沟通问题会越来越严重。每个团队都习惯于通过书面文件与其他团队沟通，而不是采用面对面直接交谈的方式，而且他们会把问题推给对方。每个团队都只顾完成自己团队的任务，而不关心整个产品。例如，需求分析人员写完需求文档并获得签发认可后，就认为自己的工作已经“完成”了，而不会全程跟踪该功能直到功能上线。

随着我们的开发团队开始转为Scrum式架构，各个团队具有了多职能特征，分析人员、测试人员和开发人员都坐在一起，团队之间的协作水平有了大幅提高。不过我们并没有彻底贯彻多职能团队的做法，还是有一部分分析人员和测试人员并不在功能开发团队里，这样他们就可以专注于项目大局，而不是单个功能。在这种模式下，团队很容易扩展，从而让我们既能够在短期着眼于功能，又可以长期着眼于产品，在二者之间找到了良好的平衡。