iis默认文档的优先级最低_最低要求文档：相关事项

iis默认文档的优先级最低

一位同事问我有关团队故事所需的文档类型。 他想知道一个大型的，地理位置分散的团队可能会做什么。 故事，史诗和路线图合理吗？ 他们对需求文档的处理能力如何？

当我考虑需求和多少文档时，我从卡片，对话，确认的模式开始。 我遵循的指导原则是：如果我不能在卡的正面写足够大的文字以供查看，那么我的故事就太大了。 我不使用大卡。 我打破了这个故事。 这是创建最少文档的一种方法-将故事分解成可用的部分。

与所有有趣的问题一样，这取决于团队的背景。 以下是考虑您的上下文以创建最低要求文档的方法：

团队有多少合作？

太多分散的团队作为筒仓中的人员进行工作，彼此之间进行工作分配。 如果您没有足够的重叠时间，那么确实需要移交工作。

如果团队放弃工作，那么他们的工作就是资源效率，而不是流程效率 。 而且，由于他们没有团队协作，因此他们需要对需求有很多描述。

注意：在“ 从混乱到成功的分布式敏捷团队”中 ，如果您没有足够的重叠时间，Mark和我建议使用除敏捷方法以外的任何其他方法。

要求是否被表述为要解决的任务或问题？

假设产品负责人（可能是一个人）编写了需求。 （这不是一个好主意，但我认为这是该团队的现实。）

请注意，当PO单独写入时，PO不会遵循Card，Conversation，Confirmation的模式 。 之所以存在这种模式，是为了在客户和团队之间建立协作 。 因为该团队已经没有协作时间，所以使用依赖于协作的敏捷方法非常困难。

如果PO将故事或史诗作为要解决的问题来编写，则PO将管理一些文档工作。 那是因为采购订单至少在回答“为什么如此重要”的问题上中途了。 如果PO向每个故事和史诗添加了接受标准，并且团队同意各个级别的发布标准，则团队可能接近

如果PO编写了功能需求，则团队不知道为什么这是有价值的需求。 他们无法使用他们的问题解决能力来完善和理解要解决的实际问题 。

我的经验：不了解真正问题的团队需要更多文档。

产品负责人有空吗？

如果该PO对团队不是很可用（是否已分发），则团队需要更多文档。

敏捷方法采用协作方法，包括与PO。 为什么有人认为任何敏捷方法都可以在没有协作的情况下起作用？

谁需要查看路线图？出于什么原因？

我经常看到大型组织将路线图视为何时获得该功能的保证。 这是遗留的想法，组织认为在这个项目结束之前他们不会有重新计划的机会。

不，敏捷项目可以尽可能多地完成发布。 我喜欢一天或更短的故事。 新团队通常需要努力才能达到目标。 但是，为什么要提前几个月提出路线图？ （请参阅我的路线图系列 。）

协作的基本要求

我的同事在一个组织中工作，这些组织正在尽力使用敏捷方法，通常是Scrum。 经理们认为敏捷方法是银弹 。 不是。 敏捷转型是一种文化变革，需要管理者积极参与。 仅仅“允许”敏捷方法是不够的。

我的同事没有问的问题：敏捷方法适合该团队吗？ 也许。 也许不会。 如本文顶部的图片所示，一个互相交劳的团队几乎没有合作。

我们在《 从混乱到成功的分布式敏捷团队》中对此做了很多论述。 并非为基于团队的协作而组织的团队-不用管基于客户的协作-很少会从敏捷方法中受益。 我经常建议采用增量方法。

您的团队需要多少文档才能满足要求（任何内容）？ 这取决于您的上下文。 这些问题可能会有所帮助。

翻译自: https://www.javacodegeeks.com/2019/07/minimum-requirements-documentation-matter-context.html

iis默认文档的优先级最低