分布式 知乎 github_如何使用GitHub本机功能来帮助管理中型分布式团队

分布式 知乎 github

by Alex Ewerlöf

由AlexEwerlöf

如何使用GitHub本机功能来帮助管理中型分布式团队 (How to use GitHub native features to help manage a mid-size distributed team)

My team created a wiki page in our private Github repo about how we work on a common code base. I want to share it with you. We’re a team of 15 people with 10 developers, a project manager (PM), a tech lead (TL), an engineering manager, a UXer and DevOps spread across three European countries. The product is an internal web based SaaS that’s used by other teams inside the company.

我的团队在我们的私人Github存储库中创建了一个Wiki页面，以介绍我​​们如何使用通用代码库。 我想和你分享。 我们是一个由15人组成的团队，有10个开发人员，项目经理( PM )，技术主管( TL )，工程经理，UXer和DevOps，业务遍及欧洲三个国家。 该产品是基于内部Web的SaaS，供公司内部其他团队使用。

通讯 (Communication)

We primarily communicate via Slack, but have a biweekly retro on video conference (VC). We don’t have a daily standup, but instead have a weekly reminder for the week’s tasks where everyone can write an update in a thread. The idea is to turn the standup questions around from being about people to being about the tasks. We got the idea from the “Flow” workshop by Marcus Hammarberg:

我们主要通过Slack进行交流，但每两周进行一次视频会议(VC)回顾。 我们没有每日站立的机会，而是每周提醒一周的任务，每个人都可以在线程中编写更新。 这样做的目的是将站立式问题从关于人的问题转变为关于任务的问题。 我们从Marcus Hammarberg的“ Flow”研讨会中得到了这个想法：

为什么？ (Why?)

As the project and team grows, we can work more efficiently by keeping track of the issues and PRs in a smart way.

随着项目和团队的成长，我们可以通过智能地跟踪问题和PR来更有效地工作。

GitHub has many project management features built in. Besides, it is easier for developers to have their code and tasks in one place. Features like closing issues with comments, contribution guide, and issue templates, code owners and its integrations with other services make it a quite useful tool.

GitHub内置了许多项目管理功能。此外，开发人员可以更轻松地将其代码和任务放在一个地方。 通过注释关闭问题 ， 贡献指南和问题模板 ， 代码所有者及其与其他服务的集成等功能使其成为一个非常有用的工具。

The idea is to define a loose way of handling work without putting too much load on the PM/TL while still getting their input when needed.

这个想法是要定义一种宽松的方式来处理工作，而又不会在PM / TL上增加过多的负载，同时在需要时仍能获得它们的输入。

什么？ (What?)

We use a few native GitHub features to organize the issues and have a clearer picture on what is going on in the project at any time.

我们使用一些本地GitHub功能来组织问题，并随时更清晰地了解项目中正在发生的事情。

怎么样？ (How?)

We use GitHub issues, labels, and milestones. We currently don’t use GitHub projects (but instead use Zenhub as our Kanban board).

我们使用GitHub问题，标签和里程碑。 我们目前不使用GitHub项目(而是使用Zenhub作为看板)。

什么时候？ (When?)

We use weekly milestones. At the beginning of every week, we have a planning meeting (also on VC) where together with the PM/TL we define the weekly milestone which is the focus of the team for that week.

我们使用每周里程碑。 每周开始时，我们都会召开计划会议(也在VC上)，与PM / TL一起定义每周的里程碑，这是团队在该周的重点。

We use GitHub milestones that that have names like W22, with a description of what is supposed to be achieved by the end of the week. It also clearly mentions the acceptance criteria.

我们使用名称为W22的GitHub里程碑，并描述到本周末应实现的目标。 它还清楚地提到了接受标准。

At the end of the week, we have the weekly demo (also on VC) where we show the result and give kudos to anyone who has done an outstanding job.

在一周结束时，我们有每周的演示(也在VC上)，我们在其中演示结果并向任何出色工作的人致以荣誉。

原子问题和提取请求 (Atomic issues & pull requests)

• Each issue should address one thing. If the discussion regarding an issue expands out of scope, create another issue.
  每个问题都应该解决一件事。 如果有关问题的讨论超出了范围，请创建另一个问题。
