敏捷质疑: 迭代开发

　

迭代在于我们明确的承认信息和知识的不完备性, 不可完备性. 而项目的成功, 需要某种程度的完备性.

这种认知的局限与成功的条件之间的矛盾, 促成了人们解决这类问题的通用方法: 渐进的试错法

　

试错法参考一: 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: 证伪主义应采用试错法。这是指人们应该大胆地提出假说和猜测，然后去寻找和这一假说不符合的事例。根据事例对假说进行修正，不断重复这一过程，乃至将最初的假说全盘否定。试错法对理论的修改和完善是没有止境的，试错法的结果只能是一个较好的假说，但不是最好的假说。最好的假说是终极真理的代名词，和科学精神相悖

　

试错法广泛的应用于自然科学领域. 迭代开发就是试错法在软件开发过程方面的应用

　

不完备的信息和知识, 至少包括以下几个方面:

1. 客户真正的意图

2. 客户业务真正的规则

3. 客户项目所面临的约束

4. 所采用解决方案的合理性

5. 所采用技术架构的合理性

6. 所采用技术的缺陷

7. 不可预知的变化, 包括业务规则的变化, 以及外界环境的变化, 等等

我们只能针对当前对以上问题的理解, 给出一个初步的解决方案, 然后所有人, 包括客户和开发者, 根据这个方案的运行情况, 对方案进行批评, 提出其无法满足的约束或需求, 而回头重新修正这个方案. 如此循环往复, 直到某个可接受的错误水平. (对于上面最后一条, 迭代采用的是短周期来减少变化带来的浪费.)

　

迭代的核心就暂且止于此.

　

其它的一些问题, 都是目前的迭代实践所规定的一些额外性质造成的, 比如"固定的迭代周期", 引起的问题是: 时间盒迭代删减任务会不会导致完不成原定开发计划?

这个问题是从太极敏捷派的FAQ中摘录的. 对于这个问题, 太极敏捷的解释并没有触及如下迭代的本质:

1. 迭代的开发方式中, "原定的开发计划"并不是不变的. 随着信息和知识的逐渐完备, 我们会相应的调整"原定的开发计划". (太极的解释提及了计划的不确定性: "计划，与计划的实际执行情况，是两个不同的概念。决心不同于现实。所以，我们说，跟踪、确保计划的执行比制定完美的计划更重要", 其后续的思路还在确保原定计划的实现, 而丝毫没有考率调整原定计划)

2. 一如试错法的结果, 迭代的最终结果不必满足"原定的开发计划", 只要经的起客户的批判即可, 而敏捷开发有其它的手段来尽可能的保证这一点, 比如按照客户认可的规则安排开发的优先级, 这样即使最后没有完成全部特性, 但对客户来说优先级高的那些特性早就开始运行, 留下一些优先级低的特性甚至可以抛弃了. 太极敏捷居然连这一点都没有提及, 反映出其对敏捷/迭代开发的孤立理解.

　

另外的一些说法:

1. 试错, 是为了获得反馈. 迭代过程中, 要不要做某事, 其中一个依据是需不需要那方面的反馈

2. 迭代也为"回顾"提供了自然而然的机会. 试错过程中获得的信息需要总结整理归纳抽象, 学而时习之, 温故而知新

　

当然, 以上的论述建立在试错法之上. 如果这一理论并不适合软件开发, 那么上面的论述都是没有意义的. 那么我们就用试错法本身来检验一下其是否适合软件开发:

假定其适合, 理由是可以帮助解决以上提到的问题, 如渐进的搞清楚"客户真正的意图, 客户业务真正的规则, 客户项目所面临的约束, 所采用解决方案的合理性, 所采用技术架构的合理性, 所采用技术的缺陷"等, 那么请帮忙指出其不适用的地方, 或其本身带来的问题, 如果可能的话提出更好的解决方案.