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 的代码则可能阻碍你停止损失。闲置的代码慢慢就不新鲜了。代码等待评审的时间越长,它可能偏离你的主分支越远。它偏离得越远,同步并预发这些工作就越麻烦。

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

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

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

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/pWS76U3ymNmLpzxyJhuz
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券