• Always start from an issue rather than a PR. Always discuss the problem (in an issue) before submitting a solution (in a PR).
  始终从问题而不是PR开始。 在提交解决方案之前(在PR中)，始终要讨论问题(在问题中)。

• Squash the PRs when merging to keep the history of the master branch clean and reasonable.

  合并时压缩PR，以保持master分支的历史干净合理。

• It’s good practice to add background info to a PR, but if you’re writing too much it probably means that you need to comment on the issue instead.
  将背景信息添加到PR中是一个很好的做法，但是如果您撰写的内容过多，则可能意味着您需要对此问题发表评论。
• Keep the discussions in the issues and let the priorities be assigned before starting to code.
  在开始编写代码之前，请先在问题中进行讨论，并分配优先级。

问题与PR之间的1：1映射 (1:1 mapping between issues and PRs)

• In the rare case that you make a PR without a relevant issue, make an issue and refer to it in the PR description.
  在极少数情况下进行PR而没有相关问题的情况下，请提出问题并在PR说明中进行引用。
• There must be at least one issue for every PR.
  每个PR必须至少有一个问题。
• It is recommended that each PR closes one issue.
  建议每个PR关闭一个问题。
• Write a brief description of the solution in the PR and refer to the relevant issue(s).
  在PR中撰写解决方案的简短说明，并参考相关问题。

没有直接提交给大师 (No direct commit to master)

• All changes to master should come from PRs.
  对master的所有更改都应来自PR。

• The idea is to always have a working master branch.

  想法是始终有一个正常工作的master分支。

WHO？ (Who?)

In our team, we use a lean way of taking on tasks. Once they are prioritized by the PM, anyone can go and pick a task and work on it. To signal that the issue is in progress, you simply assign it to yourself.

在我们的团队中，我们采用精益的方式来执行任务。 一旦由PM确定优先级，任何人都可以去挑选一项任务并进行处理。 要表明问题正在发生，只需将其分配给自己。

We use mob programming for larger tasks, and in that case, all people involved in the task are assigned. They are also pinged in the PR description so they’ll get an update for comments on the PR.

我们将暴民编程用于较大的任务，在这种情况下，将分配参与该任务的所有人员。 它们还会在PR描述中被ping通，因此可以获取有关PR的更新评论。

标签 (Labels)

When creating an issue, we assign the relevant labels to it for easier filtering. For example, we can filter all test related issues or prio-hi issues with one click or even bookmark the query.

创建问题时，我们会为其分配相关标签，以便于过滤。 例如，我们可以一键过滤所有与test相关的问题或prio-hi问题，甚至为查询添加书签。

There are many labels, but they basically fall into the following categories:

标签很多，但基本上属于以下类别：

优先次序 (Prioritization)

When a new issue comes in, it waits until it is prioritized by the PM and gets one of these labels:

当出现新问题时，它将等待直到PM对其进行优先级排序并获得以下标签之一：

• prio-high: high priority tasks that should be done ASAP

  prio-high ：应尽快完成高优先级任务

• prio-mid: mid priority tasks that can be done when there’s no high priority tasks

  prio-mid ：没有高优先级任务时可以完成的中优先级任务

• prio-low: low priority tasks that can wait

  prio-low ：可以等待低优先级任务

• on-hold: the tasks that we will not do until further notice

  on-hold ：我们在未另行通知之前不会执行的任务

If an issue doesn’t have any of these labels, it shouldn’t be worked on. The PM can change the priority of an issue based on the changes in stakeholder needs.

如果问题没有任何这些标签，则不应进行处理。 PM可以根据利益相关者需求的变化来更改问题的优先级。

When an issue has a milestone, it is ready to be developed. All other issues that are not in a milestone are in the “backlog”. Issues may be assigned to the weekly milestone of an upcoming week. If you can’t contribute to this week’s milestone, maybe you can prepare for next week by doing some of that work.

当一个问题具有里程碑意义时，就可以进行开发了。 尚未完成的所有其他问题都在“待办事项列表”中。 可以将问题分配给下一周的每周里程碑。 如果您不能为本周的里程碑做出贡献，也许您可​​以通过做一些工作来为下周做准备。

