论坛首页 综合技术论坛

敏捷开发和瀑布开发的混搭

浏览 10844 次
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2011-08-24  
现在这家公司的开发流程很奇怪,和以前的公司很不一样

一、首先拿到一个客户需求,这个客户需求(OR)可能就只有一句话:“做XXXX运维成本太高了,管理也很混乱,能不能给做个管理系统给控制一下”

由于这个客户很重要,所以虽然需求很不明确,连系统该做成啥样都不知道,但是领导还是决定要做。于是项目组就启动了。这个时候所有已知的东西,就只有这个一句话的OR

二、第一阶段,叫Chart开发,这个阶段找了很多业务专家,以及有现场运维实际经验的人来。一边猜想,一边问。这个阶段主要解决以下问题:
1、这个系统做出来要解决什么问题
2、这个系统大概是啥样的
3、这个系统做出来以后,用户要怎么用

然后这个阶段项目组分成3个小组:“业务分析组”、“竞争分析组”、“技术预研组”,来并行工作。业务分析组就是和业务专家在一起,“猜测”系统应该是怎么样的,回答前面的3个问题。竞争分析组把同类的产品拿来看,自己边用边分析,其实就是模仿。技术预研组则是把有风险的技术先研究研究,免得到时候做不出来

这个阶段结束以后,输出了一堆文档。最重要的就是一个叫“包需求”的东西。把前面的一句话OR扩大了很多,变成一个很长的需求列表。这个输出是后面所有工作的起点。

我感觉这里就有点问题了:
1、为啥叫包需求,我看了这么多书,就没见过有这么一个名词,再说也很难听
2、这个包需求,根据多个项目的经验,相当不准确。遗漏或者瞎猜的情况很严重

三、不管怎样,然后就进入第二阶段了。这个阶段叫“需求分析”,但是分析的不是原始需求了,而是上个阶段输出的“包需求”。这个阶段把包需求分解了,也加了很多人进来。每天大家就对着包需求“想象”场景,输出“场景分析”,这个场景分析之后,又把包需求分解成了一大堆“设计需求”(DR),这个DR也是一个长长的列表,作为下一阶段工作的起点

我感觉这里又有问题了:
1、本来包需求就是有偏差的,经过进一步想象,或者说瞎猜,这一阶段输出的设计需求,已经和原始需求有了更大的偏差
2、很多人没有经历过上一阶段,在这个阶段空降加入,效率很低,沟通成本很高
3、实际的开发人员到这个阶段还是没有全部参与,这个阶段的输出传递会有问题

四、不管怎样,接下来该进入第三阶段了。这个阶段的起点就是上个阶段的“设计需求清单”,这个阶段叫“设计阶段”,把设计需求,再进行一个“概要设计”,最后输出一个“用户故事清单”(Story List)。好吧,敏捷开发的名词终于出现了,在经过了这么久的瀑布之后。。

五、然后进入了迭代开发阶段,这个阶段才开始实际编码。工作的起点是上个阶段输出的“Story List”,每个开发小组对Story进行迭代的简单设计、开发、测试、集成测试。这个阶段有点像敏捷开发了,包括站立会议、持续集成、交叉检视等等手段都会引进来

六、总结,个人感觉,这个开发流程,前面是瀑布,后面是敏捷,我猜到了开头,却猜不到结局。。。
1、前面花了很大的力气(至少3个月),进行需求分析和设计,但是这个需求分析和设计的结果,往往在开发阶段发现有很多问题,部署后用户表示和最初的想法有差距
2、前期的工作成果,传递得很不好,没有参加前3个阶段的开发人员,在开发阶段基本不会去看前期的输出,但实际编码的又是这些人,这样前期的工作意义又被削弱了

总之,我觉得还是我以前那个公司,开发流程更像真正的敏捷。虽然没有站立会议、结对开发这种手段上的东西。但是出可运行交付的周期更短,用户可以更快的反馈结果,浪费在需求分析和设计阶段的时间更少

不过。。。体验一下现在这种流程也不坏,有比较才有想法嘛~~
   发表时间:2011-08-24  
很好的文章。作者有想法。
0 请登录后投票
   发表时间:2011-08-27  
FDD(靠,就想输入FDD还嫌短,JE的判断能不能智能点)
0 请登录后投票
   发表时间:2011-08-27  
