Documentation 敏捷文档的具体例子？

在回答这个问题时，克里斯·巴伦斯回答说

我的问题是，你知道我能看到（例如在互联网上或书中）这类文档的任何好例子吗

如果可能，我很高兴看到许多例子，包括：

• 小/短/简单示例
• 大的/长的/复杂的例子
• 著名的例子
• 高质量的例子

---

我觉得这对谷歌来说不是一个容易的话题：我发现很多关于它的文章，但展示它的演示却很少。

就书籍而言，一个非常好的起点是迈克·科恩（Mike Cohn）写的。对于第一次接触敏捷方法论的人来说，这有很好的例子和良好的起点

就网站资源而言，它们非常少。也许一个很好的开始就是在谷歌图片上搜索这些关键词，因为很多人都在拍摄他们的燃尽图和用户故事。这对我刚开始的时候帮助很大。以下是一些示例：、和

然而，请注意，虽然燃尽图是一个简单的报告，您可以在迭代中运行您当前的故事点，但用户故事要比这更复杂，确实需要一些阅读来了解情况。从用户故事书开始

---

希望有帮助

考虑阅读Ambler的“敏捷建模”。他提出了一个非常有力的理由，说明为什么仅仅创建成吨的完整UML是一个相当糟糕的主意，并给出了一些很好的例子

几个月前，我们在开发功能的同时开始编写用户文档。为每个Scrum团队分配一名技术编写员

开发时必须编写用户文档有助于验证设计。技术作者也参与了应用程序的设计

这是对发布消耗和sprint消耗的补充

---

当团队认为与产品负责人沟通有用时，他们会创建其他文档。这一点变得不那么重要，因为我们正在学习编写更好的用户故事。

我认为对于这两个问题，你可以比浏览Alistair Cockburn的网站做得更糟。特别是，他有一篇关于燃尽图和生成燃尽图的不同方法的优秀文章：

（我附和早期海报对迈克·科恩作品的推荐）

其中一个窍门是确定哪种文档对您的项目有好处。你有很多开发人员，分布在时间和空间上吗？你需要更大、更重、更详细的故事。你有一个或两个开发者在同一个地方工作吗？你可以用较轻的。团队是否在系统中工作了很长时间（如果是遗留的）？轻松的故事可能就行了。团队是系统的新手，还是其业务需求复杂？这会将您推向更详细的方向

如果你正在进行一个“小”项目，根据十几个小的定义中的任何一个，你可能会对非常轻松的故事感到满意。下面是一个例子，同样来自Cockburn的网站：

---

我很惊讶地听到“网站资源很少”：这些类型的文档在实践中是否没有被开发开源（即公开可用）项目的“虚拟团队”（即地理分布的开发人员）使用？如果不是，你能推测为什么不吗？我实际上在一个远程敏捷团队工作，当然我们使用远程工具，我想你的意思是从学习敏捷的角度来看。对于虚拟工具，您可以选择Acunote、TargetProcess和Unfuddle。这些工具对远程团队很有用，但在可能的情况下不应该取代软木板；但是，它们往往不在网站上，因为它们是使用web以外的工具（如您引用的工具）编写的？或者，这更多是因为封闭/专有和开放/公共开发项目之间的区别：即它们在网站上，但不是在公共网站上？我想说，在我们的团队中，我们确实有用户故事，但很容易把它们弄得太大而忽略了重点。将用户故事放在索引卡上的部分原因是为了不让用户故事太大。仅仅解释为什么不创建大量UML并不能回答我的问题。对不起，我没有时间写更完整的内容，主要是想让你参考这本书。他确实讨论了用例的替代方案以及捕获什么是重要的。我一直认为功能规范是最有用的文档。用户文档是功能规范的一个子类，IMO。因此，如果你说用户文档已经足够了，并且在使用软件之前和/或使用软件开发它是很好的，我认为这是合理的。实际上，用户文档对于开发人员来说可能已经足够了（“我们正在构建什么最终用户功能？”）但对于项目经理来说可能不是enoug（“在这个冲刺过程中，我们在做什么，反过来说，哪些低优先级的功能被分类并至少在下次之前被忽略？”）。