锁定老帖子 主题:敏捷开发和瀑布开发的混搭
精华帖 (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个阶段的开发人员,在开发阶段基本不会去看前期的输出,但实际编码的又是这些人,这样前期的工作意义又被削弱了 总之,我觉得还是我以前那个公司,开发流程更像真正的敏捷。虽然没有站立会议、结对开发这种手段上的东西。但是出可运行交付的周期更短,用户可以更快的反馈结果,浪费在需求分析和设计阶段的时间更少 不过。。。体验一下现在这种流程也不坏,有比较才有想法嘛~~ 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2011-08-24
很好的文章。作者有想法。
|
|
返回顶楼 | |
发表时间:2011-08-27
FDD(靠,就想输入FDD还嫌短,JE的判断能不能智能点)
|
|
返回顶楼 | |
发表时间:2011-08-27
莫非是华为?
|
|
返回顶楼 | |
发表时间:2011-08-28
个人觉得敏捷和混搭是非常不错的,光敏捷陈本太高,光瀑布确实也太多冗余。
应该是瀑布为主,冗余为辅助。 你们觉得呢。 |
|
返回顶楼 | |
发表时间:2011-08-29
非常好的案例,值得深思其经验教训
|
|
返回顶楼 | |
发表时间:2011-08-29
最后修改:2011-08-29
karisen 写道 kyfxbl 写道 现在这家公司的开发流程很奇怪,和以前的公司很不一样
一、首先拿到一个客户需求,这个客户需求(OR)可能就只有一句话:“做XXXX运维成本太高了,管理也很混乱,能不能给做个管理系统给控制一下” 由于这个客户很重要,所以虽然需求很不明确,连系统该做成啥样都不知道,但是领导还是决定要做。于是项目组就启动了。这个时候所有已知的东西,就只有这个一句话的OR 二、第一阶段,叫Chart开发,这个阶段找了很多业务专家,以及有现场运维实际经验的人来。一边猜想,一边问。这个阶段主要解决以下问题: 1、这个系统做出来要解决什么问题2、这个系统大概是啥样的3、这个系统做出来以后,用户要怎么用 然后这个阶段项目组分成3个小组:“业务分析组”、“竞争分析组”、“技术预研组”,来并行工作。业务分析组就是和业务专家在一起,“猜测”系统应该是怎么样的,回答前面的3个问题。 …… …… 六、总结,个人感觉,这个开发流程,前面是瀑布,后面是敏捷,我猜到了开头,却猜不到结局。。。 1、前面花了很大的力气(至少3个月),进行需求分析和设计,但是这个需求分析和设计的结果,往往在开发阶段发现有很多问题,部署后用户表示和最初的想法有差距 从你的描述中,所谓的第一阶段 就迷失了方向,必然造成后期 更大更多的需求变更,甚至都无法完成交付,增加了运维成本。从立项到第一版本的交付仅仅占整个生命周期的很小一部分,大部分工作都是在维护。 1、要进行需求调研,进行业务建模,而不是系统建模。 2、对于项目而言,我所理解的业务专家 是指客户,即最终使用系统的人,没有比客户更懂得系统的业务用例了;而懂得相同业务或行业的专家,属于同行专家范畴。 3、从一开始就规划系统,让所谓的业务专家参与“猜测”系统,这些人一般非技术出身,对于看不见摸不着的系统抽象实在是有限,当然了 客户相信 所谓的专家研发团队的能力,懵懵懂懂的:是的,我们是要这样的。结果最后研发团队交付了一个看得见用得着的系统时,客户可能会说:这个系统与我们想象的还有些差距。甚至会说:哦,不,这不是我想要的系统。 |
|
返回顶楼 | |
发表时间:2011-08-29
菜菜土人 写道 个人觉得敏捷和混搭是非常不错的,光敏捷陈本太高,光瀑布确实也太多冗余。
应该是瀑布为主,冗余为辅助。 你们觉得呢。 瀑布和敏捷 均适用于 中小规模的系统 |
|
返回顶楼 | |
发表时间:2011-08-29
karisen 写道 菜菜土人 写道 个人觉得敏捷和混搭是非常不错的,光敏捷陈本太高,光瀑布确实也太多冗余。
应该是瀑布为主,冗余为辅助。 你们觉得呢。 瀑布和敏捷 均适用于 中小规模的系统 我不这么认识,那大项目用什么呢 ? 你说来听听。 平安保险业务平台算不算大系统? 阿里巴巴B2B算不算大系统?电信BSS算不算大项目? 这么这些平台都该怎么管理呢,或者你认为这些都是中小规模的 ? |
|
返回顶楼 | |
发表时间:2011-08-29
karisen 写道 菜菜土人 写道 个人觉得敏捷和混搭是非常不错的,光敏捷陈本太高,光瀑布确实也太多冗余。
应该是瀑布为主,冗余为辅助。 你们觉得呢。 瀑布和敏捷 均适用于 中小规模的系统 我想请教2个问题: 1、你认为什么才是“大规模”系统? 2、“大规模”系统又是走的什么开发流程呢? |
|
返回顶楼 | |