一场误会

Standing On Shoulders of Gaint

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
                                                                             软件项目开发

                  ——管理措施

        最近老板让我做一个软件项目组的管理措施,搜集了多方资料和平时的一些经验得出以下的一些知识:
        在一个软件产品发布并使用之后,其中肯定有许多地方不如意和值得改进的地方。客户在使用的过程中会发现一些问题,提出更高的需求,市场也在发生变化,我们的竞争对手也在发展,新的技术不断地产生,这些因素推动着我们的产品不断地向前发展,使软件版本不停地往上增长。这些发展的需求不是一下子提出来的,在客户使用的过程中发现某些不如意不方便的地方,他们会向我们提出宝贵的意见,而技术人员会把这些需求记录下来,以便修改或成为下一个版本的新特性或需求。

一个软件的开发主要分为需求、设计、编码、测试、维护几个重要的阶段,下面就每个阶段的一些管理措施提点愚见:

1.    需求管理

在进入正式开发之前,必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。在软件项目的开发过程中,需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能 ,优化性能,提高用户友好性的要求。在软件项目管理过程中,项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,项目研发人员的士气将越来越低落,将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

在整个开发周期中期望用户的需求一直保持不变是不大可能的因为用户对于如何应用计算机软件并没有一个成熟的经验。需求变化的原因很多,如:  

  一开始没有调研全,需要增加需求; 

  客户需求发生了变化,需求必须变化; 

  需求错误; 

需求不清楚。

基于上述的问题,必须对需求进行管理,使需求能够真正成为软件工程和管理的基线。 一种比较明智的方法是在签定开发合同(协议)时把用户需求的改动和经济利益挂钩,如果用户增加或改动了需求,那么软件的交付日期可以推迟,费用也应增加。 

需求是一项复杂的工作,使用的方法也很多,不同的开发方式有不同的方法,这里简单介绍一些相关的方法:  

可行性分析:在允许的成本、性能要求下,分析每项需求实施的可行性,提出需求实现相关风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。  

快速原型:当用户自身对有的需求不十分清楚时,我们可以建立一个系统原型,用户通过评价原型更好地理解所要解决的问题。  

图形分析模型:绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系,找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。  

数据字典:数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项,确保客户与开发小组是使用一致的定义和术语。   

2.   设计管理

项目经理把功能模块分配给每个开发人员,每个开发人员把自己相关的功能模块收集起来,同时预估时间,其中主要包括写文档的时间、开发时间和单元测试的时间,一般要求精确到工作日。这些信息返回给项目经理,项目经理再把本小组人员的任务和预估时间发送给管理层,由管理层对此任务及进度进行评估审核,管理层会根据产品发布时间及客户需求、市场因素等方面作出选择,可能某些功能由于时间紧急会被推迟到下一个版本中去。若预估出来的时间同预计的产品发布时间有较大冲突,而且此功能是本版本中必须得做的,则开发小组会被要求重新预估时间,加快开发速度来达到这个要求。

虽然这个开发进度时间是一个大概的估计时间,但我们要尽力按照这个开发进度来执行。作为开发人员每个星期写一篇周记,描述自己本周所做的工作,根据自己的描述来评估我们自己的工作,每个人手上的工作是否按照这个进度在走,是否有人延后了,是否延误了别人的工作。在周记里每个人都要报告自己的进度,同时还要报告上个星期做了什么,正在做什么,以及下个星期打算做什么。通过这个周记,会让你觉得有人在监督你,无形之中迫使你不断地督促自己不要使任务延后,如果有延后的迹象也会尽早发现而赶上。若某些经过努力不能赶上,那也没有办法,只能修改原先的进度表,因为那是我们的估计与现实发生了偏差,我们必须使我们的进度表符合实际情况。

3. 编码管理

