我最近负责开发团队的 wiki。 wiki 仍处于起步阶段，所以我有很大的工作空间。它的目标是容纳开发团队的内部。目前，wiki 拥有的主要信息是编码标准。
-- 编辑--
【问题讨论】：
标签： wiki
我通常会放在那里的其他东西
【讨论】：
我们有一个开发 wiki，它是一个很棒的工具。我们将它用于一切！
随着时间的推移。这个工具被认为越来越有价值。我们最终为公司正在开发的不同产品创建了新的 wiki。
我希望您发现您的开发 wiki 和我们一样有用！
【讨论】：
Wikipatterns 是一个致力于记录最佳 wiki 实践的网站。他们还描述了反模式并讨论了处理它们的方法。我读了他们的书，在一个 150 多人的组织中创建一个 wiki 对我来说是一笔巨大的财富。
【讨论】：
我们在开发 wiki 上强调的一件事是，它会在事情发生变化时进行更新。 我们不希望旨在提供信息并成为收集知识的中心来源的 wiki 变得过时以致于无用。随着代码的更新，请开发人员更新 wiki 上的任何相关信息。
除了编码标准之外，我们还保留有关使用我们的代码库的提示和技巧、新员工的设置信息以及一般环境信息。
【讨论】：
最难的部分是让开发人员使用您的 wiki。我在这里有一些长期存在的建议：http://possibility.com/wiki/index.php?title=GettingYourWikiAdopted
让 Wiki 被采用是困难的
有一个冠军
删除异议
创建内容
将 Wiki 融入公司流程
传福音
不要放弃
考虑不使用 Wiki 进行对话
就做吧！不要等待预算
有一个过渡计划
推广您的 Wiki
一个好的做法是通过您的 wiki 提供每个构建的完整文档和源代码。然后开发人员将前往 wiki 访问构建信息，这使其非常宝贵。
【讨论】：
对于软件开发团队来说，Wiki 可能是一种宝贵的资源，但它们并不是灵丹妙药。创建一个很快就会被废弃或严重过时的 Wiki 太容易了。
在我看来，成功的 Wiki 的关键是让整个团队都参与进来。这意味着让人们远离其他资源（尤其是电子邮件档案）作为知识库，并为人们做出贡献提供一些激励。
但是，不要成为格式沙皇也很重要：如果您有很多文档是用 MS WORD 生成的，那么将它们全部以 Wiki 格式完成可能是理想的，但这需要时间并且可能如果您有图表、文档等，这很烦人。在这种情况下，最好妥协并让人们将其保存为 word 格式，只要访问最新版本的唯一方法是通过 Wiki。
如果您不是经理，则需要让一名经理参与进来，因为这需要一些“强制执行”。
在 Wiki 及其在软件工程中的使用方面积累了研究和经验。例如，您可以搜索 ACM 数字图书馆。我是 SE wiki 年度研讨会的协办者，我们有一些有趣的经验报告，并且在国际 Wiki 研讨会上还有其他材料。
【讨论】：
【讨论】：
想出一些风格指南，教别人如何设计风格。当我负责一个企业 wiki 时，所有其他开发人员只会写出几乎没有格式的蹩脚散文，而且看起来很糟糕。
远离需要讨论的事情。我在书评区尝试了鞋拔，但很难让其他人评论。
内部图书馆的例子很好。和/或“故事板”在调用 MethodX 时引导用户完成流程。
【讨论】：
您的开发团队在其内部 wiki 中使用了哪些最佳实践？
让它看起来不错。我知道这听起来并不重要，但是如果您花一点时间进行品牌推广，就实际使用它的人而言，它会有所回报。吸收是关键，否则它就会枯萎死亡。
在开发 wiki 上拥有哪些重要信息？
如果您要访问开发团队的 wiki，您希望看到哪些信息？
项目信息，谁在做什么等。设计决策。还有最佳实践和有用网站的链接。
是否有一些信息不应该出现在 wiki 上，即使它看起来是个好主意？
低级别的任务列表往往会波动并且不会保持最新，并且可能会产生误导。 此外，部门之间的关键通信更适合电子邮件，然后可以将对话复制到 wiki。不然太容易忽略了！
【讨论】：
请记住，wiki 是交互式的。如果您正在考虑发布，例如发布燃尽图，那么您的思考还不够远。分发这些信息只是其中的一部分。
例如，与其创建“当前燃尽图”页面，不如创建一个“2008 年 10 月 27 日当周燃尽图”页面，然后鼓励人们评论该图表，以及它的含义以及原因你那周表现太差了。
【讨论】：
我们拥有和内部团队 wiki。我们在其中放置了我们正在开发的每个项目的所有必要信息：
我们填写的任何其他内容都需要写在项目上。它是我们正在运行的最有用的 Web 应用程序（除了 Mantis）。在更一般的页面上，我们对我们使用的每个分类法、一般项目指南、政策、编码和我们使用的开发实践进行了定义。 它就在那里，简单而有效，我认为每个团队都应该拥有一个。
【讨论】：