Git 团队协作 (1):团队作战 1&1.1

阅读数:11 2019 年 11 月 20 日 17:19

Git团队协作(1):团队作战 1&1.1

(团队作战)

内容简介
Git 团队协作 是一本软件团队协作指南,采用以人为本的方式讲解版本控制,强调如何利用 Git 促进团队协作。第一部分介绍如何创建一个优秀的团队、如何构建工作流等。第二部分从实践的角度学习 Git 命令。第三部分介绍如何在 GitHub、Bitbucket 和 GitLab 平台上托管项目。

我教授版本控制已经超过十年了。参加我的现场研讨会的大部分人都疲于处理办公室政治问题,而不是技术问题。当然,这些问题不尽相同。或许他们苦于让同事明白版本控制有多么重要,或许他们想要明确责任关系,又或许他们被团队选出来去搞清楚团队工作流中的乱象。不管是什么问题,先理解并解决背后的人际关系问题可以使 Git 的学习和使用更加容易。

完成本章学习之后,你将具备以下技能。

  • 识别一个完整团队中的各个角色
  • 组织一个富有成效的会议
  • 通过关键词识别与你的团队脱节的成员
  • 使用策略来培养团队成员彼此间的认同和信任

在开始前,你必须理解你的团队以及软件需求。如果一开始团队就充满了信任和彼此关爱,当你计划用 Git 命令来达成目标时,将会发现自己一身轻松。在充满信任的团队里,当有人遇到困难时,你们可以互相帮助,人们在需要帮助时也会更加坦诚。当人们感受到支持,并理解为什么要用这些 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 的代码则可能阻碍你停止损失。闲置的代码慢慢就不新鲜了。代码等待评审的时间越长,它可能偏离你的主分支越远。它偏离得越远,同步并预发这些工作就越麻烦。

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

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

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

Git团队协作(1):团队作战 1&1.1

图灵地址 http://www.ituring.com.cn/book/1779

评论

发布