每一个项目都有不同的生命周期，而不同的项目到底选择哪种开发模式，对你能否顺利将项目进行下去有很大影响。
我们可以利用一些工具，帮助我们判断选择最合适的方法。
今天给大家介绍一个工具——Stacey矩阵
通过这张图，我们可以简单明了的划分项目，选择相对应的方法行动。
1区：Simple
需求很明确，使用的技术也很确定。这类项目就是简单的项目(Simple)
甲方需要什么我们很清楚，我们怎么做也很清楚。
比如注册一个新公司，需求很明确，手续也很清楚，就那么几步规定动作，因此大量代理机构都可以帮你完成这个项目。
既然需求明确，怎么实现也清楚，最好提前把计划做到位，预测型，也可以成为“瀑布型”开发模式最适合。
2区：Complex
需求很明确，技术方案并不确定。
也就是说怎么实现不知道，这类项目叫复杂的项目(Complex)，也叫棘手的项目。
比如，无人驾驶，这项目需求明确吧?
“无人驾驶”四个字把需求说的明明白白，就是不要人开，车自己会走。
但是“无人驾驶”研究了几十年，各种方法都试过了，一直也没搞定。
直到今天，随着人工智能的发展，才开始让无人驾驶技术逐渐变得现实起来。
所以，像这种需求很明确，技术方案不确定的项目，我们需要用“迭代型”开发，一步步摸索着实现。
3区：Complicated
技术很确定，需求却不明确，这类项目是烧脑型的项目(Complicated)。
其实这种项目我们在实际工作中经常会遇到。
比如，客户想让你开发一个软件，问你会什么语言啊?C语言你会吗?Java你会吗?
你说，这些我都会，但是你到底想要一个实现什么功能的软件呢?
客户懵圈了。
如果你遇到这样的项目，那么“增量型”开发就是适合的方法。
先把客户能够确定的、表达清楚的部分做出来，一边做一边想一边交付，一点点增加实现。
4区：Chaotic
需求不清楚，怎么实现也不清楚，这叫混乱状态的项目(Chaotic)
如果你遇到这样的项目，最好的解决办法就是——别碰。
远离这种混乱的项目，也是给自己节省点精力。
5区：Hazy
就是图中紫色区域，需求不是特别明确，技术方案也不是特别确定。
当我们发现这个项目需求是什么不是特别明确，用什么技术能实现也不是特别明确时，最好用敏捷开发，这种方式也是很多公司在使用的方法。
因为在实际工作中，需求时刻在变，人们对于需求的理解也时刻在变。
而且，随着项目的进行，努力的目标和成功的标准也可能发生变化。
这就意味着项目环境也在不停的变化。
因此，使用“敏捷型”开发，适应性强，灵活机动，拥抱变化。
因为现在很多IT公司都采用敏捷开发和瀑布开发的模式，所以今天我们来聊聊这两种开发模式的区别。
网上流传着一个一个很有趣的“敏捷和瀑布”对比例子，给大家作为阅读参考：
敏捷开发
客人到餐馆来点菜(新项目)
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
根据图文菜单，客人点了十个菜(根据原型和设计稿，基本确定了需求)后厨开始准备(项目启动)
配菜、炒菜，先上了两盘，让客人尝了尝味道(先提供可用实例给客户用)
客人说还不错，后厨继续准备后面的菜，陆续上菜(不断迭代，不断测试)
上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了(敏捷的好处，可以不断测试和需求变更)
又上了两盘，不够辣，又拿到后厨加了辣(敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量)
到最后两盘时，客人要求换两个菜，还好没炒(迭代的好处，随时接受需求变更)客人吃完，很满意(基本满足了全部的要求)
瀑布模型开发
客人到餐馆来点菜(新项目)
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
根据图文菜单，客人点了十个菜(根据原型和设计稿，基本确定了需求)
后厨开始准备(项目启动)
根据客人的下单配菜，炒菜(基本上不会主动去了解完整需求)
半个小时了，菜还没上桌，客人饿极了(项目启动后很长一段时间客户什么都看不到)
再过了二十分钟，十个菜都一起上来了(项目最终一次交付)
客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉(我是买单的，我要变需求)
这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”(瀑布的坏处，需求变更比较麻烦)
于是，后厨只给客户加了盐，加了辣
客人吃完，不是很满意，下次不来了(没有满足需求)
总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。
在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用。
最后一句话送给大家：少研究一些主义，多关注一些实际问题。
更多项目管理文章，敬请关注立智教育集团