问题
We already have mentoring, share information among each other, and hold regular technical sessions. However, we want these things written down, for the record and for new team members in the future. Right now we're at around 30 developers.
We're thinking about an internal blog and wiki.
While it would be great to share stuff on public blogs (and maybe even have official public developer blogs), for now we want to keep it internal. Our shop does mostly bespoke programming, and not products, so there will be a lot of proprietary customer information there. Self-censorship for a public blog will just slow us down.
Wikis are nice in concept but they need more organization and editorial, so I'm not convinced that it will be as sustainable.
How does your organization do it.
回答1:
Well, whatever technology or product you will decide to use, they will not be the problem. All knowledge which is not sufficiently well shared at the coffee machine needs attention.
- Attention when actually writing it (be it a document on a network drive, a wiki-page, a SharePoint server, whatever).
- Attention to categorize it (by linking, tags, web-pages, whatever...).
- Attention to keep it up-to-date (by individual on-demand or scheduled effort,).
Whatever you use, no technology will help with this. For this you need to motivate the team to write things down, read up things in the repository up first before phoning (and interrupting) a bunch of other team-members, and correct things if they are wrong.
From my experience, SharePoint and Wikis perform about the same. You need to beat people to use it, until they experience that they want to use it, because they will at some point experience that such type of information sharing can save time -- their time.
As you have already a habit of sharing information, this may not be so much of a hard problem for you. I'd recommend that one (or a few, better less than too many) provide some (spare) initial structure, and then let the fill-in begin. As no perfect categorization exists, you should not worry too much about it.
回答2:
Wikis are great. They do need to be structured, but I think the biggest obstacle in getting a wiki to work is to get people to actually use it to write down relevant information.
At my previous job, we had an internal IRC-channel which was very useful for microcommunication. At my current job, this does not work at all; very few developers have the habit of using a chatprogram for work purposes.
回答3:
I've seen collaboratives like Basecamp and Huddle used to great effect here, internal wikis (and intranets in general) tend to be under-developed and ignored in my experience.
回答4:
We use a combination of Trac for wiki, scm, and ticketing and a private Jabber/IRC server for us to talk to each other.
回答5:
In my previous job, we used SharePoint to keep our documentation organised. This was reasonably successful, but there's obviously a need to keep the site up to date, relevant and suitably setup. However, SharePoint's architecture was flexible enough for us to be able to customise it to our needs without resorting to coding. What I would suggest is that you put aside some time for managing whatever solution you go for. Without maintenance, it's very easy for a documentation repository to become either stale or disorganised. We made a point of updating our team's folders at the end of every Sprint of work (we used the Scrum agile methodology).
Wikis are a great idea for sharing knowledge, possibly in a less formal manner. I experimented with using a private WetPaint wiki, but didn't get buy-in from management. However, it's certainly worth a try. You aren't going to get away with no need for editorial control, but there's nothing wrong with making this aspect a shared responsibility between teams or doing it in a round-robin manner.
What I would recommend is booking time in your calendars for knowledge exchange sessions. It's all to easy for larger development houses to split into silos (not deliberately, but almost as a by-product of necessary specialisation) and for this to result in two or more teams working on many of the same problems. Monthly or fortnightly sessions with the whole group can be very useful. Videoed presentations are another idea, but there has to be a balance between keeping a record of technical details and the preparation required to do this effectively. (We never got this off the ground in my previous job.)
If you're split into small teams, I'd really recommend daily stand-up meetings where everyone goes through what they achieved the previous day and what they plan to do today. This is one of the keys to Scrum, it keeps everyone up to date really quickly and it saves a lot of unnecessary meetings and reviews.
I hope this helps.
回答6:
We use Yammer for short infos, which is a Twitter-like service, but it is private within your email domain. There is a web application, a Windows and Mac client and even an iPhone version.
For documentation we use an open source Wiki (ScrewturnWiki on the ASP.NET platform). It was accepted very well.
回答7:
One place I worked we also used a Wiki, but found that it wasn't updated often enough. Had to keep pushing people to use it.
Obviously we a crazy shared file system with matching shared email folders for project comms.
We also used an internal Instant Messaging system to avoid blanket emails around the office, but like Fog Creek I would probably now implement a private Twitter clone.
One thing we did is have a day each year where all the developers would meet up somewhere outside the office and present to each other on interesting things they had found/done. Sometimes stuff from projects, sometimes from personal work and sometimes from the day a month people were allowed to work on whatever the liked (like Google's 20% time).
回答8:
For content management we used to use a Zope server with Plone and ZWiki. We now use SharePoint 2007.
We also use Jabber for IM (we're a distributed team). IM is nice for quickly sharing things with the team, but you have to be careful not to abuse it or you'll be drowning in noise.
回答9:
We use Fogbugz for the wikis, the discussion groups and focused discussion of particular cases. For instant messaging, we use Sametime. This combination has turned out to be very powerful for us because it provides piles of functionality without forcing a lot of interface onto us. Low ceremony is good.
NOTE - instant messaging is the only aspect of Sametime that we use - I guess there are a lot of other crazy things that you can do and we are completely uninterested in.
回答10:
messengers and email
回答11:
We use Campfire for our chat and Jing for our image and/or short video demonstrations. They have proved invaluable.
回答12:
Our team is not very big (11 developers) so we have each month a meeting in which we share knowledge. Beside that I am busy adding interesting documents to the intranet.
And we often walk to each other to ask questions.
回答13:
As a programmer who works from home (without any option of going "to the office") - Our main means of communication is a private IRC channel. We're a small team of 3 developers so it works well.
回答14:
Skype is good to share info/ask quick questions. For some long term know-how we use Wiki.
回答15:
Wikis have worked well for me in the past. We used the free ScrewTurn wiki running on a small VM. It was fast, very easy to use and people seemed to like it so they actually used it.
来源：https://stackoverflow.com/questions/427847/what-tools-do-you-use-to-share-information-among-developers-in-your-group