软件项目管理        课程设计

设计（论文）题目 软件项目管理的具体内容                                    

学院名称     信息科学与技术学院                            

专业名称     软件工程                            

学生姓名                              

学生学号                               

任课教师                              

设计（论文）成绩                                     

教务处 制

20##年 07月04日

目录

1、       摘要... 2

2、       正文... 2

2.1软件项目管理 - 软件项目的计划... 3

2.2软件项目管理 - 软件项目的控制... 5

2.3软件项目管理 - 软件项目管理的组织模式... 6

2.4软件项目管理 - 软件项目管理的内容... 7

2.5软件项目管理 - 编写《软件项目计划书》... 7

2.6软件项目管理 - 软件配置管理... 7

2.7软件项目管理 - 人员组织与管理... 8

3、人月神话读后感... 10

1、          摘要

软件项目管理的内容主要包括如下几个方面：人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理 这几个方面都是贯穿、交织于整个软件开发过程中的，其中人员的组织与管理把注意力集中在项目组人员的构成、优化。

关键词：软件项目的计划；软件项目的控制；软件项目管理的组织模式；软件项目管理的内容；《软件项目计划书》；软件配置管理；人员组织与管理；软件过程能力评估

2、          正文

软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期（从分析、设计、编码到测试、维护全过程）都能在管理者的控制之下，以预定成本按期，按质的完成软件交付用户使用。而研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则，方法，同时避免前人失误。                          

 软件项目管理的提出是在20世纪70年代中期的美国，当时美国国防部专门研究了软件开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现70%的项目是因为管理不善引起的，而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理。到了20世纪90年代中期，软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10％的项目能够在预定的费用和进度下交付1995年，据统计，美国共取消了810亿美元的商业软件项目，其中31％的项目未做完就被取消，53％的软件项目进度通常要延长50%的时间，只有9％的软件项目能够及时交付并且费用也控制在预算之内。            

软件项目管理和其他的项目管理相比有相当的特殊性。首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。这样庞大的系统如果没有很好的管理，其软件质量是难以想象的。                                 

 软件项目管理的内容主要包括如下几个方面：人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理 这几个方面都是贯穿、交织于整个软件开发过程中的，其中人员的组织与管理把注意力集中在项目组人员的构成、优化；软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值，包括过程度量和产品度量两个方面；软件项目计划主要包括工作量、成本、开发时间的估计，并根据估计值制定和调整项目组的工作；风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防；质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划，有组织的活动；软件过程能力评估是对软件开发能力的高低进行衡量；软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。因为大家对人力资源管理和软件过程能力比较有兴趣，下面就详细的对这两方面展开讨论。

2.1软件项目管理 - 软件项目的计划

软件项目计划是一个软件项目进入系统实施的启动阶段,主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。
    软件项目管理过程从项目计划活动开始，而第一项计划活动就是估算：需要多长时间、需要多少工作量、以及需要多少人员。此外，我们还必须估算所需要的资源（硬件及软件）和可能涉及到的风险。
    为了估算软件项目的工作量和完成期限，首先需要预测软件规模。度量软件规模的常用方法有直接的方法——LOC（代码行），间接的方法——FP（功能点）。这两种方法各有优缺点，应该根据软件项目的特点选择适用的软件规模度量方法。
    根据项目的规模可以估算出完成项目所需的工作量，我们可以使用一种或多种技术进行估算，这些技术主要分为两大类：分解和经验建模。分解技术需要划分出主要的软件功能，接着估算实现每一个功能所需的程序规模或人月数。经验技术的使用是根据经验导出的公式来预测工作量和时间。可以使用自动工具来实现某一特定的经验模型。
     精确的项目估算一般至少会用到上述技术中的两种。通过比较和协调使用不同技术导出的估算值，我们可能得到更精确的估算。软件项目估算永远不会是一门精确的科学，但将良好的历史数据与系统化的技术结合起来能够提高估算的精确度。
     当对软件项目给予较高期望时，一般都会进行风险分析。在标识、分析和管理风险上花费的时间和人力可以从多个方面得到回报：更加平稳的项目进展过程；更高的跟踪和控制项目的能力；由于在问题发生之前已经做了周密计划而产生的信心。
    对于一个项目管理者，他的目标是定义所有的项目任务，识别出关键任务，跟踪关键任务的进展情况，以保证能够及时发现拖延进度的情况。为此，项目管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。
    常用的制定进度计划的工具主要有Gantt图和工程网络两种。Gantt图具有悠久历史、直观简明、容易学习、容易绘制等优点，但是，它不能明显地表示各项任务彼此间的依赖关系，也不能明显地表示关键路径和关键任务，进度计划中的关键部分不明确。因此，在管理大型软件项目时，仅用Gantt图是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。
    工程网络不仅能描绘任务分解情况及每项作业的开始时间和结束时间，而且还能清楚地表示各个作业彼此间的依赖关系。从工程网络图中容易识别出关键路径和关键任务。因此，工程网络图是制定进度计划的强有力的工具。通常，联合使用Gantt图和工程网络这两种工具来制定和管理进度计划，使它们互相补充、取长补短。
