一次迭代式开发的研究：软件开发的风险

我们的软件开发存在着巨大的风险，当我们经历了数月的辛苦工作后才发现，我们的软件并不是客户满意的软件。这时候往往出现几种情况：

1.客户开始频繁挑刺，大量的需求变更在很短的时间发生，加班再所难免，团队士气降到最低点；

2.甲乙双方开始相互推诿，谁是谁的责任，争吵不可避免，甚至最终谈判破裂，项目失败，双方不欢而散。

这些都是我们不愿看到的，却不得不面对。到底问题出在哪里呢？就在我们的开发过程中。以往的开发过程被称为瀑布式开发，它要求我们在正式的软件开发之前，在需求分析阶段，就要把客户的所有需求都分析清楚，确定下来。而在正式的软件开发的数月间，我们不再与客户交流，而是按照需求规格说明书自己埋头开发，直到最终交付客户。这样的方式，最终交付客户的风险可想而知。这种开发方式的弊端主要有这几个方面：

1.客户描述不清自己的需求。客户不是专业人士，因此在起初他们描述不清自己的需求，只有一些简单的想法。一句经典的话是这样说的：“When I saw it, I have changed.”只有当他们看见我们制作的一个个demo版界面原型时，甚至操作着原型的模拟操作流程时，他们才开始整理，并使自己的需求逐渐清晰起来。这需要一个过程。

2.我们理解客户的业务领域也需要一个过程。我们是技术专家，我们掌握着丰富的软件知识，但我们不是领域专家，我们不了解客户的业务领域，因而这不能让我们的软件获得成功。我们只有深入理解客户的业务领域之后，才能深刻理解客户的业务需求，才能使我们的软件成功。这需要一个逐渐深入的过程，因此不可能在软件开发的初期那短短的需求分析阶段完成。

一切的一切说明了一点：我们必须改变我们的开发方式。我们需要一个持续的需求分析过程，这个过程应当与我们的设计、开发、测试过程同步；我们需要不断地向客户展示我们的软件成果，听取客户的意见，使我们开发的软件不会偏离正确的轨道。而这就是迭代式开发，另一种软件开发模式。

一次迭代式开发的研究：软件开发的风险
一次迭代式开发的研究：什么是迭代式开发
一次迭代式开发的研究：怎样进行迭代式开发
一次迭代式开发的研究：迭代开发从这里开始
一次迭代式开发的研究：准确的工作量评估
一次迭代式开发的研究：功能的优先级评估
一次迭代式开发的研究：一个迭代式项目计划
一次迭代式开发的研究：开始真正的工作
一次迭代式开发的研究：从容应对需求变更
一次迭代式开发的研究：需求变更的关键步骤
一次迭代式开发的研究：Where you are
（续）