Git 团队协作（一）：如何组建充满斗志和凝聚力的团队？

编者按：本文节选自童仲毅译《Git 团队协作》一书中的部分章节。

在小团队中，可能一个人就承担了很多角色。紧跟小团队中每个人的日常工作相对容易。然而，在大团队中，角色可能分散在不同部门。那些对代码库进行用户验收测试的团队，可能从来没有和被测试产品的设计师和开发者说过话。两种团队都可能遇到问题：如果没有足够的背景知识，却被提出了更高的要求，最后注定会有所遗漏；团队之间人为的屏障总是会增加他们之间的紧张关系。在开发代码时，这样的隔阂可不是什么好事。

你是否听说过“以终为始”这句话？当我构建软件时，总是在替别人构建。即使我拼命回忆，也想不起来自己曾经出于自娱自乐的目的开发过某个产品。我不是天生的黑客。我被软件吸引，是因为它能带给别人价值。每次我坐下来解决一个问题时，想的都是给用户提供更好的体验。我希望避免反复，也希望保护用户的安全。我希望他们感觉到自己心灵手巧，而非笨拙。如果在我和用户之间还隔了客户，我有时还需要改变客户思考问题的方式，以便满足他们的商业目标，同时保证终端用户的良好体验。每当我们坐下来工作时，应该从描述希望为用户解决的问题开始，也就是从用户故事（user story）开始。

接下来，在测试驱动开发流程中，你将会编写验收测试，界定如何知道问题已被解决。声明会依据编写用途被自动化测试套件、质量保证（QA）团队或是同行评审员使用。如果提前与测试团队商定验收测试，那么开发者会更清楚工作的产出应该是什么样的。一般来说，测试应该描述需要解决的问题，而不是规定将要使用的技术。

测试流程应该包含安全性评审。规模更大的公司有幸拥有专门的安全专家。让这些专家尽早介入这个流程，请他们教你如何编写安全的代码。如果你的 QA、安全和开发团队是分散的，在一开始将他们聚在一起，这会使测试流程变得更加有趣，因为开发者力图提供完美的代码，而测试团队力图挑刺。

如果部署不由你负责，同样让运维团队尽早介入。保证你的开发环境和最终的产品环境越接近越好。理想情况下，你应该使用构建脚本（build script）来尽可能自动复制环境。你可以选择使用 Docker（http://www.docker.com/）和 Vagrant（http://vagrantup.com/）来创建环境副本。和运维团队一起，使用诸如 Chef（https://www.chef.io/chef/）、Puppet（https://puppetlabs.com/）或 Ansible（http://www.ansible.com/home）这样的工具创建管理配置文件的基础设施。

讲到开发的技术栈，如果你在使用开源软件，请了解一下你将要使用的产品的开发社区。我们很少遇到新的问题，而有的人可能已经遇到过你的问题。在代码社区中寻找导师，同时指导别人。打破团队的边界，走出办公室，可怕的问题会变得简单得多。

当促进大公司中部门间的协作时，可以减少代码在原地闲置的时间。闲置的代码会以各种方式耗费你的金钱：新特性的代码可能阻碍你赚更多的钱；修复 bug 的代码则可能阻碍你停止损失。闲置的代码慢慢就不新鲜了。代码等待评审的时间越长，它可能偏离你的主分支越远。它偏离得越远，同步并预发这些工作就越麻烦。

最后，我们会审视自己的团队。技术架构师负责规划解决方案应该如何实施。架构的决策应该有文档记录并尽可能共享。架构师可能也是编码团队的一员。编码团队可能由前端开发者、后端开发者、设计师和项目经理组成。我有时候也和商业分析师一起工作。如果你在敏捷开发环境中工作，可能还需要一个敏捷专家和一个产品负责人。

我倾向于在这样的环境中工作：无论哪里有需要，每个人都愿意伸出援手。自我管理的团队通常彼此非常信任和尊重。不过，这种状态是需要你努力构建的。共识驱动的开发最适合小规模的内部项目，但这并不意味着你不能在其他地方尝试协作。管理项目时，我喜欢让开发者选择他们想做的工单。这增加了他们的自主性，如果需要，让开发者从任务中解脱片刻。不过，我也发现有些人喜欢别人替他们分配好工单。

没有一种方式可以组织所有团队或管理所有项目。一个充满斗志和凝聚力的团队，其秘诀是尊重团队中的每个人，只要有可能，就根据他们的喜好来改善流程。

图书简介：http://www.ituring.com.cn/book/1779