进度安排是软件项目计划的首要任务，而项目计划则是软件项目管理的首要组成部分。与估算方法和风险分析相结合，进度安排将为项目管理者建立起一张计划图。

2.2软件项目管理 - 软件项目的控制

     对于软件开发项目而言，控制是十分重要的管理活动。下面介绍软件工程控制活动中的质量保证和配置管理。其实上面所提到的风险分析也可以算是软件工程控制活动的一类。而进度跟踪则起到连接软件项目计划和控制的作用。
    软件质量保证（SQA，Software Quality Insurance）是在软件过程中的每一步都进行的“保护性活动”。SQA主要有基于非执行的测试（也称为评审）、基于执行的测试（即通常所说的测试）和程序正确性证明。
    软件评审是最为重要的SQA活动之一。它的作用是，在发现及改正错误的成本相对较小时就及时发现并排除错误。审查和走查是进行正式技术评审的两类具体方法。审查过程不仅步数比走审多，而且每个步骤都是正规的。由于在开发大型软件过程中所犯的错误绝大数是规格说明错误或设计错误，而正式的技术评审发现这两类错误的有效性高达75%，因此是非常有效的软件质量保证方法。
    软件配置管理（SCM，Software configuration management）是应用于整个软件过程中的保护性活动，它是在软件整个生命周期内管理变化的一组活动。
    软件配置由一组相互关联的对象组成，这些对象也称为软件配置项，它们是作为某些软件工程活动的结果而产生的。除了文档、程序和数据这些软件配置项之外，用于开发软件的开发环境也可置于配置控制之下。
    一旦一个配置对象已被开发出来并且通过了评审，它就变成了基线。对基线对象的修改导致建立该对象的版本。版本控制是用于管理这些对象而使用的一组规程和工具。
变更控制是一种规程活动，它能够在对配置对象进行修改时保证质量和一致性。配置审计是一项软件质量保证活动，它有助于确保在进行修改时仍然保持质量。状态报告向需要知道关于变化的信息的人，提供有关每项变化的信息。

2.3软件项目管理 - 软件项目管理的组织模式

  软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。如果是订单开发，则成立软件项目组即可；如果是产品开发，需成立软件项目组和产品项目（负责市场调研和销售），组成软件产品项目组。公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。
项目管理委员会项目管理委员会是公司项目管理的最高决策机构，一般由公司总经理、副总经理组成。主要职责如下：
（1）依照项目管理相关制度管理项目；
（2）监督项目管理相关制度的执行；
（3）对项目立项、项目撤消进行决策；
（4）任命项目管理小组组长、项目评审委员会主任、项目组组长. 
项目管理小组项目管理小组对项目管理委员会负责，一般由公司管理人员组成。主要职责如下：
（1）草拟项目管理的各项制度；
（2）组织项目阶段评审；
（3）保存项目过程中的相关文件和数据；
（4）为优化项目管理提出建议。
项目评审小组项目评审小组对项目管理委员会负责，可下设开发评审小组和产品评审小组，一般由公司技术专家和市场专家组成。主要职责如下：
（1）对项目可行性报告进行评审；
（2）对市场计划和阶段报告进行评审；
（3）对开发计划和阶段报告进行评审；
（4）项目结束时，对项目总结报告进行评审。
软件产品项目组软件产品项目组对项目管理委员会负责，可下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理。成员一般由公司技术人员和市场人员构成。主要职责是：根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。 

