我所在的团队在我们的开发过程中使用 scrum。我们目前正在尝试改进我们流程的某些方面，以解决我们最近注意到的一些问题。在这样做的过程中，我们正在探索我们对 Scrum 流程的总体喜欢和不喜欢的地方，以帮助我们确定我们作为一个团队在工作中的价值观。我们认为，如果我们能够确定我们重视什么，那么我们就可以提出围绕这些价值观的实施，以帮助新的解决方案在团队中坚持下去。
话虽如此，我真的很感兴趣其他人如何看待 Scrum 过程。你真正喜欢它的哪一点？什么是令人沮丧的，感觉开销太大或没有生产力？成功和失败的具体例子很好，但我感兴趣的是一个更大的观点，讨论围绕 scrum 的陷阱或 scrum 真正闪耀的地方。
想法？
我不喜欢管理者将 Scrum 流程作为快速发布周期来实现，而所有其他方面都与瀑布流相同或更糟。
我认为根据我的经验，关键是要了解业务和管理人员如何选择实施 Scrum 和/或敏捷的部分内容，或者换句话说，他们对流行语的解释。
我喜欢每日站立的想法，每个人都说他们昨天做了什么，他们今天计划做什么以及他们有什么障碍，因为这会产生责任感，假设没有更好的术语来表达尊重和荣誉。
任务卡及其演变对于其他人了解正在发生的事情以及让某人了解他们是否确定了某些事情很有用。卡片在某种程度上确实为自己的沟通渠道做出了贡献，这取决于您如何看待它，这可能是好是坏。
回顾和迭代计划会议通常有助于让每个人都进入同一页面，并允许对流程进行反馈，以帮助从人们看到的任何角度改进流程。我认为在这里有一个好的领导者是必不可少的，因为如果团队一两次切线，这些会议的效率可能会降低。
我发现回顾与我在以前的工作场所进行的验尸非常相似。我发现它们对几件事非常有用：
看看别人认为通常是好是坏。测试是个大问题吗？当项目只有 2 周或更短时间时，新员工进来是否有帮助？
让每个人都有发言权。这有助于培养归属感和团队合作精神，当您希望有人在夜里熬夜或在这里和那里工作到很晚时，这会很有用。
保持每日站立的速度是一个挑战，但如果完成了一定数量的练习，它就会变得更加自然。在某种程度上，围绕 Scrum 的过程可以放大好习惯和坏习惯，具体取决于它的使用方式。
这是一个相当广泛的问题！这是我的看法。
我认为 Scrum 真正擅长的是教会组织热爱敏捷/迭代/增量/精益软件开发。对于习惯于项目管理的命令和控制层次结构的公司而言，团队成功地真正适应客户需求所必需的授权是一种巨大的文化转变。Scrum 使所有这些对于组织来说都是平易近人的，具有明确定义的角色和流程。
基本上，对我来说，它为程序员团队购买了他们在大公司的所有政治和官僚机构中继续进行 XP 所需的空间。
然而，随着这种授权而来的是责任。Scrum 不强制要求任何 XP 工程实践，但如果没有 CI、TDD 和重构等核心实践，任何 Scrum 团队都会在几次迭代后陷入停顿。我个人认为在 scrum 的“规则”中不明确这一点是非常不负责任的，这将是我的批评之一。
我的另一个批评是任务卡和任务计划。我还没有看到一个团队这样做真的很有效：通常会有一个非常累人的一天，你试图考虑在整个迭代中你将要做的所有事情，然后你开始工作并发现你实际上需要做一些不同的事情。通过任务燃尽来衡量进度感觉像是让团队协作和团结的好方法（特别是如果您否认任务所有权），但最终它不是跟踪团队进度的可靠方法。
我更加强调价值或故事点的燃尽，而这些天通常会让团队每天更新一个大的累积流程图，而不是我们所处的位置。这些任务保留在人们的待办事项清单上，但它们不会出现在董事会或由任何人管理。
当然，关键的做法是回顾。Mike Cohn 对我之前关于 XP 实践的观点的反驳是，通过回顾，团队最终会发明/采用 XP，这确实有一定的道理。当然，定期自省是确保您的团队尽可能有效并继续有效的最佳方式。