敏捷/极限编程中的发布计划

Question

我一直在学习关于如何准确实现敏捷的几本书。我对发布计划感到困惑。

我们的应用程序是一个由不同模块(报价、保单管理、索赔管理等)组成的保险系统。在第一阶段，我们只是计划发布报价，我们估计它大约4个月。

现在，我的问题是，我们是否必须首先确定整个系统(包括所有其他模块)的用户故事，然后才开始第一个版本(即引用)？还是发布计划也是一个迭代过程？

Answer 1

敏捷==迭代

非那样做不行。一切都是迭代的。需求。设计。代码。测试。发展冲刺。释放冲刺。

每一天都是一个迭代的过程，每天站起来，然后工作。

关键是要避免试图预见未来和神奇地计划一切的成本和风险。它不能被计划，所以不要尝试。

我们是否需要在初始阶段探索整个系统的特性？

你不能。所以不要尝试。

你不能预见未来。当你开始发布你的用户学习--你学习--然后你意识到你最初认为的是错误的。

敏捷==学习边学边学。让项目计划反映你的学习情况。

在第一阶段，我们只是计划发布报价。

为什么？这对涉众来说是最高的商业价值吗？这是最重要的部分吗？这是否为用户创造了最直接的，短期的，“现在”的价值？

Answer 2

离地平线越远的地方，规划就越少粒状。

例如：

• 确保为团队在接下来的2周的工作中可能获得的所有故事指定了接受标准(例如，在给定/何时/然后的表单中)。
• 确保你已经为接下来的10周的工作找到了故事。只要一句就行了(例如用.我要..。所以这个表格)。
• 确保你在接下来的6个月及以后的道路计划中列出了高层次的史诗/功能。

Answer 3

不要识别整个系统的用户故事。时间和精力将被浪费，因为客户一看到您的第一个演示就会要求更改。

相反，与客户合作，为第一个版本中的每个迭代定义引用故事的用户价值。在发行版的早期提供用户价值故事，这样客户就可以尝试您的工作。

比如说，你的产品必须同时提供汽车保险和房主保险的报价。您可以为每个用户创建一个用户价值故事，然后首先交付客户认为最重要的一个。在看到你的工作后，他们可能会决定自动报价模块是如此好，他们希望你交付汽车索赔模式下一个，而不是房主。希望你能明白这一点，那就是尽早为客户提供价值，帮助他们做出明智的决定，帮助你有效地改进产品。