先来说下短迭代的好处。
1、快速交付特性，更加灵活的应对变化和突发情况，很好的应对外发版本；
2、减少每个版本发布的质量回退风险。
但是之前的项目中也多次试图试行短迭代。然而开发反馈，迭代太快根本没时间做质量活动，测试反馈，版本发的太频繁无法进行深入的测试。整个团队都处于焦虑之中。而对于项目管理者来说节奏也非常难以掌控，因为有太多的“意外”事件出现，打乱原先的计划。
直到上个项目尝试了精益看板的方式，并成功做到了基本上的周迭代之后，才慢慢体会出短迭代比长迭代难以执行的原因，就是当出现这种”意外”事件之后，短迭代几乎毫无回旋余地。
项目想要真正做到短迭代必须要遵循两个重要的宗旨。
一、显式呈现所有潜在的任务
我们原来习惯呈现迭代计划的时候是这样的：
而我们在实际执行迭代的时候，情况是这样的：
当迭代时间比较长的时候，这些未被列出的“隐藏”任务因为存在相对较长的缓冲时间，有能力消化在本迭代。但是如果迭代时间变成一周，这些“隐藏”任务相对计划任务耗时比将会显著提升，迭代回旋余地十分有限，由于计划和实际执行情况不符，节奏很容易打乱，团队也会非常疲惫。
不呈现所有任务，还有另外一个坏处，当需要做的事情没有被呈现的时候，就会被团队视为“额外”任务，项目一紧，比如及时的轻量级的代码重构，复杂方案的提前验证这些本来能提前降低后续风险，对质量非常有好处的举措都变成了“额外”工作，要么会无人提及，要么第一个被放弃。
那为什么安排计划的时候不能按照实际情况来呢，显式的呈现所有潜在的任务，把所有“隐藏”的风险，都变成显式的工作量的风险，迭代才不会遇到那么多“意外”。
二、自动化持续集成
关于版本发布太频繁，测试无法进行深入测试的问题，咨询了华为内部六级测试专家，他给的答复一个是缩减迭代的范围，我理解就是显式的呈现所有的任务，另外就是采用持续集成的方式每天对全量版本进行测试，迭代转测只做新增特性的测试。
现在如果让我来理解什么是敏捷，我觉得就是两点：
首先，敏捷字面上的意思无非就是灵活、反应快，怎么才能反应快呢，就是不断要丢掉一些之前必须背负的“包袱”， 丢给谁呢，丢给工具，丢给机器，丢给持续集成，丢掉这些“包袱”，自然就敏捷了。
其次，敏捷实际上就是把需求进行端到端的解耦，原来瀑布模式，先收集一个大的需求包，然后通过交接棒的形式，不断交给下一个环节，直到全部变成软件功能交给客户，敏捷类似纵向切片，就是无论给一个还是几个需求，都能直接变成软件功能交付给客户。现在一些流行的技术“特性端到端解耦”，“微服务”其实都是为了更好的做到需求的端到端解耦。
从以上两个点出发，我们就能很好的理解，敏捷中我们需要做什么，敏捷的力度我们需要如何掌握。
想要实现短迭代，可能还有一些其他的因素，但是“显式呈现所有潜在的任务”和“自动化持续集成”是短迭代得以执行的两个关键要素。
