You are allowed to 'seem stupid', but please ask if you don't know, or don't fully understand what I'm saying. And please tell me if I'm wrong (I didn't realize it because I'm equally stupid.)
在我目前的工作中，我们每月召开一次 IT 小组会议，有时来自不同团队的开发人员会演示他们一直在从事的项目。
I worked at one company where every Friday we had lunch meetings for developers. Management would provide food while developers had to share their knowledge; present some tool or technique one learned recently, or give a demo of a project you are working on, etc. It wasn't restricted to the technologies that were being used by the team at that time, developers were encourage to learn new technologies and give a demo to the team.
And at my current job we have monthly IT group meeting, where sometimes developers from different teams demo off the projects they've been working on.
An internal twitter-esque utility. Maybe a wiki if you can get it to work, I personally find it a little too much. But twitter is different. "just added an extention method to escape a like clause in a rowfilter" and stuff like that.
Some people may find it a little overbearing, but a common location for utilities so you know where to look and string.CountOccurrences isn't scattered throughout the codebase.
Hire the right people - This is essential if you want to create a great dynamic (asocial people require a lot more effort)
Pre-mortem and post-mortem. We use the wiki for this, create a page for each of your projects, split it into section of recurring things (both goods and bad). At the end of each milestone, have the team meet to do a post-mortem. At the end of the project (or after a fix lenght of time), have project coordinator compile this into something easy to read for posterity (and put it on your wiki)
Daily stand-up are a must! You already said it, but I find it so helpful!
If you have multiple teams in the company, organize conference about one of their greatest achievements. If possible on a regular basis, even accros department, you would be surprised how artists can be interested into programmers work.
Lunch is a good time to share, in our company we have the president breakfast, project leads lunch, end of projects supper. I love them all, mix and match for greater results.
Offsite meeting with the whole company is great, we do it at least once a year (morning we present what's coming up in the futur, afternoon, is activities to learn about the projects)
Wikis are great, but beware of informations that can become false over time (this is a reccuring problem with any written informations)
Patterns & Practices meetings - These don't have to be every week but there should be some time devoted to where the team can discuss various outstanding questions and have concensus for things that may save a lot of people headaches.
Culture factor - Does the work place provide enough socializing to help the team gel or could some team-building exercises, e.g. an obstacle course or cooking together, be useful in getting some dynamics established. Is there a humility among developers so that there aren't big egos that can be a problem. Another factor here is to think about how you'd answer this: Would you go to a local pub and have a drink with your fellow teammates? If yes, then you have some good points here while if not, then there may be some investigation to do here.
Retrospective follow-up - How are ideas presented during retrospectives considered and implemented? How are meetings handled in general?
Demos within the team - If some story got finished and involved some big code points, then perhaps there should be a little demonstration of this for the team to see what was done and allow others to see what was done so that the knowledge does get spread around. This can dovetail with my first point in terms of being something that helps to further communication.
I'm a big proponent of working in pairs. It is a good way to transfer knowledge and keep communication lines open. Try mixing up the pairs for each project as well.
I've tried many approaches, and am a big fan of working in pairs on projects, as well as doing regular discussions or meetings with the team.
However, I've also found that the single best thing I can do is foster a culture of constant communication between the developers. I try to have all of my developers communicate with each other as they work - not even necessarily waiting until a weekly or monthly meeting.
For me, this is a little trickier as most of my developers are not in the same location, so we have a single XMPP chat room setup, and all of us are always logged in when we're working on the project. Some of the developers (including myself) will login during our off hours, as well.
I do the same with the people in my office - we tend to be a fairly quiet bunch, but I'm very open to having people interrupt each other with questions, or grab a chair and sit down to brainstorm at any time.
Part of why this works, though, is I try not to restrict the communication to the work at hand, or any specific project. My feeling is that people are going to talk about other, non-work related things, whether or not I foster that. I'd rather have the "water cooler" talk in an official channel, though, than outside.
This makes everybody feel more at ease to ask the questions that "seem obvious". Also, people ask questions continually, since they're right there, and used to talking to everybody. It's easy to ignore if needed, but also much easier to just throw out a general question and see if anybody has ideas without feeling like a pain, etc.
My experience is that the time lost due to interruption is much smaller than the time saved due to having a group that is always eager to help solve a problem at hand.
If you have a small enough team, using adequately SVN commit comments, and exploit them a tool that generates an RSS feed (like Trac for instance) can be an easy and efficient way to promote communication.
There are several requirements for this to work, which are quite easy to attain: - commit frequently (that is good in itself, as it allows everybody to benefit from each programmer's local changes, and to identify problems early); - use verbose comments (which is good to, as it allows to trace more easily what was changed, in case anything breaks down); - ensure everybody actually reads (better even, keeps posted to, through an RSS reader) the feeds.
Of course, there is no way to "reply" to such comments, but if someone really needs to reply, it's probably between that person and the committer, so mail is usually enough.
An other useful tool is to ask each developer to, let's say, once a week, write a 10 or so bullet point list of recommendations for fellow coders, on a topic he/she is really familiar with.
预算更加困难：开发人员 Mary 向开发人员 Sophie 询问了一个半小时的动态链接问题。 第二天，她带着一些问题回来了。 经验丰富的开发人员会花更多时间进行分发，而年轻的开发人员则需要更多时间学习。
Time.
Official
Getting out of your dusty office to clear your mind, really taking the time to go to a lecture or training, it all helps to spread knowledge.
It's also easy to budget: N developers go to meeting for T hours.
Unofficial
"On the job" training... The things you need for your specific job can only be taught by someone who knows the job.
In the current climate, under the current pressure (must ship now), no-one takes time to fully explain something. Only when people are relaxed, they are readyfor information sharing. People are relaxed when they have enough time.
Apart from that, you need to bump into some specific linker error before you really start thinking about it. Without the time to think, ask, read, you won't be able to get the knowledge. You can't postpone it to an official linker-training.
Way harder to budget: developer Mary asked developer Sophie about dynamic linkage for an hour and a half. The day after, she went back with some questions. Experienced developers will spend more time distributing, while younger will need more time learning.
发布评论
评论（10）
相信。
您可以“看起来很愚蠢”，但如果您不知道或不完全理解我在说什么，请询问。 如果我错了，请告诉我（我没有意识到，因为我同样愚蠢。）
Trust.
You are allowed to 'seem stupid', but please ask if you don't know, or don't fully understand what I'm saying. And please tell me if I'm wrong (I didn't realize it because I'm equally stupid.)
我在一家公司工作，每周五我们都会为开发人员举办午餐会议。 管理层将提供食物，而开发人员必须分享他们的知识； 展示最近学到的一些工具或技术，或者演示您正在从事的项目等。
不限于当时团队正在使用的技术，鼓励开发人员学习新技术并向团队提供演示。
在我目前的工作中，我们每月召开一次 IT 小组会议，有时来自不同团队的开发人员会演示他们一直在从事的项目。
I worked at one company where every Friday we had lunch meetings for developers. Management would provide food while developers had to share their knowledge; present some tool or technique one learned recently, or give a demo of a project you are working on, etc.
It wasn't restricted to the technologies that were being used by the team at that time, developers were encourage to learn new technologies and give a demo to the team.
And at my current job we have monthly IT group meeting, where sometimes developers from different teams demo off the projects they've been working on.
内部 Twitter 式实用程序。 如果你能让它工作的话，也许是一个维基百科，我个人觉得它有点太多了。 但推特不同。 “刚刚添加了一个扩展方法来转义 rowfilter 中的 like 子句”之类的东西。
有些人可能会觉得它有点霸道，但它是实用程序的常见位置，因此您知道在哪里查找和字符串。CountOccurrences 并没有分散在整个代码库中。
An internal twitter-esque utility. Maybe a wiki if you can get it to work, I personally find it a little too much. But twitter is different. "just added an extention method to escape a like clause in a rowfilter" and stuff like that.
Some people may find it a little overbearing, but a common location for utilities so you know where to look and string.CountOccurrences isn't scattered throughout the codebase.
我将添加更多内容
I'll add a few more
我想到的还有一些事情：
模式和模式 实践会议 - 不必每周举行，但应该花一些时间让团队可以讨论各种悬而未决的问题，并就可能让很多人省去麻烦的事情达成共识。
文化因素 - 工作场所是否提供足够的社交活动来帮助团队凝聚，或者是否可以进行一些团队建设练习，例如障碍训练或一起做饭，有助于建立一些动力。 开发人员之间是否保持谦逊，以免自负造成问题。 这里的另一个因素是考虑如何回答这个问题：你会去当地的酒吧和你的队友一起喝一杯吗？ 如果是，那么您在这里有一些好的观点，如果没有，那么这里可能需要进行一些调查。
回顾性跟进 - 如何考虑和实施回顾期间提出的想法？ 会议一般是如何进行的？
团队内的演示 - 如果某个故事已经完成并涉及一些大的代码点，那么也许应该对此进行一些演示，以便团队看到做了什么，并允许其他人看到做了什么，以便了解确实传播开来。 这可以与我的第一点相吻合，因为它有助于进一步沟通。
A few more things to my mind:
Patterns & Practices meetings - These don't have to be every week but there should be some time devoted to where the team can discuss various outstanding questions and have concensus for things that may save a lot of people headaches.
Culture factor - Does the work place provide enough socializing to help the team gel or could some team-building exercises, e.g. an obstacle course or cooking together, be useful in getting some dynamics established. Is there a humility among developers so that there aren't big egos that can be a problem. Another factor here is to think about how you'd answer this: Would you go to a local pub and have a drink with your fellow teammates? If yes, then you have some good points here while if not, then there may be some investigation to do here.
Retrospective follow-up - How are ideas presented during retrospectives considered and implemented? How are meetings handled in general?
Demos within the team - If some story got finished and involved some big code points, then perhaps there should be a little demonstration of this for the team to see what was done and allow others to see what was done so that the knowledge does get spread around. This can dovetail with my first point in terms of being something that helps to further communication.
我非常支持结对工作。 这是传播知识和保持沟通渠道畅通的好方法。 也尝试混合每个项目的配对。
I'm a big proponent of working in pairs. It is a good way to transfer knowledge and keep communication lines open. Try mixing up the pairs for each project as well.
我尝试了很多方法，并且非常喜欢在项目中结对工作，以及与团队进行定期讨论或会议。
然而，我还发现我能做的最好的事情就是培养开发人员之间不断沟通的文化。 我尝试让所有开发人员在工作时相互沟通 - 甚至不必等到每周或每月的会议。
对我来说，这有点棘手，因为我的大多数开发人员不在同一个位置，因此我们有一个 XMPP 聊天室设置，并且在我们处理项目时我们所有人都始终登录。 一些开发人员（包括我自己）也会在下班时间登录。
我对办公室里的人也这样做——我们往往是一群相当安静的人，但我很愿意让人们随时用问题打断对方，或者抓起椅子坐下来进行头脑风暴。
不过，这种方法有效的部分原因是我尽量不将沟通限制在手头的工作或任何特定项目上。 我的感觉是，人们会谈论其他与工作无关的事情，无论我是否鼓励这样做。 不过，我宁愿在官方渠道进行“饮水机”谈话，也不愿在外面进行。
这让每个人都更放心地提出“看似显而易见”的问题。 此外，人们会不断地提出问题，因为他们就在那里，并且习惯于与每个人交谈。 如果需要，很容易忽略，但也更容易提出一个一般性问题，看看是否有人有想法，而不感到痛苦，等等。
我的经验是，由于中断而损失的时间远小于由于中断而节省的时间。拥有一个总是渴望帮助解决手头问题的团队。
I've tried many approaches, and am a big fan of working in pairs on projects, as well as doing regular discussions or meetings with the team.
However, I've also found that the single best thing I can do is foster a culture of constant communication between the developers. I try to have all of my developers communicate with each other as they work - not even necessarily waiting until a weekly or monthly meeting.
For me, this is a little trickier as most of my developers are not in the same location, so we have a single XMPP chat room setup, and all of us are always logged in when we're working on the project. Some of the developers (including myself) will login during our off hours, as well.
I do the same with the people in my office - we tend to be a fairly quiet bunch, but I'm very open to having people interrupt each other with questions, or grab a chair and sit down to brainstorm at any time.
Part of why this works, though, is I try not to restrict the communication to the work at hand, or any specific project. My feeling is that people are going to talk about other, non-work related things, whether or not I foster that. I'd rather have the "water cooler" talk in an official channel, though, than outside.
This makes everybody feel more at ease to ask the questions that "seem obvious". Also, people ask questions continually, since they're right there, and used to talking to everybody. It's easy to ignore if needed, but also much easier to just throw out a general question and see if anybody has ideas without feeling like a pain, etc.
My experience is that the time lost due to interruption is much smaller than the time saved due to having a group that is always eager to help solve a problem at hand.
如果您有一个足够小的团队，充分使用 SVN 提交评论，并利用它们生成 RSS 提要的工具（例如 Trac）可以是促进沟通的简单而有效的方式。
要实现此功能有几个要求，这些要求很容易实现：
- 经常提交（这本身就很好，因为它允许每个人从每个程序员的本地更改中受益，并尽早发现问题）；
- 使用详细的注释（这很好，因为它可以更轻松地跟踪更改的内容，以防出现任何问题）；
- 确保每个人都真正阅读（更好的是，通过 RSS 阅读器持续发布）提要。
当然，没有办法“回复”此类评论，但如果有人确实需要回复，可能是在该人和提交者之间，所以邮件通常就足够了。
另一个有用的工具是要求每个开发人员（比方说，每周一次）针对他/她真正熟悉的主题，为其他编码人员编写一份大约 10 个要点的建议列表。
If you have a small enough team, using adequately SVN commit comments, and exploit them a tool that generates an RSS feed (like Trac for instance) can be an easy and efficient way to promote communication.
There are several requirements for this to work, which are quite easy to attain:
- commit frequently (that is good in itself, as it allows everybody to benefit from each programmer's local changes, and to identify problems early);
- use verbose comments (which is good to, as it allows to trace more easily what was changed, in case anything breaks down);
- ensure everybody actually reads (better even, keeps posted to, through an RSS reader) the feeds.
Of course, there is no way to "reply" to such comments, but if someone really needs to reply, it's probably between that person and the committer, so mail is usually enough.
An other useful tool is to ask each developer to, let's say, once a week, write a 10 or so bullet point list of recommendations for fellow coders, on a topic he/she is really familiar with.
时间。
走出尘土飞扬的办公室
，清理一下思绪，真正花时间去听讲座或培训，这都有助于传播知识。
预算也很容易：N 个开发人员参加 T 小时的会议。
非官方的
“在职”培训...您的特定工作所需的内容只能由了解该工作的人教授。
在当前的气候下，在当前的压力下（必须立即发货），没有人花时间来充分解释某件事。 只有当人们放松时，他们才准备好分享信息。 当人们有足够的时间时，他们就会放松。
除此之外，在您真正开始考虑之前，您需要遇到一些特定的链接器错误。 如果没有时间去思考、提问、阅读，你将无法获得知识。 您不能将其推迟到官方链接器培训。
预算更加困难：开发人员 Mary 向开发人员 Sophie 询问了一个半小时的动态链接问题。 第二天，她带着一些问题回来了。 经验丰富的开发人员会花更多时间进行分发，而年轻的开发人员则需要更多时间学习。
Time.
Official
Getting out of your dusty office to clear your mind, really taking the time to go to a lecture or training, it all helps to spread knowledge.
It's also easy to budget: N developers go to meeting for T hours.
Unofficial
"On the job" training... The things you need for your specific job can only be taught by someone who knows the job.
In the current climate, under the current pressure (must ship now), no-one takes time to fully explain something. Only when people are relaxed, they are readyfor information sharing. People are relaxed when they have enough time.
Apart from that, you need to bump into some specific linker error before you really start thinking about it. Without the time to think, ask, read, you won't be able to get the knowledge. You can't postpone it to an official linker-training.
Way harder to budget: developer Mary asked developer Sophie about dynamic linkage for an hour and a half. The day after, she went back with some questions. Experienced developers will spend more time distributing, while younger will need more time learning.
社会化和共同目标总是鼓励信息交流。
Socialization and common goal always encourages exchanege of information.