项目管理概念(ppt 54页).ppt

软件工程,第18章项目管理概念,主要内容,管理涉及的范围人员产品过程项目W5HH原则关键实践小结,项目管理,项目管理涉及对人员、过程和在软件从初始的概念演化为可运行的实现的过程中发生的事件的计划和监控。在软件项目中，每个人或多或少都做着“管理”的工作。但是，管理活动的范围各不相同。软件工程师管理他的日常活动，计划和监控技术任务。项目经理计划和监控软件工程师团队的工作。高级管理者协调业务和软件专业人员之间的关系。,项目管理,理解4P人员、产品、过程和项目。必须将人员组织起来以有效地完成软件工作。必须和客户及其他共利益者很好地沟通，以便了解产品的范围和需求；必须选择适合于人员和产品的过程；必须估算完成工作任务的工作量和工作时间，从而制定项目计划，包括：定义工作产品、建立质量检查点以及确定一些机制监控计划所规定的工作。,项目管理,在管理活动开始时，必须首先制定项目计划。该计划定义将要进行的过程和任务，安排工作人员，确定评估风险、控制变更和评价质量的机制。在按时并在预算内交付高质量的产品之前，你不可能完全肯定项目计划是正确的。不过，作为项目经理，鼓励软件人员协同工作形成一支高效的团队，并将他们的注意力集中到客户需求和产品质量上，这肯定是正确的。,项目管理,我拜访了很多商业公司好的和不好的，我又观察了很多数据处理管理者的业绩好的和不好的，我又观察了很多数据处理管理者的业绩好的和不好的。我常常恐惧地看到，这些管理者徒劳地与恶梦般的项目斗争着，在根本不可能完成的最后期限的压力下苦苦挣扎，或者是在交付了用户极为不满意的系统之后，又继续花费大量的时间去维护它。PAG85,管理涉及的范围,有效的软件项目管理集中于四个P上，即人员、产品、过程和项目。它们的顺序不是任意的，任何管理者如果忘记了软件工程工作是人的智力密集的劳动，他就永远不可能在项目管理上取得成功；任何管理者如果在项目开发早期没有鼓励共利益者之间的广泛交流，他就冒着为错误的问题构造了“良好的”解决方案的风险；对过程不在意的管理者可能冒着把有效的技术方法和工具插入到真空中的风险；没有建立可靠的项目计划就开始工作的管理者将危及产品的成功。,人员,SEI专门开发了一个人员管理能力成熟度模型(PM-CMM)，旨在“通过吸引、培养、激励、部署和聘用那些改进软件组织软件开发能力所需要的人才，提高软件组织承担日益复杂的应用问题的能力”。人员管理成熟度模型中针对软件人员定义了以下的关键实践区域：招募、选择、业绩管理、培训、报酬、个人事业发展、组织和工作设计以及团队精神或企业文化培养。在人员管理上达到较高成熟度的组织，更有可能完成有效的软件工程实践。,产品,在制定项目计划之前，应该首先确定产品的目标和范围，考虑可选的解决方案，识别技术和管理上的限制。如果没有这些信息，就不可能进行合理的成本估算，也不可能进行有效的风险评估和适当的项目任务划分，更不可能制定可管理的项目进度计划来给出意义明确的项目进展标志。,产品,软件开发者和客户必须一同定义产品的目标和范围。在很多情况下，这项活动是作为系统工程或业务过程工程的一部分开始的，并一直持续到作为软件需求工程的第一步。确定产品的目标只是标识出产品的总体目标，而不用考虑这些目标如何实现。而确定产品的范围，要标识出产品的主要数据、功能和行为特性，而且更为重要的是，应以量化的方式界定这些特性。,产品,了解了产品的目标和范围之后，就要开始考虑备选的解决方案了。虽然这一步并不讨论细节，但可以使管理者和参与开发的人员根据给定的约束条件选择“最好”的方案，其中，约束条件包括产品交付的期限、预算的限制、可用的人员、技术接口以及其他各种因素。,过程,软件过程提供了一个框架，在该框架下可以制定软件开发的综合计划。一小部分框架活动适用于所有软件项目，不用考虑其规模和复杂性。多种不同的任务集合每一种集合都由任务、里程碑、工作产品以及质量保证点组成使得框架活动适合于不同软件项目的特性和项目团队的需求。最后是普适性活动如软件质量保证、软件配置管理和测量，这些活动覆盖了过程模型。普适性活动独立于任何一个框架活动，且贯穿于整个过程之中。,项目,实施有计划的、可控制的软件项目的主要理由是：这是我们知道的管理复杂事物的唯一方法。产业数据表明26%的软件项目彻底失败，46%的项目成本和进度超出预定。虽然软件项目的成功率已有所提高，但项目的失败率仍然高于它的应有值。为了避免项目失败，软件项目经理和开发产品的软件工程师必须留意一些常见的警告信号，了解实施成功的项目管理的关键因素，还要确定计划和监控项目的一目了然的方法。,人员,所有的人，从高级工程副总裁到最低层的开发人员，常常认为人员是不成问题的。虽然管理者常常表态说人员是最重要的，但有时他们言行并不一致。以下将分析参与软件过程的人员，并且研究组织人员的方式，以实现有效的软件工程。,共利益者,参与软件过程的共利益者可以分为以下五类：高级管理者负责定义业务问题，这些问题往往对项目产生很大影响。项目（技术）管理者必须计划、激励、组织和控制软件开发人员。开发人员拥有开发产品或应用软件所需技能的人员。客户详细描述待开发软件需求的人员以及关心项目成败的其他共利益者。最终用户一旦软件发布成为产品，最终用户就是直接与软件进行交互的人。项目团队必须以能够最大限度地发挥每个人的技术和能力的方式进行组织，这是团队负责人的任务。,团队负责人,项目管理是人员密集型的活动，胜任开发的人却常常有可能是拙劣的团队负责人，他们完全不具备管理人员的技能。WEI86提出了领导能力的MOI模型：激励：鼓励技术人员发挥其最大才能的一种能力。组织：形成能够将最初概念转换成最终产品的现有过程（或创造新的过程）的能力。思想或创新：即使必须在特定软件产品或应用的约束下工作，也能鼓励人们去创造并让人感到有创造性的一种能力。成功的项目负责人应采用一种解决问题的管理风格。即，软件项目经理应该注重理解要解决的问题、把握住涌现的各种意见、同时让项目团队的每一个人知道质量很重要，不能妥协。,团队负责人,关于一个具有实战能力的项目经理应该具有什么特点，另一种观点则强调了以下四种关键品质：解决问题。具有实战能力的软件项目经理能够准确地诊断出最为密切相关的技术问题和组织问题；能够系统地制定解决方案，适当地激励其他开发人员来实现该方案；有把在过去项目中学到的经验应用到新环境中；如果最初的解决方案没有结果，能够灵活地改变方向。管理者的特性。优秀的项目经理必须能够掌管整个项目。必要的时候要有信心进行项目控制，同时还要允许优秀的技术人员能够按照他们的本意行事。成就。为了优化项目团队的生产效率，项目经理必须奖励那些工作积极主动并且做出成绩的人，并通过自己的行为表明出现可控风险并不会受到惩罚。影响和队伍建设。具有实战能力的项目经理必须能够“理解”人。他必须能理解语言和非语言的信号，并对发出这些信号的人的要求做出反应。项目经理必须能在高压力的环境下保持良好的控制能力。,软件团队,几乎可以说有多少开发软件的组织，就有多少种软件开发人员组织结构。组织结构不能轻易改变。至于组织改变所产生的实际和行政上的影响，并不在软件项目经理的责任范围内。但是，软件项目中所直接涉及的人员的组织，则是项目经理的职责。,软件团队,MAN81提出了规划软件工程团队结构时应考虑的七个项目因素：待解决问题的难度。开发程序的规模，以代码行或者功能点来度量。团队成员需要共同工作的时间。能够对问题做模块化划分的程度。待开发系统的质量要求和可靠性要求。交付日期的严格程度。项目所需要的友好交流的程度。,软件团队,CON93提出了软件工程团队的四种“组织范型”：封闭式范型。按照传统的权利层次来组织团队。随机式范型。松散地组织团队，团队工作依赖于团队成员个人的主动性。开放式范型。试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。同步式范型。依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么主动的交流。,软件团队,从历史的角度看，最早的软件团队组织是封闭式范型结构，最初称之为主程序员团队。团队的核心成员包括：一个高级工程师（“主程序员”），负责计划、协调和评审团队的所有技术活动；技术人员，进行分析和开发活动；一个后备工程师，支持高级工程师的活动，并可以在项目进行过程中以最小的代价接替高级工程师的工作。主程序员可以有多人配合他的工作，包括一个或多个专家、支持人员和软件资料员。,软件团队,CON93提出的随机式范型是主程序员团队结构的一个变种，主张建立具有独立创新性的团队，其工作方式可恰当地称为创新的无政府状态。尽管自由的软件工作方式是有吸引力的，但在绩效良好的团队中必须将创新能力作为软件工程组织的中心目标。,软件团队,为了建成一支绩效良好的团队：团队成员必须相互信任。团队成员的技能分布必须适合于要解决的问题。如果要保持团队的凝聚力，必须将坚持个人己见的人员排除于团队之外。无论什么类型的团队，每一个项目经理的目标都是帮助建立一支有凝聚力的团队。同一般的团队相比，有凝聚力的团队成员具有更高的生产率和更大的动力。他们拥有共同的目标和共同的文化，而且在很多情况下，“精英意识”使得他们独一无二。,软件团队,但是，并非所有的团队都具有凝聚力。事实上，很多团队都受害于JAC98称之为“团队毒性”的东西。JAC98定义了5个“培育潜在含毒团队环境”的因素：(1)狂乱的工作氛围；(2)引起团队成员间产生磨擦的重大挫折；(3)“碎片式的或协调很差”的软件过程；(4)在软件团队中没有清晰的角色定义；(5)“接连不断地重蹈覆辙”。,软件团队,为了避免狂乱的工作环境，项目经理应该确保团队可以获取完成工作所需的所有信息；而且，主要目标一旦确定下来，除非绝对必要，否则不应该修改。如果给予软件团队尽可能多的决策权，就能使团队避免挫败和压力。通过理解将要开发的产品和完成工作的人员，以及允许团队选择自己的过程模型，可以避免选择不适当的软件过程。团队本身应该建立自己的责任机制，并规定一系列当团队成员未能完成任务时的纠正方法。最后，避免失败的关键是建立基于团队的信息反馈方法和解决问题的技术。,敏捷团队,小型的充满活力的团队，也称为敏捷团队，采纳了很多成功的软件项目团队的特性，同时又避免了很多产生问题的毒素。同时，敏捷方法学强调团队成员的个人能力与团队协作精神相结合，这是团队成功的关键因素。在软件项目中，为了充分发挥每个成员的能力，并培养有效的合作，敏捷团队是自组织的。自组织团队不必保持单一的团队结构，而是采用随机、开放、同步式的范型。,敏捷团队,很多敏捷过程模型给予敏捷团队相当大的自主权进行项目管理，可以因工作需要做出技术决定。将计划制定工作压缩到最低程度，并且允许团队选择自己适用的手段，只受业务需求和组织标准的限制。在项目进行过程中，自组织团队关注的是在特定的时间点使项目获益最大的个人能力。为了做到这一点，敏捷团队可以召开简短的日常团队会对当天必须完成的工作进行调整以使其同步进行。基于在团队会中取得的信息，团队能使他们所采用的手段不断适应持续增加的工作。当每一天过去的时候，连续的自组织和协作使团队朝着软件逐步增长的完工的方向发展。,协调和通信问题,使软件项目陷入困境的原因很多。许多开发项目规模很大，导致复杂性高、混乱、难以协调团队成员间的关系。不确定性是经常存在的，它会引起困扰项目团队的一连串的变更。互操作性已经成为许多系统的关键特性。新的软件必须与已有的软件通信，并遵从系统或产品所施加的预定义约束。,协调和通信问题,现代软件的这些特征规模、不确定性和互操作性确实都是存在的。为了有效地处理这些问题，软件工程团队必须建立切实可行的方法来协调工作人员之间的关系。为了做到这一点，需要建立团队成员之间以及多个团队之间的正式的和非正式的交流机制。,产品,从软件工程项目一开始，软件项目经理就面临着进退两难的局面。需要定量地估算成本和有组织地计划项目的进展，但却没有可靠的信息可以使用。虽然对软件需求的详细分析可以提供必要的估算信息，但需求分析常常需要数周甚至数月的时间才能完成。更糟糕的是，需求可能是不固定的，随着项目的进展经常发生变化。不过，无论如何计划总是“眼前”就需要的！因此，从软件工程项目一开始，就要研究应该开发哪些产品以及要解决哪些问题。至少，要建立和界定项目的范围。,软件范围,软件项目管理的第一项活动是确定软件范围。软件范围是通过回答下列问题来定义的：项目环境。要开发的软件如何适应于大型的系统、产品或业务环境，该环境要施加什么约束？信息目标。软件要产生哪些客户可见的数据对象来作为输出？需要什么数据对象作为输入？功能和性能。软件要执行什么功能才能将输入数据变换成输出数据？软件需要满足什么特殊的性能要求吗？,软件范围,软件项目范围在管理层和技术层都必须是无歧义的和可理解的。对软件范围的描述必须是界定的。即，要明确给出定量的数据；说明约束和限制，并且描述其他的缓解因素。,问题分解,问题分解，有时称为问题划分或问题细化，它是软件需求分析的核心活动。在确定软件范围的活动中，并不试图去完全分解问题，只是分解其中的两个主要方面：(1)必须交付的功能；(2)所使用的过程。在面对复杂问题时，常常采用分而治之的策略。就是将一个复杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用的策略。在开始估算前，必须对软件范围中所描述的软件功能进行评估和精化，以提供更多的细节。因为成本和进度估算都是面向功能的，所以对功能进行某种程度的分解是很有益处的。,过程,刻画软件过程的框架活动适用于所有软件项目。问题是项目团队要选择一个适合于待开发软件的过程模型。项目经理必须决定哪一个过程模型最适合于：(1)需要该产品的客户和从事开发工作的人员；(2)产品本身的特性；(3)软件项目团队工作的项目环境；当选择一个过程模型后，项目团队可以基于一系列过程框架活动来制定一个初步的项目计划。一旦确定了初步计划，过程分解就开始了。也就是说，必须制定一个完整的计划，来反映框架活动中所需要的工作任务。,合并产品和过程,项目计划开始于产品和过程的合并。软件项目团队要完成的每一项功能都必须通过针对软件组织而定义的一系列框架活动来完成。完成任何一项功能的项目团队成员都要将各个框架活动应用于该功能的实现上。实质上，产生了一个类似于图18-1所示的矩阵。每个主要的产品功能显示在第一列，框架活动显示在第一行。软件工程工作任务列在紧接下来的行中。项目经理（和其他团队成员）的工作是估算每一个矩阵单元的资源需求，与每个单元相关的任务的开始和结束日期，以及每项任务所产生的工作产品。,合并产品和过程,图18-1合并产品和过程,过程分解,软件团队在选择最适合项目的软件过程模型时，应该具有很大的灵活性。一旦选定了过程模型，项目团队可以根据需要灵活地确定过程模型中应包含的软件工程任务。较小的项目如果与以前已开发过的项目相似，可以采用线性顺序模型。如果时间要求很紧，而且问题能够被很好地划分，RAD模型可能是正确的选择。如果时间要求太紧，不可能完成所有功能时，增量模型可能是最合适的。同样，如果项目具有其他特性，可能会选择其他的过程模型。,过程分解,一旦选定了过程模型，就要根据所选的过程模型对过程框架做适应性修改，但在所有情况下前面讨论过的通用框架活动沟通、策划、建模、构建和部署都可以使用。过程框架既适用于线性模型，也适用于迭代和增量模型、演化模型、甚至是并发模型或构件组装模型。过程框架是不变的，是软件组织所进行的所有软件工作的基础。,过程分解,但实际的工作任务是不同的。例如，一个小型的比较简单的项目在沟通活动中可能需要完成下列工作任务：1、列出需澄清的问题清单。2、与客户见面说明需澄清的问题。3、共同给出范围陈述。4、和所有相关人员一起评审范围陈述。5、根据需要修改范围陈述。,过程分解,考虑一个比较复杂的项目，它具有更广的范围和更重要的商业影响。这样一个项目在沟通活动中可能需要完成下列工作任务：,项目,为了成功地管理软件项目，必须了解可能会出现什么问题。在一篇关于软件项目的优秀论文中，REE99定义了10个表示信息系统项目正处于危险状态的信号：软件人员不了解其客户的要求。产品范围定义得很糟糕。没有很好地管理变更。选择的技术发生了变化。业务需求发生变化。最后期限是不切实际的。客户抵制。失去赞助。项目团队缺乏具有合适技能的人员。管理者没有很好地利用已学到的最佳实践和教训。,项目,1、在正确的基础上开始工作。通过以下两点来完成：首先努力地正确理解要解决的问题，然后为每个参与项目的人员设置现实的目标和期望。这一点又通过组建合适的开发团队以及给予团队完成工作所需的自由、权力和技术而得到加强。,项目,2、保持动力。很多项目的启动都有一个良好的开端，但是，后来慢慢地开始瓦解。为了维持动力，项目经理必须采取激励措施使人员变动量保持绝对最小，项目团队应该强调完成的每个任务的质量，而高层的管理应该尽可能不干涉团队的工作。,项目,3、跟踪进展。对于一个软件项目，当工作产品被生产出来和被批准时，跟踪项目进展要作为质量保证活动的一部分。此外，可以收集软件过程和项目测量数据，然后对照软件开发组织的平均数据来评估项目的进展。,项目,4、做出聪明的决策。总体上，项目经理和软件团队的决策应该“保持项目的简单性”。只要有可能，就使用商用成品软件