每一个项目都有不同的生命周期，而不同的项目到底选择哪种开发模式，对你能否顺利将项目进行下去有很大影响。

我们可以利用一些工具，帮助我们判断选择最合适的方法。

今天给大家介绍一个工具——Stacey矩阵

通过这张图，我们可以简单明了的划分项目，选择相对应的方法行动。

1区：Simple

2区：Complex

需求很明确，技术方案并不确定。

也就是说怎么实现不知道，这类项目叫复杂的项目（Complex），也叫棘手的项目。

比如，无人驾驶，这项目需求明确吧？

“无人驾驶”四个字把需求说的明明白白，就是不要人开，车自己会走。

但是“无人驾驶”研究了几十年，各种方法都试过了，一直也没搞定。

直到今天，随着人工智能的发展，才开始让无人驾驶技术逐渐变得现实起来。

所以，像这种需求很明确，技术方案不确定的项目，我们需要用“迭代型”开发，一步步摸索着实现。

3区：Complicated

技术很确定，需求却不明确，这类项目是烧脑型的项目（Complicated）。

其实这种项目我们在实际工作中经常会遇到。

比如，客户想让你开发一个软件，问你会什么语言啊？C语言你会吗？Java你会吗？

你说，这些我都会，但是你到底想要一个实现什么功能的软件呢？

客户懵圈了。

如果你遇到这样的项目，那么“增量型”开发就是适合的方法。

先把客户能够确定的、表达清楚的部分做出来，一边做一边想一边交付，一点点增加实现。

4区：Chaotic

需求不清楚，怎么实现也不清楚，这叫混乱状态的项目（Chaotic）

如果你遇到这样的项目，最好的解决办法就是——别碰。

远离这种混乱的项目，也是给自己节省点精力。

5区：Hazy

就是图中紫色区域，需求不是特别明确，技术方案也不是特别确定。

当我们发现这个项目需求是什么不是特别明确，用什么技术能实现也不是特别明确时，最好用敏捷开发，这种方式也是很多公司在使用的方法。

因为在实际工作中，需求时刻在变，人们对于需求的理解也时刻在变。

而且，随着项目的进行，努力的目标和成功的标准也可能发生变化。

这就意味着项目环境也在不停的变化。

因此，使用“敏捷型”开发，适应性强，灵活机动，拥抱变化。

因为现在很多IT公司都采用敏捷开发和瀑布开发的模式，所以今天我们来聊聊这两种开发模式的区别。

网上流传着一个一个很有趣的“敏捷和瀑布”对比例子，给大家作为阅读参考：

敏捷开发

• 客人到餐馆来点菜（新项目）

• 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）

• 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）

后厨开始准备（项目启动）

• 配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）

• 客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）

• 上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）

• 又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）

• 到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）

客人吃完，很满意（基本满足了全部的要求）

瀑布模型开发

• 客人到餐馆来点菜（新项目）

• 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）

• 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）

• 后厨开始准备（项目启动）

• 根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）

• 半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）

• 再过了二十分钟，十个菜都一起上来了（项目最终一次交付）

• 客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）

• 这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）

• 于是，后厨只给客户加了盐，加了辣

• 客人吃完，不是很满意，下次不来了（没有满足需求）

总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。

在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用。

最后一句话送给大家：少研究一些主义，多关注一些实际问题。