IT项目管理的文章精选.docx
《IT项目管理的文章精选.docx》由会员分享，可在线阅读，更多相关《IT项目管理的文章精选.docx（44页珍藏版）》请在冰豆网上搜索。
IT项目管理的文章精选
小软件项目开发的管理
一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到自己身上，可能会适得其反。
同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。
但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。
本文的目的是从作者的经验来谈谈小项目开发的管理。
一、小项目的特点
大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。
小项目相比之下，具有以下特点:
1.项目功能相对较少
2.开发人员较少
3.开发周期较短
另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员流动性较大，这也是不容忽视的一个现实.
二、小项目开发中常犯的错误
小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:
1、开发之前没有认真地进行项目可行性和工作量的估计。
往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别。
2、没有真正的设计过程
开发人员少，意味着不同人员的程序之间交互、接口相对少一些。
开发周期短意味着往往是同样的几个人从头到尾负责一个项目。
这两者都让人容易犯些错误。
往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。
这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差（应该承认人是会犯错误的）。
一个误解可能造成以后的返工。
另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。
其根源在于没有一个负责协调的人员不断监控整个开发过程。
第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解以前别人做好的代码，索性自己从头来。
另外，没有文档的程序，日后维护和版本升级都比较困难。
3.不经过单元测试而直接进入系统测试
造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。
例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。
但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。
殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。
由于模块间的调用关系，可能查了很久才发现是某个模块的问题。
这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。
另外由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。
但是如果对每个模块进行单元测试时都进行一下边界测试，就会很容易消除一些隐患。
真可谓欲速则不达也。
三.合理的开发流程
合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。
但是小项目有它自身的一些特点，实行起来可以相对灵活些。
以下我从几个方面描述一下我认为比较合理的模式.
1.需求获取
在进入正式开发之前，必须先从用户处获取准确的需求。
在这上面花费相当时间是很必要的。
软件项目可以大致分为专用软件和通用软件两大类。
对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。
但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。
这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。
对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。
为了比较好地与用户进行交流，使用一些工具是很有好处的。
为了讨论用户界面，可以用VB,delphi等做一个原型，根据原型有针对性地与用户讨论需求。
（原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发）
为了讨论软件运行的流程，可以采用UML的UseCase图。
2.需求分析
在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。
这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系,可能需要不断修改而形成一份分析文档。
我想强调几个问题。
一是要分清问题域与系统责任。
系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。
例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。
又如，你需要在一个已经存在的数据库上开发一些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。
但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。
二是需求获取与需求分析的关系。
用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。
例如当初采用UseCase来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。
三是分析与设计过程的衔接。
分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。
这些具体实现是在设计阶段来完成的。
面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。
但是，是把分析和设计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。
对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采用其他的平台时，便可以以这份分析文档作为开发的基础。
对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。
但是这意味着可能没有一份完整的分析文档。
现在很多CASE工具并不区分分析和设计的阶段。
但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。
3.设计过程
设计阶段的工作包括:
对分析模型必要的修改。
可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。
定义界面部分、数据访问（数据库）部分。
由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。
于是设计阶段的工作量并不大。
4.编码
进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。
5.测试
如前所述，即使是小项目，也应该严格地进行测试。
四、人员的安排
比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。
在这几个人中，有一位项目负责人，负责分析、设计和协调的工作。
由于项目小，项目负责人也要参加编程,那么这人必须把时间合理运用，
经验告诉我几条原则:
1.协调几个人的工作比自己完成一段编码更重要.
由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。
只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。
2.给每个开发人员明确的任务书.
不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系统。
但是，具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文档来表示。
3.让大家都大致熟悉设计模型.
让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。
以下工程开发指导是我对决定一项使用任何语言的软件工程成功与否的决定因素的一些认识。
1．记住往往事与愿违
纯粹的“轶事工程”（原文为：
anecdotalproject，其含义不好理解，暂译为"轶事工程"，盼指正--译者）的失败几率总是存在，一些低至百分之五十而另一些高达百分之八十，但是所有的这些都表明：
你失败的机会大于你成功的机会。
为什么我要从这个令人丧气的预测开始我的话题呢？
因为每一天开始时，我都想“今天将会不同，我今天能够完成四倍数量的事情”，尽管（在此之前）有过一系列不间断的例外。
对于软件工程来说，过度的狂热往往被那些（只）关心结果人所夸大——“这一次，我们将解决以前从来没有人解决过的问题，只需付出更少的时间和更小的代价”，尽管他们知道，真正的规则是：
“你只能从此三者中选择一个”。
记住你身后高高堆积的纸牌[i]非常重要。
你手中有一根包含时代力量的魔术手杖或者是挂在悬崖上，会让你做出完全不同的两个决定。
如果你懂得你的处境属于后者，你将会说：
“是的，这很好。
但首先让我们看看我们是否能够在现有的进度和预算情况下完成这一切。
”
一个将不稳定形势和对失败的认识放到显著位置的方法是研究过去的失败。
一份很好的资料是RobertsGlass（一位爱好研究崩溃的专家）的著作：
《软件失控》（SoftwareRunaways,出版信息：
PrenticeHall1998），以及他其它的著作。
此外可以阅读TomDemarco和TimLister的经典之作《人件——生产性工程和团队》（Peopleware:
ProductiveProjectsandTeam,出版信息：
第二版，DorsetHouse,1999）。
2．切合实际地安排时间
时间安排的“魔法”经常受到非开发人员为满足软件开发实践之外的愿望和期待而产生的想法所驱使。
最近我校正了自己的时间安排策略。
我先将整个工程显示脑海中，然后闭上眼睛，清理自己的大脑并让它判断这个工程大概需要多少时间。
如果不考虑奇怪的技术问题、各种会议和其他分心的事物的影响，得出的这个时间居然非常合理。
但我建议将这个合理的时间乘以3，或许可能是4，并且加上百分之十。
如果这个估计出来的时间将让你失去市场机遇，那么考虑不要进行这个工程。
如果你认为像这样计划时间不合理，那么首先请注意，大多数工程将遵循这个规律。
其次，试想一下，如果你所在公司的所有工程都很成功进行会带来局面：
你将拥有更多的收入；更少的程序员会因为愚昧的工程时间安排筋疲力尽而退出。
你也许还会争论说这个时间评估技术非常没有科学性，这一点我同意。
然而，所有的软件评估技术都含有臆测和直觉的成分在内，甚至连功能点（原文为：
functionpoint，若有其他正规译法，请指正）分析都需要对功能点进行猜测。
我的“信封背面”技术将所有臆测结合到了一起，而不试图假装没有猜测。
用更少的时间，也许产生更好的结果。
但是，我的猜测是建立在我自己的经验之上的。
3．首先让它运作起来
当我试图进行一些无意义的事情时，我最大的创造性成功来临了。
铭记最重要技巧——当你开始一个工程时，你好比已经用手指将自己挂在一个悬崖之上；然后你考虑一下能够做什么疯狂的事情简单地让你的工程运作起来。
这并不意味着你需要马上投入进去并用通常的方式开始撰写代码，你只需要尽早尽快找到一个转换周期非常短的工具，用来判断你是否可以做该项工作以及你的工程可行性如何。
我在后面将要提到的Python语言就是这样一种工具。
将你的计划运作起来有很多好处。
凭你的经验，你应该知道，用户只有能够开始使用你开发的东西的时候才能理解你开发的是什么，然后他们会突然产生各种念头并对该软件应该做些什么真正提出要求。
一份系统说明书往往只是一份文档，人们往往不会认真地阅读，但是如果你让他们体验一个可运行的程序之后，他们就会确切地明白你的意思。
更早地了解用户们真正想要什么岂不是更好？
事情往往会比你想象出来的要复杂四倍以上，所以对你能够完成的东西要尽可能地保守一些。
无论何时，一些不可知的因素都在伴随着你的工作（这一点你可以从产品描述中一些“最”中察觉到：
“最快”、“最大”、“最新”），原型的价值不能进行夸大。
如果在此之前你没有做过类似的工程，那么最重要的事情是尽快地判明该工程是否可以实现，开发一个根本不能发挥作用的程序将会以浪费你的大量金钱而收场。
最后一点，优化。
要能够在这个阶段抵抗得了诱惑。
牢记DonaldKnuth说过的话（其中略有一点开玩笑的意思）：
“不成熟的优化是所有麻烦的根源”。
虽然优化是一些工程的关键因素，但是在确认程序切实可行之前一切优化都是盲目的。
在最后建造系统之前浏览一遍所有的问题。
每个工程都有一些你没有接触过的东西，你应该首先将注意力放到这个领域，创建一个测试程序或者原型来寻找解决问题的方法。
在你知道你是否可以做到并且知道做到的难度有多大之前，你没有其他办法能够得知工程是否能够成功、如何为它安排时间以及它需要多少付出等等。
4．使用恰当的工具
一个工程的早期部分应该是高度探索性和实验性的，因为那个阶段是发现自己不会做什么以及如何去建造程序的阶段。
寻找最适合工具的最好方法是去体验一下他们，然后摈弃其中工作效率低下的那些。
例如，你可能开始的时候用的是RationalRose，后来决定使用VisioProfessional来创建视图，因为你需要Visio（或者通过Versa）提供的一些特性。
用来做工程的恰当工具并不一定就必须是你已经了解的编程语言。
当使用一种语言时，你就被局限在该语言所能表示的范围之中了。
如果你是一个C++程序员，你很自然可能想用C++创建所有的工程管理和工具。
但当你需要更加灵活的工具时，Perl是一种更快速的选择（甚至将考虑学习需要的时间在内）。
在你的实际工程开发中，使用Python来快速造型或者甚至交付一个内嵌Python语言的应用程序将给你带来更好的局面。
首先，它是免费的，所以不需要支付任何许可授权费用；同时它对C和Java有完全兼容的接口，你可以使用Python解决所有Perl能够解决的问题，所以它是C++和Java的一种完美的辅助语言。
5．接口的设计
在C++中，接口是一个包含所有虚函数的类；而在Java中接口技术被直接支持；在COM和COBRA中，你没有其他选择，你和所有的抽象打交道——所有的都是接口，没有实现。
接口提供了一个更加整洁的设计方式。
要想让程序员们确信这一点有些困难，但是它对将COM或者COBRA指定为构件模型非常有帮助的（COBRA技术也是与操作系统无关的技术）。
它不仅仅提供了工程实现语言的灵活性，并让你能够完全地将工程切割开来。
如果你打算在你的开发组或者公司之外实现你的工程的一部分，整洁的接口可以阻止任何与工程其它部分不适当的连接，同时你可以用任何语言来进行开发。
你可以采取快速造型来实现所有的接口，稍后才对其中比较特别的部分进行优化。
6．设计时充分考虑异常情况
在C++中，异常控制并不像在Java中那样得到有力支持——这是Java在工程管理方面成功之处。
在设计、代码编写和模块使用的时候往往会有一些错误，除非软件自身能够通过抛出一个异常来声明这些错误，否则你将会花费许多小时或月的时间来捕获这些问题。
只有通过严谨的异常使用，你才能保证这些问题不会出其不意地让你的工程陷入困境。
7．简洁往往付出代价
虽然很难说服管理部门，但是“简洁”这个词是可维护性和复用性的同义词。
不仅如此，一个简洁的程序让人感觉很好。
但是因为我们确信软件工程是一种商业行为，目的是为了赚钱，而不是为了感觉，因此很难说简洁的程序比其他非简洁的程序更加有灵气地结合在一起。
但是由于软件是一种能够赚钱的艺术实体，在美学和实用性之间必然会一场争论。
8．人与人之间的交流是一个瓶颈
这就是为什么小型的组队往往更加有生产力的原因。
当一个工程像火焰一样失去控制的时候，将更多的程序员扔进火焰将使情况变得更糟。
这也是为什么简短的小会议往往可以发挥作用而冗长的大型会议却做不到，还有为什么太深的管理机制会导致生疏的原因。
参阅《人件》（早些时候提及过）一书了解更多的细节。
解决交流问题的最好办法是免费的：
在一台废弃的计算机上安装一个Linux服务器，你可以在几分钟内完成这项工作，自动安装将包括一个Apache网页服务器。
然后将你们所有的文档，从测试分析到用户文档，拷贝到服务器上，以便每个人都能够访问到最新的信息。
你可以轻松地加入JavaServlets或者Perl脚本（Acrobat格式来代替HTML格式。
如果你的工程足够大的话，指定一名成员专门负责维护服务器是值得的。
9．制定一份计划（可以是任何类型的）
我曾经见过许多工程在没有签订任何合同（更别说一份计划）时已经有大量资金流动。
哪怕是对于一个很小的工程，你也需要某种计划，甚至它可能只是被写在一个信封的背面或者只存在于主程序员的脑海中。
当工程逐渐变大，你需要一个回顾的过程。
一个典型的计划包括：
分析阶段（包括你打算用程序解决什么问题以及程序将完成什么）、设计阶段（程序如何完成它的任务、程序实现的组成、分析阶段预定目标是否达到的测试使用信息以及发布、安装和培训等事项）。
当新的信息被收集时，这些阶段将被重复。
根据工程的大小，这些步骤将被缩小或者放大，但你必须像熟悉你的编程语言一样熟悉它们。
10．考虑外部帮助
一种放弃：
我的公司提供培训和咨询服务，因此当然我感觉这是一个好主意。
然而，如果你的公司内部有经验丰富的人可以担任你的工程的顾问，你可以不必向公司之外寻求帮助。
这是一种以知识为基础的商业行为，生产力最低和最高的软件工人之间的生产力差别是很大的。
如果你无法雇用那些最有生产力的工人，你可以通过培训提高他们的生产力，通过咨询和代码预排来改进你的工程的分析、设计和实现。
对于顾问和客户来说，有一本优秀的书籍是Weinberg的《咨询的秘密》（出版信息：
DorsetHouse,1986）
另一方面，我曾经见过一些工程中，使用外部的开发组队剥夺了内部的队伍的权利，该项目最后以花费更多的时间和资金收场。
这将我们带到我的最后一个提示:
11.了解永远没有银弹（原文为：
silverbullets,此处直译为银弹，估计引申含义和freelunch接近）的道理
这句谚语是由FredBrooks发明的，对于今天仍然适用——尽管有许多“银弹”已经被发明出来了。
统一建模语言（UML）就是这样一个例子：
它当然是一个很好的通用词汇表和设计符号集，但是UML仅仅轻微地减少了方法学家之间的争论而已。
永远不会有不劳而获的事情。
你必须艰辛地计划你的对象、它们的接口和结构，然后跨越一道道障碍将工程变成成果。
你必须清楚没有任何可以保证成功的方案可以依赖，同时牢记工程的失败的几率让自己更好的瞄准成功。
在最好的情况下，管理软件项目也是很困难的。
不幸的是，许多新项目经理实质上没有受到任何就职培训。
这里有20个成功的管理经验供项目经理参考。
1.定义项目成功的标准
在项目的开始，要保证风险承担者对于他们如何判断项目是否成功有统一的认识。
经常，满足一个预定义的进度安排是唯一明显的成功因素，但是肯定还有其他的因素存在，比如：
增加市场占有率，获得指定的销售量或销售额，取得特定用户满意程度，淘汰一个高维护需求的遗留系统，取得一个特定的事务处理量并保证正确性。
2.识别项目的驱动、约束和自由程度
每个项目都需要平衡它的功能性，人员，预算，进度和质量目标。
我们把以上五个项目方面中的每一个方面，要么定义成一个约束，你必须在这个约束中进行操作，要么定义成与项目成功对应的驱动，或者定义成通向成功的自由程度，你可以在一个规定的范围内调整。
相关的详细信息，请参照我的《创建一种软件工程文化》（CreatingaSoftwareEngineeringCulture）（DorsetHouse,1996）中的第二章。
3.定义产品发布标准
在项目早期，要决定用什么标准来确定产品是否准备好发布了。
你可以把发布标准基于：
还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其他方面表明项目已经达到了它的目的。
不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与你的客户指的“质量”一致。
4.沟通承诺
尽管有承诺不可能事件的压力，从不作一个你知道你不能保证的承诺。
和客户和管理人员沟通哪些可以实际取得时，要有好的信誉。
你的任何以前项目的数据会帮助你作说服的论据，虽然这对于不讲道理的人来说没有任何真正的防御作用。
5.写一个计划
有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。
困难的部分不是写计划。
困难的部分是作这个计划--思考，沟通，权衡，交流，提问并且倾听。
你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。
6.把任务分解成英寸大小的小圆石
英寸大小的小圆石是缩小了的里程碑。
把大任务分解成多个小任务，帮助你更加精确的估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。
7.为通用的大任务开发计划工作表
如果你的组经常承担某种特定的通用任务，如实现一个新的对象类，你需要为这些任务开发一个活动检查列表和计划工作表。
每个检查列表应该包括这个大任务可能需要的所有步骤。
这些检查列表和工作表将帮助小组成员确定和评估与他/她必须处理的大任务的每个实例相关的工作量。
8.计划中，在质量控制活动后应该有修改工作
几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。
你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。
如果你事实上不用作任何的修改，很好，你已经走在了本任务的计划前面。
但是不要去指望它。
9.为过程改进安排时间
你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投资一些时间在过程改进上。
从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。
不要把你项目成员可以利用的时间100％的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。
10.管理项目的风险
如果你不去识别和控制风险，那么它们会控制你。
在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。
要一个软件风险管理的简要的指南，参见我的文章“KnowYourEnemy:
SoftwareRiskManagement”（Oct.1998）。
11.根据工作计划而不是日历来作估计
人们通常以日历时间作估计，但是我倾
升级会员 