你喜欢和不喜欢scrum过程的什么？

Question

我所在的团队使用scrum进行开发。我们目前正在尝试修改我们流程的某些方面，以解决我们最近注意到的一些问题。在这样做的过程中，我们正在探索scrum过程中我们喜欢的是什么，以及我们不喜欢的是什么，以便帮助我们确定我们作为一个团队在工作中的价值观。我们认为，如果我们能够确定我们重视的是什么，那么我们就可以提出围绕这些价值的实现，以帮助新的解决方案留在团队中。

话虽如此，我还是对其他人如何看待scrum过程很感兴趣。你真正喜欢它的地方是什么？是什么让人沮丧，让人觉得开销太大，或者没有效率？成功和失败的具体例子很好，但我感兴趣的是一个更大的视角，其中讨论围绕scrum的陷阱或scrum真正闪耀的地方。

有什么想法？

Answer 1

我不喜欢管理者将scrum过程实现为快速发布周期，而所有其他方面都与瀑布相同或更差。

Answer 2

这是一个相当宽泛的问题！这是我的观点。

我认为Scrum真正擅长的是教组织热爱敏捷/迭代/增量/精益软件开发。对于一家习惯于项目管理的指挥和控制层次的公司来说，团队成功地真正适应客户需求所需的授权是一种巨大的文化转变。Scrum通过明确定义的角色和流程，使组织可以接近所有这些内容。

基本上，对我来说，它为程序员团队赢得了他们在大公司的所有政治和官僚机构中进行XP所需的空间。

然而，伴随着这种授权而来的是责任。Scrum没有强制要求任何XP工程实践，但是如果没有像CI、TDD和重构这样的核心实践，任何scrum团队都会在几次迭代后停滞不前。我个人认为，在scrum的“规则”中不明确这一点是相当不负责任的，这将是我的批评之一。

我的另一个批评是任务卡片和任务计划。我还没有看到一个真正有效的团队:通常会有非常疲惫的一天，你试图考虑你在整个迭代中要做的一切，然后你开始行动，发现你实际上需要做一些不同的事情。通过任务耗尽来衡量进度看起来像是让团队合作和建立联系的好方法(特别是如果你否认任务所有权)，但最终它不是跟踪团队进度的可靠方法。

我把更多的重点放在burn-up的价值或故事点上，这些天通常让团队每天更新一个大的Cumulative Flow Diagram图表，而不是我们所处的位置。这些任务保留在人们的待办事项列表上，但它们不会出现在黑板上，也不会被任何人管理。

当然，关键的实践是回顾。Mike Cohn对我之前关于XP实践的观点的反驳是，通过回顾，团队无论如何都会发明/采用XP，这确实有一定的有效性。当然，定期自省是确保您的团队尽可能有效的最好方法。

Answer 3

我认为根据我的经验，关键是理解那些来自业务和管理层的人如何选择实现Scrum和/或敏捷的一部分，或者换句话说，他们对流行语的解释。

我喜欢每日脱口秀的想法，每个人都说他们昨天做了什么，他们今天计划做什么，他们有什么障碍，因为这创造了责任，假设没有更好的词语来表达尊重和荣誉。

任务卡及其演变可以帮助其他人了解正在发生的事情，也可以让一些人了解他们是否已经确定了什么。卡确实在某种程度上形成了自己的通信渠道，这可能是好的，也可能是坏的，这取决于你如何看待它。

回顾和迭代计划会议通常是一种有用的方式，可以让每个人都站在同一个页面上，并允许关于过程的反馈，以帮助从任何角度改进它。我认为在这里有一个好的领导者是至关重要的，因为如果团队走上一两条正题，这些会议可能不会有太大的成效。

我发现回顾与我在以前的工作场所的事后回顾非常相似。我发现它们在一些事情上非常有用：

1. 看到了别人通常认为是好是坏的东西。测试是一个大问题吗？当项目只有两周或更少的时间时，新员工加入是有帮助还是没有帮助？
2. 允许每个人都有自己的意见。这有助于产生归属感和团队合作，当你想让某人开夜车或在各处工作到很晚的时候，这种归属感和团队合作会很有用。

保持日常站立的速度是有挑战的，但如果有一定数量的练习，那么它就会变得更自然。在某种程度上，围绕Scrum的过程可以放大好习惯和坏习惯，这取决于它的使用方式。