git 团队合作_如何成为一个有效的团队合作者

git 团队合作

I’ve had jobs as a developer where I had teammates who were great people, but we did not work well together. Not because we were bad at it but mostly because the culture of that workplace did not reward or incentivize working as a team — or working well as a team.

我曾担任过开发人员的工作，在那里我的队友都是很棒的人，但是我们在一起工作并不顺利。 这不是因为我们不擅长于此，而是主要是因为该工作场所的文化没有奖励或激励团队合作或团队合作。

However, there were always those people who would stand out, manage to overcome such work cultures, and show that working well as a team is not only effective but highly rewarding. Nowadays, I’m privileged enough to be working in an environment where teamwork is much smoother, constant, and rewarded, and I can see the difference is huge.

但是，总会有一些人愿意 脱颖而出，设法克服这种工作文化，并表明作为一个团队进行良好的合作不仅有效，而且回报丰厚。 如今，我很荣幸能够在团队合作更加顺畅，持续不断并且获得回报的环境中工作，并且我可以看到两者之间的巨大差异。

“Working effectively together feels good. It may be a new experience in the workplace for some.” — Kent Beck in Extreme Programming Explained

“有效的合作感觉很好。 对于某些人来说，这可能是一种新的工作经验。” — 极限编程中的肯特·贝克(Kent Beck) 讲解

Regardless of your work environment, being able to work well with others will always make you stand out, get the best results out of your efforts, and become a reference on your team. So, here’s what great team players do to achieve this.

无论您的工作环境如何，都能与他人保持良好的合作关系总是会让您脱颖而出，并从自己的努力中获得最好的结果，并成为您团队中的参考。 因此，这就是优秀的团队成员为实现这一目标所要做的。

1.他们与非技术人员进行有效沟通 (1. They Communicate Effectively With Non-Technical People)

Whenever talking to non-technical folk, avoid using too many technical terms or an unnecessary level of detail.

每当与非技术人员交谈时，请避免使用过多的技术术语或不必要的详细程度。

This seems obvious at first, but I’m pretty sure you’ve already told some PM or PO about a bug or a technical challenge only to be met with a confused facial expression followed by a question along the lines of “OK, is this a blocker?”

乍一看似乎很明显，但是我敢肯定，您已经告诉PM或PO一些错误或技术挑战，然后才遇到一个困惑的面部表情，然后问一个类似“好的，这是阻挡者？ ”

Whenever you find yourself in this situation, always provide small chunks of information that represent a comprehensive but simplified version of everything that you have to say. If the person you are talking to is still curious or not convinced, repeat the process with an increased level of detail. Keep doing so until you’ve made your point. This will also give you the opportunity to focus on the parts that the listener has the most difficulty understanding or finds most important.

每当您遇到这种情况时，请始终提供少量信息，这些信息代表了您所要说的一切的全面而简化的版本。 如果您正在与之交谈的人仍然好奇或不确定，请以更高的详细程度重复该过程。 继续这样做，直到提出自己的观点为止。 这也将使您有机会专注于听者最难以理解或发现最重要的部分。

This will save time for both you and whoever wants to know what happened in the depths of the technology you are working on.

这将为您和任何想知道正在开发的技术深度方面发生的事情的人节省时间。

Source: KRAZAM 资料来源：克拉扎姆

2.他们与其他开发人员进行良好的沟通并发现学习机会 (2. They Communicate Well With Other Developers and Detect Learning Opportunities)

Now, whenever you are talking with other developers, you certainly have more freedom to use statements that go well without any explanations. But not all developers have the same amount of seniority and, most importantly, familiarity with the technology that you are both working on.

现在，无论您何时与其他开发人员进行交谈，您无疑都拥有更大的自由来使用运行良好的语句而无需任何解释。 但是并不是所有的开发人员都具有相同的资历，最重要的是，他们对你们都在使用的技术也很熟悉。

In order to communicate effectively in this case, it is important that you tune the speed of your delivery so the other developer has time to at least tell you if you just went through something that they don’t quite understand. Especially when working with someone less experienced than you, it is important that you are able to pinpoint gaps in their knowledge so you are able to create short but concise moments of teaching.

为了在这种情况下有效地进行通信，请务必调整交付速度，以便其他开发人员有时间至少告诉您是否只是经历了他们不太了解的事情，这一点很重要。 尤其是在与没有您的经验的人一起工作时，重要的是您能够查明他们的知识差距，以便能够创造简短但简洁的教学时间。

If you are the less experienced developer or simply don’t know much about something that is being discussed, don’t forget to say so, as no one will be able to guess this.

如果您是经验不足的开发人员，或者只是对所讨论的内容不了解，请不要忘记这么说，因为没人会猜到这一点。

The person who is learning will likely carry these very precise and self-contained moments with them throughout their entire career, so make sure you don’t rush when you are talking and make this conversation very interactive so you don’t lose such opportunities.

正在学习的人可能会在整个职业生涯中与他们一起度过这些非常精确且自成一体的时刻，因此请确保您在讲话时不要着急，并使对话非常互动，这样您就不会失去这样的机会。

If you happen to work on a team where there is very little cooperation, try creating such moments of sharing somehow. Both teaching and learning are crucial to building knowledge as a developer.