莫非是华为?
0 请登录后投票
   发表时间:2011-08-28  
个人觉得敏捷和混搭是非常不错的,光敏捷陈本太高,光瀑布确实也太多冗余。

应该是瀑布为主,冗余为辅助。

你们觉得呢。
0 请登录后投票
   发表时间:2011-08-29  
非常好的案例,值得深思其经验教训
0 请登录后投票
   发表时间:2011-08-29   最后修改:2011-08-29
karisen 写道
kyfxbl 写道
现在这家公司的开发流程很奇怪,和以前的公司很不一样

一、首先拿到一个客户需求,这个客户需求(OR)可能就只有一句话:“做XXXX运维成本太高了,管理也很混乱,能不能给做个管理系统给控制一下”

由于这个客户很重要,所以虽然需求很不明确,连系统该做成啥样都不知道,但是领导还是决定要做。于是项目组就启动了。这个时候所有已知的东西,就只有这个一句话的OR

二、第一阶段,叫Chart开发,这个阶段找了很多业务专家,以及有现场运维实际经验的人来。一边猜想,一边问。这个阶段主要解决以下问题:
1、这个系统做出来要解决什么问题2、这个系统大概是啥样的3、这个系统做出来以后,用户要怎么用
然后这个阶段项目组分成3个小组:“业务分析组”、“竞争分析组”、“技术预研组”,来并行工作。业务分析组就是和业务专家在一起,“猜测”系统应该是怎么样的,回答前面的3个问题。

……
……

六、总结,个人感觉,这个开发流程,前面是瀑布,后面是敏捷,我猜到了开头,却猜不到结局。。。
1、前面花了很大的力气(至少3个月),进行需求分析和设计,但是这个需求分析和设计的结果,往往在开发阶段发现有很多问题,部署后用户表示和最初的想法有差距



从你的描述中,所谓的第一阶段 就迷失了方向,必然造成后期 更大更多的需求变更,甚至都无法完成交付,增加了运维成本。从立项到第一版本的交付仅仅占整个生命周期的很小一部分,大部分工作都是在维护。

1、要进行需求调研,进行业务建模,而不是系统建模。

2、对于项目而言,我所理解的业务专家 是指客户,即最终使用系统的人,没有比客户更懂得系统的业务用例了;而懂得相同业务或行业的专家,属于同行专家范畴。

3、从一开始就规划系统,让所谓的业务专家参与“猜测”系统,这些人一般非技术出身,对于看不见摸不着的系统抽象实在是有限,当然了 客户相信 所谓的专家研发团队的能力,懵懵懂懂的:是的,我们是要这样的。结果最后研发团队交付了一个看得见用得着的系统时,客户可能会说:这个系统与我们想象的还有些差距。甚至会说:哦,不,这不是我想要的系统。




0 请登录后投票
   发表时间:2011-08-29  
菜菜土人 写道
个人觉得敏捷和混搭是非常不错的,光敏捷陈本太高,光瀑布确实也太多冗余。

应该是瀑布为主,冗余为辅助。

你们觉得呢。


瀑布和敏捷 均适用于 中小规模的系统
0 请登录后投票
   发表时间:2011-08-29  
karisen 写道
菜菜土人 写道
个人觉得敏捷和混搭是非常不错的,光敏捷陈本太高,光瀑布确实也太多冗余。

应该是瀑布为主,冗余为辅助。

你们觉得呢。


瀑布和敏捷 均适用于 中小规模的系统


我不这么认识,那大项目用什么呢 ? 你说来听听。

平安保险业务平台算不算大系统?  阿里巴巴B2B算不算大系统?电信BSS算不算大项目?

这么这些平台都该怎么管理呢,或者你认为这些都是中小规模的 ?
0 请登录后投票
   发表时间:2011-08-29  
karisen 写道
菜菜土人 写道
个人觉得敏捷和混搭是非常不错的,光敏捷陈本太高,光瀑布确实也太多冗余。

应该是瀑布为主,冗余为辅助。

你们觉得呢。


瀑布和敏捷 均适用于 中小规模的系统


我想请教2个问题:

1、你认为什么才是“大规模”系统?
2、“大规模”系统又是走的什么开发流程呢?
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics