敏捷方法论中站起来的目的是什么?[关闭]


13

我曾经在瀑布方法中工作,现在我在一个遵循敏捷方法的团队中工作。看来他们做错了。例如,我们每天进行25分钟以上的站立训练,这确实很烦人。此外,我觉得自己比起其他任何事情都可以向管理层证明自己的薪水。

我有这种感觉吗?这通常是站立式的吗?


3
您是否在回顾展期间建议站立式会议太耗时?25分钟的会议期间讨论了什么?
dcaswell

团队中有多少人?
盖·西顿

1
@GuySirton:我理解你在说什么,但是另一方面,每天大约30分钟还没过去吗?
user10326 2013年

1
唐氏票没有解释....
user10326

2
@ user10326:您的管理层显然认为并不过分。假设他们制定了规则(各公司之间有所不同),并且您不能说服他们太长,那么那将是30分钟。您几乎肯定不会通过参考程序员或Scrum手册来说服他们。如何处理团队/工作情况可能是Workplace SE的问题。在这里,我们可以告诉您它应该如何工作,但不确定我们是否可以帮助您解决您的具体情况。
Guy Sirton

Answers:


13

对于Scrum,Ken Schwaber和Jeff Sutherland 解释说

每日Scrum

Daily Scrum是一个15分钟的有时间限制的活动,开发团队可以同步活动并为接下来的24小时制定计划。这是通过检查自上次“每日Scrum”以来的工作并预测下一个工作之前可以完成的工作来完成的。Daily Scrum每天在同一时间和地点举行,以减少复杂性。在会议期间,开发团队成员说明:

  • 昨天我做了什么工作来帮助开发团队实现Sprint目标?

  • 我今天将如何帮助开发团队实现Sprint目标?

  • 我是否看到任何阻碍我或开发团队实现Sprint目标的障碍?

开发团队使用Daily Scrum来检查实现Sprint目标的进度,并检查进度如何趋向于完成Sprint Backlog中的工作。每日Scrum可以优化开发团队达到Sprint目标的可能性。每天,开发团队应该了解它打算如何组成一个自组织团队,以实现Sprint目标并在Sprint结束时创建预期的增量。开发团队或团队成员通常在“每日Scrum”之后立即开会,进行详细讨论,或者调整或重新计划Sprint的其余工作。

Scrum主管确保开发团队开会,但是开发团队负责进行每日Scrum。Scrum Master指导开发团队将每日Scrum保持在15分钟的时间内。

Scrum Master强制执行以下规则:只有开发团队成员才能参与Daily Scrum。

每日Scrum可以改善沟通,消除其他会议,查明需要移除的发展障碍,突出并促进快速决策,并提高开发团队的知识水平。这是一次关键的检查和适应会议。

其他方法可能具有不同的仪式,甚至不同的Scrum团队也可能会以不同的方式优化其工作方式。关键思想是快速聚会,以确保团队按计划进行交付。它不应该是管理状态报告。然而,敏捷思想是更容易被颠覆的思想之一。


如果有帮助的话,还有一个基于网络的站立会议,我们可以用来进行日常站立:standup.report
MagExt

8

TL; DR

如果在适当规模的Scrum团队中正确执行任务,则每天的站起来时​​间不会超过15分钟左右。如果花费的时间更长,则可能是团队规模太大或您存在流程问题。

站立的目的

日常站立会议是整个团队的一次承诺和协调会议。它旨在确保整个团队都意识到障碍,完成或未完成哪些故事,以及准备将哪些任务从一个团队成员的待办事项清单中拉到另一个人的任务中。

Scrum负责人和产品负责人必须积极参与此次站台活动,但是如果团队向他们中的任何一个汇报工作,那么您的Scrum流程可能会被彻底打破。有关Project Management Stack Exchange的相关答案,在底部有10点“项目气味”列表,其中一些可能适用于您的情况。即使它们不适用,您也绝对应该在下一次Sprint回顾展上重新评估站立式健身的有效性。

尊重时间盒

尽管我不喜欢“三个问题”作为一种具体形式,因为它们往往会导致召开类似于地位拉动的会议,但如果我不指出迈克·科恩对《每日Scrum》的规范描述,我会被忽略。该页面部分显示:

通过专注于每个人昨天完成和今天将完成的工作,团队可以很好地了解已完成的工作和尚待完成的工作。Scrum日常会议不是状态更新会议,老板在该会议中收集有关谁落后于计划的信息。而是在此会议上团队成员相互作出承诺。

该页面上有更多详细信息和一些具体示例。但是,就您的问题而言,明确指出:

Scrum每日站立会议的时间严格限制为15分钟。这使讨论变得轻松但相关。

时间框是Scrum的基础。虽然团队可以根据检查和适应周期来调整Scrum中的大多数时间范围,但延长站立时间的做法被认为是不明智的做法。如果在您的流程中没有遵循时间装箱原则,那通常是一种非常虚幻的“项目气味”。


3

您所描述的是团队“失败”的一种方式。

最好的站起来很短,因为每个人都了解其他人在做什么,他们解释他们昨天取得的成就,他们今天将取得的成就,并标出任何可能/可能影响他们兑现诺言的能力的东西。然后,团队的其他成员可以表示他们可以帮助彼此快速解决彼此的障碍,但是解决方案不属于其他组织。

简而言之,它们应该是将团队联系在一起的粘合剂。

听起来更像是状态更新,并且您要负责交付/不交付,但团队功能失调,因为团队没有使用站立会议来互相支持以交付和消除障碍。

在我所看到的两种环境中,这是由一名Scrum主管导致的,该主管未能将确保团队兑现其迭代承诺的责任下放。在一种情况下,这特别适得其反,并在团队内部产生了我们/他们的态度。

Scrum是关于自我组织的团队,团队在其中自我组织以快速解决问题以兑现其承诺


2

与所有敏捷流程一样,其目的是:“从中获得价值”。

日常站立通常是一种以低影响的方式确保团队成员之间沟通的机制,每个人都可以了解团队在当前任务方面的位置。因此,每个人都说“我昨天做了x,今天我要做”的5分钟站立是很好的,而15分钟的站立是团队决定下一步工作并更新任务板的15分钟。

但是,根本不需要一个,如果您以其他方式传达这些信息,例如使用滚动式社交通知系统,则根本不需要。

同样,如果您希望自己的站立时间更长,并且团队报告更多,那么也可以。我对此表示怀疑,但我知道有些团队更喜欢采用更具指导性的方法来开展工作。毕竟,敏捷可以应付所有类型的团队。

您应该问的真正问题是,您是否从中获得任何价值,如果没有,那么您将如何改变它以使自己获得价值。按照一些Scrum圣经中的规定进行站立站立并不敏捷。做一个站起来对您的团队来说意味着什么,以便你们所有人一起更好地工作是。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.