89 agile scrum development-process
我是一个非常小的初创公司,我们开始使用Scrum/Agile开发周期的形式.
在很多方面我都喜欢Scrum.我们有短暂的冲刺(2周),我喜欢Burn Down Chart来跟踪球队的进步.我也喜欢功能板,所以我总是知道接下来应该做什么.从板上取下一张功能卡,完成它然后将它放入烧毁堆中感觉很好.
但是,我们现在正进入我们的第18个Sprint发布周期,我开始感到有点焦虑.不是我不喜欢工作或我的同事,只是这些短跑是......好吧,冲刺.从开始到结束,我确实感觉自己正在与时间赛跑以保持我们的发展速度.当我们完成sprint时,我们花了一天时间来计划下一个sprint的功能集和估计,然后再关闭.
对于在成熟的敏捷/ Scrum开发过程中工作的人来说,这是正常的吗？或者我们错过了什么？Scrum环境中是否有时间未分配/未跟踪以完成一些小事并清除头脑？
The*_*att 68
这是相对正常的,如果项目持续很长一段时间,有时可能会成为我们团队成员的抱怨.
我们在这里讨论的关键是可持续的步伐.如果您和您的团队能够长期保持您的步伐,那就非常好 - 您已经实现了所有Scrum团队都在努力实现的超高生产率.
或者,如果您发现自己过高估计了一天中可以完成的工作量,那么您可能需要在回顾期间重新评估.团队在为sprint进行容量规划时选择识别的一天中的生产时间量被称为焦点因素.
Henrik Kniberg这样说:
我用于新团队的"默认"焦点因素通常是70%,因为这是我们大多数其他团队随着时间的推移而结束的地方.
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
然而,你所说的听起来只是短跑后冲刺的不间断动力,不一定是你一天的生产力.以下是我们试图解决的一些建议:
小智 24
来自维基百科的职业倦怠:"职业倦怠主要是由于长时间工作,停机时间短,持续的同行,客户和高级监控造成的组织问题"
他们可能在烧坏定义旁边有一个Scrum的图标图像.
如果你认为你可以派人去做其他事情以便进行短暂的转移以解决倦怠问题,那么你显然没有想过.哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇哇!现在我精神焕发,准备好再度这6个月的折磨,直到我终于再次休息.不,你知道发生了什么,哇!我的工作很糟糕.现在我真的可以看到我愚蠢的经理的微观管理,开发过程是另一种方式,让我从更少的生活中得到更多的东西,而生活的时间太短......我应该找到别的事情或者把工作换成压力更小的东西.
恕我直言,短短2周Scrum应禁止,但小剂量,连续不超过4-8.将其用作特殊或关键事物的工具,而不是持续使用.使用常识.
Tro*_*unt 14
经过36周的努力,你已经筋疲力尽了; 那不是Scrum,那就是人性!Scrum不是为了让你更努力地工作,它可以帮助你更加一致地工作并具有更高的可预测性.我经常看到人们将正常项目管理的症状与他们认为是敏捷方法的症状混淆(即"客户不断变化的要求 - 它必须是Scrum的错!").这是一个重要的区别,但因为没有确定原因你不能治疗症状.就个人而言,我正在寻找减少倦怠的方法,例如压力管理技巧.关于如何在紧张的环境中取得成功,有很多信息.
小智 11
Sprint不是100码短跑; 它是马拉松中的一个(随机)英里,也就是你可以无限期维持的速度.
您的团队是否在每个Sprint结束时进行回顾？这是团队"检查和调整"过程的机会吗？作为ScrumMaster,我经常要求团队评估团队作为一个实体"感觉"的方式,以及他们是否有乐趣.我们探索原因或原因,并尝试调整和替代方案.
根据我的经验,团队成员享受(最多限制)Sprint时间盒限制的"压力".关键是接近但不超过该区域.根据需要,校准该区域是回顾中的主要检查点.
至于"... Scrum环境中的时间未分配/未跟踪以完成一些小事并清除头脑",将团队承诺保持在可用容量的x%(最好是点数,但可以使用小时数)如果需要的话;在任何一种情况下,我发现60-70%范围内的某些东西似乎是规范)是Sprint内部可持续性的关键,偶尔的"免费代码日"适用于外部Sprint.
acr*_*man 10
无论你正在使用什么样的开发过程,如果团队被烧坏了,那就错了.它可能就像没有度过他们需要的休假时间的人一样简单,也可能在你如何处理你的scrums的细节中.团队长期有效,因为每个人都可以获得他们所需的休息.
小智 10
我目前正在研究的团队非常好地解决了这个问题.在三次冲刺之后,我们有一个星期的时间,每个开发人员可以按照他想要的方式工作.这些辅助项目应与商业价值挂钩,但没有压力要做到这一点.这是一个允许我们开发人员探索新技术的措施,但它也为我们提供了一周更轻松,有趣的工作.
这肯定有助于我不被烧毁.
一种解决方案是减少在sprint上花费的一天中的小时数.
我知道有些人的工作日只有两个半小时的冲刺,剩下的时间集中在各种其他活动上:支持,减轻技术债务,研究等等.他们的发展速度也是相应的.
这可能看起来有点极端,但如果我没弄错的话,在最近广泛的经济冲击发生之前它是一个有利可图的公司.
小智 6
我完全理解你在说什么.对于那些说"你的速度太快"的人,我不确定我是否同意当人们被这个过程烧掉时,速度始终是问题.即使记录你所有的进步也是一件好事,它本身也可能是一个压力因素(并没有保持跟踪也是如此),不仅仅是因为如果他们发现某些事情不会发生,你的老板/ PM将会对你产生影响按计划,但为你自己.只是拥有这些记录的信息会让大多数人的工作比平时更加困难,而且我不确定在你的时间估算上花更多的时间来解决这个问题.我不认为激励因素(如你的烧毁图表)总是积极的.
有些人不会有这种感觉,有些人会这样.没有一种适合所有人的工作方式.在我看来,永远不会.
另外,如果你说这些敏捷方法和冲刺没有变得更有效/更高效,你为什么要使用它？为什么你认为公司想要使用这些方法呢？这不是因为它们很有趣......
在我看来,效率/生产力总是以某种价格出现.它只是通过使用魔术方法(如果你明白我的意思)不会突然冒出来.
让你变得更有效(工作和压力)以及减少工作的唯一方法是让别人做这项工作或自动化.
在我看来,应该始终检查一个流程,看看哪些可以自动化,并花时间自动化流程.自动化的代价是做额外的工作,而不是做"真正的工作",但无论从长远来看,您将始终获利的自动化任务有多小.总是!如果不是一天,两个.不是一个月,两个.两年内不是一年.你明白了.
但是,我喜欢有时间去处理个人项目的想法.大多数公司永远不会允许这样做.但也许你可以说服你的雇主花时间来自动化你的流程,这项工作可能是"在sprint控制之外",以便让你在谈论"休息"并为新冲刺获得能量的时间.
那些只是我的2美分.当人们说这些方法不是为了让我们更有效,更努力工作时,我有点害怕.他们当然是!当你无法看到自己在做什么时,你会在你的身体告诉你的时候休息.当你所做的"一切"被追踪时,你会推动自己.或者我纠正自己,大多数人都这样工作,有些人会休息.
你是第18次冲刺!？
考虑到每个冲刺2周,这意味着36周不间断地在同一个项目上工作.您还评论说每天工作大约6个小时.听起来很多!
我对敏捷方法学的了解不多(尽管我们在当前的项目中实际使用的是Scrum),但是关于你的工作时间(我的意思是,你花在完成任务上的时间)的原则应该是60% 〜70%.现在,再做一次数字,如果你的劳动节长达8个小时,而你花了6个小时工作,你真的花费了大约75%的劳动时间.这可能是一个小小的偏差,最终让你有这种感觉.
OTOH,我相信如果你的项目需要很长时间才能完成,冲刺应该更大,而不是2周,而不是一个月.考虑倦怠图表上的向下曲线:使用常规任务刻录开始冲刺,并在冲刺结束前的最后2或3天减少您的活动.
敏捷不是雕刻的石头:"工作更快/更强/更好/更难",它更像是一片白云的蓝天:"工作愉快,美丽更富有成效".(最后由愚蠢的朋克+无线电头提供一点点大声笑).