领导者应该决定要解决的问题的“内容”和“时间”(而不是要实施的解决方案)。产品团队成员应该可以自由地通过他们只能根据自己的专业知识和知识构思和执行的解决方案来定义“如何”。本文将指导我们从 Scrum 转向Shape Up,立即开始按时交货,没有任何延误。并以灵活的范围和固定的期限来制定和执行项目,产品团队感到更有成就感,因为取得了更多进展,并且以增量方式更快、更频繁地将功能推向生产。
功能请求是一个要实施的解决方案,尽管它是在这种情况下构思想法的更自然的方式,但它是规范性的,因为它阻止产品团队成员探索其他可能更好的解决方案。当这些功能请求来自不了解产品的限制和可能性的利益相关者时(大多数情况下自然是这种情况),他们会让团队在试图在短时间内构建超出必要的功能时陷入困境。一段时间,这会导致错过最后期限并使团队、利益相关者和用户不满意。
我见过并读到许多团队实施这种方法;有些人声称使用了Shape Up 的改编版本。我理解为什么 – 这种方法需要改变思维方式,不仅对于产品团队,而且对于为下一步将优先考虑的项目做出贡献或提供输入的利益相关者。
在MiSalud,通过医疗团队、客户支持以及首席执行官不断收到来自患者的反