迭代在于我们明确的承认信息和知识的不完备性, 不可完备性. 而项目的成功, 需要某种程度的完备性.
这种认知的局限与成功的条件之间的矛盾, 促成了人们解决这类问题的通用方法: 渐进的试错法
试错法参考一: http://en.wikipedia.org/wiki/Trial_and_error.
试错法参考二: http://zh.wikipedia.org/wiki/%E8%AF%95%E9%94%99%E6%B3%95: 是解决问题、获得知识常用的方法，即根据已有经验，采取系统或随机的方式，去尝试各种可能的答案。当问题相对来说比较简单或范围比较有限时，试错的方法有 一定效果。在试错的时候，可以选择一个可能的答案应用在待解问题上，如果没有效就选择另外一个可能的答案接着尝试。整个过程在出现一个合适的可能性时结束
试错法参考三: http://zh.wikipedia.org/wiki/%E5%8D%A1%E5%B0%94%C2%B7%E6%B3%A2%E6%99%AE%E5%B0%94#.E8.AF.81.E4.BC.AA.E5.8E.9F.E5.88.99: 证伪主义应采用试错法。这是指人们应该大胆地提出假说和猜测，然后去寻找和这一假说不符合的事例。根据事例对假说进行修正，不断重复这一过程，乃至将最初 的假说全盘否定。试错法对理论的修改和完善是没有止境的，试错法的结果只能是一个较好的假说，但不是最好的假说。最好的假说是终极真理的代名词，和科学精 神相悖
试错法广泛的应用于自然科学领域. 迭代开发就是试错法在软件开发过程方面的应用
不完备的信息和知识, 至少包括以下几个方面:
-
客户真正的意图
-
客户业务真正的规则
-
客户项目所面临的约束
-
所采用解决方案的合理性
-
所采用技术架构的合理性
-
所采用技术的缺陷
-
不可预知的变化, 包括业务规则的变化, 以及外界环境的变化, 等等
我们只能针对当前对以上问题的理解, 给出一个初步的解决方案, 然后所有人, 包括客户和开发者, 根据这个方案的运行情况, 对方案进行批评, 提出其无法满足的约束或需求, 而回头重新修正这个方案. 如此循环往复, 直到某个可接受的错误水平. (对于上面最后一条, 迭代采用的是短周期来减少变化带来的浪费.)
迭代的核心就暂且止于此.
其它的一些问题, 都是目前的迭代实践所规定的一些额外性质造成的, 比如"固定的迭代周期", 引起的问题是: 时间盒迭代删减任务会不会导致完不成原定开发计划?
这个问题是从太极敏捷派的FAQ中摘录的. 对于这个问题, 太极敏捷的解释并没有触及如下迭代的本质:
-
迭代的开发方式中, "原定的开发计划"并不是不变的. 随着信息和知识的逐渐完备, 我们会相应的调整"原定的开发计划". (太极的解释提及了计划的不确定性: "计划，与计划的实际执行情况，是两个不同的概念。决心不同于现实。所以，我们说，跟踪、确保计划的执行比制定完美的计划更重要", 其后续的思路还在确保原定计划的实现, 而丝毫没有考率调整原定计划)
-
一如试错法的结果, 迭代的最终结果不必满足"原定的开发计划", 只要经的起客户的批判即可, 而敏捷开发有其它的手段来尽可能的保证这一点, 比如按照客户认可的规则安排开发的优先级, 这样即使最后没有完成全部特性, 但对客户来说优先级高的那些特性早就开始运行, 留下一些优先级低的特性甚至可以抛弃了. 太极敏捷居然连这一点都没有提及, 反映出其对敏捷/迭代开发的孤立理解.
另外的一些说法:
-
试错, 是为了获得反馈. 迭代过程中, 要不要做某事, 其中一个依据是需不需要那方面的反馈
-
迭代也为"回顾"提供了自然而然的机会. 试错过程中获得的信息需要总结整理归纳抽象, 学而时习之, 温故而知新
当然, 以上的论述建立在试错法之上. 如果这一理论并不适合软件开发, 那么上面的论述都是没有意义的. 那么我们就用试错法本身来检验一下其是否适合软件开发:
假定其适合, 理由是可以帮助解决以上提到的问题, 如渐进的搞清楚"客户真正的意图, 客户业务真正的规则, 客户项目所面临的约束, 所采用解决方案的合理性, 所采用技术架构的合理性, 所采用技术的缺陷"等, 那么请帮忙指出其不适用的地方, 或其本身带来的问题, 如果可能的话提出更好的解决方案.