我发现似乎原来有多人希望能够将敏捷归纳成规则。最近我在很多书籍、博客或者和敏捷或者Scrum相关的PDF文件里面看到类似“你必须这么做”或 者“如果你不这么做的话那你就是做错了。”之类的话。在最近几个月和一些项目管理办公室（PMO）的对话中，我也遇到了相似的问题。
这让我想到我2012年新年第一件要做的事情，就是希望大家提供建议，而不是制定规则。
敏捷软件开发中的硬性规则其实非常少。我在这里列出一些我能想到的：
以不长于一个月的迭代方式进行工作
在每个迭代结束的时候都能够完成之前承诺的目标，然后获得股东的反馈
在每个迭代开始之前，聚到一起来讨论这个迭代的目标
在每个迭代结束的时候，回顾在这个迭代中你们表现得怎么样
在迭代中进行大量的交流
除此之外，更多的都是建议了。在接近20年里，我所接触到的很多敏捷流程都没有严谨的形式。例如，我推荐团队使用用户故事记录需求；我推荐团队使用 故事点数进行估算；我推荐团队尽量不要从周一开始一个迭代；我推荐团队吃中国的宫爆鸡丁。但是，上述这些都不是成功实施敏捷的必要条件。每一条都有可能对 团队有所帮助，当然我推荐也有我自己的理由，但是这些都不是必须的。
所以，在这里我再次重申：给建议，但是不要制定规则。我真的有点想要给制定你们加入这个行动的规则，但是我不是刚刚才说完了不要制定规则吗？
