如果您正在尝试编写一些高质量的代码，某些代码可能适合pair -编程。 XP 人们说你应该一直这样做，但我相信有时这样做会更有帮助。例如，当一名开发人员比另一名开发人员更有经验时，这有助于指导。此外，当您希望在某个特定领域传播知识时。 （只有一个人理解系统的一部分；下次需要修改时，让那个人与其他人一起打字。）此外，有时系统的一部分非常重要，正确地编写它比每分钟的代码行数重要得多。这是一个让两个人共同解决问题的好地方，最终两个人对这个关键代码而不是一个人有深入的了解。
Standup meetings each day (keep them short) with everyone present help everyone understand what each other is doing. This also helps the manager get some management out of the way, helps prevents thrashing, and puts a little pressure on each individual without the manager having to do it. (You want to have something done so you'll look good in front of your peers tomorrow morning). Some methodologies like Scrum formalize this.
Have code review with different team members. Is one of the non-manager team members more experienced? Having this person do code review with others would be good; he/she would share their experience and be someone else (besides the manager) who knows most of what's going on. There's no law that says in a peer review one person must be more senior than the other and be the one who declares code right or wrong. I think though that if two "peers" are doing code review, they should just pair-program to begin with.
if your are trying to write some quality code, certain bits of code might lend themselves to pair-programming. XP people say you should do this all the time, but I believe it's more helpful sometimes and other times. For example, when one developer is more experienced than the other, this helps with mentoring. Also, when there is a specific area where you want knowledge to be spread. (Only one guy understands a part of the system; next time that needs revising, have that guy do it with the other person typing.) Also, sometimes a part of the system is really important, and having it crafted correctly is far more important than lines-of-code per minute. This is a great place to have two heads on the problem, and in the end two people have intimate knowledge of this key code instead of one.
Something like once a week, have someone present a short talk during lunch on something interesting they're doing. This can generate great discussion, promote confidence and mutual respect, but what we're interested in here is that it promotes awareness.
Value, support and believe in good code. Some shops (the managers mainly) don't really believe in good code, and this leads to people just busting out (crappy) code, even if the developers could make great code. Communication about code happens a lot easier if developers are happy with the code they're making, if you're implementing some new technology now and then, and if quality work helps your career.
And more about pair programming. The key part of pair programming for this discussion is that pair-progrmaming promotes shared code and cross-knowledge. The reason I mention the specific places where pair programming is particularly helpful is because the policy "we're going to do pair programming" succeeds about 10% of the time. The other 90%, the proponents of the practice can't give a good enough answer when a big manager asks, "why are all these people sitting at the same desks?" The advantages of pair programming have to be 200%+ than just one programmer doing it, because you're using two people. Done at the right time, pair programming can increase your solution/buck ratio; at the wrong time it can decrease it.
Agile techniques like pair programming and daily stand-up meetings are good formal ways to get communication happening.
But it sounds like what you really need to do is just get people talking to each other. Developers tend to be introverts, so you have to work at this. Have lunch together. Look over each other's shoulders. Ask for advice from one another (even when you don't need it). Ask each other about those weird technologies that not everyone understands. Gather for integration tests.
I am in a similar situation at my workplace. Some members of the team are, like you said, highly independent and do not share any insight or practices with other member of the team. I find this to be highly unprofessional and overall hurtful to the team.
Of course it's only inevitable to have some members more proficient than others, and, in the world of programming, some members will have trouble shoving their egos aside. The best thing to do is to have scheduled meetings and code reviews in which everyone is involved. Have a central documentation site where people can post certain techniques that they use. If you figure something out that you think can be useful to the rest of the team, upload it to the site and send an e-mail telling everyone. Communication is key.
What could help you are daily stand-ups (from agile development). It takes only couple of minutes and basicaly all the members present to the others status of their work, problems they deal with and plans for tomorrow.
In our team, we have progress meetings every week. This allows to discover what others do and where each one is placed in the big picture.
Sometimes it is followed by a mini social event when we share a homemade cake. The name of the person who brings the cake next time is written in the minutes of progress meeeting.
Go make BBQ together, play foosball, find some team activity besides work that everyone likes. That will teach people to trust each other as opposed to being "independent" and multiply by 10 the effect of every other useful team practice, like scrum-meeting or pair programming.
Here are some thoughts off the top of my head (small company, three programmers; used to work in a team of about 20).
Some sort of progress reporting so that everybody can see what everybody else is working on. "What I've been working on" meetings work for some people, but I'm not a fan of them - they're too regimented, and a sit-down meeting for this purpose can often turn into a waste of time and/or be prone to disappearing down ratholes. At my current work we have a cron job that reminds us to send our weekly progress emails: in these we are expected to say what we've achieved, the next few items on our todo list (with estimates where appropriate), any problems we've encountered.
Selective commit notifications. Very few people pay more than a cursory glance to company-wide commit mails (even in my small team) - but if you can empower each developer to monitor just the fields they're working in, they probably can keep track of it. (You shouldn't have too many people working on the same piece of code at once, anyway. Too many cooks and all that.)
Some sort of ticketing system to provide a todo list can be helpful. You need to be very clear over how this is managed, though - particularly what your processes are for originating and closing tickets.
Internal documentation. This is a hard problem; some developers hate it, some write far too much, and some write just enough. At least half the problem is in indexing and presentation; it's no good if the information you need is buried five layers deep in an impenetrable document entitled "Beware of the Leopard". I'm quite a fan of wikis for this purpose as they're so easy to use.
Above a certain size of team you might find it becomes a full-time job for somebody to manage your documentation. At a previous workplace we spent the money on a search engine appliance, continually crawling our intranet sites, which was wonderful.
We are in a similar situation (a long project and are all friends), and had similar problems. The following practices allowed us to improve a lot:
Daily standup meeting are a must. In my experience a well conducted daily standup is the best thing to encourage communication among the team. Everyone knows what all team members are doing, and can help out with any problem.
A wiki is also essential. You can put up standard practices and technologies that are used within the team. To have everyone actively participate, the leader assigns all team members something to write about and maintain whithin the wiki. It is particuarly effective when each one writes about something that they particularly likes or is interested in.
Try to have the whole team present, or all the members that are available, in meetings where requirements/features are analyzed, priorized, etc. It doesn't matter if some of members of the team are not specificaly working in that area of the project. This will give context to everybody and a broader vision of the project. It will allow (and encourage) them to participate in this discussions of the project as a whole, and not solely concentrate on the part that they are working on. This practice will motivate a lot of discussion, all of us when given a chance and knowledge (it only takes a very small amount) have an opinion and like to comment on all everything within the project.
The final practice that motivates a lot of "shop" talk, is that every two week some member gives a small presentation about some technology or technique. Generaly it includes practical exercises, and time discuss and ask questions.
发布评论
评论（8）
站立会议（简短）每个人都在场，可以帮助每个人了解彼此在做什么。这也有助于经理摆脱一些管理障碍，有助于防止颠簸，并把给每个人一点压力，而经理不必这样做。 （你想要完成一些事情，这样你明天早上就会在同事面前看起来很好）。 Scrum 等方法将这一点正式化。
与不同的团队成员一起进行代码审查。非经理团队成员之一是否更有经验？让这个人与其他人一起进行代码审查会很好；他/她会分享他们的经验，并成为了解大部分情况的其他人（除了经理）。没有法律规定在同行评审中，一个人必须比另一个人资历更高，并且是宣布代码正确或错误的人。我认为，如果两个“同行”正在进行代码审查，他们应该从结对编程开始。
如果您正在尝试编写一些高质量的代码，某些代码可能适合pair -编程。 XP 人们说你应该一直这样做，但我相信有时这样做会更有帮助。例如，当一名开发人员比另一名开发人员更有经验时，这有助于指导。此外，当您希望在某个特定领域传播知识时。 （只有一个人理解系统的一部分；下次需要修改时，让那个人与其他人一起打字。）此外，有时系统的一部分非常重要，正确地编写它比每分钟的代码行数重要得多。这是一个让两个人共同解决问题的好地方，最终两个人对这个关键代码而不是一个人有深入的了解。
比如每周一次，让某人在午餐期间就他们正在做的有趣的事情进行简短的谈话。这可以引发热烈的讨论，促进信心和相互尊重，但我们在这里感兴趣的是它可以提高意识。
重视、支持并相信优秀的代码。一些商店（主要是经理）并不真正相信好的代码，这导致人们只是破坏（蹩脚）代码，即使开发人员可以做得很好代码。如果开发人员对他们正在编写的代码感到满意，如果您时不时地实施一些新技术，如果高质量的工作对您的职业生涯有所帮助，那么关于代码的沟通就会容易得多。
以及有关结对编程的更多信息。本次讨论的结对编程的关键部分是结对编程促进 共享代码和交叉知识。我之所以提到结对编程特别有用的具体地方，是因为“我们将进行结对编程”策略的成功率约为 10%。另外 90% 的人，即这种做法的支持者，当一位大经理问“为什么所有这些人坐在同一张办公桌上？”时，他们无法给出足够好的答案。结对编程的优势肯定比仅由一名程序员进行的优势高出 200% 以上，因为您使用的是两个人。 在正确的时间进行结对编程可以提高您的解决方案/降压比；在错误的时间它可以减少它。
Standup meetings each day (keep them short) with everyone present help everyone understand what each other is doing. This also helps the manager get some management out of the way, helps prevents thrashing, and puts a little pressure on each individual without the manager having to do it. (You want to have something done so you'll look good in front of your peers tomorrow morning). Some methodologies like Scrum formalize this.
Have code review with different team members. Is one of the non-manager team members more experienced? Having this person do code review with others would be good; he/she would share their experience and be someone else (besides the manager) who knows most of what's going on. There's no law that says in a peer review one person must be more senior than the other and be the one who declares code right or wrong. I think though that if two "peers" are doing code review, they should just pair-program to begin with.
if your are trying to write some quality code, certain bits of code might lend themselves to pair-programming. XP people say you should do this all the time, but I believe it's more helpful sometimes and other times. For example, when one developer is more experienced than the other, this helps with mentoring. Also, when there is a specific area where you want knowledge to be spread. (Only one guy understands a part of the system; next time that needs revising, have that guy do it with the other person typing.) Also, sometimes a part of the system is really important, and having it crafted correctly is far more important than lines-of-code per minute. This is a great place to have two heads on the problem, and in the end two people have intimate knowledge of this key code instead of one.
Something like once a week, have someone present a short talk during lunch on something interesting they're doing. This can generate great discussion, promote confidence and mutual respect, but what we're interested in here is that it promotes awareness.
Value, support and believe in good code. Some shops (the managers mainly) don't really believe in good code, and this leads to people just busting out (crappy) code, even if the developers could make great code. Communication about code happens a lot easier if developers are happy with the code they're making, if you're implementing some new technology now and then, and if quality work helps your career.
And more about pair programming. The key part of pair programming for this discussion is that pair-progrmaming promotes shared code and cross-knowledge. The reason I mention the specific places where pair programming is particularly helpful is because the policy "we're going to do pair programming" succeeds about 10% of the time. The other 90%, the proponents of the practice can't give a good enough answer when a big manager asks, "why are all these people sitting at the same desks?" The advantages of pair programming have to be 200%+ than just one programmer doing it, because you're using two people. Done at the right time, pair programming can increase your solution/buck ratio; at the wrong time it can decrease it.
结对编程和每日站立会议等敏捷技术是进行沟通的良好正式方式。
但听起来你真正需要做的就是让人们互相交谈。开发人员往往都是内向的人，所以你必须在这方面努力。一起吃午饭。看着彼此的肩膀。互相寻求建议（即使你不需要）。互相询问那些不是每个人都理解的奇怪技术。聚集进行集成测试。
Agile techniques like pair programming and daily stand-up meetings are good formal ways to get communication happening.
But it sounds like what you really need to do is just get people talking to each other. Developers tend to be introverts, so you have to work at this. Have lunch together. Look over each other's shoulders. Ask for advice from one another (even when you don't need it). Ask each other about those weird technologies that not everyone understands. Gather for integration tests.
我在工作场所也面临类似的情况。正如您所说，团队中的一些成员高度独立，不与团队其他成员分享任何见解或实践。我发现这是非常不专业的，并且总体上对团队造成了伤害。
当然，有些成员比其他成员更熟练是不可避免的，而且在编程世界中，有些成员很难将自己的自我抛在一边。最好的办法是安排每个人都参与的会议和代码审查。拥有一个中央文档站点，人们可以在其中发布他们使用的某些技术。如果您发现一些您认为对团队其他成员有用的东西，请将其上传到网站并发送电子邮件告诉每个人。沟通是关键。
I am in a similar situation at my workplace. Some members of the team are, like you said, highly independent and do not share any insight or practices with other member of the team. I find this to be highly unprofessional and overall hurtful to the team.
Of course it's only inevitable to have some members more proficient than others, and, in the world of programming, some members will have trouble shoving their egos aside. The best thing to do is to have scheduled meetings and code reviews in which everyone is involved. Have a central documentation site where people can post certain techniques that they use. If you figure something out that you think can be useful to the rest of the team, upload it to the site and send an e-mail telling everyone. Communication is key.
每天的站会（来自敏捷开发）可以帮助您。只需几分钟，基本上所有成员都向其他人介绍他们的工作状况、处理的问题以及明天的计划。
我认为站立会议对你来说是一个好的开始。您可以在 Martin Fowler - 这不仅仅是站着：每日站立会议的模式中找到更多信息
What could help you are daily stand-ups (from agile development). It takes only couple of minutes and basicaly all the members present to the others status of their work, problems they deal with and plans for tomorrow.
I think stand-ups is a good start for you. You can find some more info e.g. at Martin Fowler - It's Not Just Standing Up: Patterns of Daily Stand-up Meetings
在我们的团队中，我们每周都会召开进度会议。这样可以发现其他人在做什么以及每个人在大局中的位置。
有时，我们会举办一个小型社交活动，分享自制的蛋糕。下次带来蛋糕的人的名字会写在进度会议的记录中。
In our team, we have progress meetings every week. This allows to discover what others do and where each one is placed in the big picture.
Sometimes it is followed by a mini social event when we share a homemade cake. The name of the person who brings the cake next time is written in the minutes of progress meeeting.
团队建设
一起去烧烤，打足球，在工作之外找一些大家都喜欢的团队活动。这将教会人们相互信任，而不是“独立”，并将其他所有有用的团队实践（如 scrum 会议或结对编程）的效果乘以 10。
Teambuilding
Go make BBQ together, play foosball, find some team activity besides work that everyone likes. That will teach people to trust each other as opposed to being "independent" and multiply by 10 the effect of every other useful team practice, like scrum-meeting or pair programming.
以下是我的一些想法（小公司，三名程序员；曾经在一个大约 20 人的团队中工作）。
Here are some thoughts off the top of my head (small company, three programmers; used to work in a team of about 20).
我们处于类似的情况（一个漫长的项目并且都是朋友），并且遇到了类似的问题。以下做法让我们有了很大的进步：
每日站立会议是鼓励团队成员之间沟通的最佳方式
团队。每个人都知道所有团队成员在做什么，并且可以提供帮助
有任何问题。
团队内部使用的技术。为了让大家积极主动
参与，领导分配所有团队成员写一些东西
关于并维护 wiki 中的内容。当
每个人都写一些他们特别喜欢或正在做的事情
尝试让整个团队或所有感兴趣
在分析需求/功能的会议中可用，
优先级等等。如果团队中的某些成员是
并不专门从事该项目的该领域。这将给
每个人的背景以及更广泛的项目愿景。它将
允许（并鼓励）他们参与讨论
项目作为一个整体，而不是仅仅关注他们所关注的部分
正在努力。这种做法会引发很多讨论
当我们有机会和知识时（只需要很少的时间）
金额）有意见并喜欢对其中的所有内容发表评论
该项目。
两周一些成员就某些技术或
技术。一般包括实际练习和时间讨论
并提出问题。
We are in a similar situation (a long project and are all friends), and had similar problems. The following practices allowed us to improve a lot:
daily standup is the best thing to encourage communication among the
team. Everyone knows what all team members are doing, and can help
out with any problem.
technologies that are used within the team. To have everyone actively
participate, the leader assigns all team members something to write
about and maintain whithin the wiki. It is particuarly effective when
each one writes about something that they particularly likes or is
interested in.
available, in meetings where requirements/features are analyzed,
priorized, etc. It doesn't matter if some of members of the team are
not specificaly working in that area of the project. This will give
context to everybody and a broader vision of the project. It will
allow (and encourage) them to participate in this discussions of the
project as a whole, and not solely concentrate on the part that they
are working on. This practice will motivate a lot of discussion, all
of us when given a chance and knowledge (it only takes a very small
amount) have an opinion and like to comment on all everything within
the project.
two week some member gives a small presentation about some technology or
technique. Generaly it includes practical exercises, and time discuss
and ask questions.