如果您读过 持续计划的原因 ，您可能想知道，“我们怎样才能做到这一点？”这里有一些想法。
你有几个先决条件：
- 团队经常完成功能。我喜欢团队可以在一天左右完成的小故事。
- 团队不断整合他们的功能。
具有持续集成的频繁功能创建了一个环境，在该环境中，您知道自己的进行中工作 (WIP) 数量最少。您的程序还有源源不断的功能流入代码库。这意味着您可以更频繁地决定团队接下来可以做什么。
现在，假设您有 一些小故事 。如果你无法想象如何制作一个小故事，这里是我上周使用的一个例子，它帮助人们想象一个小故事是什么：
想象一下，您想要为您的产品设置一个名为“安全登录”的功能集。您可能有以下顺序的故事：
- 已经注册的人可以使用他们的用户名和密码登录。为此，您只需要有一个平面文件和一个不太明亮的解析器——甚至可能只是在平面文件中进行查找。平面文件中不需要太多案例。你可能只有两三个。是的，这是一个最小的故事，它允许您编写自动化测试来验证它即使在您重构时也能正常工作。
- 尚未注册的人可以创建新的 ID 和密码。
- 在这个人创建一个新的 id 和密码之后，那个人就可以登录了。你现在可能会想到数据库模式。您可能还不需要整个架构。您可能想等到看到所有负面故事/功能。 （我还在考虑平面文件。）
- 现在，您可以为登录添加“parse-all-possible-names”。您可以重构故事 #2 以使用解析器，而不是将姓名和电子邮件复制到平面文件中。您现在已经足够了解数据库的输入是什么，因此您可以实现解析器。
-
您想检查您不想登录的人。这是三个不同的小故事。你可能需要一个尖峰来考虑你想在什么时候做哪些故事，或者做一些调查。
- 它们是来自特定的 IP 地址（网络）还是物理位置？
- 您是否需要所有用户都遵循特定的名称格式？
- 您是否要使用验证码（网络）或其他一些机器人预防设备进行登录（三次尝试等）？
也许你在这里有更多的故事。我对安全登录的了解有限。那些实施安全登录的人可能认为我超出了我的极限。
这五个故事是安全登录的功能集。第一次接触此功能集时，您可能只需要故事 1、2 和 3。没关系。您还有其他故事在产品待办事项列表中等待。
如果您是产品所有者，您会查看每个功能相对于其他功能的相对价值。也许你需要这个团队来做这三个第一个故事，然后开始一些收入故事。也许会计团队需要帮助处理他们的积压工作，而这个功能团队可以提供帮助。也许产品核心团队需要帮助。如果您有某种登录方式，那么现在就足够了。也许对于外部发布来说还不够好。对于内部发布来说已经足够好了。
你改变特性团队经常做的事情的能力是敏捷和精益产品所有权价值的一部分——这有助于更快地完成项目。
您可能有一个最初的四分之一积压，可能如下所示：
从顶部和左侧开始。
您会在顶部看到内部版本。您会在内部版本下方看到功能集。这部分仍然是一个愿望清单。
在功能集下是细节中的实际故事。请注意 PO 如何改变每个团队的工作，以创建一个工作框架。
详情在底部的故事中。
这是我的照片。您可能想要与此不同的东西。
这个想法是为每个演示创建一个最小可行产品，并在项目团队继续创建产品时继续改进行走骨架。
因为你有整个产品的发布标准，你可以作为团队演示询问，“我们必须做什么才能达到我们的发布标准？”该问题允许并帮助您重新计划下一次迭代（或看板中的故事集）。团队可以看到相互依赖性，因为他们的故事很小。他们可以互相询问，“嘿，在你开始使用引擎之前，你能先进行文件传输吗？”
团队与他们的产品负责人一起工作。产品负责人（产品负责人团队）共同制定和重新规划下一次迭代的计划，从而重新规划本季度的计划。你有持续的计划。
你不需要召开大型会议。特性团队小世界网络帮助团队在小范围内看到他们需要什么。产品所有者团队小世界网络帮助产品所有者了解他们在短期和稍长期内对产品的需求。产品经理可以至少每季度与产品负责人团队会面一次，以修改总体产品路线图。
如果团队有小故事，如果他们注重技术卓越并使用持续集成，那么您可以这样做。
在一个程序中，你希望从小到大。小故事导致更频繁的内部发布（每天都很棒，至少每月一次）。更频繁的内部发布会让每个人都看到进步，这有助于人们完成他们的工作。
您不需要召开大型计划会议。您确实需要了解产品并始终与团队合作的产品所有者。
下一篇文章将讨论您是否需要在项目/项目中进行弹性或预测。之后 ：）