當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

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

發布時間：2023/11/29 编程问答 43 豆豆

生活随笔收集整理的這篇文章主要介紹了分布式知乎 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工具在至少兩個重要方面不足：

There’s no easy way to group issues together under (Epics). We used labels for a while, but it was suboptimal.

在(Epics)下沒有將問題歸類在一起的簡便方法。我們使用標簽一會兒，但是效果欠佳。

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/