如何使用连续计划

如果您读过《持续计划的理由》 ，您可能会想知道“我们如何做到这一点？” 这里有一些想法。

您有两个前提条件：

• 团队经常完成功能。 我喜欢团队可以在一天左右完成的小故事。
• 团队不断地整合其功能。

具有持续集成功能的常用功能会创建一个环境，让您知道自己的工作量（WIP）最少。 您的程序还具有源源不断的功能，流入代码库。 这意味着您可以更频繁地决定团队接下来可以做什么。

现在，假设您有一些小故事 。 如果您无法想象如何制作一个小故事，下面是我上周使用的一个示例，该示例帮助某人设想了一个小故事：

想象一下，您想要为产品提供一个称为“安全登录”的功能集。 您可能会按以下顺序编写故事：

1. 已经注册的人可以使用其用户名和密码登录。 为此，您只需要一个平面文件和一个不太明亮的解析器，甚至只需在平面文件中进行查找即可。 平面文件中不需要太多案例。 您可能只有两个或三个。 是的，这是一个简短的故事，使您即使编写重构也可以编写自动化测试以验证其是否有效。
2. 尚未注册的人可以创建新的ID和密码。
3. 该人员创建新的ID和密码后，该人员便可以登录。您现在可能会想到数据库架构。 您可能还不需要整个架构。 您可能要等到看到所有负面的故事/功能。 （我还在这里考虑平面文件。）
4. 现在，您可以添加“ parse-all-possible-names”进行登录。 您可以将故事2重构为使用解析器，而不是将名称和电子邮件复制到平面文件中。 您现在已经足够了解数据库的输入内容，因此可以实现解析器。
5. 您想检查不想登录的人。这是三个不同的小故事。 您可能需要花点时间考虑要在什么时候做哪些故事或进行一些调查。
   1. 它们来自特定的IP地址（Web）还是物理位置？
   2. 您是否需要所有用户遵循特定的名称格式？
   3. 您是否要使用验证码（Web）或其他一些机器人防护设备进行登录（尝试3次等）？

也许您在这里还有更多故事。 我对安全登录的了解有限。 那些实施安全登录的人可能会认为我超出了我的极限。

这五个故事是用于安全登录的功能集。 第一次触摸此功能集时，您可能不需要的故事只有1个，2个和3个。 没关系。 您的产品待办事项列表中还有其他故事。

如果您是产品所有者，请查看每个功能相对于其他功能的相对价值。 也许您需要这个团队先做这三个故事，然后再开始一些收益故事。 会计团队可能在积压方面需要帮助，而该功能团队可以提供帮助。 产品核心团队可能需要帮助。 如果您有某种登录名，那么现在已经足够了。 也许对于外部发行而言还不够好。 对于内部版本来说已经足够了。

您更改功能团队经常执行的操作的能力是敏捷和精益产品所有权价值的一部分-这有助于程序更快地完成工作。

您可能有一个四分之一的初始积压，如下所示：

从顶部和左侧开始。

您会在顶部看到内部版本。 您会在内部版本下看到这些功能集。 这部分仍然是愿望清单。

功能集下方是详细信息中的实际故事。 请注意，PO可以如何更改每个团队的工作，以创建工作框架。

详细信息在底部的故事中。

这是我的照片。您可能想要与此有所不同。

这个想法是为每个演示创建最小可行产品，并在项目团队继续创建产品时继续改进步行架构。

因为您具有整个产品的发布标准，所以当团队进行演示时，您可以问：“我们必须做什么才能达到发布标准？” 该问题允许并帮助您重新计划下一次迭代（或看板中的一组故事）。 团队可以看到相互依赖，因为他们的故事很小。 他们可以互相问：“嘿，您可以在开始使用Engine之前先进行文件传输吗？”

团队与产品负责人一起工作。 产品负责人（产品负责人团队）共同制定和重新计划下一个迭代计划，从而重新计划季度计划。 您有持续的计划。

您不需要开会。 要素团队小型世界网络可帮助团队在小型团队中了解他们的需求。 产品负责人小组小型世界网络可以帮助产品负责人在短期和较长期内了解他们对产品的需求。 产品经理可以至少每季度与产品所有者团队见面一次，以修订大图产品路线图。

如果团队故事不多，关注技术卓越并使用持续集成，则可以执行此操作。

在程序中，您希望小巧变大。 小故事会导致更频繁的内部发布（每天都很棒，至少每月一次）。 内部发布的频率更高，使每个人都能看到进度，这有助于人们完成工作。

您不需要召开大型计划会议。 您确实需要了解产品并一直与团队合作的产品所有者。

下一篇文章将涉及您是否希望在项目/程序中具有弹性或预测能力。 以后:)

翻译自: https://www.javacodegeeks.com/2015/08/how-to-use-continuous-planning.html