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