敏捷实践
敏捷团队是否应该有准备好的定义？
阅读：
敏捷团队是否应该有准备好的定义？
在准备定义的危险，敏捷思想领袖Mike Cohn表达了一个社区中许多人都关心的问题:通过建立关于开发团队在处理待定项之前必须提供什么信息的严格规则，我们有倒退到线性过程模型的风险。
这是一个真正恐怖的前景！
等一下。我在想别的东西。它不是一个可怕的前景。它实际上是一个非问题。
期待一个团队在没有定义的项目上开始工作是愚蠢的。只是将模糊的声明折叠到以太网上并附上任意截止日期不起作用。它从来没有。
这个想法是与利益相关者合作，确保积压项目处于适当的形状，以使人们能够完成它。这个想法是不是在团队和利益相关者之间建造一堵墙。它是基础合作，不是一个代替。
许多人似乎很难这个概念。例如，迈克尔·詹姆斯评论准备的定义在Scruminc.com在2017年8月，写道，“声明'一些公司实际上需要详细的清单来确定一个故事是否准备就绪，”说明了为什么开准备的定义实践通常违反了敏捷价值观和原则。“
这些担忧让我想起了许多年前我在州政府工作时发生的一件事。在同一栋大楼工作的一个人是盲人。有一天，他想参加一个为盲人政府工作人员举行的会议。国家给他发了一辆汽车去旅行。他们直接把汽车给了他。他们没有提供司机。当他询问时，他提醒他的妻子不是允许驾驶汽车，因为她不是汽车已经发出的人。他们知道他是盲目的，但该案例没有规则。他遇到了使用国家车辆规则规定的所有标准。他们用微笑递给他钥匙，（他认为）一波。
确实，如果您选择，您可以自由地使用与您的定义相同的常识。你是自由的用锤子打你的拇指， 也。
评论（2）
jardena.
很棒的文章戴夫！我认为人们将协议与规则混为一谈。如果准备好的定义是团队协议，他们可以在不再为它们提供服务时更改协议！如果它是一个企业规则，那么这将引起各种问题，最好是线性过程模型，但在最糟糕的团队中是最糟糕的。
如果没有准备好的定义，那么球队的流失和冲突是不必要的，因为他们正在追逐准备。
准备好的定义只是对齐团队在决策框架上的一个例子。通常是好事。
戴夫·麦克劳
不确定你真的在这里解决了科恩的观点。他突出了“建立严格规则”的危险，您的建议也没有严格的规则（“只是”使用常识）？
这只是公理的，这类组织正在考虑正式定义的准备好的功能障碍的风险很高。我已经看到了许多情况，其中DOR（或DOD）的现实是代表一些中央功能的领土练习来控制工作的条目（或发布）;反驳。
如果您可以通过使用常识来避免任何不断的结果，那么几乎任何方法都会工作得很好。