敏捷开发

责编:menVScode 2019-07-01 17:48 阅读(131)

很多IT公司的现状,大量的加班,做出来的产品又不见的有人会买单,大量的工作产出没有价值或价值很低。

敏捷思维的理论是:用最少的output(产出),获得最大的outcome(成果)

在一个sprint(迭代)过程中,进行Sprint Review Meeting(迭代评审会)时,不是所有的output都会被PO(product owner)或者利益相关方认为是outcome。

这个时候,我们要注意价值的识别,要聚焦,要用最少的output来获得更多的outcome。

千万不要期望,用大量的output堆出outcome来,知道吗,996都是这么来的。


做减法、做减法、做减法……

假设你的游轮即将沉没,你必须乘坐救生船到一个荒岛上,只能随身携带3件物品,你必须立即作出决定!

相信很多人的答案都是:淡水、食物、求救工具。

我们都知道金银财宝此时毫无价值,那为什么不是药品、被子、衣物呢?

因为,这不是最重要的!

利用敏捷的思维,一定要善于做减法,懂得取舍。碰到任何的情况,都要问自己,这件事情(用户故事、活动、文档等)有价值吗?在我的价值排序中,它是靠前的吗?

是!那就努力的达成目标。如果不是!不要犹豫,把它扔到你再也无法找到的地方,然后,下班,约会去。


敏捷开发&瀑布模型开发例子

【敏捷开发】

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

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

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

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

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

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

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

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

到最后两盘时,客人要求换两个菜,还好没炒(迭代的好处,随时接受需求变更)

客人吃完,很满意(基本满足了全部的要求)

【瀑布模型开发】

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

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

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

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

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

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

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

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

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

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

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

标签: 敏捷开发 敏捷
前端交流群: MVC前端网(menvscode.com)-qq交流群:551903636

邮箱快速注册

忘记密码