Anyone can create an issue. In fact a question can be an issue, if you feel it’s the best way to get answers. An issue will not automatically convert to task until it has been prioritized (got a prio-* label) and added to a milestone.

任何人都可以制造问题。 实际上，如果您认为这是获得答案的最佳方法，那么问题可能就是一个问题。 在确定优先级(带有prio-*标签)并将其添加到里程碑之前，问题不会自动转换为任务。

尺寸 (Size)

• EPIC: is an issue that can lead to several PRs and should be broken down into atomic issues before it gets implemented.

  EPIC ：是一个可能导致多个PR的问题，应在实现之前将其分解为atomic问题。

• atomic: is an issue that can be implemented on its own and will lead to a PR.

  atomic ：是可以单独实施的问题，将导致PR。

分组 (Grouping)

We also use labels to group similar issues together or flag different aspects of an issue or PR. An issue can have any number of these flags:

我们还使用标签将相似的问题归为一组，或者标记问题或PR的不同方面。 一个问题可以具有以下任意数量的标志：

• tooling the issues that touch on the build system, linting, test tooling...

  tooling的问题是触摸在构建系统上，掉毛，测试工装...

• test the issues about testing and QA

  test有关测试和质量检查的问题

• ux the issues that require some UX work, improve UX, or affect UX in some way

  ux需要一些UX工作，改善UX或以某种方式影响UX的问题

• config the issues related to configuration changes

  config与配置更改相关的问题

• doc the issues about documentation (in-code comments or published documentation like wiki)

  doc有关文档的问题(代码注释或Wiki之类的已发布文档)

• perf: suggestions for monitoring and improving performance

  perf ：监控和提高性能的建议

• dx: stuff that improves developer experience like logging and so on.

  dx ：改善日志记录等开发人员体验的内容。

• security: security issues or security improvements.

  security ：安全性问题或安全性改进。

• discussion: we haven't reached a consensus there, maybe you can contribute?

  discussion ：我们在那里还没有达成共识，也许您可​​以做出贡献？

• help needed: the issue needs some help from external teams (if you're waiting on an internal volunteer, you can just go ahead and ping them). These issues are typically a good candidate for PM/TL to facilitate cross-team communication.

  help needed ：此问题需要外部团队的帮助(如果您正在等待内部志愿者，则可以继续并对其进行ping操作)。 这些问题通常是PM / TL促进跨团队沟通的良好候选人。

• feature: for introducing new features

  feature ：用于引入新功能

• bug: for bug reports

  bug ：用于错误报告

• more labels can be added if we have enough issues that fit a certain lavel.
  如果我们有足够多的问题适合特定条件，则可以添加更多标签。

GitHub不能做的事情 (Things GitHub can’t do)

Unfortunately, the current Github tooling falls short for at least two important things:

不幸的是，当前的Github工具在至少两个重要方面不足：

1. There’s no easy way to group issues together under (Epics). We used labels for a while, but it was suboptimal.
   在(Epics)下没有将问题归类在一起的简便方法。 我们使用标签一会儿，但是效果欠佳。
2. Apart from using labels, there’s no way to prioritize the issues. We need a tool where the order of the issues can show their importance.
   除了使用标签外，无法对问题进行优先排序。 我们需要一种工具，问题的顺序可以显示其重要性。

Both of these issues are solved by Zenhub, which is a Chrome/Firefox extension that enriches the native GitHub interface. It also has a hosted service for those who don’t use Chrome/Firefox.

Zenhub解决了这两个问题， Zenhub是Chrome / Firefox扩展，丰富了本地GitHub界面。 它还为不使用Chrome / Firefox的用户提供托管服务。

The only area that Zenhub still falls short is defining a limit on work in progress (WIP limit).

Zenhub仍然不足的唯一领域是定义进行中的限制( WIP限制 )。

There’s much more to how we work, and I’ll try to write a series about it. Make sure to follow me to stay up to date with the latest posts.

我们的工作方式还有很多，我将尝试写一系列有关它的文章。 请务必关注我，以了解最新信息。

翻译自: https://www.freecodecamp.org/news/using-github-native-features-for-a-mid-size-distributed-team-3acdfd0f027c/

分布式 知乎 github