Git 团队协作(一):如何组建充满斗志和凝聚力的团队?

发布于:2020 年 2 月 18 日 08:00

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

Git团队协作(一):如何组建充满斗志和凝聚力的团队?

阅读数:1001 发布于:2020 年 2 月 18 日 08:00

更多 GitHub、Git、文化 & 方法 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • 大厂都在用哪些敏捷方法?(上)

    大厂做项目采用常见的“分而治之”的策略:大项目拆成小项目,大服务拆成小服务,大团队拆成小团队。

    2019 年 3 月 7 日

  • 5 种提高开发速度的方法

    天下武功,唯快不破。本文主要讨论了在诸多因素影响下,如何确保开发人员能以最佳速度工作?

    2020 年 8 月 16 日

  • 总复习 | 重新审视“最佳实践”

    这一讲,我们将按照最佳实践的维度,将分散在不同主题模块下的最佳实践重新串联起来,帮你做一个整体复习。

    2019 年 4 月 24 日

  • 代码入库到产品上线:Facebook 如何使用 CI/CD 满足业务要求?

    我会介绍持续集成、持续交付和持续部署,这3个工程方法的定义、作用,并以Facebook为参考,介绍具体的工程实践。

    2019 年 9 月 4 日

  • Swarming 是如何帮助敏捷团队实施交付的

    快速且频繁地交付可工作的软件是敏捷开发的目标之一。Swarming就是能够帮助敏捷团队实现这一目标的技术。那什么是Swarming,Swarming有哪些好处,该在何时使用,又该如何使用呢?

    2013 年 3 月 26 日

  • 质量保证的推荐实践

    质量保证是软件开发过程中必不可少的组成部分,资深工程师Aya推荐了几种实践方法,认为可以有效地提高质量保证的效果。

    2013 年 10 月 16 日

  • 大厂都在用哪些敏捷方法?(下)

    没有万能的开发模式,只有适合项目的开发模式,最重要的还是要摸索出一套适合你自己项目特色的开发模式。

    2019 年 3 月 9 日

  • 如何处理遗留代码

    构建(Build),自动化(Automate),测试(Test),这个BAT可以帮助你建立一张防护网,确保代码可以如你所愿的继续工作。 Richardson向我们展示了这些步骤如何迅速发现并解决那些没有意识到的副作用。看看它与你日常工作相比的区别是什么,你是否需要用不同的手段处理工作。

    2007 年 11 月 20 日