提供建议而不是规则

我发现似乎原来有多人希望能够将敏捷归纳成规则。最近我在很多书籍、博客或者和敏捷或者Scrum相关的PDF文件里面看到类似“你必须这么做”或 者“如果你不这么做的话那你就是做错了。”之类的话。在最近几个月和一些项目管理办公室(PMO)的对话中,我也遇到了相似的问题。

这让我想到我2012年新年第一件要做的事情,就是希望大家提供建议,而不是制定规则。

敏捷软件开发中的硬性规则其实非常少。我在这里列出一些我能想到的:

以不长于一个月的迭代方式进行工作
在每个迭代结束的时候都能够完成之前承诺的目标,然后获得股东的反馈
在每个迭代开始之前,聚到一起来讨论这个迭代的目标
在每个迭代结束的时候,回顾在这个迭代中你们表现得怎么样
在迭代中进行大量的交流

除此之外,更多的都是建议了。在接近20年里,我所接触到的很多敏捷流程都没有严谨的形式。例如,我推荐团队使用用户故事记录需求;我推荐团队使用 故事点数进行估算;我推荐团队尽量不要从周一开始一个迭代;我推荐团队吃中国的宫爆鸡丁。但是,上述这些都不是成功实施敏捷的必要条件。每一条都有可能对 团队有所帮助,当然我推荐也有我自己的理由,但是这些都不是必须的。

所以,在这里我再次重申:给建议,但是不要制定规则。我真的有点想要给制定你们加入这个行动的规则,但是我不是刚刚才说完了不要制定规则吗?