我最近负责开发团队的维基。维基还处于初级阶段，所以我有很多合作的空间。它的目标是在开发团队内部安置。目前，wiki所持有的主要信息是编码标准。维护程序员维基
- 编辑 -
我平时忍了其他的事情有
的一件事是，它是当事情更新更改。 我们不希望我们的wiki旨在提供信息，并成为收集到的知识的中心来源，因此变得过时而无用。随着代码的更新，开发人员需要更新wiki上的任何相关信息。
除了编码标准之外，我们还保留与我们的代码库，新雇员的设置信息和一般环境信息一起使用的技巧和窍门。
想出一些风格指南，并教导别人如何风格的东西。当我负责一个公司维基时，其他所有开发人员都会写出几乎没有格式化的糟糕散文，而且看起来很糟糕。
远离需要讨论的事物。我在书评部分尝试了鞋拔，但要让别人评论事物实在太难了。
房屋图书馆的例子很好。和/或“故事板”在MethodX被调用时通过一个过程漫步用户。
您的开发团队在内部维基上使用了哪些最佳实践？
让它看起来不错。我知道这听起来并不重要，但如果你花一点时间打造品牌，那么实际使用它的人就会有所收获。摄取是关键，否则它就会枯萎而死亡。
什么信息对开发wiki很重要？
如果你去，你希望看到什么样的信息维基你的开发团队？
项目信息，谁正在做什么等设计决策。也是有用网站的最佳实践和链接。
是否有一些信息不应该在维基上，尽管它似乎是一个好主意？
低级任务列表往往会波动，不能保持最新，并且可能会产生误导。 此外，部门之间的关键通信更适合电子邮件，那么对话可以复制到维基。否则就太容易忽视了！
我们有一个开发wiki，它是一个很棒的工具。我们用它为应有尽有！
随着时间的推移。这个工具被认为越来越有价值。我们结束了为公司正在开发的不同产品创建新的维基。
我希望你找到你的开发wiki和我们一样有用！
请记住，wiki是互动的。如果你正在考虑发布，比如发布燃尽图，那么你的思路不够。分发这些信息只是其中的一部分。
例如，不是创建“当前Burndown图表”页面，而是创建“10-27-2008 Week of Burndown Chart”页面，然后鼓励人们评论该图表及其意义，以及你那周为什么这么差呢？
最难的部分是让开发人员使用你的wiki。我有一些长期建议位置：http://possibility.com/wiki/index.php?title=GettingYourWikiAdopted
获得通过的Wiki是艰难
有一个冠军
删除异议
创建内容
绊住了维基在公司流程
Evangelize
不要放弃
考虑不使用维基对话
想做就做！不要等待预算
有一个过渡计划
促进您的wiki
一个很好的做法是，在整个文档和源代码为每个通过您的wiki建设提供。然后开发人员将访问wiki访问构建信息，这使得它非常宝贵。
Wiki可以成为软件开发团队的宝贵资源，但它们不是银弹。创建一个很快就会被废弃或变得过时的Wiki是很容易的。
在我看来，成功的维基的关键是让整个团队加入进来。这意味着让人们远离其他资源（特别是电子邮件存档）作为知识库，并为人们贡献一些奖励。
但是，不要格式化沙皇也很重要：如果你有很多文件，例如MS WORD，它们可能是Wiki格式的所有文件，但这需要时间并可能会如果你有图表，文档等，就会很烦人。在这种情况下，最好妥协并让人们以文字格式保存它，只要通过Wiki访问最新版本的唯一方法。
如果你不是经理，你需要找一个经理，因为这需要一些“执法”。
在维基软件及其在软件工程中的应用方面一直在积累研究和经验。例如，您可以搜索ACM数字图书馆。我是SE的维基年度研讨会的合作伙伴，我们有一些有趣的经验报告，并且在维基国际研讨会上还有其他材料。
我们的房子和内部团队维基。还有我们把所有必要信息，以便我们在开发的每个项目：
以及其他我们填写的内容eeds写在一个项目上。它是我们正在运行的最有用的Web应用程序（除Mantis之外）。在更一般的网页上，我们对每个我们正在使用的分类学，我们使用的一般项目指导方针，政策，编码和开发实践进行了定义。 它在那里，它简单而有效，我认为每个球队都应该有其中之一。
Wikipatterns是一个致力于记录最佳wiki实践的网站。他们还描述反模式并讨论如何处理这些模式。我读了他们的书，对于我来说，在一个拥有150多人的组织中维护一个维基是非常重要的。
您使用的是什么wiki软件？这些工具的功能和可能性受到限制。 – 2008-10-29 18:57:36
我们正在使用screwturn wiki – wusher 2008-10-29 18:59:58
另外，你有什么其他工具？如果你没有错误追踪器，你可能想用你的wiki（当然，最好是得到一个错误追踪器）。 – 2008-10-29 19:00:30