维护程序员维基[关闭]

• 新程序员源库简介
• 一般文档(不是API文档本身,而是更多类似教程的内容)
• 员工名单/谁在做什么以及如何联系他们
• 说明软件中使用的概念的注释/资源/文章
• 代码库的构建过程和文件系统布局的文档

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

• 计划/待办事项列表
• 其他人感兴趣的信息
• 其他我觉得应该分享的东西

我们有一个开发wiki,它是一个很好的工具。我们用它 一切 !

• 当头脑风暴新想法时,我们会在wiki上捕捉到它们。wiki的低摩擦特性使组织中的任何人(我们是一家小公司)都可以很容易地根据自己的想法添加想法。我们有一个高级的“头脑风暴”页面,链接到包含每个想法的详细描述的页面。
• 对于每个迭代,我们将“移动”特性想法项目从“头脑风暴”列表移动到该迭代的特性列表。该特性的详细信息被清除,以包括设计和实现的详细信息。
• 随着功能的完成,迭代页面成为了我们的发行说明页面——其中还包括来自版本控制系统的发行标签。
• 我们有一个bug页面,其工作原理与功能页面非常相似。在迭代/发布页面进行/完成时,错误修复被添加到这些页面中。
• 我们还在wiki上创建了我们的用户文档,并将这些页面与版本一起导出。

随着时间的推移。这个工具被越来越重视。我们最终为公司正在开发的不同产品创建了新的维基。

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

Wikipatterns 是一个致力于记录最佳wiki实践的网站。他们还描述了反模式并讨论了处理它们的方法。我读了他们的书,对我来说,在一个150多人的组织里,把一个wiki从地上拿下来是一个很好的资产。

我们在dev wiki上强调的一点是,当事情发生变化时,它会被更新。 我们不希望我们的wiki(旨在提供信息并成为收集知识的中心来源)变得如此过时,以致于毫无用处。随着代码的更新,开发人员需要更新wiki上的任何相关信息。

除了编码标准之外,我们还保留使用代码库、为新员工设置信息和一般环境信息的技巧和技巧。

• 烧毁图
• 开发环境的常见设置信息(适合新员工开始时使用)
• 规格
• 已知问题和开发工具的解决方法

想出一些风格指南,教别人如何设计风格。当我负责一个公司的wiki时,所有其他的开发人员都只会写一些格式很差、看起来很糟糕的垃圾文章。

远离需要讨论的事情。我曾在一个书评区试过Shoehorn,但很难让其他人对这件事发表评论。

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

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

让它看起来漂亮。我知道这听起来并不重要,但是如果你花点时间给品牌打上烙印,它会从人们实际使用它的角度得到回报。摄取是关键,否则它会枯萎死亡。

在dev wiki上有哪些重要信息?

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

如果您要为开发团队访问wiki,您希望看到什么信息?

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

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

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

记住,wiki是交互式的。如果你在考虑出版,比如出版燃尽图,那么你的想法就不够了。分发这些信息只是其中的一部分。

例如,与其有“当前燃尽图”页面,不如为“2008年10月27日的一周燃尽图”创建一个页面,然后鼓励人们对该图表发表评论,以及它的含义,以及为什么你在那一周表现如此糟糕。

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

接受维基是很困难的

有冠军

删除反对意见

创建内容

在公司流程中嵌入wiki

福音传道

不要放弃

考虑不要使用wiki进行对话

想做就做!不要等待预算

有一个过渡计划

推广你的wiki

一个好的实践是通过wiki为每个构建提供完整的文档和源代码。然后开发人员将访问wiki来访问构建信息,这使得它非常有价值。

对于软件开发团队来说,维基是一种宝贵的资源,但它们不是一颗银弹。创建一个wiki太容易了,它会很快被废弃或者变得非常过时。

在我看来,一个成功的wiki的关键是让整个团队加入。这意味着让人们远离作为知识库的其他资源(尤其是电子邮件档案),并为人们提供一些贡献的激励。

然而,不成为一个格式沙皇也很重要:如果你有很多文档,比如说,用Word生成,那么最好都用wiki格式生成,但是如果你有图表、文档等,这需要时间,而且可能会很烦人。在这种情况下,最好折衷一下,让人们用Word格式保存它,只要这是唯一的方法。通过wiki访问最新版本。

如果你不是经理,你需要一个经理加入,因为这需要一些“强制执行”。

维基及其在软件工程中的应用已经积累了大量的研究和经验。例如,您可以搜索ACM数字库。我是一个为SE举办的维基年度研讨会的协调人,我们有几个有趣的经验报告,在维基国际研讨会上还有其他材料。

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

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

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