本文主要介绍scrum的好处(如何使用scrum)，下面一起看看scrum的好处(如何使用scrum)相关资讯。
摘要:你有没有一种感觉，团队使用scrum后，任务越来越多，加班越来越严重？什么事？好兄弟，这篇文章正好可以帮到你~你有没有一种感觉，团队使用scrum后，工作任务越来越多，加班越来越严重？什么事？好兄弟，这篇文章正好可以帮到你~
使用scrum后，团队越来越累。scrum应该被指责吗？其实这个锅scrum真的不是背出来的。《2020-scrum-guide（简体中文）》是这样描述的:scrum基于经验主义和精益思想。经验主义主张知识来源于实践经验，是根据目前观察到的情况做出判断而获得的。精益思维减少浪费，关注根本。 也就是说，scrum可以帮助团队减少浪费，开发出最具核心价值的产品，但并不意味着工作量会随着scrum而增加或减少。有什么问题？让 让我们分析一下。
问题分析本文列举了三个有代表性的原因。
1.需求没有得到很好的阐明。自规划会议以来，团队一直处于混乱状态:一些业务场景相对复杂，po can 不要仅仅通过计划会议向团队阐明所有重要的业务需求；在规划会议结束时，许多需求细节甚至主要功能都没有被开发人员理解，他们带着满满的疑问进入了编码阶段。结果，可想而知，——的开发人员在迭代中一直与po保持一致，并不断修正完成的代码。测试的人员也忙着测试的职能，忙着回测试——，整个团队忙着飞，但是做出来的产品没有起飞。
2.估计不准确。这里有两方面的估算误差，一是团队速度的估算误差，二是所需工作量的估算误差。
例如，团队的一次迭代很难满足40个故事点的需求。结果团队高估了自己的能力，认为可以轻松满足50个故事点的需求，最终导致团队疲于交付。需求工作负荷估计误差与速率误差相同。
3.团队卷起it行业已经成为常态。在使用scrum之前，每个人都写一份周报，发给领导汇报工作。没有人知道对方做了什么。现在每天都有晨会，晨会的时候听说的，嗯？这位兄弟昨天做了这么多吗？然后我 我会比你做得更多(更好)。当——的内卷化气氛在团队中蔓延时，整个团队都会很疲惫。
解决方案1。增加需求梳理会，提前了解需求。scrum框架中预设的五个活动不包括需求梳理会议，所以许多团队对这个词感到很不舒服需求梳理会议及(以下简称梳理会)。陌生人，那什么是梳理期？
梳理会议是po向团队成员阐明未来迭代需求的活动。在梳理会议之后，团队成员将对需求有更好的理解。虽然梳理会议不是scrum的标准活动，但是在实际生产中，很多scrum团队都会在迭代中插入梳理会议，帮助团队对需求达成共识，保证下一次冲刺的顺利进行。
梳理会什么时候开，开多久？梳理会一般在迭代中后期进行。和scrum标准事件一样，梳理会议的时间应该是固定的，适合时间盒。梳理会议的持续时间通常不超过总迭代时间的5%。例如，对于两周的迭代，团队可以选择第二周的周三下午召开需求梳理会议。
怎么开梳理会？首先声明，需求梳理会不是计划会的提前演练，而是与计划会相比的辅助关系。梳理会议的目的是对产品积压进行整理、提炼和分类。规划会议更多的是关于拆分和声明sprint backlog中的需求。
梳理会议首先需要po说明哪些需求需要迭发，同时po负责向团队阐明这些需求。如果需求太大，po和团队将一起分割需求。在梳理会上进行需求拆分的目的是为了找出下一次迭代结束时要做什么。这个过程不涉及团队分工，所以需求拆分可以在故事层面完成，将故事拆分成任务的操作可以在规划会上完成。
需求分解完成后，团队和po一起确定新产品待定项(pbi)的优先级，并估计在不久的将来要开发的需求的工作量。因此，梳理将为规划会议打下良好的基础，同时，团队将有更多的时间深入了解需求，以避免需求没有得到很好的阐明。
2.合理估计团队速度和工作量。如果团队成员对需求理解到位，但是每次迭代仍然被大量的工作压得喘不过气来，可能是规划会议的工作很多，需要团队对团队速度和每个需求的工作量有很好的估计。
单个需求的工作量可以用小时来衡量，高端的话可以用故事点来衡量。在工作量估算的过程中，最好是全团队参与。——人口更多，实力更强。一方面可以更全面地考虑需求，另一方面可以缩小估算偏差。更多估算知识，请参考《【devcloud · 敏捷智库】估算四篇合集》。
团队速度通常不等于迭代时间的100%，因为团队仍然需要会议、研讨会等。
团队速度是基于故事点的，也就是正常情况下，团队在一次迭代中能交付多少故事点。如果团队没有尝试过用故事点来估算团队速度，用工作时间来估算也是可以的。建议将迭代时间的80%作为工作时间。限制，也就是说团队索赔的总工作量不能超过迭代时间*团队人数的80%。比如团队7人，迭代时间两周(每天工作八小时，每周工作五天)，8*5*2*7*80% = 448h，也就是说这个团队每次迭代所宣称的总工作量应该在448h左右(故事点也是如此)。
如果团队觉得448h时间还短(不考虑团队混日子的情况)或者有很多空闲时间，那么后续迭代可以根据实际情况重新估算团队速度。
3.scrum master遵循敏捷原则，让团队远离内卷团队成员一点点可能会有一定的积极影响；但是如果体量严重，比如996甚至007，整个团队都会很累，对团队的发展是不利的。
scrum本身提倡精益思维。既然团队迭代初期宣称的需求工作量是符合团队速度的，那么团队加班到底是为了什么？是不是过度开采，后期会不会造成浪费？scrum master和整个团队都要反思。
此外，敏捷的十二条原则中有一条是:敏捷过程提倡可持续发展，负责人、开发人员和用户应该能够共同保持其步伐的稳定延续。 如果团队能够按照内卷的节奏持续高效的发展，是可以接受的，但是团队往往很难坚持下去，这就违背了敏捷的原则。作为一个scrum高手，我们应该注意这一点，引导团队做出调整。
整个环境都参与其中。如果scrum mast《颈椎护理指南》《21天弄明白腰间盘》等健康书籍。
总结以上三点，从不同角度讲述使用scrum后团队越来越累的原因和解决方法，希望对你有所帮助。
本文由devsecops专家服务团队制作，前往专家服务获取更多devsecops工程方法、工具平台、最佳实践等干货。
点击关注了解华为云；;s新鲜科技第一次~
标签:
团队需求
了解更多scrum的好处(如何使用scrum)相关内容请关注本站点。