项目进度计划时的系统观

1、培养做项目进度计划时的系统观客户最关注什么 产品质量往往是基本，这是一个默认属性。但是做到哪个度仍然可以谈，所以首先要清楚用户对质量要求的优先级，一般来言可能是可用-易用-性能-安全。这一般叫测试类型，另外就是测试的等级表明测试要达到何种覆盖率或程度。这些都影响到项目周期。 除了默认质量要求，项目周期往往是客户最为关注的。这个往往并不是经过详细的估算，排完进度了再确定下来的，而是项目一开始往往就由客户敲定，而项目范围往往也是在合同就会明确下来。所以跟用户敲项目周期就显得很重要了，根据软件工程和经济学得出结论是：对于一个软件项目我们可以考虑投入更多资源来缩短项目周期，但当项目周期缩短到一定度以后

2、，投入再多的资源也没有用。因此项目经理谈判的底线为在不考虑人力资源情况下项目能够达到的最短周期，如果这个最短周期还达不到客户要求，必须缩减项目范围而不是牺牲产品质量。 项目计划重点就是通过调整各个要素，保证项目能够有8,9成以上的胜算，对于影响到项目成功的全部列入风险和关键问题进行跟踪。项目经理在计划完成后一大半的时间都应该花费在消除不确定性上。项目失败往往并不是进展过程出现太多异常，而是一开始项目经理就不清楚自己有几层把握，一开始也没有分析清楚有哪些不确定性和关键要素。 项目周期敲定了再排进度 如果简单的认为项目周期确定了再排进度就只能是倒排进度，那说明还没有真正理解各要素的平衡和进度安排的

3、实际含义。项目经理往往根据项目周期倒排不切实际的进度计划，那导致项目进度延期就是必然的事情了。 制定进度前最重要的仍然是根据人力资源情况和项目周期来综合考虑生命周期模型的选择，是瀑布还是增量迭代，这个直接影响到WBS的分解。而WBS中我们又最关心工作包或任务的粒度问题，这个需要和可用的人力资源配合起来，一个功能模块分解细后可以更多的人力资源参与进来，使更多的任务能够并行，但无疑会增加前面接口设计和后期集成的工作量。当接口设计和集成工作所花费时间大于开发任务并行所缩短的时间时候，这个时候就到了分解的最小粒度。在这个粗细粒度间就是可以通过调配人力资源能够获取的最大进度压缩。 在IT项目中由于岗位角

4、色划分，往往并不适合采用关键路径的方法来预计进度。进度安排关键在让所有人都尽可能早的动起来，在这里可以考虑的思考方式是: 1.关注项目关键资源，关键资源必须优先安排来执行关键任务 2.通过组件细分和迭代，增加后期集成时间，但缩短前期关键路径等待时间 3.通过每日构造将测试也迭代起来 4.进度紧往往更不该跳过需求和总体设计评审而直接编码，后期返工往往是灾难性的 最有效的方法论和过程 在裁剪过程的时候，必须清楚的认识到哪些过程元素是保证项目成功的核心要素，哪些是可以省略的。XP方法论对于任何一个功能的开发仍然是遵循小瀑布，而不是跳过程。一个设计思路可以在纸面设计草图后就可以开始编码，后期再形成规范

5、的文档，但决定不是说不经过设计就开始编码。需求，DEMO原型，总体架构，数据库设计，评审，项目开发模式和规范都是重要的元素，都应该最有效的去发挥作用。因此以下是可以考虑的关键点 1.DEMO原型必须和用户沟通确认，但需求阶段技术架构工作可以并行 2.需求和架构，数据库必须经过评审 3.架构或总体设计完成后必须进行培训，强调后续的开发模式和规范 4.架构开发不一定要全部完成才能开始后续工作，但事先要定义清楚接口 4.详设可以出纸面草图，面对面沟通后即可开始编码，后期再补规范文档 5.对于100%要做的不涉及业务规则功能可提前编码，如一些基础表的维护项目计划技巧对于现今的软件开发人员来说是必需的。

6、这里有一些帮助您有效地计划下一个项目的建议。认识到信心来自规划的过程，而不是计划本身。创建项目计划会迫使您早在编写代码之前就考虑如何构建您的系统?减少项目的风险，因为您已经考虑了各种策略和方法并且已经选择了最有意义的一项。您的目的不应该只是不花气力产生一个计划；它应该是一个实际可行的计划，您可以根据它来成功管理您的项目。软件过程推动计划的开发每个软件过程都有一个不同的集合，它包括组织团队的活动方法以及规划项目常用的技术。由于这个原因，基于RationalUnifiedProcess(RUP)的项目规划不同于OOSP项目的规划，而OOSP项目的规划也不同于eXtremeProgramming(X

7、P)项目的规划。不同的过程有不同的计划。从粗粒度的计划开始在项目将要开始时，应该制定一个粗粒度的、确定项目高级活动和预期里程碑的计划。粗粒度的计划将组织成迭代?根据项目的大小和性质，每次迭代通常在三周到八周之间发生（四周到六周为更佳）。其中一些迭代将集中在项目初期，而很多迭代将集中在整个应用的功能部分开发，还有一些迭代集中在将您的系统转变成产品。实施者应该是计划人员创建项目计划的最佳人员是负责实施该计划的人员。当规划由一个人创建而由另一个人实施时，如果项目不能按时完成或超出预算，他们不太会相信计划，而很有可能会责备它。也就是说，参与项目的每个人都应该投入到项目计划的开发和进展中。不要忘记“不该

8、忘记的事”计划不仅要反映需求设计、建模、编程和测试的“真实”工作，而且还应该反映辅助活动（然而仍是重要的），它包括：休假和法定假日、培训和教育、项目管理活动（如规划和人员管理）、开销（如系统当机时间、会议和回复电子邮件）、体系结构定义、测试之后的系统返工、系统交付、与重用相关的活动（如普遍化）。将任何设想和约束编入文档规划时您总要作一些假设，如能够及时获得应用程序服务器的新发行版，或可以得到熟悉您正在应用的技术和技巧的开发人员。同时，您将在一些约束下工作，如影响计划的强制截止期限或资源限制。将这些假设和约束编入文档，这样，当您实施项目的任何时候更新计划时，都可以记起您先前做出的一些“不寻常”决

9、定。认识到不同的资源意味着不同的计划十名有经验的开发人员组成的团队创造出的成效要远远多于十名初学者组成的团队所创造的成效。要想更加实际的话，您的计划必须反映项目可使用的资源的真实情况。创建现实的计划项目组必须相信其项目的目的、估价和时间表。要做到这点，您必须真实地规划，避免规划超出您能理解的范围。仅当您打算研究未知事项时，才能容忍无知。只规划有价值的事IBMDeveloperWorks网站提供了许多可应用于您项目的最佳实践。然而，根据项目的性质，不是所有这些技术都将适合于您的独特情况。要将这些最佳实践简单地看作是您放置在“项目管理工具箱”中的工具，您可以根据需要适当使用这些工具。适当使用项目管理工具一些项目管理工具，如MicrosoftProject，提供了重要功能如Gantt图表（活动时间表）的开发、规划与实际结果的比较、PERT图表（网络图表）的开发、任务的定义、任务之间相关性的定义、对任务的资源分配和资源平衡。所有这些事情似乎象是一个好主意