小软件项目开发的管理

一起学习

小软件项目开发的管理 　　一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人 的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项 目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别 ，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。 一、小项目的特点 　　大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目 相比之下，具有以下特点: 　　1.项目功能相对较少 　　2.开发人员较少 　　3.开发周期较短 　　另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员 流动性较大，这也是不容忽视的一个现实. 二、小项目开发中常犯的错误 　　小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实 这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误: 　　1、开发之前没有认真地进行项目可行性和工作量的估计。 　　往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度， 结果实际完成时间与估计完成时间往往有较大差别。 　　2、没有真正的设计过程 　　开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味 着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几 个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有 一份较正式的文档。 　　这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承 认人是会犯错误的)。一个误解可能造成以后的返工。 　　另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于 自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一 个负责协调的人员不断监控整个开发过程。 　　第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理 解以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升 级都比较困难。 　　3.不经过单元测试而直接进入系统测试 　　造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一 些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数， 需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直 接用真正的数据来运行几次就行了。 　　殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模 块间的调用关系，可能查了很久才发现是某个模块的问题。这种方法一来效率比较低， 大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系 统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边 界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一 下边界测试，就会很容易消除一些隐患。真可谓欲速则不达也。 三.合理的开发流程 　　合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开 发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的 一些特点，实行起来可以相对灵活些。 　　以下我从几个方面描述一下我认为比较合理的模式. 　　1.需求获取 　　在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是 很必要的。 　　软件项目可以大致分为专用软件和通用软件两大类。 　　对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完 成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。 　　但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比 较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有 好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那 么必然造成时间上的浪费。 　　对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑 ，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软 件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络 ，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。 　　为了比较好地与用户进行交流，使用一些工具是很有好处的。 　　为了讨论用户界面，可以用VB, delphi等做一个原型，根据原型有针对性地与用户 讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作 为下一步开发的基础，增量式地完成开发) 　　为了讨论软件运行的流程，可以采用UML的Use Case图。 　　2.需求分析 　　在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行 的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整 个系统。 　　这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系,可 能需要不断修改而形成一份分析文档。 　　我想强调几个问题。 　　一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能，而 问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成 ，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那 么，"程控机"在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的， 仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一 些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新 的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内 容必须在分析文档中有一些说明，作为系统的外在约束。 　　二是需求获取与需求分析的关系。 　　用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。 　　例如当初采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个 实体，就是一个个类。 　　三是分析与设计过程的衔接。 　　分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编 程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向 对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分 析和设计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。 　　对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这 样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或 者采用其他的平台时，便可以以这份分析文档作为开发的基础。 　　对于需求变化频繁的项目，可能采用少量分析->少量设计->少量编码->测试的方式 更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一 份完整的分析文档。 　　现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对 分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。 　　3.设计过程 　　设计阶段的工作包括: 　　对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可 能是编程环境的要求，或者为了重用以前的某些工作。 　　定义界面部分、数据访问(数据库)部分。 　　由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编 码阶段来完成。于是设计阶段的工作量并不大。 　　4.编码 　　进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前 面的阶段进行必要的修改。 　　5.测试 　　如前所述，即使是小项目，也应该严格地进行测试。 四、人员的安排 　　比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。在这几 个人中，有一位项目负责人，负责分析、设计和协调的工作。由于项目小，项目负责人 也要参加编程,那么这人必须把时间合理运用， 　　经验告诉我几条原则: 　　1.协调几个人的工作比自己完成一段编码更重要. 　　由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发 人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。 　　只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。 　　2.给每个开发人员明确的任务书. 　　不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系 统。但是，具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确 的文档来表示。 　　3.让大家都大致熟悉设计模型. 　　让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会 发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。 Microsoft 的软件开发--快照 //摘自《开发过程调试技术》（《Debugging the Development Process》 Steve Maguire著 岳晋生 等译；电子工业出版社 ISBN 7-5053-3067-5）一书，讲述了微软管理软件项目的经验，是一本很有参考价值的书。 本书中的大多数例子来自我在Microsoft的经验。对于Microsoft 公司里如何在主管人员之间划分责任进行一个简短的描述以及一个典型项目如何进行的概貌可能会帮助读者理解这些例子的背景. 一个Microsoft的项目一般至少有三种不同的主管人员直接为产品的开发而工作。 * 项目主管. 项目主管最终为代码负责。他或她也负责开发和监督进度，使项目按预定计划进行、培训程序员、为上层管理进行程序检查，等等。项目主管通常是小组中最有经验的程序员 并且常写代码，但只是把这当作第二手的工作. * 技术主管. 技术主管是小组里的程序员之一,他比其他任何人都更了解产品的代码。技术主管负责产品的内容完整性，使所有的新功能都用脑中已有的代码来设计。他或她通常也负责确保项目的的所有技术文档是最新的: 文件格式文档、内部设计文档,等等。如同项目主管一样，技术主管通常是小组中最有经验的程序员之一. * 程序经理 程序经理负责协调同市场、文档、测试和产品支持等关系产品的开发工作。简短的说，程序经理的工作是监督产品--每件放在产品封装盒中的东西--的完成，并且是以公司希望的质量标准完成。程序经理通常同产品支持小组一起工作协调产品的外部beta版的发布，并同最终用户一起工作来看怎样提高产品。程序经理通常自己也是程序员，但他们的编程工作限于使用产品的宏语言（如果有的话)来编写“指南”(wizards)和其他有用的最终用户宏。不是别人，正是程序经理负责产品应是什么样的“构想”. "程序经理"的名字可能让人误解,因为它暗示程序经理在职位上高于项目主管、测试主管、文档主管和市场主管。实际上，程序经理是同其他主管位于同一层次的职位。程序经理的更适合的名字应该是“产品主管",因为程序经理负责确保产品的所有部分--不仅是代码--按进度完成并且是按可以接受的质量完成。 在一个典型的项目中，程序经理（如果项目足够大的话，则是经理）在前期同市场、开发和产品支持小组一起工作，提出产品的改进列表。在创建功能列表之后，程序经理撰写产品说明书，它详细描绘每项功能应该怎样提供给用户--例如，提供一个新对话框的绘制方法以及如何使用它,或是提供一个新宏函数的名字以及它的参数描绘。一旦产品说明书的草图完成之后，将把它传递给该产品涉及的所有小组，进行彻底的检查。一旦最终说明书确定下来，各小组就开始工作。 程序经理同时使用功能的实体模型来进行可用性研究，以确保所有这些新功能直观上同每个人开始想的那样易于使用。如果一项功能显得难以使用，程序经理建议对说明书进行修改。程序经理也为产品盘的样例文档和我前面提到的最终拥护宏而工作。当功能完成时,他或她将逐项检查一确保它满足交付产品的所有质量标准--特别是,功能在低档机上也有足够的活力。 开发工作继续向前,并最终到达一点，称之为“可视冰点”(Visual freeze),是指所有会影响显示的功能都完成了。一旦代码到达可视冰点，用户手册将用程序运行时的屏幕画面来写成。结果是,从该点开始，开发人员要小心不要以任何方式影响显示，从而是手册中的屏幕画面同程序运行时用户看到的画面保持一致。当然，程序员希望在所有代码完成后在截取屏幕画面，但是手册需要很长的时间，在代码完成之前必须送去印刷。在一些情形里，为了让所有功能及时达到可视冰点以便在产品发布时能准备好手册，程序员仅部分地完成功能--例如，显示一个无功能的对话框，只用于屏幕截取而不干别的事情。以后，程序员再返回来全部地完成它们。 一旦所有的功能完成之后--“代码完成”阶段--程序员将努力修正错误列表中的所有重大的错误，并做一些必要的功能上的改进。当代码最后准备交付时,项目主管或技术主管生成“金主盘”. 程序经理将金主盘送去复制生产，并将软件和手册、注册卡和其他东西一起装盒.稍稍压紧并包装之后，产品就准备好可以出售给用户了。我省掉了许多细节，但是这样简短的总体描述足以让你理解本书中偶尔出现的可能过于Microsoft化的例子的背景。 我也该指出，e--mail是Microsoft的生命血液，所有内部事务是通过e--mail进行的。并且，至少是在开发周期中，你必须真正有充足的理由才能用电话打断他人的工作。开发人员之间的大多数交流通过e--mail进行，以及在许多自发进行的大厅会议中进行。这种全体对打断他人工作的敏感性很好地说明了Microsoft的政策：给每个人一个带门的个人办公室。如果你在工作并且不想被打搅，你只要关上门就行. 做起来比听起来难 我最后担心的是,本书可能让人听起来似乎应用了它提供的所有建议后，一夜之间，能转变一个不完美的项目。你确实可以立即应用书中的许多技术和策略，可以很快取得效果；但是其他的--例如培训技巧--要花上一段时间才能有效果。如果你的小组现在出了问题，则不能指望读完本书一星期后就将项目扳转过来。以我的经验来说，扭转一个遇到麻烦的项目要两到六个月的时间，大多数的好转发生在头两个月里。然后，进一步的好转来得很慢并且幅度不大。 后记--关于领导的一句话 偶尔我会冒出这种想法，就是作为项目负责人，你不可能也永远不会成为小组的一部分，你总要高出一级,而对此你无能为力。在我自己的经历中，却并不如此。我曾经成为过许多小组的一员--既当负责人又做程序员--而且无一例外，那些凝成整体的小组总是这样一些小组，其项目负责人只是小组的另一个成员，而他碰巧要做些非编程的事情，也从来没有负责人要高人一等的感觉。 对于某些不了解美国橄榄球的人来说，四分卫相比于其它队员来说是个较高级的位置。不管怎么说，四分卫调配着每场比赛，四分卫是控制着球的焦点人物,在胜利后总是四分卫被别的队员抛起来。 四分卫可能显得比其它队员地位要高一些，但我们要了解得更清楚一点。四分卫队员是另一个队员而已，只不过碰巧承担某种独特的任务。一个有效的项目负责人同样如此。他或她应当明白，一个焦点队员并不比其他成员地位要高。 项目负责人只是另外一名成员而已，与其他队员一样，都有着自己独特的职责。 有成效的领导人明白每个小组成员在组里起着不同的作用，有些组员负责项目的数据输入部分,有些负责打印功能，还有的负责外部文件转换器和用户界面设计，负责人可能要象其他人一样实现某部分功能，但除此之外，他还有职责设定项目的目标和优先级,通知测试和市场这样的独立的小组该项目的进展情况，创造出一个小组成员能有效工作的环境，并保证小组成员不断学习新的技能，以这种方法增加对公司的价值。一个项目负责人可以做所有这些工作，而并不认为自己要高人一等。 如果项目负责人有了高人一等的态度，就会引发一整串有害的行为。这里列出的是极端情况下会发生的一些事情。 * 项目负责人将失败归罪于小组，而将成功据为己有。 * 项目负责人不关心组里的人员。他们只是些工人，谁又在乎他们每周工作80个小时呢?负责人只关心小组不能按期交货会使他脸上无光。 * 项目负责人希望小组成员对他唯命是从,从不对他的权威性表示怀疑。"我说了这么做，就这么做"是其座右铭。 * 急于显得自己在哪一方面都不比别人差,负责人会攻击那些威胁到他的权威和在某方面比他更有能力或知识更丰富的小组成员。 * 因为他必须永远正确，当他错了时,他从不承认。 * 项目负责人让每一个对开发过程提出改进意见的人闭上嘴巴，或是扰乱开发工作的顺利进行。 * 项目负责人以为自己是必不可少的人物. 当然，并不是所有那些认为自己高人一筹的项目负责人都这么专横，但即使是在较缓和的情形下，这种高人一等的意识也会流露出来。究竟小组成员是在为项目负责人工作，还是与项目负责人一起工作？项目负责人的言语就反映出了他的态度。 一个项目负责人如果把自己看作是小组的一员，就会工作得更顺利，因为他几乎不用花时间让那些组员摆正自己的位置--为什么他要这样呢？采取并不高人一等的态度，他就使自己不必要去对付那些对他权威的威胁。如果他在刚接手的小组里发现了一位超级明星，他也不会提高警惕，去开始一场一山不容二虎的龙争虎斗，而这种斗争在那些认为自己高人一等的负责人中非常普遍。这样一位负责人更有可能觉得幸运,可以为了项目的利益与那位超级明星携手工作。 作为项目负责人你所采取的态度会影响你所做的每一件事情。如果你和某位组员关于性能复审意见不同，你会如何反应？你是会因为觉得自己必须正确而固执己见呢，还是会讨论一下该问题，看看能否有一种更站得住脚的解释？如果你和组员意见相左,你是否会修正一下复核报告，将两种立场都写进去，以便以后读到这份复核报告的人能够自己去作出评价？ 再看一看列出来的那些坚持认为自己高人一等的项目负责人的那些典型行为吧。一个把自己看成只是小组里的另一名成员的负责人会这么做吗？在一种认为自己要高人一等的负责人和那种更加尊重你的负责人之间，你更愿意与那一种人共事呢？要成为你愿意与之共事的那种负责人。 项目负责人要把自己看成小组中的一员，而不要以为自己高人一等。 下载本文示例代码


小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理小软件项目开发的管理