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