以下是小编帮大家整理的软件项目管理学习之：进度管理，死亡之旅（共含7篇），仅供参考，欢迎大家阅读。同时，但愿您也能像本文投稿人“偶然放弃”一样，积极向本站投稿分享好文章。
摘录的案例：
老板BB：今天是1.3日，到10.1我们必须完成AIX新产品的开发，这个产品对公司很重要，具有最高的优先级，这是最后的期限，
老板BB：我们分析阶段要用多少时间？
老板BB：假设需求就在你面前，你需要多少时间分析
项目成员：如果分析超过4.1日，我们是不可能完成后续任务的
项目Lead：我们会找到方法在4.1日完成所有分析
老板BB：那我们设计需要花多少时间？
项目成员：没有分析需要时间估计，很难清楚设计需要时间
老板BB：假如你已经做过了分析？
项目Lead：只剩下6个月的时间，设计最好不要超过3个月
老板BB：大家能够同意这个时间，我很高兴，好，4月1号前完成分析，7月1号前完成设计，那么你们有3个月的时间实现项目。这次会议
老板BB：记住，SEI下周要过来做一次评估。这是评估指南。你要把它读一遍，记住它，然后把它撕碎。它告诉你如何回答 SEI 审计师问你的任何问题。它还告诉你在构建过程中可以使用哪些部分内容以及避免使用哪些部分内容。到 6 月份时，我们会被确定为 CMM3 级机构。
案例分析：
倒排进度有时在受资源
盲目乐观，空乏的估算，不切实际的进度，很多项目一开始就注定是死亡之旅。项目经理不能领导项目成功，就只能成为项目失败的替罪羊。项目经理一开始对高层领导的盲目迎合和缺乏风险意识，最终将使项目和自己受到沉重的代价。任何项目都有风险，但对于耗无胜算的项目（按目标完成概率<40%），最好的方法就是选择离开，而不是项目失败后再来找藉口，请记住选择和方向很重要，我们在选择前可以深思熟虑，选择后则只有勇往直前，
过程很重要，好的过程有助于我们开发出好的产品。但在不切实际的进度面前过程更加显得苍白无力。对进度的恐慌迫使我们有强烈的意愿去达到各阶段的目标和里程碑，因为你和高层领导都清楚这样一个事实，如果里程碑无法达到，你去告诉你的领导你严格的遵守了各个过程是多么没有说服力的话语。而实际上你完全遵守过程执行，往往减少后期大量的返工时间，更容易达成项目目标。不是过程不好，而是我们不够成熟，我们需要的是尽可能早的暴露风险和未知，这样你才能安下心来长舒口气。
重要片断：
令你大为惊奇的是，现在要回答“当用户敲击回车键时，系统应该做什么？”这个问题，需要填写15页的表格和问答题。（华丽而无效的过程）
3.27号，距离分析完成还有一周时间，你们已经产生了大量的文档和图示，但是你们对问题的分析却和1 月3号时一样的浅薄。（交付物代表了什么？）
4.1日，奇迹发生了，你的上司给高层发邮件说明你们已经成功的完成了分析阶段。老板团队所表现出的不可思议的团结和团队协作（盲目的乐观）
有传言说，一旦被 SEI 授予 CMM3 级，和BB同层以及更高层的管理者就可以得到丰厚的奖金。（权力和政治）
“如果我们要将设计详细到代码级的程度，我们为何不直接去编写代码呢？”
“因为那样的话，你当然就不是在设计了。而设计阶段惟一允许做的事情就是设计。”
评审会议很快就变成有关面向对象的意义、分析和设计的定义以及何时使用聚合和关联的争论。（偏离主题的评审）
你告诉你的上司，这些变更意味着你需要对系统的大部分内容进行重新分析和重新设计，但是他却说，“分析阶段已经结束。惟一允许做的事情是设计。现在回去设计吧。”（死板的规程）
7月1号，另一个奇迹发生了！你完成了设计！一份无法反映真实需求的设计文档。充斥着大量的类图，模型和序列图。（复杂而无用的模型）
你的上司雇佣了一个顾问来构建一个计算所编写的代码行数的工具。他把一张很大的坐标纸贴在墙上，在顶部标出了数字1000000.每天他都会延长红线来显示增加了多少行代码。（毫无意义的度量）
接着，他立刻闪现出了管理方面的洞察力，说，“我知道了！，任何一行代码都不能超过 20 个字符。任何超过 20 个字符的代码行必须得分成两行或者更多的行——越多越好。现有的所有代码都必须按这个标准改写。这会使我们的代码行增加！”
拼凑、拼凑、拼凑还是拼凑。你和你的团队疯狂地编码。到8月1号，你的上司皱着眉头看着墙上的坐标纸，制定出了强制性的每周要工作 50小时。（加班已不能解决问题）
最后，到3月份。经过了大量的 65 小时工作周后。一个非常不可靠的版本完成了。实地使用时，错误的出现率非常高，技术支持人员对于发怒的客户的抱怨和要求束手无策。所有人都不高兴。（为时已晚）
4月，高层决定通过购买的方式来解决问题，他购买了由 Rupert工业公司开发的产品的使用授权并重新销售。客户的怒火被平息了，市场人员沾沾自喜，而你被解雇了。（替罪羊产生）
软件开发项目进度管理初探论文
摘要：软件开发项目具有需求不确定性、时间期限严格等特点，由此决定了软件开发项目进度管理非常必要，但同时也存在着一定的难度。重点对软件开发项目进度管理进行分析研究，明确软件开发项目进度管理的4个主要步骤：根据项目目标和现有资源，进行项目工作分解；在项目工作分解结构图的基础上，确认项目活动，用科学的方法估算活动时间并排序；编制项目进度计划和进度管理计划；在项目实施过程中，对项目进度进行跟踪和监控并定期评估，必要时需根据实际情况按一定规则，变更项目进度计划。
关键词：软件开发项目；项目进度；项目进度管理
DOI：10．11907／rjdk．161212 中图分类号：TP319 文献标识码：A 文章编号：1672－7800（2016）004－0151－030
引言
软件开发项目进度，是指完成整个软件开发项目所需活动的过程和时间周期。软件开发项目进度管理是为了确保项目按时完成而对其各项活动及阶段进行的管理。软件开发项目进度管理包括4个步骤，其中软件开发项目进度计划编制和进度控制是实际工作重点，但编制项目进度计划前，应先分解项目，明确该项目包含的活动，并对项目活动进行排序［1］。下文中“软件开发项目”简称为“项目”。
1项目工作分解
一个项目提出后，根据项目目标确定项目的研究范围后，应对项目进行分解，将可交付成果和复杂的项目逐步分解成较小的、便于管理的组成部分，并创建工作分解结构图，为项目进度计划打下基础［2］。
1．1项目工作分解的作用
项目分解的作用主要体现在两个方面：（1）便于进行综合性方案设计。工作分解就是在项目目标的指导下，在任务范围中从粗到细、从简到繁，逐步分析，直到可执行的最小独立单元，这样能够较好地保持项目的系统性和完整性，策划者据此可以通盘考虑实现项目目标应完成的工作，能够清晰地分辨任务实现的重点和步骤、完成周期、成本费用，并评估风险，同时，也有利于发现潜在的不明确内容，为项目总体设计提供可靠依据。（2）便于分配任务和明确责任。项目工作分解把项目划分成多个独立性较强的任务单元，明确区分各任务的目标、范围和界限，对每个工作任务提出具体要求，便于在执行项目时，落实责任者或完成单位。既可以作为委托工作或下达任务的依据，也便于观察、了解和控制整个项目过程。
1．2项目工作分解结构的依据、原则和方法
项目工作分解结构的主要依据是前期取得的项目主要资料和其它相关项目的借鉴性文件，包括项目需求文件、任务（合同）范围说明、本项目的其它资料、其它项目的相关资料等。工作分解结构的原则是：在各层次上保持项目内容的完整性，不能遗漏任务必要的组成部分；每个项目单元只能从属于某一个上层单元，不能同时交叉从属于两个上层单元；相同层次的项目单元应有相同的性质，各项目单元应有明确的任务界限，保持各项目单元的独立性；项目分解的原则应事先确定，同一层次上分解出的项目单元，其分解的原则应该是一致的。工作分解的方法有自上而下和自下而上等方法。自上而下法是先明确项目最终产品，然后确定中间可交付成果，再对主要可交付成果细分，直至每一个工作只包含一个可交付成果；自下而上法是首先明确项目的所有可交付成果，然后将可交付成果进行逻辑分组，接着将每组汇总成一个母元素，成为上一层次的元素，再将高一层次的元素进行分组、汇总，以此类推，最终汇成一个母元素。
1．3项目工作分解结构一般步骤
工作分解首先应识别项目的主要要素，项目的主要要素就是项目的主要交付物，然后对识别出的主要要素作进一步细化，分解出更详细的有形的、可检验的产品或服务，在此基础上，选择自上而下或自下而上的方法编制工作分解结构图（也可以使用单位标准模板或以前项目的模板），编制完工作分解结构图后，应编制详细的结构图说明，说明的内容包括各要素的界定、说明、估算经费、时间、预安排的责任部门、人员等。
1．4项目工作分解结构输出
项目工作分解的输出结果包括项目结构图和相关说明。项目分解结构图（WBS）是通过分解技术，将项目任务按照其内在性质和结构逐层细化而形成的示意图。它涵盖为完成项目交付物需进行的所有项目工作，为项目责任分配和任务协调提供依据。项目结构说明包括各层要素的详细描述、工作说明、负责组织、进度日期、成本预算等。
2项目活动确认及排序
完成项目工作分解后，应对所确定的可交付成果的具体活动进行分析确认和排序，为编制项目计划打基础。
2．1项目活动确认
依据项目工作分解结构的成果、其它关于项目范围的说明性文件、项目约束条件、项目的假设前提、管理计划和单位的历史信息等［3］确认项目活动。对于一些小项目，可通过大家集体研究讨论，集思广益的方法，形成可行的活动清单并估算所需时间，对于较大、较复杂的项目，则需要由相应领域专家研讨或使用一定的工具和方法来确认项目活动，这些方法包括：进一步使用活动分解技术、采用已有模板法、领域专家判断法等。项目活动确认后，形成的结果包括：涵盖项目所有必要活动的项目活动清单、描述项目过程中基本关键点的项目里程碑图等，此外，还应适时更新项目工作分解结构图和项目总体管理计划。
2．2项目活动排序
确认了项目活动，要识别各项活动的相互关系，项目活动之间的关系也称为项目活动之间的先后信赖关系，包括人们无法改变的硬逻辑关系和需由各种因素综合确定的软逻辑关系，在项目活动排序时，要根据项目活动清单、项目里程碑和一些约束条件，先识别并安排硬逻辑关系，再安排软逻辑关系，同时要考虑项目假设条件和外部条件的影响。项目排序图的编制方法可以采用节点图法或箭线图法。项目排序的最终结果，是描述项目各项活动相互关系的项目网络图及其活动说明，项目网络图应包括项目的主要活动和情况，并明确各活动之间的'逻辑关系或依赖关系，在网络图的说明中，应描述活动排序的基本方法，对于特殊的排序应进行说明。
2．3项目时间估算
项目时间估算是指根据项目范围、资源及相关信息，对项目已标识的各活动持续时间所进行的估计。大多数项目活动时间的长短，取决于人力、物力、财力及资源的多少，同时还受人的能力、物资质量和设备效率的影响。对项目活动时间进行估算时，即要考虑各活动所消耗的实际工作时间，也要考虑活动的延迟时间。因此，一般由熟悉项目活动或有经验的人员或团队，采用专家判断法、类比估算法或模拟估算法完成。
3项目进度计划编制
编制项目进度计划，是综合分析项目活动排序、持续时间、资源需求和进度约束，确定每一个项目活动及整个项目起始和完成日期，建立一个相对科学可行的项目进度计划的过程。编制项目进度计划是一个迭代过程，需要运用科学的计划方法，将时间、经费、人员、设备及各种资源作统筹安排，还要与其它相关项目协调一致。
3．1编制依据
编制项目进度计划的依据包括：项目活动排序后得到的项目网络图、项目活动估算得到的时间值、现有的和能取得的资源、项目时限和重要里程碑、项目约束条件以及其它风险和假设前提。
3．2编制方法
根据不同项目的具体情况采用不同的方法，本文重点介绍编制项目进度计划的3种方法。（1）甘特图法。甘特图又称横道图或条形图，它是通过赋予时间以含义的横道图形式，列出项目活动工期及其相应的开始和结束时间，以反映项目进度信息的一种可视化计划方法。甘特图左侧列出项目活动和工期，顶部列出时间，横道长短代表活动持续时间长短。甘特图的优点是简单、明了、直观、易于绘制，缺点是不能系统地将项目各项活动之间的逻辑关系表示出来，也不能进行定量分析和计算，更不能指出影响项目的关键所在。（2）关键路线法。关键路线法也是通过横道图以日历形式列出项目活动、工期、相应的开始结束时间来进行规划。它与甘特图的不同之处在于，它运用特定的、有顺序的网络逻辑方法来预测总体项目历时，是一种数字分析技术。关键路线法的重要功能是确定项目的关键工作和关键路线，关键路线的确定是将项目网络图中每一条路径上的所有项目活动的历时分别相加，最长的那条路径就是关键路线。（3）计划评审技术。计划评审技术是指当项目或项目某些活动历时估算存在不确定性时，运用加权平均历时估算法，来估算项目历时的网络分析技术。这种技术适用于不可预知因素较多，或从未做过的新项目或复杂项目。计划评审技术网络图的画法与一般网络图画法相同，不同之处在于对项目活动时间的估计和分析［4］。
3．3编制结果
编制项目进度计划的主要成果用表格或图表形式呈现，项目各项活动都标明了各种日期参数的项目进度计划文档。此外，还应包括进度管理计划，用以明确项目进度计划发生变化时的处理原则。
4项目进度控制
项目进度控制是进度管理的重要内容和过程，是前期一系列进度计划工作的延伸，是进度管理中与实施并行的实践性关键阶段。
4．1进度控制依据
项目进度计划是经过论证和批准的，在技术和资源上具有可行性，所以是项目进度控制的主要依据。通过项目跟踪监测和沟通形成的有关项目进度的绩效报告、根据项目进展情况提出的变更请求、编制进度计划时形成的进度管理计划，也都是进行项目进度控制的依据。
4．2进度控制主要工作
控制项目进度的主要工作是：依据作为项目进度基准的项目进度计划，通过跟踪监测和沟通，采用一定的工具和方法进行分析比较，确定项目进度是否发生了变化，如果发生了变化，找出变化的原因，对影响变化的因素进行控制或制定项目进度的补充计划，从而确保进度变化朝着有利于项目目标实现的方向发展［5］。控制项目进度还可以借助项目管理软件来实现。
4．3进度控制结果
进度控制的结果有两种，第一种是项目所有进展均按计划顺利进行的理想情况；第二种是发生一些偏差，并制定一系列纠偏措施，之后更新项目进度计划。两种情况均应记录项目控制的经验或教训［6］。
参考文献：
［1］关保昌，沈建明．现代国防项目管理［M］．北京：军事科学出版社，2011．
［2］祝振铎，董雄报．信息系统项目工作分解结构（WBS）研究［J］．硅谷，2011（15）：78－78．
［3］方德坚，张杨华．也谈软件项目进度管理［J］．赤峰学院学报：自然科学版，2011（5）：15－16．
［4］王芙蓉．软件项目进度计划与风险控制研究［D］．大连：大连海事大学，2009．
［5］徐飞汀．软件项目进度计划管理研究［D］．北京：北京邮电大学，2010．
［6］崔晓明，马力．软件项目进度控制方法研究［J］．计算机工程与设计，2010（12）：2754－2757．
项目整体管理是项目管理全过程的一个缩影，它在各个相互冲突的目标与方案之间进行权衡取舍，以达到或超过项目利害关系人的要求与期望，项目管理人员都应该清楚，项目管理中的每个过程都不可能单独存在，它们之间或多或少都有着关联关系。以PMP项目管理知识体系为例，每个管理过程都是围绕“启动－计划－执行－监控－收尾”这五个过程组展开的。在CMMI中每个PA都不可能单独存在，在其描述里都会有专门的章节来介绍与之相关联的PA。CMMI的PP项目计划与之相关的PA及其之间的关系如图1所示。
图1 PP项目计划与之相关的PA的关系图
第1章 项目整体管理基本概念
项目整体管理既然是项目管理过程的一个缩影，它也相应包含以下几个重要的过程：
1. 制定项目章程
2. 制定初步的项目范围说明书
3. 制定项目管理计划
4. 指导和管理项目的执行
5. 监控项目
6. 整体变更控制
7. 项目收尾
之前我们提到项目整体管理过程是围绕项目管理的“五大”过程组展开的，它们的对应关系如表1所示：
表1 项目整体管理过程分别对应的过程组项目整体管理的过程过程组制定项目章程启动制定初步的项目范围说明书启动制定项目管理计划计划指导和管理项目的执行执行监控项目监控整体变更控制变更项目收尾收尾
项目整体管理过程与CMMI L3中的主要PA对应关系如表2所示：
表2 项目整体管理过程与CMMI L3之间的对应关系项目整体管理过程过程组制定项目章程DAR制定初步的项目范围说明书RD制定项目管理计划PP、CM、MA、RSKM、PI指导和管理项目的执行TS、PI、VAL监控项目PMC、PPQA、RSKM整体变更控制CM项目收尾VER
“指导和管理项目的执行”、“监控项目”和“整体变更控制”之间的关系有些类似于“PDCA戴明环”。它们的输出为下一个过程的输入，它们的输入为上一个环节的输出。为了更好地对项目整体管理进行记忆，七个过程之间的关系可以如图2所示：
图2 项目整体管理流程图
第2章 制定项目章程
项目章程是正式批准项目的文件。该文件应该由项目外部的，能够为项目提供各种资源的项目发起人来进行发布，项目经理可以依据该文件使用组织中的资源。
在项目章程中最好明确项目经理的人选，在某些特殊情况下可能无法做到这一点，那么项目经理的人选最晚也要在项目计划开始前确定，否则项目将无法进行。总的来说，项目经理的指派越早越好。
项目章程中应该明确项目的目的，就像打仗一样总要找个理由。一般可以从以下几个方面进行考虑：
1. 市场需求
2. 运营需要
3. 客户要求
4. 技术革新
5. 法律要求
6. 社会需求
2.1 制定项目章程的过程
制定项目章程的过程如下表所示：
依据
大多数的项目都是为客户提供产品或服务的，因此都会有合同。但如果是为公司内部开发一些产品时，可能就不会有合同的存在，这要视具体情况而定。
项目的工作说明书是对项目所提供的产品或服务的文字描述。对于外部项目来说可以从客户招标文件中获得，例如建议邀请书、信息需求和招标邀请书，有些情况下也许是合同中的某个部分。但工作说明书必须明确以下内容：
经营需求：也就是前面提到的项目的目的。
产品或服务范围说明书：描述所需要产品或服务特征的文件。这个时候的产品范围比较笼统，在项目开始后会进一步细化。
战略计划：所有项目都应该支持组织的战略目标，在做项目选择时应当将组织的战略计划视为考虑的因素。（例如评分法范例中就将组织的战略作为评估标准之一）
事业环节因素是指组织范围内对项目的成功有影响的因素与制度，这些是必须要考虑的。例如公司的文化、行政管理制度、公司相关硬件配备情况、人事管理的制定等等。由此可见项目的事业环节因素还是很重要的。
在项目过程中，有利于项目成功的任何信息都可以从组织过程资产（组织财富库）中进行参考。在CMMI体系中强调的组织过程财富库就是这个概念，通常组织过程财富库中放有各种过程的规范、生命周期模型、风险库、度量库，以及项目结束后总结的经验和教训。因此组织过程财富库分为两部分：
组织进行工作的相关流程
用于组织范围内进行借鉴的知识库
制定项目章程的工具
项目选择的详细方法可以参考“2.2项目选择方法”。
在制定项目章程时的方法论是指相关项目管理的标准或过程，正式和非正式的都可以。只要有利于制定项目章程好的经验都可以作为方法论的一个部分。
项目管理信息系统很多企业都有，但其功能都不一定全部覆盖项目管理的方方面面，有的是做缺陷管理的，有的是做工作任务分配等等。
专家可以是公司内部的，也可以是从外面聘请的。专家在这里主要是对项目章程的依据进行判断。
成果
经过以上过程项目章程被最终制定。
2.2 项目选择方法
合同和项目说明书有了，公司每年的项目会有很多，到底应该开展哪个项目呢？在CMMI中可以通过DAR的决策流程进行筛选，最终找到合适的项目。有些时候复杂的项目选择过程也被视为一个项目的阶段。其中项目选择的方法可以分为以下两类：
1. 经济模型
经济模型又称为效益测量法。例如：项目间的比较、评分模型、效益贡献等。
2. 数学模型
数学模型又称为有约束的优化法。例如：线性、非线性、动态、整数、多目标规划算法等。
机会成本
在进行项目选择时往往会提到“机会成本”的概念。例如：在众多项目选择时只能选择一个项目，那么在作出选择后，在放弃的众多项目中机会最大的那个项目所产生的利润，我们就可以称它为机会成本。
例如以下三个项目它们的利润分别是：
项目A：100万
项目B：50万
项目C：80万
最后公司做出的决策是选择项目A，那么这个时候项目的计划成本就是80W。假如项目C被选中，那这个时候的机会成本就是100万。
Ranking评分法
另外一种常见的方法就是“Ranking评分”法。首先要制定项目的评估标准，以及每个标准所占的权值，然后对项目依次打分。例如A公司项目评分表：
经过评分筛选，A公司选择“项目B”作为本年度的首选项目。
决策树
最后再为大家介绍另外一种项目选择的方法“决策树”法。例如我们每天从家去单位上班，可能会有不同的路线，根据不同的路况抵达公司所需的时间也许都不相同。
假如我们从家到公司有两条路线可以选择，走第一种路线时，60%的情况下30分钟左右可以抵达公司，40%的情况下60分钟可以抵达公司；走第二种路线时，50%的情况下30分钟左右可以抵达公司，30%的情况下20分钟可以抵达公司，20%的情况下由于堵车80分钟才可以到达公司。
其决策树如图3所示，这时我们将每种可能性进行求和计算，最终“路线1”的期望值是42分钟，“路线2”的期望值是37分钟，所以每天早上从家去公司上班应该选择“路线2”。
图3 决策树
第3章 制定项目初步范围说明书
项目范围初步说明书确定了项目的范围，即所需要完成的各项事宜。项目说明书是作为项目验收和项目范围控制的依据。项目范围初步说明书可以利用项目发起人或赞助人所提供的信息进行编制，经过逐步细化后就形成了项目范围说明书。其内容包括但不局限于以下内容：
1. 项目或产品的目标
2. 验收的标准
3. 项目的范围边界
4. 产品或服务的要求与特征
5. 项目的可交付成果
6. 假定
7. 约束
8. 初步识别的风险
9. 里程碑
制定项目初步范围说明书的过程如下表所示：
* 本过程与之前章节相同的部分就不再重复。
工具
制定项目初步范围说明书的方法论确定了协助项目管理团队制定与控制项目初步范围说明书变更的过程。
第4章 制定项目计划
项目管理计划的内容根据项目的复杂度不同而有所不同，项目管理计划包括了很多附属计划，例如：进度计划、产品集成计划、配置管理计划、度量计划、风险管理计划、采购计划、过程改进计划、质量保证计划、费用管理计划等等，甚至里程碑清单、配置项列表、资源日历等也都属于项目管理计划的范畴。因此项目管理计划可以由一个或多个分计划，以及其他事宜组成，其详细程度只要满足项目的具体需要就可以，
制定项目管理计划的过程如下表所示：
* 本过程与之前章节相同的部分就不再重复。
依据
之前已经讲过项目管理计划可以由多个从属计划组成，每个从属计划可能都对应一个管理过程。例如在PMP中可以就对应“范围、时间、成本、质量、人力资源、沟通、风险、采购”这8个管理过程；以CMMI L3为例就对应了18个PA。
因此在制定项目管理计划时项目管理的各个过程就理所应当的作为其制定计划的依据。
工具
在制定项目管理计划的方法论中确定了协助项目管理团队制定和控制项目计划变更的过程。
配置管理系统包含了变更管理系统，它本身也作为项目管理信息系统的一个部分，比较典型的就是微软的TFS，TFS包含了代码版本管理的工具和工作任务的分配等功能，另外它还与MS Project等Office工具进行了集成。
第5章 指导与管理项目执行
在本过程中要求项目经理和项目团队依据项目管理计划，采取各种行动完成项目范围说明书中定义的工作。
指导与管理项目执行的过程如下表所示：
* 本过程与之前章节相同的部分就不再重复。
依据
首先从指导与管理项目执行的定义来看，项目管理计划是其依据的根本。
其次大家回想一下在自己的项目中是否都开展了以下工作？
1. 软件项目的变更是最常见的，当某个变更被批准后项目组就要去执行。
2. 不管是PMP还是CMMI都专门对风险的管理过程进行了定义，风险的三要素就是“风险的概率”、“风险的严重程度”和“风险的影响”，在项目实施的过程中项目经理经常都会开展风险的预防措施以降低风险发生的概率。
3. “同行评审”在测试理论范畴内也称作“静态测试”，在CMMI的VER中专门定义了如何进行“同行评审”，在VAL中也定义了哪些地方要开展“同行评审”活动。因此在“同行评审”和测试过程中发现的各种缺陷都要被跟踪并最终得到解决。
4. 在“同行评审”和测试过程中发现的各种缺陷得以解决后，项目组都要对其进行再次的核对。
5. 在项目进行过程中假如QA人员发现某些环节没有按照规范开展相关活动，那么项目组就要开展相应的纠正措施。
以上工作都要经过相关人员确认并批准后方可实施。
最后行政收尾和验收工作也应该属于项目实施的一个部分，因此也要作为“指导与管理项目执行”过程依据的一部分。这里的收尾特指行政收尾的过程，软件项目的生命周期都分为不同的阶段，每个阶段的里程碑评审的过程其实就是在做行政收尾的部分工作。因为里程碑评审也称为阶段末评审，具体要开展哪些评审活动是在CMMI的VAL中定义的。与客户一起进行的验收工作只是行政收尾的一个部分，例如设计完成后，开发人员就相当于设计人员的客户，因此设计完成后的评审也就相当于设计人员与开发人员进行验收交接的过程。
工具
指导与管理项目执行的方法论确定了帮助项目团队执行项目计划的过程。
成果
1. 项目经过实施后最终应该生成可交付成果给客户。可交付成果是指任何在项目管理计划中记录，并为了完成项目而必须产生和提交的独特的、可核实的产品、成果或提供服务的能力。在软件项目中除了代码以外还包含相关的文档。
2. 在项目过程中往往会由于各种原因发生变更，因此变更的请求也是在项目实施过程中产生的。变更的请求应该得到批准后才能实施。
3. 对于批准的变更在项目过程中应该得以实施，因此实施的变更请求也是在项目实施过程中产生的。
4. 对于已经配置的预防风险的措施一定要执行。
5. 对于QA所发现的未按规范执行的过程应该被纠正。
6. 对于QC所发现的各种缺陷也应该被弥补。
7. 项目实施过程中特别是到了里程碑时，往往需要对项目的绩效进行总结。项目的绩效也就是指项目各种活动和参数的状态。例如：项目计划完成的百分比，尚未完成的任务有哪些，批准并已经开销的费用有多少等。
第6章 项目监控
项目监控是监控项目的启动、规划、执行和收尾所需的各个过程。项目监控与配置管理一样都贯穿了项目的整个生命周期。在CMMI中项目监控主要是由项目经理和QA人员按照PMC和PPQA的定义开展相关工作。
项目监控的过程如下表所示：
* 本过程与之前章节相同的部分就不再重复。
依据
项目经理和QA人员如何对项目进行监控呢？监控就是在一定时期或阶段，以项目计划为依据与项目的绩效进行对比，以找到实际与计划之间的差距。因此项目管理计划和项目的工作绩效信息都应该作为项目监控的输入条件。
如果某些变更没有获得批准，项目组也要对其进行监控防止其实施。
工具
项目监控的方法论确定了协助项目管理团队按照项目管理计划监控挣值进行的项目的过程。
EV挣值是软件度量的一个重要组成部分，也是项目绩效的一个重要工具。
成果
1. 对QC所发现的各种缺陷都应该提交出来，并且给予推荐的解决方法。
2. 对所识别的风险也要给予推荐的预防措施。
3. 对于没有按照规范开展的活动，QA也要给出推荐的纠正措施。
这里使用的都是“推荐”两个字，因为很多时候发现问题的人并不是项目组内的，为了互相尊重，更好的进行沟通，出于礼貌的原因要给项目组以建议，而不是命令。
4. 由于项目监控强调使用EV挣值技术，其作为软件度量的重要组成部分。度量的两个目的就是：客观反映项目的绩效，对项目的未来发展进行预测。
5. 由于项目监控进行项目计划与项目工作绩效的对比，有些不一致的地方会引发重大变更，因此有时会产生变更的请求。
第7章 整体变更控制
变更管理属于配置管理的一个部分，因此变更管理也是贯穿于整个项目生命周期的。在CMMI中变更分为两个级别：一般变更和重大变更。 在PMP中变更控制有3个主要目标：
1. 建立一种方法始终如一地识别与提出对既定基线的变更，并估计这些变更的价值与有效性。
2. 通过考虑每一项变更的影响，不断确认与改进项目的机会。
3. 建立将所有变更始终如一地通知项目利害关系人的机制。
变更过程所涉及到的配置管理活动：
1. 配置项的识别
2. 配置状态的核算
3. 配置审计
工具
变更控制的方法论有助于项目管理团队实施项目整体变更控制的过程。
第8章 项目收尾
项目收尾过程组分为行政收尾和合同收尾两个过程。他们都要对所做的产品和工作进行核实。在软件项目组大多数情况下都是先进行不同阶段的行政收尾，最后才与客户进行合同收尾。假如项目是没有客户的，那么也就不需要合同收尾了。
行政收尾在CMMI中对应的是VAL确认过程，它不但包含了客户进行验收测试的过程，还包含了不同工种之间的交接过程。行政收尾时还要将项目收集到的信息进行记录和分析，将经验和教训进行总结，并提交组织财富库进行保存。
1. 确定利害关系人批准变更和所有级别可交付成果要求的行动与活动。
2. 确认项目已经满足所有赞助人或客户的要求，核实所有可交付成果已经提供并验收，以及确认所需要的行动与活动已经遵循出口准则。
合同收尾在CMMI中对于的是SAM供应商管理，包括结清与项目相关的合同协议，以及确定配合项目正式收尾的有关活动。这一过程即涉及产品的核实，又涉及行政收尾。合同的提前终止属于合同收尾的特例。
项目收尾的过程如下表所示：
* 本过程与之前章节相同的部分就不再重复。
依据
1. 在进行项目收尾时合同、项目计划和工作绩效是必不可少的依据
2. 可交付成果是项目收尾的内容
3. 事业环境是需要考虑的因素，例如：利害关系人的因素
4. 组织过程资产是待更新的
工具
项目收尾的方法论有助于项目管理团队实施行政收尾与合同收尾。
成果
行政收尾是建立和制定将项目产品或服务移交生产或运营的程序，其处理的对象如下：
1. 确定利害关系人批准变更和所有级别可交付成果所要求的行动与活动。
2. 确认项目已经满足所有赞助人、客户和其他利害关系人的要求，核实所有可交付成果依据提供并验收，依据确认项目已经达到完工与退场的条件。
3. 达到项目完工或退场标准所必须进行的各种活动。
合同收尾提供了一种逐步和顺序处理合同条款，以及任何必要的完成与出口准则的方法。
可交付成果包含了很多内容，其中有些是不需要交付给最终客户的，例如：评审的记录、会议的通知等。
项目收尾中一个很重要的工作就是对项目进行总结，并将其保存到组织财富库中供以后其他项目进行参考。总结并更新组织财富库的内容包括以下方面：
1. 正式验收的文件表明客户已经正式验收了可交付的成果，例如与客户在验收时经常会使用到UAT。
2. 项目档案是指项目过程中产生的各种文件，例如风险列表、项目日历等。
3. 项目收尾文件是表明项目已经完成，可交付成果已移交给客户的正式文件。如果项目在完工前就提前终止，那么该文件会记录为什么项目会提前终止，并正式将项目已经完成和尚未完成的工作成果移交给他人所需的程序。
4. 历史信息，经验和教训。
来自：tech.it168.com/m/-01-03/200801031454422.shtml
摘要：目前，我国软件业市场发展迅速，软件行业所创造的产值收入在国民经济中已经占据了一定的地位。我国软件市场开发前景大，发展速度快，对软件项目的开发进度管理提出了更高的要求。为了保证软件开发项目的顺利完成，避免出现项目延期及进度滞后变更等不良状况，现对软件项目开发进度管理进行深度研究。文章通过对关键链项目管理方式方法及作用的研究，探讨敏捷软件开发项目的进度管理研究，旨在为做好敏捷软件开发项目的管理工作提出意见建议。
关键词：关键链项目管理；敏捷软件开发；进度管理
随着软件行业的深度发展，软件开发项目的复杂性大大提高。软件项目开发中的需求变化性较强，开发的资金、技术支持等条件不断变化，导致传统的软件开发项目管理方法已经不能满足日益进步的开发需求。基于关键链项目管理思想的敏捷软件开发就是在这一大背景下产生的，敏捷开发能够实时根据需求变更改变开发进度管理，注重人才价值与软件价值的互通，注重团队合作，注重与需求方客户合作，所以越来越多的软件行业、企业与开发团队开始采用这种软件开发模式。
1基于关键链项目管理的敏捷软件开发项目现状研究
1.1关键链项目管理综述
关键链项目管理提出于，是根据项目管理发展状况将项目管理中的约束理论与实际管理工作实践相结合所提出的创新型的、适用性较强的.管理模式，对各行业的项目管理工作都能起到很好的推广和借鉴作用。[1]关键链项目管理法通过对项目的进度计划及约束项目管理因素的分析，合理调度项目计划中的全部资源，消除影响项目进度的约束性因素，减少不合理的工作计划对项目本身的影响，集中管理项目时间进度，控制项目整体进度。关键链项目管理是一种新型的管理模式，包含科学的项目进度管理方法及项目整体资源的合理调配方法，既能满足项目发开中进度计划的需求又能保证项目目标的完成，同时又能有效的解决项目进行中影响项目进度的风险性因素，这些有效的项目进度管理方式都给敏捷软件开发项目提供了很好的管理参考。
1.2敏捷软件开发项目的现状
我国的敏捷软件开发项目由于起步晚，缺乏实践经验，正处于探索研究阶段，其过程中必然出现很多问题。其中，造成敏捷软件开发项目管理出现问题的最重要缺陷因素就是项目进度的管理，体现在以下几个方面：第一，忽略外界因素对项目开发进度管理的约束性因素。[2]敏捷软件开发是一个涉及面广，复杂性高的项目工作，很多外界因素包括资金、技术、资源、人员等都会对项目进度造成重大影响，而现在的敏捷软件开发项目并没有对其产生足够重视。第二，约束因素问题得不到有效解决。制约敏捷软件开发项目进度的因素有很多，在得不到重视的情况下解决问题变得更加困难，这就大大延长了项目的工期，同时又带来了新的不可预计的影响因素出现的风险几率。第三，对项目参与人员的主观能动性重视不足。主观能动性不强，工作态度不积极，缺少创新思考，缺乏解决问题的创新思路，这些都会大大延缓项目的进度，拖慢项目工期，使得敏捷软件开发项目整体失败。
2.1改变管理模式
敏捷软件开发项目环节多，项目运行复杂，因此要改变旧式的分散管理模式，将成本管理、资源管理、风险管理及进度管理进行集中控制，做到管理统一。这样有利于项目成本的节约，项目资源的合理调配，项目风险的有效控制，保证项目的正常运行并顺利完成。[3]在做到集中管理的同时要侧重项目进度管理，对项目进度管理保持高度的重视。因为项目进度管理是整个敏捷软件开发项目的重点工作，各种因素都会对项目进度产生严重甚至决定性的影响，只有侧重项目进度管理工作，保持高度重视才能保证项目进度的顺利完成，避免项目延期甚至项目失败的情况。
2.2合理调配项目资源
敏捷软件开发项目进度的管理离不开项目资源的支持，其中最重要的就是资金、技术及人员的支持。资金支持不及时会导致项目进度的拖延；技术更新支持不及时会拖慢甚至暂停项目进度；管理人员及技术人员落实不到位会严重影响项目的整体进度，给敏捷软件开发项目的进度管理造成极大困难。所以，要合理调配项目资源，将整体项目的资金、技术、人员更多的投入到项目进度管理环节，保证项目进度的良好进行进而保障敏捷软件开发项目的顺利完成。
2.3及时处理约束因素
在敏捷软件开发项目的进度管理中要及时解决制约进度的各种因素问题，避免因项目资金、技术、人员、管理等项目资源的匮乏问题产生的进度滞后现象。出现影响项目进度的因素必须加大各种资源的投入，及时解决，保证项目进度。同时，问题的解决方式要在尽量满足项目进度的前提下寻找针对性的或者可替代性的解决方法，杜绝因困难问题难以解决而进行进度计划修改，保证项目进度，更好的做好项目进度管理工作。
2.4发挥人员主观能动性
在敏捷软件开发项目进度管理工作中要重视人的作用，激发其工作积极性与创造性，解决敏捷软件开发项目进程中的技术难题及工作适应性问题，丰富项目的人员、技术资源，保障项目进度的按期进行甚至因技术创新、管理有序而提前完成项目工期任务。
3结束语
关键链项目管理是一种先进的项目管理模式，能够为项目的正常运行直至顺利完成提供管理保障。基于关键链的敏捷软件开发项目进度管理，要做到侧重进度管理，及时解决阻碍进度管理工作的资源问题，合理调配项目资源，保证项目进度管理工作的顺利进行，进而保障项目的顺利完成。同时要结合实际情况，对敏捷软件开发项目进度管理进行科学合理的调整，保证项目完成的高质、高效。
参考文献:
[1]胡丹.基于关键链的敏捷软件开发项目进度管理研究[D].浙江工业大学，.
[2]张雪娇.基于关键链技术的敏捷软件开发项目管理研究[D].华中科技大学，.
[3]杨光.软件开发项目进度管理模型构造与系统仿真[D].北京邮电大学，.
软件开发项目进度管理研究论文
软件开发项目具有需求不确定性、时间期限严格等特点，由此决定了软件开发项目进度管理非常必要，但同时也存在着一定的难度。重点对软件开发项目进度管理进行分析研究，明确软件开发项目进度管理的4个主要步骤：根据项目目标和现有资源，进行项目工作分解;在项目工作分解结构图的基础上，确认项目活动，用科学的方法估算活动时间并排序;编制项目进度计划和进度管理计划;在项目实施过程中，对项目进度进行跟踪和监控并定期评估，必要时需根据实际情况按一定规则，变更项目进度计划。
0引言
软件开发项目进度，是指完成整个软件开发项目所需活动的过程和时间周期。软件开发项目进度管理是为了确保项目按时完成而对其各项活动及阶段进行的管理。软件开发项目进度管理包括4个步骤，其中软件开发项目进度计划编制和进度控制是实际工作重点，但编制项目进度计划前，应先分解项目，明确该项目包含的活动，并对项目活动进行排序[1]。下文中“软件开发项目”简称为“项目”。
1项目工作分解
一个项目提出后，根据项目目标确定项目的研究范围后，应对项目进行分解，将可交付成果和复杂的项目逐步分解成较小的、便于管理的组成部分，并创建工作分解结构图，为项目进度计划打下基础[2]。
1.1项目工作分解的作用
项目分解的作用主要体现在两个方面：
(1)便于进行综合性方案设计。工作分解就是在项目目标的指导下，在任务范围中从粗到细、从简到繁，逐步分析，直到可执行的最小独立单元，这样能够较好地保持项目的系统性和完整性，策划者据此可以通盘考虑实现项目目标应完成的工作，能够清晰地分辨任务实现的重点和步骤、完成周期、成本费用，并评估风险，同时，也有利于发现潜在的不明确内容，为项目总体设计提供可靠依据。
(2)便于分配任务和明确责任。项目工作分解把项目划分成多个独立性较强的任务单元，明确区分各任务的目标、范围和界限，对每个工作任务提出具体要求，便于在执行项目时，落实责任者或完成单位。既可以作为委托工作或下达任务的依据，也便于观察、了解和控制整个项目过程。
1.2项目工作分解结构的依据、原则和方法
项目工作分解结构的主要依据是前期取得的项目主要资料和其它相关项目的借鉴性文件，包括项目需求文件、任务(合同)范围说明、本项目的其它资料、其它项目的相关资料等。
工作分解结构的原则是：在各层次上保持项目内容的完整性，不能遗漏任务必要的组成部分;每个项目单元只能从属于某一个上层单元，不能同时交叉从属于两个上层单元;相同层次的项目单元应有相同的性质，各项目单元应有明确的任务界限，保持各项目单元的独立性;项目分解的原则应事先确定，同一层次上分解出的项目单元，其分解的原则应该是一致的。
工作分解的方法有自上而下和自下而上等方法。自上而下法是先明确项目最终产品，然后确定中间可交付成果，再对主要可交付成果细分，直至每一个工作只包含一个可交付成果;自下而上法是首先明确项目的所有可交付成果，然后将可交付成果进行逻辑分组，接着将每组汇总成一个母元素，成为上一层次的元素，再将高一层次的元素进行分组、汇总，以此类推，最终汇成一个母元素。
1.3项目工作分解结构一般步骤
工作分解首先应识别项目的主要要素，项目的主要要素就是项目的主要交付物，然后对识别出的主要要素作进一步细化，分解出更详细的有形的、可检验的产品或服务，在此基础上，选择自上而下或自下而上的方法编制工作分解结构图(也可以使用单位标准模板或以前项目的模板)，编制完工作分解结构图后，应编制详细的结构图说明，说明的内容包括各要素的界定、说明、估算经费、时间、预安排的责任部门、人员等。
1.4项目工作分解结构输出
项目工作分解的输出结果包括项目结构图和相关说明。项目分解结构图(WBS)是通过分解技术，将项目任务按照其内在性质和结构逐层细化而形成的示意图。它涵盖为完成项目交付物需进行的所有项目工作，为项目责任分配和任务协调提供依据。项目结构说明包括各层要素的详细描述、工作说明、负责组织、进度日期、成本预算等。
2项目活动确认及排序
完成项目工作分解后，应对所确定的可交付成果的具体活动进行分析确认和排序，为编制项目计划打基础。
2.1项目活动确认
依据项目工作分解结构的成果、其它关于项目范围的说明性文件、项目约束条件、项目的假设前提、管理计划和单位的历史信息等[3]确认项目活动。对于一些小项目，可通过大家集体研究讨论，集思广益的方法，形成可行的活动清单并估算所需时间，对于较大、较复杂的项目，则需要由相应领域专家研讨或使用一定的工具和方法来确认项目活动，这些方法包括：进一步使用活动分解技术、采用已有模板法、领域专家判断法等。项目活动确认后，形成的结果包括：涵盖项目所有必要活动的项目活动清单、描述项目过程中基本关键点的项目里程碑图等，此外，还应适时更新项目工作分解结构图和项目总体管理计划。
2.2项目活动排序
确认了项目活动，要识别各项活动的相互关系，项目活动之间的关系也称为项目活动之间的先后信赖关系，包括人们无法改变的硬逻辑关系和需由各种因素综合确定的软逻辑关系，在项目活动排序时，要根据项目活动清单、项目里程碑和一些约束条件，先识别并安排硬逻辑关系，再安排软逻辑关系，同时要考虑项目假设条件和外部条件的影响。项目排序图的编制方法可以采用节点图法或箭线图法。项目排序的最终结果，是描述项目各项活动相互关系的项目网络图及其活动说明，项目网络图应包括项目的主要活动和情况，并明确各活动之间的逻辑关系或依赖关系，在网络图的说明中，应描述活动排序的基本方法，对于特殊的排序应进行说明。
2.3项目时间估算
项目时间估算是指根据项目范围、资源及相关信息，对项目已标识的各活动持续时间所进行的估计。大多数项目活动时间的长短，取决于人力、物力、财力及资源的多少，同时还受人的能力、物资质量和设备效率的影响。对项目活动时间进行估算时，即要考虑各活动所消耗的实际工作时间，也要考虑活动的延迟时间。因此，一般由熟悉项目活动或有经验的人员或团队，采用专家判断法、类比估算法或模拟估算法完成。
3项目进度计划编制
编制项目进度计划，是综合分析项目活动排序、持续时间、资源需求和进度约束，确定每一个项目活动及整个项目起始和完成日期，建立一个相对科学可行的项目进度计划的过程。编制项目进度计划是一个迭代过程，需要运用科学的计划方法，将时间、经费、人员、设备及各种资源作统筹安排，还要与其它相关项目协调一致。
3.1编制依据
编制项目进度计划的依据包括：项目活动排序后得到的项目网络图、项目活动估算得到的时间值、现有的和能取得的资源、项目时限和重要里程碑、项目约束条件以及其它风险和假设前提。
3.2编制方法
根据不同项目的具体情况采用不同的方法，本文重点介绍编制项目进度计划的3种方法。
(1)甘特图法。甘特图又称横道图或条形图，它是通过赋予时间以含义的横道图形式，列出项目活动工期及其相应的开始和结束时间，以反映项目进度信息的一种可视化计划方法。甘特图左侧列出项目活动和工期，顶部列出时间，横道长短代表活动持续时间长短。甘特图的`优点是简单、明了、直观、易于绘制，缺点是不能系统地将项目各项活动之间的逻辑关系表示出来，也不能进行定量分析和计算，更不能指出影响项目的关键所在。
(2)关键路线法。关键路线法也是通过横道图以日历形式列出项目活动、工期、相应的开始结束时间来进行规划。它与甘特图的不同之处在于，它运用特定的、有顺序的网络逻辑方法来预测总体项目历时，是一种数字分析技术。关键路线法的重要功能是确定项目的关键工作和关键路线，关键路线的确定是将项目网络图中每一条路径上的所有项目活动的历时分别相加，最长的那条路径就是关键路线。
(3)计划评审技术。计划评审技术是指当项目或项目某些活动历时估算存在不确定性时，运用加权平均历时估算法，来估算项目历时的网络分析技术。这种技术适用于不可预知因素较多，或从未做过的新项目或复杂项目。计划评审技术网络图的画法与一般网络图画法相同，不同之处在于对项目活动时间的估计和分析[4]。
3.3编制结果
编制项目进度计划的主要成果用表格或图表形式呈现，项目各项活动都标明了各种日期参数的项目进度计划文档。此外，还应包括进度管理计划，用以明确项目进度计划发生变化时的处理原则。
4项目进度控制
项目进度控制是进度管理的重要内容和过程，是前期一系列进度计划工作的延伸，是进度管理中与实施并行的实践性关键阶段。
4.1进度控制依据
项目进度计划是经过论证和批准的，在技术和资源上具有可行性，所以是项目进度控制的主要依据。通过项目跟踪监测和沟通形成的有关项目进度的绩效报告、根据项目进展情况提出的变更请求、编制进度计划时形成的进度管理计划，也都是进行项目进度控制的依据。
4.2进度控制主要工作
控制项目进度的主要工作是：依据作为项目进度基准的项目进度计划，通过跟踪监测和沟通，采用一定的工具和方法进行分析比较，确定项目进度是否发生了变化，如果发生了变化，找出变化的原因，对影响变化的因素进行控制或制定项目进度的补充计划，从而确保进度变化朝着有利于项目目标实现的方向发展[5]。控制项目进度还可以借助项目管理软件来实现。
4.3进度控制结果
进度控制的结果有两种，第一种是项目所有进展均按计划顺利进行的理想情况;第二种是发生一些偏差，并制定一系列纠偏措施，之后更新项目进度计划。两种情况均应记录项目控制的经验或教训。
第一，要认清形势。
我觉得任何事情一定要在认清形势的基础上再开始考虑如何计划，这样才能让别人满意你的结果而自己也能获得较大的收获。一开始，*总就强调过，我们不应该把这个项目当成还是课堂的项目，完成老师的硬性要求，而是一个真正的公司的项目。这样我们就可以考虑到时间方面的限制和我们在技术上的优势，而在需求上与甲方PM交涉。我们公司内部在经过一番讨论后，确定了最利于我们完成该项目而又达到甲方PM要求的项目方案，然后与甲方PM进行商榷，在与甲方PM分析了各种情况后，最后终于敲定了让甲方PM满意，而我们自己又认为能完成得比较好的需求。
第二，相信团队合作才可能把项目做到最好。
从整个项目的过程来看，团队合作中需要沟通、分工、协作和监督。只有做好这四项才算是一个好的合作团队。首先，团队合作最基本的技能就是沟通。沟通的目的就是让别人了解你的想法，因为每个人考虑问题的时候总会有各种各样的偏差，我们只有沟通很好的沟通来综合所有人的好的想法，以减少走弯路，而让事情进行的更顺利。我们公司内部的沟通是比较随意的，因为大家都比较熟悉，任何时候有什么想法都会提出来，然后大家一起讨论，并得出最后的结果。而整个项目的进行中很重要的又比较正式的沟通就是与甲方PM的沟通，完成这个项目其实也是与甲方的合作的过程，因为甲方PM是在职人员，他的人生阅历比我们多，而且沟通能力是很强的，我们从与他的'沟通中都学到了不少知识与技巧，其中很多都是我们以前做老师给我们的作业项目所没有的但却是很重要的。我们其实也很感谢甲方PM，他很认真负责地跟我们沟通，我们在沟通中用词不当或犯什么错误时，他都会指出来，并改正我们的说法，因此单从与他的沟通中就学到了不少以后工作时将会用到的实在的知识。
其次，团队合作的关键环节就是在有效沟通的基础上进行分工，分工要明确，落实到每个人。由于这个项目时间的限制和语言的不熟，这个项目必须由我们公司所有成员都尽努力才能做好，这样就需要合理的分工。比如我们这个项目中分为总的来说可以分为界面，核心算法，和数据库这三个模块，而算法也分有好几种，只有把它们分配给对各模块感兴趣的人做，让他们在规定的时间里进行钻研努力，才能达到最好的效果。我们组在这方面做的比较好，苏总在我们项目提出时，就根据各人的能力和兴趣把每个人分配在不同的主要任务中，在每周与甲方PM定好下阶段的提交物后，都是仔细地把任务均匀地分配给各个人。因为我们组是按照每人的工作量来最后算成绩的，均匀地分配任务就不会造成组员的不满了。再其次，团队合作中协作是必不可少的。在项目组中各成员都明确了任务后，就需要大家单独工作的同时去配合其他人。尽管大家都有不同的任务，但是相互之间在一些问题互相协作的话，不仅可以提高各个任务进行的速度，也利于对项目中别的模块的了解。
由于我们组的成员都是比较熟悉的，所以在协作方面还是不错的，比如某人搭建完环境后，帮其他的组员在他们自己的电脑上搭好，这样就会节省大量的时间，而这名组员也可以把时间用在别的事情上。而且虽然我们进行了明确的分工，但毕竟是一个项目，之间还是有很大的关联的，这样在编码的时候，都会进行讨论和互相帮助，这样就减少了错误的可能性也节省了时间。最后，项目经理的监督是必不可少的。一个团队中，难免有人会偷懒或拖延，或者完成任务的质量不理想，项目经理就要对这些人进行督促和提出合理的建议。通过监督了解项目的进展、质量、问题等并及时的调整资源利用情况，以保证项目的成功。虽然我们组没有出现上面提到的种种情况，苏总还是进行了严格的监督，我们每人都是按照苏总给我们的计划提交相应的产品给他，但质量是参差不齐的，苏总都会进行审核，然后给出建议，让我们修改优化后，他才把产品提交给甲方PM，因此甲方PM一直对我们的提交物比较满意，这与苏总的努力是分不开的。
第三，要详细制定计划，并严格按照计划来执行。
这次的项目周期很短，因此计划就显得格外的重要，只有进行详细的计划，我们才有紧迫感，并要求自己抓紧时间完成当天的任务。对比去年的软件工程课，那个项目与这个项目的规模差不多，但是开发周期是真个学期，每个阶段都显得很长，就算制定了一个计划，也没有按照那个计划来，拖个几天是很正常的，今天不能完成明天做，因为有的是时间，这样越来越松懈，就把大量的任务往后压，到最后就拿质量换时间了。而这个项目一开始就让人有很强的紧迫感，计划几乎是细到天的，我们每人组员都要在周报中详细汇报这周中每天做了什么的，PM通过周报来很好地管理进度，当然必要的情况下还是会做相应的变动的。到最后我们的项目如期完成了，而且结果是比较让人满意的，这样的结果对比去年的就会让我以后在做别的事的时候，更加自觉地详细做计划并严格按照计划执行。另外，这样做的好处就是让人感觉每天都很充实，没有虚度光阴，每次我浑浑噩噩地度过一天而没有学到任何东西后，我都有一种罪恶感，感觉对不起父母和关心自己的人，而制定了详细的计划并认真执行的话，每天都会以饱满的精神状态来学习，心情也很好，这样才是健康的生活方式。
虽然通过这门课，我的经验更佳丰富了，个人编程能力，沟通能力等都有了一定提高，但是我也感觉到了自己的诸多不足，比如我的沟通能力还有待提高，这或许不是一两天的问题，但是我会更加注意，并在以后的生活学习中，留心并提高沟通能力。还有不足就是项目期间，热情还不是不够，每次都把相应的任务做完后，就不管了留给PM，然后等下一个任务，而自己却没有更加用心地去考虑如何把整个项目做的更好，或许是因为我不是PM的缘故吧，在以后的项目中，我要改变这种心态，以更加积极的热情去参与项目。
★ 软件项目管理论文
★ 项目管理策划书
★ 项目管理心得
★ 项目管理工作总结
★ 项目管理规章制度
★ 项目管理岗位职责
★ 项目管理经验总结
★ 项目管理总结
