首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

干项目太累,那是因为你姿势不对

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

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

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

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

1区:Simple

需求很明确,使用的技术也很确定。这类项目就是简单的项目(Simple)

甲方需要什么我们很清楚,我们怎么做也很清楚。

比如注册一个新公司,需求很明确,手续也很清楚,就那么几步规定动作,因此大量代理机构都可以帮你完成这个项目。

既然需求明确,怎么实现也清楚,最好提前把计划做到位,预测型,也可以成为“瀑布型”开发模式最适合。

2区:Complex

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

也就是说怎么实现不知道,这类项目叫复杂的项目(Complex),也叫棘手的项目。

比如,无人驾驶,这项目需求明确吧?

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

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

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

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

3区:Complicated

技术很确定,需求却不明确,这类项目是烧脑型的项目(Complicated)。

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

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

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

客户懵圈了。

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

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

4区:Chaotic

需求不清楚,怎么实现也不清楚,这叫混乱状态的项目(Chaotic)

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

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

5区:Hazy

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

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

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

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

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

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

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

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

敏捷开发

客人到餐馆来点菜(新项目)

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

根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)后厨开始准备(项目启动)

配菜、炒菜,先上了两盘,让客人尝了尝味道(先提供可用实例给客户用)

客人说还不错,后厨继续准备后面的菜,陆续上菜(不断迭代,不断测试)

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

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

到最后两盘时,客人要求换两个菜,还好没炒(迭代的好处,随时接受需求变更)客人吃完,很满意(基本满足了全部的要求)

瀑布模型开发

客人到餐馆来点菜(新项目)

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

根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)

后厨开始准备(项目启动)

根据客人的下单配菜,炒菜(基本上不会主动去了解完整需求)

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

再过了二十分钟,十个菜都一起上来了(项目最终一次交付)

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

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

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

客人吃完,不是很满意,下次不来了(没有满足需求)

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

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

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20201222A0672400?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券