2.4软件项目管理 - 软件项目管理的内容

从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的整个阶段。在20世纪80年代初，著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则，同样，在进行软件项目管理时，也应该遵循这七条原则。它们是：
（1）用分阶段的生命周期计划严格管理；
（2）坚持进行阶段评审；
（3）实行严格的产品控制；
（4）采用现代程序设计技术；
（5）结果应能够清楚地审查；
（6）开发小组地人员应该少而精；
（7）承认不断改进软件工程实践的必要性。

2.5软件项目管理 - 编写《软件项目计划书》

项目组成立的第一件事是编写《软件项目计划书》，在计划书中描述开发日程安排、资源需求、项目管理等各项情况的大体内容。计划书主要向公司各相关人员发放，使他们大体了解该软件项目的情况。对于计划书的每个内容，都应有相应具体实施手册，这些手册是供项目组相关成员使用的。

2.6软件项目管理 - 软件配置管理

是否进行配置管理与软件的规模有关，软件的规模越大，配置管理就显得越重要。软件配置管理简称SCM（Software Configuration Management的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。
    目前软件开发中面临的问题:在有限的时间、资金内，要满足不断增长的软件产品质量要求；开发的环境日益复杂，代码共享日益困难，需跨越的平台增多；程序的规模越来越大；软件的重用性需要提高；软件的维护越来越困难。
软件配置管理应提供的功能:
    在ISO9000.3中，对配置管理系统的功能作了如下描述：唯一地标识每个软件项的版本；标识共同构成一完整产品的特定版本的每一软件项的版本；控制由两个或多个独立工作的人员同时对一给定软件项的更新；控制由两个或多个独立工作的人员同时对一给定软件项的更新；按要求在一个或多个位置对复杂产品的更新进行协调；标识并跟踪所有的措施和更改；这些措施和更改是在从开始直到放行期间，由于更改请求或问题引起的。
    版本管理软件配置管理分为版本管理、问题跟踪和建立管理三个部分，其中版本管理是基础。版本管理应完成以下主要任务：
建立项目； 
重构任何修订版的某一项或某一文件；
利用加锁技术防止覆盖；当增加一个修订版时要求输入变更描述；
提供比较任意两个修订版的使用工具；
采用增量存储方式；
提供对修订版历史和锁定状态的报告功能；
提供归并功能； 
允许在任何时候重构任何版本；
权限的设置； 
晋升模型的建立；

提供各种报告。 

2.7软件项目管理 - 人员组织与管理

软件开发中的开发人员是最大的资源。对人员的配置、调度安排贯穿整个软件过程，人员的组织管理是否得当，是影响对软件项目质量的决定性因素。
    首先在软件开发的一开始，要合理的配置人员，根据项目的工作量、所需要的专业技能，再参考各个人员的能力、性格、经验，组织一个高效、和谐的开发小组。一般来说，一个开发小组人数在5到10人之间最为合适，如果项目规模很大，可以采取层级式结构，配置若干个这样的开发小组。
    在选择人员的问题上，要结合实际情况来决定是否选入一个开发组员。并不是一群高水平的程序员在一起就一定可以组成一个成功的小组。作为考察标准，技术水平、与本项目相关的技能和开发经验、以及团队工作能力都是很重要的因素。一个一天能写一万行代码但却不能与同事沟通融洽的程序员，未必适合一个对组员之间通讯要求很高的项目。还应该考虑分几个网站开发项目，小组中有页面美工、后台服务程序、数据库几个部分，应该合理的组织各项工作的人员配比。对于一个中型农技110网站，对数据采集量要求较高，一个人员配比方案可以是2个美工、2个后台服务程序编写、3个数据采集整理人员。
    可以用如下公式来对候选人员能力进行评分，达到一定分数的则可以考虑进入开发组，但这个公式不包含对人员数量配比的考虑。
Score=∑WiCi(i=1to8)
Ci是对项目组人员各项能力的评估。其值含义如下 

在决定一个开发组的开发人员数量时，除了考虑候选人素质以外，还要综合考虑项目规模、工期、预算、开发环境等因素的影响，下面是一个基于规模、工期和开发环境的人员数量计算公式：
L=Ck*K1/3*td4/3
L:开发规模，以代码行LOC为度量td:开发时间K：人员数
Ck：技术常数表示开发环境的优劣
 取值2000：表示开发环境差，没有系统的开发方法，缺乏文档规范化设计；
取值8000：表示开发环境较好；
取值11000：表示开发环境优。
在组建开发组时，还应充分估计到开发过程中的人员风险。由于工作环境、待遇、工作强度、公司的整体工作安排和其他无法预知的因素，一个项目尤其是开发周期较长的项目几乎无可避免的要面临人员的流入流出。如果不在项目初期对可能出现的人员风险进行充分的估计，作必要的准备，一旦风险转化为现实，将有可能给整个项目开发造成巨大的损失。以较低的代价进行及早的预防是降低这种人员风险的基本策略。具体来说可以从以下几个方面对人员风险进行控制：
a．保证开发组中全职人员的比例，且项目核心部分的工作应该尽量由全职人员来担任， 以减少兼职人员对项目组人员不稳定性的影响。
b．建立良好的文档管理机制，包扩项目组进度文档、个人进度文档、版本控制文档、整体技术文档、个人技术文档、源代码管理等。一旦出现人员的变动，比如某个组员因病退出，替补的组员能够根据完整的文档尽早接手工作。
c．加强项目组内技术交流，比如定期开技术交流会，或根据组内分工建立项目组内部的开发小组，是开发小组内的成员能够相互熟悉对方的工作和进度，能够在必要的时候替对方工作。
d．对于项目经理，可以从一开始就指派一个副经理在项目中协同项目经理管理项目开发工作，如果项目经理退出开发组，副经理可以很快接手。但是只建议在项目经理这样的高度重要的岗位采用这种冗余复制的策略来预防人员风险，否则将大大增加项目成本。
e．为项目开发提供尽可能好的开发环境，包括工作环境、待遇、工作进度安排等等，同 时一个优秀的项目经理应该能够在项目组内营造一种良好的人际关系和工作氛围。良好的开发环境对于稳定项目组人员以及提高生产效率都有不可忽视的作用。

3、人月神话读后感

人月神话读后感

二十九年前(1975)﹐IBM大型电脑之父──Fred Brooks 出版一本书﹕"The Mythical Man-Month"。收集了他在1960年代领导1000多人共同发展OS/360大型软件系统的心得和经验。该书是论文集﹐其中有一篇文章叫"The Mythical Man-Month"﹐他就以此作为书名。在1956~1965 之间﹐Brooks实际领导IBM 360 大型电脑的开发计划﹐包括硬体结构及庞大的OS/360作业系统在内﹐因之他具有IBM 大型电脑之父的尊称。由于OS/360是多达1000位程式师共同合作的大型软件开发工作﹐让他深刻了解到大型软件开发的技术和管理上所面临的种种困难和挑战。于是﹐他就将其领导开发OS/360软件系统的经验心得收集在这本书里。人们常拿Man-Month （多少人﹐做多少个月）来计算软件的工作量﹐但是Brooks发现软件的开发工作是需要人与人之间密切沟通的﹐使得设计工作不易分割﹐所以Man-Month 为单位的计算方法是有问题的(mythical)。也就得出著名的Brooks法则── 「对于进度已落后的软件开发计划而言﹐若再增加人力﹐只会让其更加落后。」(Adding manpower to a late software project makes it later)这是该书名称的涵义。

看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。 本书对我触动最大的，一是保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。

二是“一个拿2倍工资的人，生产率可能是其他人的10倍。”不知道其他公司的程序员们如何看。我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。组建一个团队，最好的就是那种精英团队。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难。

