冲刺应该有多放松(或没有放松)?


12

完成分配给冲刺的故事的态度应该是什么?显然,您想优先考虑在sprint中完成它们,但是对我而言,敏捷的全部要点是动态的:您不想故意拖延或使其“错过”在sprint中完成用户故事的机会,但是在当出现意外情况,而那些故事没有完成并被推送到下一个冲刺的同时,您也不希望感觉自己做错了什么。那不应该是令人恐惧或消极的经历,对吗?

缺少冲刺承诺是否可以接受负面/恐怖经历?当出现必须处理的意外任务(例如生产支持)时,开发人员是否应该对错过的冲刺承诺负责?


2
因此,这取决于团队和公司的文化,因此没有一个正确的答案...投票决定不具有建设性。
奥德(Oded)

2
@Oded听起来很像个答案。您基本上是说,公司可以通过冲刺做出负面和潜在的滥用体验?让我们在这里谈论理想。我不是要您概括任何内容。
void.pointer 2012年

1
在没有时间和资源的理想世界中,应该没有压力。那对你没有帮助。
CodeART 2012年

2
@RobertDailey根本不是一个解决方案-这不是一个可以回答的问题。当然,做一个积极的经历比消极的经历要好得多,而且实际的虐待永远是不可能的。但是,即使在单个工作场所,单个项目中,气氛也会变化。有时压力很大,有时压力不大。无论是否敏捷,任何工作场所都是如此。如果您一直对工作场所感到不满,对其进行处理(修复或离开),但不要期望下一家公司会在100%的时间内提供低压力和高满意度。
卡勒布(Caleb)2012年

1
@Robert-我的最后几条评论本质上是通用的,并不反映当前的问题。我试图向bjarkef解释,基于帖子的有趣程度(或不有趣),不会投票给近距离投票。我对自己的最后一句话也是试图解释一些问题在任何SE网站上都找不到主页。同样,这些只是一般性说明,与问题不直接相关。
奥德

Answers:


7

绝对应该以在sprint中完成项目为目标。

SCRUM的主要好处之一是,它使项目获得了“心跳”。

确定优先顺序,从清单中挑选项目,交付它们,进行演示,反映它们的运行方式,然后以可预测的周期再次进行。

所有的计划,估计和优先级均基于此概念。我们可以并且将在冲刺中提交X个点,并且可以随着时间的推移确定一个速度,以此来更好地进行规划。

如果您对冲刺的内容和承诺太过随意,那么SCRUM在我看来就是崩溃了,您会因此受益匪浅。

当然,现实世界有时对此有话要说,但这应该是例外,而不是规则。


One of the main benefits of SCRUM is that it gives the project a 'heartbeat'.任何敏捷方法都可以这样说。
maple_shaft

5

关键是必须围绕未完成故事进行问责

这意味着应该有一个完整的理由来说明故事还没有完成,并且这个理由已在以后的项目计划中加以说明,因此不再赘述。

这个原因不只是模糊的“东西出现”。

例如,如果由于团队成员必须解决生产问题而导致故事不完整,则需要在以后的迭代中解决这种可能性-通过计划与该团队成员在一起的时间更少或安排其他工作来解决。

如果可以通过更勤奋或预先努力来避免原因,那么是的,这种责任感可能会有些痛苦。希望痛苦在于“这是我们下次需要做的更好的”变化,而不是“您没有做好工作”的变化。


4

那不应该是令人恐惧或消极的经历,对吗?

如果它发生一次或两次,否则,就不应该是负面的经历。如果定期发生,那么您有问题。团队然后总是超负荷工作。更好地估算,并三思而后行为冲刺所做的事情,但不要着急。

冲刺放松意味着您的承诺不足。

轻松的冲刺意味着您有过多的承诺。

我只是提供我所承诺的内容,并尝试变得更好。只有在特殊情况下,我才能将故事移至下一个冲刺。我宁愿每天都承受一点压力,而不是在某些截止日期前不久承受压力。


负面经验涵盖了许多不同的情况。一位朋友的冲刺经历相当消极,这主要是因为团队尚未“还”了解冲刺的概念。为了缩短发布周期,他们基本上加快了死亡步伐,并将其称为冲刺。
Edwin Buck

4

根据我的经验- 与敏捷中的其他任何事情一样,我们适应了包括估计在内的连续反馈系统。

