介绍
我们实施 Scrum 开发已经有一段时间了。
我也在 2021 年 6 月以新工程师的身份加入了 Scrum 团队，已经一年多一点了。
这一次，我站在一个新人的角度，尝试总结一下团队中哪些是好的，哪些是不好的，以及未来可以改进的地方，不局限于Scrum方法。
前提
启动时的成员
- 两名有 Scrum 经验的资深开发人员（不到半年）
- 3 位开发新手，Scrum 经验不足 ← 我来了
一路走来，成员的数量有增有减，但大多数情况下，我们每天都和这些成员一起旋转。
好东西
通读 Scrum 指南
从 2022 年 5 月左右开始，我们将每月举办一到两次导读会。
这很容易做到
- 选择要阅读的部分，默读约5分钟
- 注意并在便签上写下模棱两可的东西
- 大家核对了便签内容，表示同意
我要去兜兜转转。
最初，该计划始于对 Scrum 更加熟悉的愿望。
指南太抽象了，我有时会产生在学习日语的错觉。
但另一方面，我们加深了对我们所做工作和 Scrum 目标的基本思想的理解。听说随着2020年的改版，指南的内容比以前更抽象了。
如果您一起阅读旧指南，您可能会发现另一个发现。结对编程/移动编程
这是一个在团队内部划分好恶的倡议。
顺便说一句，就我个人而言，我并不擅长。优点
- 可以分享代码和相关知识
- 了解退伍军人的想法
- 通过多人查看减少代码审查时间
过失
- 无法按照自己的节奏工作
- 因人而异，麻烦，不善说话，或无法参与故事
等等
目前，团队在创建新产品或创建使用新技术的基础设计时经常选择小怪。
除此之外，我基本上是单独编写程序，但如果顺利的话，这是一种有很多优点的方法，所以我希望能够以稍微不同的方式使用它。代码审查
现在，当我发送拉取请求时，除了我之外的所有团队成员都会进行自己的代码审查。
当每个人都回顾时，它会导致障碍，例如某人成为瓶颈或无法完成自己的任务。
另一方面，通过和大家一起回顾，
- 代码约定以某种方式适合
- 如何编写另一个人的代码导致学习和发现
这些东西的好处很大，所以我想在改变方法的同时继续。
不好
团队成立时，有很多成员没有开发或 Scrum 经验。
就个人而言，如果可以避免，这种情况是我积极避免的事情之一。
即使在团队刚成立时，
- 缺乏共同的团队经验和价值观
- 而是制作阶段
是。
当没有开发经验和 Scrum 经验的成员进入这里时。 . . ?
老将「有○○，需要xxx，（省略）是这样的。那么，估计吧。」
菜鸟“（我让你仔细解释过，但我无法理解……这是一个估计……？）”老将“每周二我们都会进行回顾、回顾和规划。”
菜鸟“评论？复古南查拉？
老将“（）”菜鸟“这里我不太明白……”
老将“好吧，让我解释一下。（今天的开发完全没有进展......）”它可以像
没有经验的成员有更多的东西要学，所以很难，而有经验的成员有更多的东西要教。如果团队中有 1 到 2 个新人，对开发和 Scrum 有一定程度的了解，我们仍然可以继续进行。
但是，如果人数超过大多数，如果在团队工作一两个月后重新开始 Scrum，似乎会顺利进行。根据开发可能需要的时间估算 SP
这是我和我的团队一起尝试过的一种方法，但效果不是很好。
团队成立后大约 9 个月，我用它来估算时间（如果看起来需要半天，则为 0.5）。
但最终，团队的速度始终没有稳定下来。如果只用时间来衡量它不顺利的原因
- 需要多长时间取决于谁接受 PBI
- SP 基本上是一个相对数字，所以绝对时间很笨重
- 很难表达 PBI 的易用性
我认为有一个打击。
然而，时间是一个容易理解的衡量标准，所以我认为在有很多初学者的情况下接受它是一个很好的挑战。
顺便说一句
我们已经改变了将某个 PBI 设置为 3 并相对估计其他 PBI 的方法，就像这里和那里经常推荐的那样。
这个方法一开始也比较难，但是通过讨论什么时候估计有差异，同意PBI比预期重或者轻，团队的速度逐渐稳定下来。未来看起来不错的事情要努力
细细细细细细
这个团队不擅长的事情清单
- 在没有编辑的情况下进行设计和会议
- 顺便说一下，想象一下发展
结果，改进通常以类似于碗计数的准确性结束。
这以自己的方式很有趣，但是在估算、测量速度和获得共识时，它仍然很不安，并且取决于个人。
这些天，我认为能够练习这样我就可以高精度地进行改进。更多地利用日报
我觉得我看到很多关于每天是否需要的文章。
团队认识到每天对于检查进度和发现可能有问题的人很重要。
但日常工作往往是一件苦差事，尤其是当你忙得不可开交时。您是否更专注于调整您对重要事物的看法，探索如何将这种看法转化为具体的方法，或者专注于发现可能有问题的人？
虽然我觉得可以用的比较多，但也有不知道怎么做的一面。
对日常生活的担忧可能是无止境的。让更多的 PO 参与或找到可以的人？
这是团队中经常出现的讨论。
从最近（大约 2022 年 6 月）开始，PO 被要求参加 Scrum 事件审查会议。但是，从 Scrum 的角度来看，最好能够自然地做到这一点。
最重要的是，在考虑做出更好的产品时，第三方（最好是用户的眼睛）是必不可少的。
我想积极主动地让其他人参与进来。综上所述
作为一个团队工作是非常困难的。
Scrum 非常深入。在做这件事的时候，有时我不知道什么是 Scrum，什么不是，但我想通过反复试验一点点进行。
原创声明：本文系作者授权爱码网发表，未经许可，不得转载;
原文地址：https://www.likecs.com/show-308628159.html