周期这个概念，作为基础思维模式之一，很容易被初入敏捷的人们忽视。但它的影响深远。
在传统方法下，尤其瀑布模式中，那些动辄以年为计算单位的开发计划，周期的理念对多数人而言，是一个淡漠的词汇。出于众所周知的原因，敏捷需要在人的脑海中强化周期的概念，而且它的迭代、增量和自适应的特性，都或多或少指向一个明确具体的方向——缩短周期。
现在我们知道了，缩短周期是需要采取的明确无误的方法，它服务于尽早呈现可以交付的产物，但也是持续改进和推向极致的手段之一。你看，敏捷的思维模式和具体实践，本身就是一个彼此勾连的系统，之间有千丝万缕的联系。抛开任何一方，或者只是谈论一个方面，都显得片面有失偏颇。
周期在日常的团队活动中会有具体的表现。迭代，形象而真实，一个体现出周期性的隐喻。在这个盒子里，团队各类角色彼此合作，交付产物。我通常见到的迭代多数为两周时间，恐怕是一个合适Pizza Team规模的长度。然后视团队规模和组织结构设置，我也见识过一周或者四周的迭代周期。
但很明显这并不足够。虽然周期让人下意识想到迭代这个显而易见的观念。但如何缩短它，却不是我们通常会去持续考虑的事情。它更像是一个固定大小的盒子，我们在其中找到节奏以及称之为信心的东西。
缩短周期，初衷是我们寻求快速反馈的期许。而这个反馈来自于客户、市场，甚至是团队中合作的对方。这个反馈降临的速度越快，我们可以响应的速度就可以越快，做出改变的速度也就越快。
我们当然可以通过减小迭代周期到一周，以及必要的持续交付和上线（每个迭代必须发生），来实现缩短周期的目的。但还有没有更极致一些的方法呢？我们可以尝试把目光从迭代这个显而易见的盒子上移开，也从开发团队身上移开，投放在更广的角色合作范围，以及更大的信息流转的范围。
这就引入了前置时间的概念。一个跨越了从需求想法的产生，到最后真实上线交付用户使用的时间长度。缩短它才是将缩短周期推向了极致。所以我们也就不奇怪《Accelerate》一书会把前置时间作为衡量高效能交付的四个关键指标之一。值得一提的是，另一个跟时间有关的指标是平均恢复时间。
需要注意的是，缩短周期不是一个无限制的追求。这个周期的结束必然需要一个可以呈现价值的交付物，以及在此周期内，团队获得愉悦的节奏以及信心。