可以错过第一次冲刺的截止日期(项目开始),但是您可以从中学到错误的地方(低估,不了解团队实力等)。然后,您可以获取反馈并将其反馈给下一个冲刺,从而获得更好的估计。

根据我的经验,在我的新敏捷项目上已经11个月了,如果我们真的错过了最后期限,我们现在几乎不会错过最后期限。但是我们确实错过了第一次冲刺的截止日期,因为我们不知道团队成员的步调和力量。

一些人认为,“分配”更多的时间用于第一次冲刺,以克服第一次冲刺的问题。


因此,如果您很少错过最后期限,那么在冲刺结束时,您自然会无所事事。那您该怎么办,拿些新东西还是请假?:)
Bjarke Freund-Hansen'5

@bjarkef冲刺结束后,我们开始下一个冲刺并开始运行。我总是觉得与“传统”开发相比,使用“ scrum”时的停机时间要少得多。
java_mouse 2012年

因此,您没有固定的sprint长度,您是在旧版本完成后开始新版本的吗?
Bjarke Freund-Hansen'5

1
@bjarkef-我们有2周的固定长度。一旦交付了几周,我们将立即在明年春天开始。
java_mouse 2012年

2

在这里看到答案/评论很有趣。在我从事的每个敏捷(类型)项目中,主要优势是将截止日期压力分散到许多小型截止日期上,而不是在项目结束时进行截止日期死亡。海事组织,冲刺应该认真对待。截止日期或交付的功能上的任何延误都应视为项目管理或开发中的潜在问题。


这样您一直在压力下工作?听起来像一个可爱的工作环境。
Bjarke Freund-Hansen'5

1
足够的压力使团队可以轻松完成任务,但有时无法完成项目就需要压倒一切。但是,不是所有人都可以。
tzerb 2012年

2

敏捷过程促进可持续发展。赞助商,开发商和用户应能够无限期地保持恒定的步伐。- 敏捷宣言背后的原则

如果这是一次令人恐惧或消极的经历,并且一直在发生,那么您就遇到了问题。软件开发应该很有趣。不消极或令人恐惧。

但是,如果团队致力于以冲刺的方式完成一些故事,并且持续不断地交付,那么您也会遇到问题。几乎肯定不会通过增加团队完成故事的压力来解决此问题。如果问题是由于外部因素引起的,则需要对其进行管理。如果团队过度投入,ScrumMaster可以指导团队致力于减少故事情节。可能有很多原因,每个原因可能需要以不同的方式解决。一个充满活力和积极性的团队应该有足够的动力去前进。

理想情况下,无论问题是什么,都应在追溯期间提出并解决。

对于团队来说,弄清楚他们在短时间内的短短时间内可以完成什么然后再完成的过程并不那么复杂(偶尔出现的故事可以推到下一个短程是可以的,速度可以波动,事情会发生变化等) )。如果经过几次冲刺后仍无法顺利进行,那说明您做错了。


1

这确实取决于您的时间表。

有时您需要完成所有故事,或者无论如何要完成大多数故事。尽管Agile确实提供了一定的灵活性,但您可能还需要在很紧的时间表上完成项目。.因此,完成大多数故事可以使您及时完成项目。

话虽这么说,但事情将会浮出水面,这将阻止您完成每个故事,每个冲刺。

如果产品在时间轴上,而错过了关键故事,则该考德尔会使产品迟到。在某些情况下,产品迟到会损害公司的竞争地位。因此,在这种情况下,您可能希望缺少故事而成为负面经历-可能会让您下次完成所有任务。


1

如果剂量正确,压力会很好。您不希望消除所有压力,而只想及时分散压力。即使您玩自己喜欢的游戏,也会有一些压力和消极情绪。实际上,您可以从中获得更多能量。

团队应该对遗失的故事真正感到难过。它将给他们下一次改变某些事情的能量(以不同的方式工作或计划更少的故事,两者都是好的)。当然,他们在讲故事时也应该感到自豪。

您还提到了意外的任务(生产支持)。那给我举起了红旗。对于与故事无关的所有问题,应该有一个约定的时间表。否则,比赛将不公平,团队会感到无助,负面情绪也不会得到改善。


1

您应该查看导致您的承诺失败的因素,并尝试修正它们。大量的随机事件将使您的冲刺不断混乱,使您的速度无法预测。修复造成这种情况的原因,或者在sprint中引入松弛。我更喜欢修理。

无论哪种方式,如果团队的工作受到外部因素的干扰,都无法对团队负责。使用回顾研究。

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.