软件开发模型之装修篇

软件开发模型之装修篇

 

经历了 N 次项目的 delay 和失望之后,经常反思,为什么我们会这样?为什么我们天天加班还会这样?为什么我们在借鉴了一堆先进的软件开发模式之后还是这样?为什么一群白领做出来的东西还经常让工人们挑出一堆一堆问题?难得这就是我们的宿命?

相信很多朋友都碰到类似的问题,很多时候我们把原因归咎到需求变更太大、项目进度太紧、项目组某某人水平不行、用的技术框架不对、项目经理的管理水平不行等等原因。诚然,上述因素对项目的最终产出物是有很大影响的,但是为什么需求变更了对项目的进度和成果会有这么大的影响?为什么项目进度可以在与客户、与领导协商的时候可以不断地被压缩、很难科学地评估项目的进度?为什么项目个体的水平对整个项目影响会很大?为什么我们要等到 deadline 的时候突然意识到我们有如此之多的问题?

最近很多朋友在讨论买房、装修的问题,我才突然意识到,与建筑行业相比,我们软件工业还处于非常原始的阶段。建筑业中上百人的施工工地可以井然有序,而我们软件工业中到了几十个人的项目团队的时候就出现这样那样的问题;反而是一些小项目, 3 4 个人做出了的产品可以受到客户的好评,但是 3 4 个人作坊式的工作方式建不了鸟巢、水立方。 我们生活的房子,从通常意义上来说,大概经历了市场调研、设计规划、地基、建设、装修、物业服务 6 大阶段;比较瀑布模型需求分析、设计、实现、测试、安装、维护的 6 个阶段,我们缺少装修的这么个阶段,有过装修经历的朋友应该都知道,装修不是一个简单的几个星期就可以完成的工作;比较 XP 的简单需求调研,简单设计,回馈,重构的开发模型,我们发现 XP 对开发人员的要求非常高,类似于要求建筑业的民工既要懂图纸设计、又要懂地基怎么样才能牢固、还要懂室内装修设计等等,从这个意义上来说,我们的 XP 出来的软件产品基本上可以到达名家大师的全手工别墅的档次,离工业化的道路还很远很远。

瀑布模型已被很多案例证明在需求分析方面存在比较大的问题,通常客户一开始只知道我要这么个东西,并不能精确地描述他们需要的究竟是什么。这样导致我们的需求分析阶段非常长,比较规范的做法最后可能一个小系统会产生上百页的需求文档,并且在软件原型基本完成的时候可能又会有比较大的调整。然后就是设计阶段,也非常冗长,详细到类、方法等等,这两个阶段占用项目的大约一半的时间,最后留给开发的时间、测试的时间还不到 50% 。参考建筑业的周期,实际上最长的时间段是建设和装修阶段。市场调研和设计很重要,但是基本上只到了平面图、预算、工期的规划等问题,除了样板房,不会把家里电视背景墙是什么样,沙发用什么等等考虑进去,这些都是后续在装修阶段通过装修公司与业主沟通后才确定,开发商交给我们大部分时候都是毛胚房。这样做的好处是把能够工业化,批量生产的部分和需要客户参与定制的部分分离开来。

软件业能不能参考这个模式?把建设和装修阶段分离开,形成以下阶段:

1) 相对比较简单的需求调研,确定客户基本的需求;

2) 相对简单的设计规划,制定项目的规范、整体模块划分和要求(类似于建筑的户型)、对外的接口(类似与建筑的电梯、水、电、气等)和项目的进度预算;

3) 编码阶段,编码阶段的产物应该是稳定的、健壮的、具有良好扩展性的实现了基本功能的产品(类似与框架结构的房子,而不是砖混结构的房子);

4) 装修阶段,用户参与的,进行产品定制、用户体验的相关的开发和完善;

5) 后期维护阶段

通过上述阶段的划分, 1 2 3 阶段的进度是可控的,并且第 3 个阶段的工作应该是可以工业化的,不需要太多的用户参与过程,第 4 个阶段需要与用户密切配合。

 

 

( 未完待续 )

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值