迭代是我用的最多的一个词，而且在快速和敏捷开发中更加强调短迭代，一周到两周为一个迭代周期。迭代的目的一方面是进度可视，进度可视的体现是产出物可视，每次迭代是一个至少内部可以独立发布的版本。同时迭代另一方面重点仍然是应当需求不明确的情况，对于需求的不明确我们的解决之道就是分解，要通过分解找到明确的内容，放入前面的迭代周期先做，而不是由于需求不明确造成我们整个项目计划的不明确。

高效的开发团队中的每一个人都应该是一个高效的人，是一个懂得如何自我管理的人。而对于开发的自我管理有一个重点则是开发团队的GTD方法，在软件开发中即是PSP个体软件过程。开发人员要达到高效不仅仅是技能水平很出色，而且必须有很强的纪律性，懂得如果管理自己的任务和分配自己的时间，同时通过大量的积累懂得自我的工作效率。

需求要条目化，条目化的重点是原子性，原子性从业务上解释则是该条需求在业务上是可以独立验证的最小单位。如果从这个角度出发，一个软件需求用例可能包括多条可以条目化的需求。而这个条目化的需求则是对应到类似FDD特征驱动开发中的特征点。只有有意识的走到这一步，才谈得上软件开发文档的全部结构化管理，并实现需求-》设计-》开发-》测试全过程条目管理管理和追踪。

可视化进度中的一个最佳实践就是类似精益生产的看板管理。那么一个重要的问题我们关注的就是看板的更新频度。按我的理解，一个短迭代周期内容应该分解到具体的特征点后全量更新到看板上，而实际的进度则应该是按照每天实际执行情况增量进行看板的更新。没有刷新的看板是没有意义的看板。

可能性的艺术，原来看SCRUM时候还没有特别注意这个词，现在深有感受。不用把太多的时间花在一件事情有些不能做找太多的理由，而应该是将一件事情分解，聚焦到可以先做的小事件并找寻方法。这也正是一种积极的主动迭代的做事情的方式，当你可能做的东西做完后，你会发现不能做的地方已经迎刃而解。

不沟通时坏事情，太多的无效沟通也是坏事情。而避免沟通无效的重点正是敏捷强调的另外一个重点，开始实施敏捷的团队最好是已经相互熟悉的团队，由于相互熟悉已经建立了软件开发和相关产品的通用词汇表。通过技能水平差别不大，以减少去解释和明确问题本身的沟通成本。