迭代开发︱Sprint如何执行才会更高效？
2022-10-28
来源：adoudou
为了进行简短的更新和同步。与迭代计划不同，我不建议你尝试在推荐时间的一半内完成每日站会。对于大多数团队而言，仅5-7分钟的时间根本不足以提出任何实际问题或理解正在完成的工作。当团队将每日站会的时间缩短得太多时，仪式就会变成一系列机械的更新，比如“昨天我做了这样那样的事，今天我要做这个和那个，没有什么问题阻碍我。”
每日站会没有正式的输入，唯一的输出是增加了开发团队的工作协调性。
03迭代评审会
迭代审核在迭代的最后一天进行。PO、SM、开发团队和任何相关的利益相关者（stakeholder）都应参加。利益相关者可能会根据迭代交付内容的不同而有所不同。
四周的迭代，审核会的时间最多为四个小时。时间会随着迭代时间的长短按比例放大缩小，对于一周的迭代，则缩短到一小时。
作为对迭代评审的输入，团队应演示本迭代所有符合完成定义（definition of done）的待办列表项，这意味着团队不会演示仍在进行中的工作。但是，有时可能需要对这一规则做些例外处理。
完成功能的演示是典型的sprint评审的核心活动。但大多数团队也会花时间来讨论进展和问题。
评审的目的是征求一些在迭代期间构建结果的反馈。PO会考虑所有反馈，并可以适当地更改产品待办列表。因此，迭代评审的输出是一份改进的产品待办列表。
04迭代回顾会
迭代回顾仪式是团队成员考虑如何改善工作方式的时间，这意味着他们可能会改变Scrum的一些方式，例如迭代的长度。但是回顾会还可以涵盖合作的一些方面，比如是否禁止早上的会议，哪些话题适合在Slack上讨论，哪些需要面对面的交流。
整个团队——也就是开发团队、SM和PO——都应该参加迭代回顾，否则就会在团队内部产生分裂。一个好的敏捷团队应该避免任何导致“我们/他们”思维模式的行为。
除了改进的意愿之外，迭代回顾没有正式的输入。输出是团队对其工作方式的改进列表。
四周的迭代，迭代回顾会的时间限制为3小时。回顾可能偶尔需要那么长的时间，但大多数团队大多数时候会在一小时内完成回顾。
05产品待办列表梳理
产品待办列表梳理是指确保产品待办列表顶部的项目已准备好排入下一个迭代。这可以包括向现有需求添加细节、估算、删除条目、调整优先级、拆分产品待办列表项以便更适合排入迭代、以及创建新需求。
虽然产品待办列表梳理本身是必要的，但并不是强制要求团队将其作为一个正式的仪式，或者在每个迭代中都要
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
