当使用看板时，团队何时讨论需求？

Question

我一直在读一些关于看板的文章，我对需求这个话题有点困惑。

在我当前的项目中，我们使用Scrum。在Sprint的开头，我们有一个会话，BA在其中做一个故事演练，并尽可能地描述它。然后我们拿着这个故事，回顾它，讨论它，并为下一个Sprint计划会议为BA准备一个问题。在下一节课上，BA回答了所有的问题，课程结束时我们已经理解了这些要求(大部分时间)。

下一步是，我们生成一个技术设计，并开发解决方案/故事。

关于看板，我所读到的一切都表明在看板上没有短跑计划。我的问题是，在什么时候(在看板)，技术人员和商界人士坐到一起讨论故事的要求？产品经理或BA不提供看板故事的演练吗？

有了Scrum，整个Sprint都可以使用BA来支持开发，我认为看板也是如此。对我来说还不清楚，如果没有冲刺计划的话，技术人员是如何理解这个故事的。

Answer 1

你说得对，看板不像Scrum那样有Sprint或的概念。那是因为它是一个精益方法。及时做了更多的事情。

该由你来决定如何安排计划活动，但我建议尽量在工作开始的时候做。当团队中嵌入了所有主要涉众的代表时，这是最有效的(同样也使Scrum更有效)。

我认为这个基于有纪律的敏捷交付的图表给出了一个精益软件过程的很好的图形表示：

每日站立和Sprint计划的事件在整个协调会议和补给建模会议期间被捕获。协调会议更像是Scrum的每日会议，补给建模会议更像是积压、细化和Sprint计划。但是，如果对您的团队有效的话，可以将一些需求讨论引入协调会议。

就像精益过程中的大多数事情一样，这种情况是及时发生的。没有时间框，事件不会发生在特定的节奏上，就像在Scrum中那样。当它为团队和涉众增加价值时，您就可以完成这项工作。

您可以将它与基于Scrum的流程的图形表示进行比较，Scrum是在有纪律的敏捷交付环境中建模的：

与其将自己限制在2-4周的短跑中，在开始时进行计划，每天站起来，最后进行回顾和回顾，更精练的方法会在利益相关者认为合适的时候制定你的演示、协调和回顾会议。

看板将为管理积压的工作和在制品(WIP)提供指导.您可以使用其他技术和方法来精确地实现其他活动，因为看板通常对这些活动保持沉默。

Answer 2

你有点误解了Sprint会议在Scrum中所做的事情，我认为这是造成你困惑的原因。一个斯普林特计划会议通常是错误的地方，以了解故事的细节。除了一些最后的调整和快速的运行，以确保没有悬而未决的关切，会对估计有重大影响，这些被考虑的故事应该基本上已经准备好了。从那里开始，斯普林特计划()就像它所说的那样:计划未来的冲刺项目。如果你没有短跑，那就不需要斯普林特计划了。

那么，故事的细节什么时候才能得到充实呢？通常是通过积压清理或在早期冲刺期间进行的通信。这里的目标是要有足够的清晰度，这样就可以给出一个相当有信心的估计。这并不要求提前制定每一个细节。不管你做了多少努力，在实现过程中总会出现一些问题。Scrum的目标是使在实现过程中出现的问题相对较小(本质上，小到不影响估计值)。

在看板，估计是可选的。如果你做了评估，那么你可能会做一些类似于Scrum的事情，在故事开始之前，它会被讨论来计算一个估计值。如果你不做估计，那么实际的行为是相似的，除了你可能不会讨论一个故事，直到它开始。

根据我的经验，我通常在团队中使用类似Scrum的方法来进行主要的开发，然后在维护阶段使用更多的看板方法。维护阶段的工作往往更分散，故事从一开始就定义得更清楚，规模更小。在主要的开发阶段，故事通常从高层次开始，需要细化和分解，才能达到可以接受的冲刺阶段。在看板上下文中开始这样的故事没有什么意义，而且绝对会使您的度量标准落空。

在Scrum或看板中都没有官方的“业务分析师”角色。这是分析和估计故事的团队。如果Sprint是开发团队第一次听到故事的细节，那么事情就出了问题。我并不是说您不能利用BA，也不是说每个开发人员都需要参加每个需求收集会议，但是在Sprint计划之前的需求收集过程中，应该会出现一些开发人员的表示。BA通常对实现的细节知之甚少，无法了解事物的成本或哪些问题可能对成本产生重大影响。这意味着，可能有一些细节会对评估产生重大影响，直到开发团队看到这些估计数才会被识别出来。此外，开发人员可能能够为成本效益更高的方法提供指导，或者建议一些相对容易实现但可能为用户带来很大价值的特性。我怀疑在您的情况下，开发人员正在协助BA，因为BA正在收集需求(例如回答BA的问题或提供一些数量级的估计)，这大致是在取代积压清理。或者，您正在做的工作(例如维护工作)自然到达相对较小的数据包，在这种情况下，看板很可能是一个更合适的过程。

Answer 3

专门针对你的问题..。

技术人员和商界人士坐到一起讨论故事的要求是什么意思？产品经理或BA不提供看板故事的演练吗？

由David开创的看板方法并不包含关于何时发生这种活动的具体实践或建议。任何看板从业者都会提供的答案是，最初当您采用看板方法时，您应该以与您在决定如何管理工作之前执行它的方式相同的方式来执行此活动。如果你每两周做一次，你应该继续每两周做一次。

你的团队会发现改变时间表是否有机会和价值。记住，1个月的时间表比1年更敏捷，2个星期的时间表比1个月更敏捷，1个星期比2个星期更敏捷。这种想法最终使我们及时成为最敏捷的人。在你开始之前，最敏捷的状态不应该是目标条件。

对于Scrum，BA通常在整个Sprint中都是平等的，以支持开发，我认为看板也是如此。对我来说还不清楚，如果没有冲刺计划的话，技术人员是如何理解这个故事的。

看板方法作为一种思维方式和一组实践并不对Sprint、Sprint计划会议或任何其他实践的存在施加任何条件或限制。它完全尊重Scrum团队和他们的实践。如果你今天有一个技术人员讨论这个故事的会议，你将继续举行会议，使用相同的时间表。

如果不了解你的团队和周围的组织，我就不能良心地告诉你日程安排会是什么样子。如果您今天不执行这些活动，还有许多其他的信息来源可以教您如何进行这些活动。看板方法可以提供指导，教你如何发现你的选择是好的。

请阅读这两个系列的博客文章。一个来自我自己，一个来自Scrum.org的团队成员Steve。

WesternDevs.com看板中没有任何东西能阻止Scrum

Scrum和看板-更强大的合作-史蒂夫波特-和看板-更强大的合作-史蒂夫波特