庄周梦蝶

生活、程序、未来
   :: 首页 ::  ::  :: 聚合  :: 管理

说说迭代中的需求变更(更正)

Posted on 2008-04-28 21:04 dennis 阅读(1718) 评论(4)  编辑  收藏 所属分类: 软件工程
    我们现在做的项目是典型的小型项目,整个组也就4、5个人,一个迭代周期基本在两周左右。尽管没有明确有“迭代”这么说法,却是以业务人员的策划案做分期实现。这个分期,按我的理解其实就是迭代。最近发现的一个问题是,在迭代开始后,业务人员却没有办法保证需求在这个迭代周期完成前的稳定性,甚至在各个模块集成之前,大家就提出N多意见,并且这些意见很多时候都是前后矛盾的。特别是在客户端的开发上,显然,客户端UI和操作习惯方面是最多变的地方。可怜我们公司唯一的MM程序员快陷入变更频繁的泥潭了,改过去改回来是家常便饭。其实也是她过于老实,要我来说,你们要改,可以,但是我要向业务人员确认,他是我唯一的变更来源,你们有什么需求向他反应,他来收集和甄别。在《敏捷软件开发》中说到,迭代开始后,客户就同意不再更改当次迭代中的素材的定义和优先级别,可惜这一点貌似很难做到了,业务人员经常屈从于管理层或者其他小组意见的压力。在我看来,在当次迭代完成前的所有建议或者说需求,都可以收集起来,由业务人员负责收集、甄别和决定,放入下一个迭代版本的开发,因为我们的迭代周期一般也在两周左右,这个周期足够辨别这些需求的合理性和响应需求的及时性,而不是像现在这样大家七嘴八舌地提意见,技术人员疲于奔命,乃至于发脾气(入夏真是脾气坏的季节);系统各部分迟迟无法进行集成测试,造成新的修改意见没有做完,预定的迭代版本的更无法按时完成的局面。

评论

# re: 说说迭代中的需求变更  回复  更多评论   

2008-04-28 23:10 by wowhhz
业务需求不能完全按照客户的要求做,拿到需求后分析客户为什么有新需求,与之前的业务怎么融合,罗辑有问题的需求不要急着做,先放着,等想法成熟大家讨论后再行动,不然浪费时间.

# re: 说说迭代中的需求变更(更正)  回复  更多评论   

2008-04-29 08:50 by dennis
@wowhhz
您说的对,这个对需求的冷处理阶段相当重要。

# re: 说说迭代中的需求变更(更正)[未登录]  回复  更多评论   

2008-04-29 11:01 by test
大家怎么都碰这个问题呀,最近做了一个项目,做到最后发现需求就是个无底洞了。
没任何脾气了,从做这个项目我每天不停的加班做啊,改啊,客户的需求无止的变化,老板也在后面催啊,烦躁啊。特别是在做这个项目的日子里也发生了很多的事情,谈了几年的女朋友也因为打发牢骚说没什么关系她,也就跟我拜拜了,很快她就找了个男朋友,我现在是每天忙着不停的一个项目又一个项目,一个需求又一个需求,大把年纪了啥都没有。
不知道是我自己的原因还是公司的原因还是客户的原因,怎么也做不完一个项目,发现项目就是做不完的。
真想改行不做了。

# re: 说说迭代中的需求变更(更正)  回复  更多评论   

2008-09-10 18:01 by 曾皓
我北大青鸟毕业,第一次做个大点的项目,也就100多万点的。我们天天改功能,客户天天提需求,改回来了,改过去了,基本上一个功能改个3遍以上,我项目经理不敢反驳客户的观点,客户怎么说,项目经理就叫我们技术人员怎么改,所以,但我们改了4个多月的时候,终于有人受不了辞职了。。。还有,这是现场开发,客户天天对你指手画脚的,有时候还骂你听不懂他说的话(他是个处长哦,把我们程序员都当手下使唤了),大半年了,只休息了1天。

只有注册用户登录后才能发表评论。


网站导航: