这是一个相当广泛的问题!这是我的看法。
我认为 Scrum 真正擅长的是教会组织热爱敏捷/迭代/增量/精益软件开发。对于习惯于项目管理的命令和控制层次结构的公司而言,团队成功地真正适应客户需求所必需的授权是一种巨大的文化转变。Scrum 使所有这些对于组织来说都是平易近人的,具有明确定义的角色和流程。
基本上,对我来说,它为程序员团队购买了他们在大公司的所有政治和官僚机构中继续进行 XP 所需的空间。
然而,随着这种授权而来的是责任。Scrum 不强制要求任何 XP 工程实践,但如果没有 CI、TDD 和重构等核心实践,任何 Scrum 团队都会在几次迭代后陷入停顿。我个人认为在 scrum 的“规则”中不明确这一点是非常不负责任的,这将是我的批评之一。
我的另一个批评是任务卡和任务计划。我还没有看到一个团队这样做真的很有效:通常会有一个非常累人的一天,你试图考虑在整个迭代中你将要做的所有事情,然后你开始工作并发现你实际上需要做一些不同的事情。通过任务燃尽来衡量进度感觉像是让团队协作和团结的好方法(特别是如果您否认任务所有权),但最终它不是跟踪团队进度的可靠方法。
我更加强调价值或故事点的燃尽,而这些天通常会让团队每天更新一个大的累积流程图,而不是我们所处的位置。这些任务保留在人们的待办事项清单上,但它们不会出现在董事会或由任何人管理。
当然,关键的做法是回顾。Mike Cohn 对我之前关于 XP 实践的观点的反驳是,通过回顾,团队最终会发明/采用 XP,这确实有一定的道理。当然,定期自省是确保您的团队尽可能有效并继续有效的最佳方式。