我以前在瀑布式方法中工作,现在我在一个遵循敏捷方法的团队中工作。看来他们做错了。例如,我们每天都有最后一个25+分钟的站立,这真的很烦人。此外,我觉得我更像是在向管理层证明我的薪水,而不是其他任何东西。
我这样想错了吗?这就是通常的站立方式吗?
发布于 2013-09-08 17:23:36
对于Scrum,Ken和Jeff 解释:
Daily每天Scrum是一个15分钟的时间盒事件,用于开发团队同步活动并为接下来的24小时创建一个计划。这是通过检查自上一次Daily以来的工作,并预测下一个Scrum之前可以完成的工作来完成的。Daily每天在同一时间和地点举行,以降低复杂性。在会议期间,发展小组成员解释:
开发团队使用Daily检查实现Sprint目标的进度,并检查进度如何趋向于完成Sprint中的工作。Daily优化了开发团队实现Sprint目标的可能性。每天,开发团队都应该理解它打算如何作为一个自组织的团队一起工作,以实现Sprint的目标,并在Sprint结束时创建预期的增量。开发团队或团队成员通常在“每日Scrum”之后立即会面,进行详细讨论,或调整或重新计划Sprint的其余工作。Scrum确保开发团队召开会议,但开发团队负责执行Daily。Scrum大师教开发团队将每日Scrum保持在15分钟的时间范围内。Scrum强制执行只有开发团队成员参与日常Scrum的规则。每天的Scrum改善沟通,消除其他会议,找出排除开发的障碍,突出和促进快速决策,并提高开发团队的知识水平。这是一次关键的检查和调整会议。
其他方法可能有不同的仪式,甚至不同的Scrum团队也可能以不同的方式优化这些方法。关键的想法是快速地聚在一起,确保团队能够顺利完成任务。这不应该是一份管理状况报告。然而,它是更容易被颠覆的敏捷思想之一。
发布于 2013-09-08 17:39:55
博士
当在适当规模的Scrum团队内正确执行时,每天的站立时间不应超过15分钟左右。如果需要更长的时间,要么团队太大,要么您有流程问题。
的目的
每天的起立是整个团队的承诺和协调会议.它的设计是为了确保整个团队意识到障碍,哪些故事已经完成或没有完成,哪些任务已经准备好从一个团队成员的待办事项清单中移到其他人的清单上。
重要的是,Scrum和Product是站起来的积极参与者,但是如果团队正在向他们中的任何一个报告,那么Scrum过程可能会很好并且真正地被破坏。关于的相关答案在底部有一个“项目气味”的十点列表,其中一些可能适用于您的情况。即使它们不适用,你也应该在下一次斯普林特回顾展上重新评估你的站立效果。
虽然我不喜欢把“三个问题”作为一个具体的格式,因为它们往往会导致类似于地位拉的会议,但如果我不指出迈克·科恩( Mike )对每日Scrum的规范描述,那我就会失职了。这一页的部分内容是:
通过关注每个人昨天完成和今天将要完成的事情,团队对已经完成的工作和剩余的工作有了很好的理解。每天的Scrum会议不是一个状态更新会议,在这个会议中,老板正在收集关于谁落后于计划的信息。相反,这是一次团队成员相互承诺的会议。
这一页上有更多的细节和一些具体的例子。但是,就你的问题而言,它明确指出:
Scrum每天的站立会议严格限制在15分钟内。这使讨论很活跃,但却是相关的。
时间盒是Scrum的基础。虽然Scrum中的大多数时间框都可以由团队根据检查和适应周期进行调整,但是延长站立时间被认为是糟糕的做法。如果时间限制原则在你的过程中没有得到遵守,那通常是一种非常棘手的“项目气味”。
发布于 2013-09-09 10:41:17
和所有敏捷过程一样,这个过程的目的是:“你从中得到的价值”。
每天的站立通常是一种确保团队成员之间以低影响的方式进行沟通的机制,每个人都可以理解团队在当前任务集上的位置。所以,5分钟的站立,每个人都说“我昨天做了x,我今天要做y”,就像15分钟一样,团队决定下一步要做什么,并更新任务板。
然而,如果你用其他方式交流这些事情,比如使用滚动的社交通知系统,就根本不需要这样做了。
类似地,如果您希望您的站立时间更长,更多的团队报告,那么这也没关系。我对此表示怀疑,但我知道有些球队更倾向于以更直接的方式来完成工作。毕竟,敏捷可以应付所有类型的团队。
你应该问的真正问题是,你是否从它得到任何价值,如果没有,你会把它改变成什么,这样你才能得到价值。按照某些Scrum圣书的规定进行站立并不是敏捷的。站起来对你的团队来说是件很重要的事情,这样你们才能更好地合作。
https://softwareengineering.stackexchange.com/questions/210850
复制相似问题