5月15日参加持续交付、敏捷、DevOps的理念实践讲座，其中一些内容非常有启发作用。整理了几个观点（理念、原则）进行分享。
- 敏捷迭代中开发的连续性，不应与明显的迭代分界（开始或结束）
- 自动化测试策略： http://lzhted.iteye.com/blog/2212646
- 部署模式：http://lzhted.iteye.com/blog/2213844
本文介绍第一个观点（原则）：敏捷迭代中开发的连续性，不应以明显的迭代分界（开始或结束）。
在介绍新的原则之前，先简单介绍我们当前的情况与挑战。
我们的现状：以每周为一个迭代，迭代前安排好开发任务（story），开发人员在一周的时间内完成开发、测试、出版本。
实际的挑战：1、因为需求和方案的工作量不总是理想（大小差距多）的，需要花费较多的工作量将方案划分成合适工作量、且可验证的story。这可以认为是一种浪费。 2、每个迭代只计划和实现本迭代的开发任务，当某个story超出迭代的工作量或依赖关系复杂时，会完整地安排在下一个迭代，出现当前迭代闲，后续迭代忙，甚至超期的问题。参考下图示例：存在依赖关系的6个story被安排在3个迭代完成，其中第一个和第三个迭代都存在浪费。
下面介绍本文整理的观点：如果我们做出改变，确保敏捷迭代中开发的连续性，不以迭代来限制任务的开发过程，整个迭代过程就会如下图所示：
在新的迭代计划中，第一个迭代仍然只交付了A和1两个开发任务，但是第二个迭代可以交付所有的开发任务。这里可以认为，迭代对于外部（交付）是阶段性的，而对于内部（开发）是连续的。连续的开发任务使得开发人员的开发节奏更稳定、效率更高。
但是，这也带来了新的挑战：1、迭代一结束时是否需要提交未完成的工作B？ 2、如何发布未完成的工作。即第一个迭代结束时，只做了一半的任务B应该如何交付？
第一个问题的答案是肯定的，任何开发工作都要及时提交。那么如何提交和发布未完成的工作？有以下两点可以实践：
- 设计公共的特性开关。未完成的工作将通过特性开关进行过滤。注意：a. 只有当没有其它方法时才使用特性开关，否则优先通过特性隐藏来过滤。 b. 当工作完成（特性激活）时，移除开关。
- 基于抽象（接口）的程序设计。即使未实现依赖的逻辑，系统也能正常编译运行。