庄周梦蝶

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

说说迭代中的需求变更（更正）

Posted on 2008-04-28 21:04 dennis 阅读(1717) 评论(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天。

只有注册用户登录后才能发表评论。
网站导航: