Damon Poole 最近在博客上写到，我们中有很多人可能正在实践敏捷开发而不自知。
有趣的是，大多数的软件车间都是无意识的追随着敏捷开发的步伐。他们定期的进行发布，这种做法跟敏捷团队的做法很相似，不过他们却没有意识到这点，并因为不得不这样做而感到羞愧。随后，他们就希望不要再这样来一次了。
大多数的团队都是什么时候做的像敏捷开发一样呢？即使他们不是敏捷的？
我指的是维护版本、补丁和热修复。别去想它们本来是不必要出现的——其根由是源自于“一次大型发布”出现的问题——而且还是在紧张的压力下完成；也 别去想有时候你必须要用另外一次热修复来重新做一次先前的热修复。第二次热修复的需要通常是在第一次热修复余波未息时，经过紧张研究发现的，根源在于热修 复大概根本就没有走过一个正常 QA 过程的完整循环。
这种事情，我们每个人应该都听着挺耳熟的，即便我们没有实施敏捷……有趣吧——不是吗？Damon 的重点在于，我们中大多数人在事情发生后感到羞耻并下决心不再让它重新发生，这种事应该是挺普遍的。为什么呢？
我相信大多数软件车间向前走一小步然后又远离敏捷开发的原因是，这种行为本身就是软件开发的自然节拍，人们很难与之相抗。要维持下去并非易事，你需 要做到两点：深入理解敏捷，和有意识地去控制。如果不是有意识地打算这样做，也没有短期迭代的同步信号，那么除非你在这条路上呆了很久，否则就很难注意到 是否走错了路。另外一个问题是，如果一个组织中的每一个人都纯粹碰巧的和敏捷节奏发生了同步，那么项目计划、习惯和已经确立的过程所发出的同步信号就会和 自然节拍发生冲突。这种情况下，自然节拍就不会再有机会东山再起了。
所以，节拍也是敏捷开发取得成功的核心要素之一——它会让人精疲力尽（但它也非常有效）。这和其他人所做的有关敏捷软件开发的报告中的观点正相吻合。在 Rhythms as Agile Diagnostics 一文中，作者首先发明了这个观点。文章说道，判断你是否走在敏捷开发的正途上的一种方式就是看一下项目中的主要节拍：
健康的敏捷项目有多种典型的节拍，如发布、迭代、站立会议、由持续集成启动的构建，还有开发人员的红 - 绿 - 红测试循环。这些节拍有着很正常的范围 （如站立会议不多于 15 分钟）和特征（在站立会议中不包括设计讨论）。如果它们超越了正常的范围，或是显示出来的特征出现了偏差，这就表示在敏捷过程中出 现了问题。医生会根据病人的脉搏或是血压来判断病人是否生病，我们通过检查节拍来判断敏捷过程中是否出错。当节拍出了问题，有时候需要被直接处理，有时候 需要我们对过程进行深入分析，找出并修正问题的根源。
这种有关节拍与敏捷开发的观点跟你的过往经验相符么？你或你的团队是否曾经无意识地实施过敏捷？如果你已经在实施敏捷，或者正在采用一些实践，那你目前的项目中有哪些节拍呢？
评论