三是进度落后与增加人力。向进度落后的项目中增加人手，只会使进度更加落后”。以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。

在此我说说我对书中印象最深的部分。

 焦油坑

职业的乐趣：首先是一种创建事物的纯粹快乐。其次，快乐来自于开发对其他人有用的东西。第三是真个过程体现出魔术般的力量—将相互吻合的零部件组装在一起。第四是学习的乐趣，来自于这项工作的的非重复特性。最后，乐趣还来自于工作在如此轻易驾驭的介质上。编程非常有趣，在于它不仅满足了我们内心深处进行创造的渴望，而且还愉悦了每个人内在的情感。当你看到一段段代码编写成功之后转变成一个可以运行的软件界面，这种从无到有的快乐是无法替代的；同时它可以通过有形的介质（编程工具）将你心里的各种奇思妙想转换为现实。每个项目的开发是独一无二的，每次的开发都能得到不同的体会和经验。

这是非常宝贵的。

职业的苦恼：编程最困难的部分，是将做事的方式往追求完美的方向调整。

软件的编码要求是非常挑剔的，一个字母的错误都会导致整个程序无法实现，而前期编码不能做到严谨细致，会导致后期陷入无休止的改错中，想想从几千行甚至上万行的代码中寻找一个细微的错误，那是让人奔溃的。其次是由他人来设定目标，供给资源，提供信息。

由于客户一般都非专业的人员，所以他们所提供的需求表述可能是不准确的，会导致需求的不断变更，导致后期的编码阶段无法高效进行。所以在需求阶段需要做好需求分析，尽可能的去完善客户的需求，防止给后期造成困扰。同时客户对项目的完成时间和资源的提供可能是不合理的，只是出于商业目的的考虑，并没有考虑到实际开发所需要的时间，这个往往会导致不停的加班赶工，同时项目组也需要与客户进行协商沟通，把项目完成时间控制在双方都可接受的范围内。既能达到客户的要求，也不至于自己手忙脚乱，最终陷入死循环。

对于系统编程人员来说，对他人的依赖是一件非常痛苦的事。他依靠的其他人的程序，而往往这些程序设计的并不合理，实现拙劣，发布不完整或者文档记录很糟糕。所以编程人员不得不花时间去研究和修改，而他们在理想情况下本应该是可靠完整的，所以项目开发应该设定统一的规范，每个程序都要按照规范来编写源代码和文档。这样才能在交接的时候其他的成员才能快速消化你的工作，然后进行后续的任务。

下一个烦恼，概念的设计是有趣的，但寻找琐碎的bug却只是一项重复性的枯燥的活动。伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的劳动，编程也不例外。在调试过程中，bug的出现往往是不可避免的，而bug的寻找往往是很枯燥的，但又必须去进行，所以对于这种烦闷枯燥但又必须进行的工作，是让人非常无奈的。

最后一个烦恼，也是最无奈的，当投入了大量的辛苦劳动，产品在即将完成或终于完成的时候，已经显得陈旧过时了。可能是同事和竞争对手已经有了更新，更好的构思。这就要求项目开发必须做好对市场的调查，同时也要安排合理的开发时间。避免冗长的时间导致项目最终成果已经过时。

焦油坑的部分是最让人印象深刻的，它系统的描述了软件开发的乐趣和烦恼，而针对这些烦恼所提出来的各种应对措施就是软件项目管理。
    外科手术队伍
     项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。
    未雨绸缪

    唯一不变的是变化本身。 在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。这个是非常重要的，它能让你面对问题的出现游刃有余，不会对整个项目开发进度造成很大影响。有备无患才是王道。

 项目中管理好各种工具也是很重要的，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。

祸起萧墙

      这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。 项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。所以详细的项目安排计划是非常有必要的，而且每个成员必须在自己规定的时间内尽可能的完成自己的工作，避免拖延。

《人月神话》这本书在软件项目管理上是非常有用的，可能它的一些观点和描述并不符合现在的软件开发，但是在大体的项目管理上，它从根源描述了软件开发要面临什么问题，然后怎样来制定解决这些问题的软件项目管理计划。我觉得这个是非常值得我们吸取的。