进入编码工作之后,可能会发现前面分析或设计阶段的某些错误,这时应返回到前面的阶段进行必要的修改。由于我们用asp.net(c#)语言进行开发,因此我们借助了VS2005工具。关于代码风格,我们基本上套用VS2005中自动的代码格式编排。良好的编码习惯有利于我们提高整个团对的开发效率,比如变量的命名、写代码时要对类及函数提供详细的注释及说明等,基本做到看它们的说明就能知道这个变量、类或函数的功能以及主要算法的实现原理。在开发过程中对主要的模块要编写单元测试,同时要单元测试先行,当所有的单元测试代码通过时,此功能也就基本上完成了。

我们采用VSS进行代码管理控制,其中存放了此产品的所有源代码,各个部分存放在不同的目录中。每天早上要求开发人员从VSS中获取最新的源代码,然后进行编译并开始一天的工作。在下班之前理论上要求员工签入所有当天修改的代码,在签入之前要保证编译是能通过的。若有谁签入的代码导致运行失败则会被要求某些惩罚措施或警告。有时我们编写的代码涉及到多个文件,而且此改动是比较复杂需要花费多天的工作量,如果现在签入进去可能会导致项目测试通不过,因为有些代码没有完全完成,而之前的代码能测试通过,而且这些代码基本上不会涉及到他人,在这种情况下可以不签入进去,直到全部代码完成能提交测试时再一起签入进去。

我们的开发是基于网络的,在互联网高速发展的今天,代码的安全也是一个不容忽视的问题,我们要注意代码的泄漏和丢失,除了掌握一些基本的安全知识以外,还要进行代码的备份(局域网备份和存储设备备份),这样在出现意外的情况下可以及时的恢复系统的正常运行。

4.   测试管理

在开发人员完成了功能模块后,测试人员开始了测试规划,确定需要测试哪些方面,如何测试及进度安排。测试人员需要写许多测试用例、测试报告等,有些测试代码需要集成测试,有些可能需要进行单独的测试,目的都是为了使产品符合要求,使开发人员容易找出问题所在并改正。产品功能是否符合了要求,是否能被发布是由测试人员决定的,因此测试人员也比较辛苦,责任重大。通过了每天的测试,还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。在完成这些测试之后由测试人员决定本产品是否能发布出去了。

由于我们每天进行着测试,因此经常有BUG被测试人员发现,一旦发现了新的BUG,就会被添加进测试报告中,同时注明紧急程度,以便开发人员可以及时进行错误BUG的修改。需要指出的是我们对BUG的定义比较广泛,一些新功能也可以作为BUG被提出,只不过这些BUG级别比较低,让它们进入到下一个版本中去实现。因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身,因为他可能会找出一些BUG,有些是其他开发者的,有些可能是此开发者本身的,把这个BUG添加进测试报告中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路。

5.   维护管理

后期的软件维护和管理也是一个非常重要的任务。定期的升级服务和培训会让客户对软件有个良好的映像。

6. 组织(团队)管理

软件项目开发过程中注重的是团队精神的发挥,我们的目标是一个软件、系统而不是几个模块的简单组合。在软件开发管理中,不能采用明令制度的方式来要求何限制开发人员,必须要有办法激励人的内动力,而激励人的内动力最好的办法是将付出和收益紧密的结合。团队精神的凝聚主要的是信任与尊重。正所谓“用人不疑,疑人不用”,如果没有基本的尊重与信任,哪里来的凝聚力,何谓团队精神?

软件项目开发人员应该本着态度第一、效率优先的工作原则,在平时的日常工作和生活中,大脑的休息和充足的睡眠可以保证开发人员有个良好的心态和精力。也许在IT行业来说,程序员加班已经成为一种佳话,一种习俗,但我们要制止长期的加班和无效率的加班,在项目不紧张或者无项目的情况下可以适当的放松、休息来调节个人的情绪和精力。

作为软件开发人员的大部分时间是在公司里度过的,因此公司的生活成了大家主要组成部分。员工之间关系的融洽,交流的畅通显得非常重要,同时大家也不想自己的生活这样枯燥乏味,一直同机器打交道。沟通无处不在,交流随时发生,有许多关系是在工作之外建立起来的。软件公司内是很容易产生各种矛盾的,因为这是由你的工作性质所决定的,比如测试人员或用户会对你的实现不满意,提出各种要求时,我相信你有时会有所抱怨的,无形之中就产生了对立,发展到后来会有抵触心理。我相信大部分人都会有此感受,这不是你的错,这主要是由我们的工作性质决定的。如果你的工作是把财富带给对方,则对方会非常欢迎你的到来,把你奉为财神爷来对待,同你的关系会非常融洽友好。因此我们需要在工作之外来消除这种对立矛盾的关系,建立一种融洽的工作氛围。我们在平时吃饭的时候饭桌上大家互相聊天沟通,说一些幽默笑话之类的,给我们紧张的工作增加点轻松的氛围。隔断时间大家可以组织一下活动,增加了公司的凝聚力。一个产品发布后组织一次活动,让绷紧的神经松弛一下,更好地迎接下一个挑战。

团队的每个成员都会养成写Blog的习惯。经常写写Blog,一是可以让大家都知道自己在做什么事情,二是项目结束时方便写最后的工作总结(许多工作自己当时不纪录也忘记了),三是利于提高自己的水平(工作和学习写点总结会系统的总结和归纳思路,进步很快)。

附件:

1.              C#编码规范.doc

2.             个人周记.doc

3.             项目组周报.doc

4.             项目总结报告.doc

5.             测试文件.xls
项目附件下载

posted on 2007-03-16 13:22  一场误会  阅读(2322)  评论(3编辑  收藏  举报