如果您碰巧在很少合作的团队中工作，请尝试以某种方式创造这样的共享时刻。 教学和学习对于建立开发人员的知识都至关重要。

3.他们是无我的程序员 (3. They Are Egoless Programmers)

This sounds fancy, but it simply means splitting your personal self from your work — both when doing your own work and when reviewing others’ work. Developers who nail this are able to consistently receive criticism of their work without feeling down about it or creating grudges.

这听起来很花哨，但这仅意味着在进行自己的工作和审查他人的工作时将自己的个人与工作分开。 对此感到满意的开发人员可以一如既往地对其工作提出批评，而不会对此感到沮丧或产生怨恨。

“The most brilliant programmers alive working competitively in an ego-rich environment can’t get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team. You need a process where team empowerment and collaboration thrive to reach your full potential.” — Don Wells on Extreme Programming

“在一个自我高度丰富的环境中，最有才华的程序员在竞争中活着，而他们却没有像普通的程序员那样自律，自组织的团队协同工作。 您需要一个过程，使团队授权和协作得以蓬勃发展，以发挥您的全部潜力。” — Don Wells谈极限编程

On the other hand, don’t be arrogant or mean when reviewing code or discussing solutions. Don’t use putdowns or any form of aggressive communication. Find problems in the code and criticize the work — not the author. Don’t state facts. State opinions, which is what they are. Make suggestions based on evidence or thoughts that support them.

另一方面，在检查代码或讨论解决方案时，不要傲慢无礼。 不要使用放任不管或任何形式的激进交流。 在代码中发现问题并批评作品-不是作者。 不要说事实。 国家意见，这就是它们。 根据支持他们的证据或想法提出建议。

“Don’t use put-downs, e.g. ‘That was the buggiest code I’ve ever seen.’ Be clinical when it comes to code that isn’t yours. Better: ‘There were a few bugs.’” — WikiWikiWeb

“不要使用放空工具，例如，“这是我见过的最bug的代码。” 当涉及到不是您自己的代码时，请保持临床。 更好：“有一些错误。”” — WikiWikiWeb

This also includes not trying to prove that you know some fancy feature from the language or design pattern. There are coders out there who write complicated stuff just to show off or maybe because that way the code would be super concise, brilliant, and… guess what: super hard for others to understand. Don’t do this. Good code is often dumb and simple. Let patterns emerge naturally and discuss big abstractions with others before forcing them into the codebase.

这还包括不试图证明您从语言或设计模式中了解某些新颖的功能。 那里有一些编码员，他们写复杂的东西只是为了炫耀，或者可能是因为那样的话，该代码将非常简洁，精妙，并且……猜出什么：其他人很难理解。 不要这样 好的代码通常是愚蠢而简单的。 让模式自然出现，并在将其强加到代码库之前与他人讨论大型抽象。

4.他们预防和摧毁知识孤岛 (4. They Prevent and Destroy Knowledge Silos)

Great team players have a keen eye for knowledge silos. Such silos occur when — probably due to working in isolation — a certain developer (or even someone with a different role) knows everything about a certain topic, while the rest of the team doesn’t.

优秀的团队成员敏锐地洞悉知识孤岛。 当(可能是由于孤立地工作)某个开发人员(甚至是一个角色不同的人)知道某个主题的所有知识而团队的其他成员却不知道时，就会发生这种孤岛。

Whenever you become aware that someone on your team ended up accumulating all there is to know about a certain feature or something else that is your team’s responsibility, invite them to share. This can be very easy and does not require a fancy document or presentation. A 30-minute meeting showing your own computer screen is good enough. If you really need to go async, a simple but well-written document in Google Docs also works well.

每当您发现团队中的某人最终积累了所有关于某项功能或团队负责的其他信息时，请邀请他们分享。 这非常容易，不需要花哨的文档或演示文稿。 一个30分钟的会议显示您自己的计算机屏幕就足够了。 如果您确实需要异步处理，那么Google Docs中一个简单但编写良好的文档也可以很好地工作。

You X Ventures on You X Ventures在 Unsplash. Unsplash拍摄 。

Pair programming can be a great way of fixing this problem altogether, as context will be shared naturally among developers or whoever takes part in such pair or mob programming sessions.

配对编程可能是解决此问题的一种很好的方法，因为上下文将在开发人员之间或参与此类配对或暴民编程会话的人员之间自然共享。

结语 (Wrapping Up)

Working together effectively and realizing that a team is more than the simple sum of its members is highly rewarding and addictive.

有效地合作并意识到团队不仅仅是成员的简单组合，这是非常有益和令人上瘾的。

Remember to communicate with as little noise as possible. Try catching daily learning and teaching opportunities and remember to leave your ego at the door. An environment of growth and fulfillment is not only made by company culture and incentives but also by small and daily interactions. Being aware of this and implementing small changes yourself is already a big step!

切记以尽可能少的噪音进行交流。 尝试抓住每天的学习和教学机会，并记住将自我放在门外。 成长和实现的环境不仅是由公司文化和激励机制造成的，而且还取决于日常的日常互动。 意识到这一点并自己进行一些小的更改已经是一大步！

翻译自: https://medium.com/better-programming/how-to-be-an-effective-team-player-d84acd04be1d

git 团队合作