19

我最近负责开发团队的 wiki。wiki 仍处于起步阶段，所以我有很大的工作空间。它的目标是容纳开发团队的内部。目前，wiki 拥有的主要信息是编码标准。

  • 您的开发团队在其内部 wiki 中使用了哪些最佳实践？
  • 开发 wiki 上的哪些信息很重要？
  • 如果您要访问开发团队的 wiki，您希望看到哪些信息？
  • 是否有一些信息不应该出现在 wiki 上，即使它看起来是个好主意？

- 编辑 -

  • 另外，有没有很好的方法来组织信息？（例如按层（数据、用户界面）、按项目或其他）
4

11 回答 11

9
  • 新程序员源码库介绍
  • 一般文档（不是 API 文档本身，而是更多类似教程的东西）
  • 员工名单/谁在做什么以及如何联系他们
  • 解释软件中使用的概念的注释/资源/文章
  • 构建过程的文档和代码库的文件系统布局

我通常在那里放的其他东西是

  • 计划/待办事项清单
  • 其他人感兴趣的信息
  • 我觉得应该分享的其他一切
于 2008-10-29T18:56:15.553 回答
6

我们有一个开发维基，它是一个很棒的工具。我们将它用于一切！

  • 当头脑风暴新想法时，我们会在 wiki 上捕捉它们。wiki 的低摩擦特性使组织中的任何人（我们是一家小型初创公司）都可以轻松地添加他们想到的想法。我们有一个高级别的“头脑风暴”页面，该页面链接到包含每个想法的详尽描述的详细页面。
  • 对于每次迭代，我们会将特征想法项从“头脑风暴”列表“移动”到该迭代的特征列表。该功能的细节已被清除，以包括设计和实现细节。
  • 随着功能的完成，迭代页面变成了我们的发布说明页面——其中还包括来自我们版本控制系统的发布标签。
  • 我们有一个与功能页面非常相似的错误页面。错误修复已添加到迭代/发布页面，因为它们正在处理/完成。
  • 我们还在 wiki 上创建了我们的用户文档，并在发布时将这些页面导出。

随着时间推移。这个工具被认为越来越有价值。我们最终为公司正在开发的不同产品创建了新的 wiki。

我希望您发现您的开发 wiki 和我们一样有用！

于 2008-10-29T19:45:12.927 回答
6

Wikipatterns是一个致力于记录最佳 wiki 实践的网站。他们还描述了反模式并讨论了处理它们的方法。我读了他们的书，在一个 150 多人的组织中创建一个 wiki 对我来说是一笔巨大的财富。

于 2008-12-09T04:38:36.413 回答
2

我们在开发 wiki 上强调的一件事是，它会在事情发生变化时进行更新。我们不希望我们旨在提供信息并成为收集知识的中心来源的 wiki 变得过时以致于无用。随着代码的更新，开发人员被要求更新 wiki 上的任何相关信息。

除了编码标准，我们还保留了使用代码库的提示和技巧、新员工的设置信息以及一般环境信息。

于 2008-10-29T19:00:51.253 回答
2

最困难的部分是让开发人员使用您的 wiki。我在这里有一些长期存在的建议：http: //possibility.com/wiki/index.php?title= GettingYourWikiAdopted

让 Wiki 被采用是困难的

有一个冠军

删除异议

创建内容

将 Wiki 融入公司流程

传福音

不要放弃

考虑不使用 Wiki 进行对话

去做就对了！不要等待预算

制定过渡计划

推广你的维基

一种好的做法是通过您的 wiki 提供每个构建的完整文档和源代码。然后开发人员将去 wiki 访问构建信息，这使得它变得非常宝贵。

于 2008-10-29T19:56:10.517 回答
2

Wiki 可以成为软件开发团队的宝贵资源，但它们不是灵丹妙药。创建一个很快就会被废弃或严重过时的 Wiki 太容易了。

在我看来，成功的 Wiki 的关键是让整个团队都参与进来。这意味着让人们远离其他资源（尤其是电子邮件档案）作为知识库，并为人们做出贡献提供一些激励。

但是，不要成为格式沙皇也很重要：如果您有很多文档是在 MS WORD 中生成的，那么将它们全部以 Wiki 格式完成可能是理想的，但这需要时间，并且如果您这样做可能会很烦人有图表、文档等。在这种情况下，最好妥协并让人们将其保存为 word 格式，只要访问最新版本的唯一方法是通过 Wiki。

如果您不是经理，则需要让经理加入，因为这需要一些“强制执行”。

关于 Wiki 及其在软件工程中的使用，已经积累了研究和经验。例如，您可以搜索 ACM 数字图书馆。我是 SE wiki 年度研讨会的协办者，我们有一些有趣的经验报告，并且在 Wiki 国际研讨会上还有其他材料。

于 2008-10-29T19:56:25.383 回答
1
  • 燃尽图
  • 开发环境的通用设置信息（新人开始时很好）
  • 眼镜
  • 开发工具的已知问题和解决方法
于 2008-10-29T19:00:31.613 回答
1

想出一些风格指南，教别人如何设计风格。当我负责一个企业 wiki 时，所有其他开发人员只会写出几乎没有格式的蹩脚散文，而且看起来很糟糕。

远离需要讨论的事情。我在书评部分尝试了鞋拔，但很难让其他人评论。

内部图书馆的例子很好。和/或“故事板”在调用 MethodX 时引导用户完成一个过程。

于 2008-10-29T19:00:59.083 回答
1

您的开发团队在其内部 wiki 中使用了哪些最佳实践？

让它看起来不错。我知道这听起来并不重要，但是如果您花一点时间进行品牌推广，就实际使用它的人而言，它会有所回报。吸收是关键，否则它只会枯萎死亡。

开发 wiki 上的哪些信息很重要？

  • 有关项目、里程碑、交付日期等的一般信息。
  • 设计决策/会议摘要。重要的是，这样您就不会一次又一次地重新访问相同的区域。
  • 当前项目一般开发的 HowTo 指南（例如，如何开发新插件）

如果您要访问开发团队的 wiki，您希望看到哪些信息？

项目信息，谁在做什么等。设计决策。还有最佳实践和有用网站的链接。

是否有一些信息不应该出现在 wiki 上，即使它看起来是个好主意？

低级任务列表往往会波动并且不会保持最新，并且可能会产生误导。此外，部门之间的关键通信更适合电子邮件，然后可以将对话复制到 wiki。否则很容易忽略它！

于 2008-10-29T19:07:23.080 回答
1

请记住，wiki 是交互式的。如果您正在考虑发布，例如发布燃尽图，那么您的思考还不够远。分发这些信息只是其中的一部分。

例如，与其创建“当前燃尽图”页面，不如创建一个“2008 年 10 月 27 日当周燃尽图”页面，然后鼓励人们评论该图表，以及它的含义以及您这样做的原因那一周很糟糕。

于 2008-10-29T19:48:58.303 回答
1

我们拥有和内部团队 wiki。我们在那里为我们正在开发的每个项目提供了所有必要的信息：

  • 存储库
  • 虚拟机地址
  • 密码
  • 项目文件
  • 项目概况
  • 项目状态

我们填写的任何其他内容都需要写在项目上。它是我们正在运行的最有用的 Web 应用程序（除了Mantis）。在更一般的页面上，我们对我们使用的每个分类法、一般项目指南、政策、编码和我们使用的开发实践进行了定义。它就在那里，简单而有效，我认为每个团队都应该拥有其中一个。

于 2008-10-29T22:09:15.820 回答