迭代计划

Question

我们正在尝试一些计划迭代的新方法。早些时候，leaddev决定了哪些功能在迭代中由哪个（哪一对）来完成。他初步猜测该功能需要实施多久。现在我们在迭代计划中对每个功能进行了一次团队讨论，团队决定我们需要多长时间来实现任务。然后我们决定谁来实施它。这需要很长时间。

你如何做你的迭代计划（规划游戏）？

Answer 1

首先，如果你想更好地控制你花时间做事的时间，请使用时间拳击。在Scrum中，每件事都是时间框式的，我认为这是件好事。根据我的经验，4个小时对于2周迭代的迭代计划会议来说是一个不错的持续时间。然后，计划会议通常分为两部分，时间为2小时。第一个用于从待执行的待办事项中选择项目。第二个用于将选定的功能分解为任务并创建Spring待办事项。

对于规划会议的第一部分：

• 用相对单位估计的故事（故事点，T恤大小等）。使用Planning Poker来估算故事，这是一个非常有效的技巧。
• 挑选速度达到你的速度（你上次在故事点上做了多少工作）。选择具有最高价值/努力比率的故事。

对于计划会议的第二部分：

• 分解故事写成任务。以几个小时估计这些任务（任务不应超过16小时）。有了这个详细程度，整个团队就可以准确理解要做什么，任何人都可以从列表中选择一项任务。
• 不要事先决定谁将实施什么，让团队自动组织。冲刺积压任务永远不会分配;相反，任务由团队成员根据需要根据设定的优先级和团队成员技能进行注册。

Answer 2

我们将每个大故事分解成任务，以便每个人都可以更容易地估计，因为大故事往往有许多更小的步骤，作为一个团队，更有信心能够估计这些步骤。一个重大故事可能是建立一个网站的一部分，例如，关于公司或展示公司销售的产品，或者获得一些新组件并运行，例如，搜索功能或产品注册。相比之下，任务通常是可以在2天或更短时间内完成的事情，这样我们就不会有大的黑洞，并且在冲刺期间牌可以在列之间移动。

一旦冲刺的任务列表已经确定，Excel电子表格的电子邮件发送给每个人在团队中增加他们的估计，并发送回的Scrum Master。 Scrum Master取得所有估算的平均值，以便衡量任务所需的时间。如果存在一些很大的差异，那么可以与每个极端的人讨论为什么他们认为事情会花费那么长时间。

Answer 3

传统上，我们采取下一个优先级最高的故事卡片从我们的积压/发行计划（高层次的“故事点”估计“），把它们分解成任务，都有人估计他们，并记下这些内容在一张纸上无论接下来哪一对都可以选择他们想要的任务，这通常不会花太长时间（一周迭代）。

最近，我一直在将我的团队转向一个看板系统，其中重点是流而不是迭代。高水平的估计对于发布计划仍然很重要，但否则我们只是确保故事的优先顺序是正确的。人们将故事从状态拉到状态，任何障碍都会在早上或全天提醒（如果这是阻碍工作的事情）。

如果您正在开发一个项目，该项目适合部分持续部署（例如包含网站或自动更新最终用户软件，而不是安装过程繁琐的事情），您可以考虑不要做了太多的估计。对于一些投资回报率的事情（即花在这上面的工作是否会超过收益？），可能仍然是必要的，但是通过消除估计并在准备好时释放事物，您可以进入更多的流程。这实际上远离了迭代，但这意味着需要花费更多时间在连续过程中完成工作，而不是规划，细分任务等。看板系统对此很有用。这是我们目前用于维护/ FastTrack版本的技术 - 当我们完成了足够的错误修复/增强功能后，我们就会发布。小版本的价值远高于大版本。

Answer 4

尽量保持迭代的长度不变，以便知道实施所需的时间。修复您的资源并计算其可用时间，并确保您有足够的资源来覆盖整个持续时间。根据可用资源，他们的专业知识和任务的优先级将资源分配给任务。继续添加任务，直到有足够的资源用于迭代