谈谈需求的变更
2013-04-01 09:46 麦舒 阅读(1697) 评论(4) 编辑 收藏 举报本来只想写一篇的,没想到写着写着就成了系列了。关于这个系列的前两篇文章:《谈谈项目的开发》《谈谈项目的执行》。在写这篇文章之前,先答复一些朋友的疑问,项目的开发,有没有必要到那以细呀?究竟有没有必要,见仁见智吧,毕竟每个管理者在管理时所面临的问题都是不同的。首先说说一名TEAM LEADER往往会面临到的问题吧:
1、保证项目的质量与可维护性。人员很多都是刚毕业的,编码的方法、变量命名都很不好。
举个例子来说,数学的大于用的单词是Bigger,很让人无语。看过我前面的文章都知道,我是很强调要多阅读代码的,如果你是经常阅读一些好的开源代码,是不可能出现这样的命名的。
2、提交的代码,看似完成,但是细节差得太远了。
比如说,TAB键的处理;ENTER键的处理;ESC键的处理;按钮的排列,哪些按钮的放右边,哪些按钮放左边;页面的边距等等这些细节。由于是新手,往往是会不注意这些的,所以必须明确下来,否则做出来的各式各样。
3、人员很不好管理。具体可以参考我前面的文章。
4、开发人员之间缺乏沟通,很多可以重用的方法,却各自都写一遍。
5、作为TEAM LEADER,要去阅读他们的代码,如果不知道问题的解决思路,阅读起来就要花费多时间。还有一个问题,就是新人的能力往往是比较欠缺的,以其在做的时候问,倒不如前事就告诉他们怎样去做。同时,也让他们有个准备,不致于按排的任务因为能力的原因而无法完成。
6、准确汇报项目的进度,每周都要向上汇报一次进度。
7、合理分配任务,协调好各人的开发进度。
由于以上几点,所以必须清楚项目细节,以便掌控整个项目开发,往着自己所期待的方法发展。
另外还有朋友问到的几个问题:
1、关于接口的细节制定:由TEAM LEADER来制定。
2、关于接口的变动。一般都是由于设计的时候没有想好,或者需求的变更。关于需求变更引起的变化后面再讨论。由于设计的不足,队员在开发时候常会碰接口的参数不够,某些功能缺乏相应的接口,关于接口,还有参数,这个应该是在开发前,就应该讨论好,想好的。在后期需要变动,应该是比少。应该怎么变,需要些什么接口,如果队员已经知道是谁负责的,直接找相关人员。否则向TEAM LEADER汇报,再按排人员。由于变动的接口比较少,TEAM LEADER对整个项目还是在掌握中的。
关于需求的变更,这人是在每个项目开发的时候的都是会碰到的。一般来说,在对项目进行初期的分析调研后,或分成几个里程碑,每个里程碑都都要完成哪些内容。现在假定有V1,V2,V3…… 这些里程碑版本,其中V1是给客户演示的一个版本,V2是待演示的一个版本,V3是正在的开发的一个版本,其中演示版本和开发版本都好理解,为什么还要有个待演示版本呢?主要是避免当前开发版本出现意外,无法按时发布。
当我们接到需求变更的时候,应该极力避免接到一个需求变就立马修改代码这种情况。需求的变更设为三个等级,轻微、普通、来得。
1、轻微。一般指的是对之前所写的代码,基本上没有影响。比如说增加显示的字段。
2、普通。一般指的是增加一个功能,但是增加的功能和之前的代码没有太大的冲突,基本上通过增加表或者字段就可以实现。
2、严重。一般指的是流程的变更。就是之前的需求分析中,少了一个流程,或者流程错了。
当需求的变更只是轻微和普通的时候,还是按原来计划进行开发。在这个阶段中,接到的需求如果不是严重性的,都放到下一个版本去。在这个过程中,要做好设计方案 ,也就是说,要改哪些API,要怎么去改,和之前文章提到的基本上一样。对于需求的变更,尽可能采用批量修改的方式,而不是有一个改一个。主要是因为:
1、尽量给开发人员一个稳定感。避免他们因为频繁的修改而做出一些过激的行为。
2、这样做会有更有条理,不容易有遗漏。
当接到一个需求变更是属于严重等级,也就是说,对当前开发影响很大的,很多地方的代码都改动的。这个时候首先要做的就是设计了,然后进行讨论,和前面说的基本上一样。在开发之前,记录好当前已经完成的功能,还有未完成的功能。然后开一个分支,不要直接在原来的基础上改,否则哪天客户一拍脑袋,又要改回去,估计你会恨不得撞墙的。不知道你们有没有碰到过,反正我是碰到过的。开一个分支的好处是,在N个版本之后,客户说要改回去,可以把对应的版本找出来,进行合并。
这就是我对需求变更的处理。沟通是需要花时间的,但是我认为,总得来说,还是值得的。