软件研发项目管理课件

软件研发项目管理2013-2-20软件研发项目管理2013-2-20标题添加点击此处输入相关文本内容点击此处输入相关文本内容前言点击此处输入相关文本内容标题添加点击此处输入相关文本内容标题添加点击此处输入相点击此处输入前言点击此处输入标题添加点1研发项目管理基础1计划管理2需求管理3设计管理4开发管理5测试管理6目录配置管理7最佳实践82研发项目管理基础1计划管理2需求管理3设计管理4开发管理5测

基础管理01

13基础管理0113总纲与规范六为法需求必为准团队必为本计划必为纲绩效必为证质量必为出变化必为形4总纲与规范六为法需求必为准4总纲与规范七定法兵马未动、合约先行（定需求）可行的做可行事（定技术方案）谋定而后动（定计划）专业的人做专业的事（定人员）沟通无止境、共识促发展（定共识）死亡之地不可不察也（定风险）应对随形、修道保法（定变更）5总纲与规范七定法兵马未动、合约先行（定需求）5总纲与规范三出路以正合（用人之术，诸如选育用留）以曲制（规律之术，诸如过程方法）以奇胜（变化之术，诸如动静之理）6总纲与规范三出路以正合（用人之术，诸如选育用留）6总纲与规范兵法一曰道目的二曰天制度三曰地需求四曰将专业角色五曰法过程7总纲与规范兵法一曰道目的7基础管理----过程管理过程的简单描述8基础管理----过程管理过程的简单描述8基础管理----过程管理软件研发的分类和组成软件基本过程：软件获取、供应、开发、运行和维护的过程，包括需求分析、软件设计、编码等过程。软件支持过程：对软件主要过程提供支持的过程，包括文档编制过程、配置管理过程、质量保证过程、验证和确认过程（测试过程）、评审过程等。软件组织过程：对软件主要过程和支持过程的组织保证过程，包括管理过程、基础设施过程、改进过程和培训过程。9基础管理----过程管理软件研发的分类和组成软件基本过程：软基础管理----过程管理ISO/IEC15504软件生存周期过程10基础管理----过程管理ISO/IEC15504软件生存周期基础管理----过程规范软件研发规范的建立软件能力成熟度模型（CMM/CMMI）IBM-Rtaional统一过程（RUP）极限编程（eXtremeProgramming，XP）微软软件框架（MSF）11基础管理----过程规范软件研发规范的建立软件能力成熟度模型基础管理----过程规范瀑布模型螺旋模型、增量模型、迭代模型V模型并发过程模型极限编程（XP）IBM-Rational统一过程（RUP）软件研发模型12基础管理----过程规范瀑布模型软件研发模型12基础管理----过程规范不是好的东西都能用，适用的才是最好的!需要我们根据自己人员的水平、公司情况、业务状况综合确定适合自己的研发过程13基础管理----过程规范不是好的东西都能用，13基础管理14

计划管理02

214基础管理14计划管理02214计划管理软件研发的项目管理有效的项目管理是在用来实现项目具体目标的规定时间内，对组织机构资源进行计划、引导和控制工作。——《项目管理知识指南》15计划管理软件研发的项目管理15计划管理WBS：

项目计划形成之前，最好先画WBS表（WorkBreakdownStructure），主要原理是：将任务逐级分解直至个人，在矩阵中体现为：先确定横向有多少结点，再将每一结点任务逐渐细化直到个人，工作分解图（WBS）实际上就是将一个复杂的开发系统分层逐步细化为一个个工作任务单元，这样可以使我们将复杂、庞大的、不知如何下手的大系统划分成了一个个独立的我们能预测、计划和控制的单元，从而也就达到了对整个系统进行控制的目的。16计划管理WBS：项目计划形成之前，最好先画WBS表（WBS-工作分解结构1项目范围规划

1.1 确定项目范围

1.2 获得项目所需资金

1.3 定义预备资源

1.4 获得核心资源

1.5 项目范围规划完成2分析/软件需求

2.1 行为需求分析

2.2 起草初步的软件规范

2.3 制定初步预算

2.4 工作组共同审阅软件规范/预算

2.5 根据反馈修改软件规范

2.6 确定交付期限

2.7 获得开展后续工作的批准(概念、期限和预算)2.8 获得所需资源

2.9 分析工作完成3设计

3.1 审阅初步的软件规范

3.2 制定功能规范

3.3 根据功能规范开发原型

3.4 审阅功能规范

3.5 根据反馈修改功能规范

3.6 获得开展后续工作的批准

3.7 设计工作完成4开发

4.1 审阅功能规范

4.2 确定模块化/分层设计参数

4.3 分派任务给开发人员

4.4 编写代码

4.5 开发人员测试(初步调试)4.6 开发工作完毕……计划管理17WBS-工作分解结构1项目范围规划 计划管理17计划管理创建WBS的基本法则每个工作工作单元在WBS只能出现一次概要任务是对其下所有任务的总结每个WBS的条目都有单独的人员负责与实际要做的工作情形保持一致建立WBS时应让项目组员参予每个WBS条目都应备案WBS既要灵活又要不失控制18计划管理创建WBS的基本法则每个工作工作单元在WBS只能出现计划管理项目估算令人烦恼的项目估算：这个项目需要多长时间？这个模块大概多久完成？需要花费多少人力才能完成这个项目？项目的总成本大概为多少？

……19计划管理项目估算令人烦恼的项目估算：19计划管理项目成本的组成1.项目成本的组成（1）直接成本人力成本硬件设备软件费用（2）间接成本项目管理成本一般管理成本20计划管理项目成本的组成1.项目成本的组成20计划管理责任矩阵用距阵的形式列出对某项任务负责的人或资源。任务管理人员项目经理分析人员项目范围规划1.1确定项目范围A1.2获得项目所需资金A1.3定义预备资源A1.4获得核心资源A分析/软件需求2.1行为需求分析A2.2起草初步的软件规范A2.3制定初步预算A2.4工作组共同审阅软件规范/预算AP2.5根据反馈修改软件规范A2.6确定交付期限A2.7获得开展后续工作的批准AP2.8获得所需资源A21计划管理责任矩阵用距阵的形式列出对某项任务负责的人或资源。任计划管理项目软硬件资源管理1.软件资源管理操作系统编译器应用软件测试工具……2.硬件资源管理服务器PC……22计划管理项目软硬件资源管理1.软件资源管理22计划管理10种常见的风险No.软件风险相应对策1人员不足录用优秀人才；人员应适应岗位需要；全面考虑团队建设；骨干人员工作要协调；实施培训；预先安排关键人员的使用计划2进度计划和预算不准确详细评估多种资源成本和进度；依成本进行设计；采用渐增式开发；软件复用；纯净需求3开发了错误的软件功能进行组织分析；实施任务分析；进行用户调查；开发原型；及早编制用户手册4开发了不适用的用户接口开发原型；制作脚本；作业分析；弄清了用户特征(功能性、风格、工作负荷)5只追求表面效果，需求中含有一些不必要的功能（镀金）纯净需求；开发原型；成本－效益分析；依成本进行设计6需求不断变更重大变更设限；信息隐蔽；渐进式开发7外供部件不足制定基准点；检验；参考基准检查；兼容性分析8外包任务问题参考基准检查；发包前审核；未发包合同；竞标设计或开发原型；建立团队9实时性能达不到要求模拟；制定基准；建模；开发原型；安装测量装置；调准10误解计算机科学能力技术分析；成本－效益分析；开发原型；参考基准检查23计划管理10种常见的风险No.软件风险相应对策1人员不足录用计划管理项目跟踪和控制1.了解成员的工作情况2.调整工作安排，合理利用资源3.促进计划内容的完善4.促进项目经理对人员的认识5.促进对项目工作量的估计6.统计并了解项目总体进度7.有利于人员考核24计划管理项目跟踪和控制1.了解成员的工作情况24计划管理现代软件研发项目管理路线图概览25计划管理现代软件研发项目管理路线图概览25计划管理项目预算与成本1、项目成本=直接成本*2.5直接成本为prj中的成本2、项目工期=基本工期+（悲观时间-乐观时间）/63、项目工期较长，可以分解为多个项目，每个项目不超过6个月，6个月内按两周做计划。4、任务分解一般两周:过粗不利分配工作,过细不利于人员的主动性.5、要识别任务关键路径,根据人员情况并行或串行。26计划管理项目预算与成本1、项目成本=直接成本*2.5直接成计划管理WBSCHart27计划管理WBSCHart27计划管理ChartEXPERT28计划管理ChartEXPERT28计划管理关键路径实例-Microsoftproject29计划管理关键路径实例-Microsoftproject需求管理30

需求管理03330需求管理30需求管理03330需求管理软件研发的需求管理开发软件系统最为困难的部分就是准确说明开发什么。——弗雷德里克·布鲁克斯31需求管理软件研发的需求管理31需求管理软件需求工程

所有与需求直接相关的活动统称为需求工程，需求工程分为了两个部分：需求开发和需求管理。其中，需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分，而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪

软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。32需求管理软件需求工程所有与需求直接相关的活动需求管理软件需求工程

业务需求（businessrequirement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。

用户需求(userrequirement)文档描述了用户使用系统而完成的任务的集合，用户需求在用户案例（usercase）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。软件需求(fsoftwarerequirement)定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。33需求管理软件需求工程业务需求（businessrequi需求管理需求开发需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。获取数据分析、处理目标系统模型需求获取系统分析员从数据流和数据结构出发，找出系统各元素之间的联系、接口特征及设计限制、能否满足功能需求34需求管理需求开发需求开发的目的是通过调查与分析，获取用户需求需求管理需求获取的方法需求研讨会头脑风暴用例模型访谈角色扮演原型法35需求管理需求获取的方法需求研讨会35需求管理基于用例的需求获取执行者的识别谁使用系统的主要功能？谁将提供、使用和删除信息？谁负责维护、管理并保持系统正常运行？谁会对某一特定需求感兴趣？系统的外部资源是什么？系统需要和哪些外部系统交互？用例的识别某个执行者要求系统为其提供什么功能？该执行者需要做哪些工作？执行者需要阅读、创建、销毁、更新或存储系统中哪些（类）信息？系统中的事件一定要告之执行者吗？执行者需要告诉系统一些什么吗？那些系统内部的事件从功能的角度代表什么？由于新功能的识别，执行者的日常工作被简化或效率提高了吗？系统需要什么样的输入输出？输入在哪里？输出去往哪里？该系统的当前情况存在哪些问题？36需求管理基于用例的需求获取36需求管理需求确认为什么需要需求评审？在哪个阶段发现成本率需求1设计3-6编码10功能测试15-40验收测试30-70发布之后40-1000修订一个缺陷的相关成本37需求管理需求确认为什么需要需求评审？在哪个阶段发现成本率需求基础管理需求跟踪需求的标识<需求类型><需求#>需求类型可以是：F=功能需求，D=数据需求，B=行为需求，I=接口需求；O=输出需求。

例：需求标识为F03的需求表示编号为3的功能需求。38基础管理需求跟踪需求的标识例：需求标识为F03的需求表示编号基础管理39基础管理39设计管理40

设计管理04

440设计管理40设计管理04440设计管理架构开发方法41设计管理架构开发方法41设计管理架构开发方法42设计管理架构开发方法42设计管理架构开发方法43设计管理架构开发方法43设计管理架构是软件的基石架构是软件的基础，一个良好的架构可以让软件有更长久的生命力，能发挥出更出色的性能；架构师要求对业务有深入的了解，这样才能让架构更符合软件的需要，更能发挥软件的特点。44设计管理架构是软件的基石架构是软件的基础，一个良好的架构可以设计管理45设计管理45设计管理46设计管理46设计管理47设计管理47设计管理48设计管理48开发管理

开发管理05549开发管理开发管理05549开发管理1.开发开发的目的包括：对照开发子系统的分层结构定义代码结构;以构件（源文件、二进制文件、可执行文件以及其他文件等）的方式开发类和对象;对已开发的构件按单元来测试;将各开发员（或团队）完成的结果集成到可执行系统中。50开发管理1.开发开发的目的包括：对照开发子系统的分层结构定开发管理2.过程策略里程碑：最初操作性能最初操作性能里程碑确定产品是否已经可以部署到Beta测试环境。在最初操作性能里程碑，产品随时可以移交给产品化团队。此时，已开发了所有功能，并完成了所有Alpha测试（如果有测试）。除了软件之外，用户手册也已经完成，而且有对当前发布版的说明。评估标准该产品发布版是否足够稳定和成熟，可部署在用户群中？是否已准备好将产品发布到用户群？实际的资源耗费与计划的相比是否仍可以接受？如果项目无法达到该里程碑，产品化可能要推迟一个发布版。51开发管理2.过程策略里程碑：最初操作性能最初操作性能里程碑确开发管理最佳开发实践新概念与最佳实践可持续开发节奏团队激励障碍列表持续集成产品燃尽图Sprint燃尽图52开发管理最佳开发实践新概念与最佳实践52开发管理

可持续开发节奏的相关概念

可持续的开发节奏是一个开发团队可长期（可以认为是永久）保持的开发节奏为了保持可持续的开发节奏，适当的休假可以让团队及时恢复精力。可持续的开发节奏并非禁止加班，但必须是偶然事件而非经常性事件53开发管理

可持续开发节奏的相关概念

可持续的开发节奏是一个开开发管理讨论当项目进度对于完成当前的迭代目标面临压力时，作为ScrumMaster，你会采取以下哪种方式？54开发管理讨论当项目进度对于完成当前的迭代目标面临压力时，作为开发管理ScrumMaster要关注团队的健康

高强度的开发节奏如果超过了团队可承受的范围，必然影响团队的健康（包括心理和生理健康）。ScrumMaster应该关注团队的健康状况。选择可持续的开发节奏，应该以团队能够感觉舒适地完成迭代目标为前提。55开发管理ScrumMaster要关注团队的健康

高强度的开开发管理不可持续开发节奏的影响56开发管理不可持续开发节奏的影响56开发管理不可持续开发节奏的影响Defect大量增加：持续加班状况下代码质量很难保证，必然导致defect数量增加。工作效率降低：研究表明，当人疲劳时工作效率将急剧下降。团队士气低下：长期的高强度工作必然使团队身心疲惫，士气低落。开始相互推诿责任：长期高负荷工作下，导致出现问题后开始相互埋怨。放弃探索最佳实践方法：磨刀不误砍柴工，最佳实践方法可以事半功倍。然而长期高强度工作会逐渐放弃花时间去“磨刀”。57开发管理不可持续开发节奏的影响Defect大量增加：持续加班开发管理障碍列表在敏捷项目管理中的意义

及时将团队的注意力引导向最重要的问题。集思广益。由团队成员一起讨论解决，而不是由传统意义上的项目经理独自来协调与分配。提高团队的自主性。与风险管理结合，对即将或已经发生的风险采取积极的应对态度。58开发管理障碍列表在敏捷项目管理中的意义

及时将团队的注意力引开发管理团队激励59开发管理团队激励59开发管理团队阶段回顾60开发管理团队阶段回顾60开发管理

什么是激励

激励=活力+指引+坚持61开发管理

什么是激励

激励=活力+指引+坚持6开发管理什么是团队–讨论：一群个体与一个团队的区别

一群个体避免交流与冲突自我中心低投入被动工作一个团队彼此信任有共同目标开诚布公互相帮助有原则有乐趣团结积极交流倾向于解决问题62开发管理什么是团队–讨论：一群个体与一个团队的区别

一群个体开发管理

团队绩效曲线

63开发管理

团队绩效曲线

63开发管理开发

详细设计\开发\单元测试为专业开发开发时间

任务<=两周；版本>=2周<=2月；这是一种健康节奏,不能经常加班。最佳开发实践

可持续开发节奏、团队激励、障碍列表、持续集成、产品燃尽图、Sprint燃尽图任务分配时间分配任务时按规划时间/1.2计算。如规划10天，10/1.2=8天，则安排8天完成，以保留时间贮备

在分配任务时1、以需求为主线（一个部分的需求、设计、开发、测试由一个人完成）2、以健康节奏（按120/100原则分配，具体因人而异3、任务分配在两周之内4、版本控制在两个月内5、行动之前落实承诺

开发主管在分配任务时1、选：胜任力2、定：定好目标，获得承诺3、育：培训4、用：定好绩效（工作节奏）5、留：奖惩（按绩效）总结

64开发管理开发详细设计\开发\单元测试为专业测试管理

测试管理06665测试管理测试管理06665测试管理

测试测试的目的在于：核实对象之间的交互。核实软件的所有构件是否正确集成。核实所有需求是否已经正确实施。确定缺陷并确保在部署软件之前将缺陷解决。66测试管理测试测试的目的在于：核实对象之间的交互。核实软件的测试管理1

软件工程与测试模型

不同的开发模式适配不同的测试模型和测试过程。开发流水线产品平台技术平台规划需求设计实现测试部署测试需求测试设计测试执行测试执行67测试管理1软件工程与测试模型不同的开发模式适配不同的测试测试管理1.1

测试模型1：瀑布模型瀑布模型的核心思想是按工序将问题化简，将功能的实现与设计分开，采用结构化的分析与设计方法将逻辑实现与物理实现分开。软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试、运行维护。规定活动自上而下、相互衔接的固定次序，逐级下落。68测试管理1.1测试模型1：瀑布模型瀑布模型的核心思想是按工测试管理1.2测试模型2：V模型V模型是最广为人知的测试模型由PaulRook在2０世纪８０年代后期提出的，旨在改进软件开发的效率和效果。从左到右，描述了基本的开发过程和测试行为非常明确地标明了测试过程中存在的不同级别，描述了这些测试阶段和开发过程期间各阶段的对应关系69测试管理1.2测试模型2：V模型V模型是最广为人知的测试模型测试管理1.3

测试模型3：W模型测试伴随整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法很好的支持迭代开发。70测试管理1.3测试模型3：W模型测试伴随整个软件开发周期，测试管理1.4

测试模型4：X模型很好地处理测试与开发的交接过程（交接的过程是一个时间段，而不是一个点）左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，给有经验的测试人员在测试计划之外发现更多的软件缺陷。71测试管理1.4测试模型4：X模型很好地处理测试与开发的交接测试管理2测试组织产品组/产品线测试组开发组项目1项目2项目3优势：1、与业务结合紧密（用例）；2、与代码结合紧密（白盒）；缺点：1、测试资源未统一动态调配，使用有浪费；2、测试技能的统一提升和培训少。72测试管理2测试组织产品组/产品线测试组开发组项目1项目2项测试管理2测试组织规模73测试管理2测试组织规模73测试管理2走向成熟：组织成熟怎么算组织成熟？74测试管理2走向成熟：组织成熟怎么算组织成熟？74测试管理2走向成熟：技术成熟：工具平台75测试管理2走向成熟：技术成熟：工具平台75测试管理2走向成熟：技术成熟：测试流水线业务知识76测试管理2走向成熟：技术成熟：测试流水线业务知识76测试管理2走向成熟：技术成熟：持续交付77测试管理2走向成熟：技术成熟：持续交付77测试管理3测试的过程管理：端到端测试过程总体测试要约测试准备测试计划与方案测试设计测试分析与报告测试执行78测试管理3测试的过程管理：端到端测试过程总体测试准备测试计测试管理3测试要约确定测试的总体范围和目标确定总体测试时间计划确定测试人员安排及组织结构确定对应角色工作职责确定测试组运作机制确定主要测试流程79测试管理3测试要约确定测试的总体范围和目标确定总体测试管理3总体测试要约：确定测试总流程80测试管理3总体测试要约：确定测试总流程80测试管理3.测试总体要约：bug类型与界定1.Bug严重程度；2.Bug分类；3.Bug修改的优先级；4.Bug状态81测试管理3.测试总体要约：bug类型与界定81测试管理3总体测试要约：确定与用户的bug流程(上线&运维)客户投诉内部自查系统BUG业务规则易操作性操作过程BUG管理系统BUG问题列表BUG专题会公司级系统运营评估电话会议前台操作员工程师客户经理每日问题反馈和解决（每日下午3:00）系统运行情况评估分析（每日下午5:30）现场派驻响应安排技术人员到现场，接收现场咨询，现场无法解决时，提交到省公司问题处理组，省公司问题处理组安排相关人员进行解决。24小时热线电话支持主要是针对紧急问题，快速提供解决问题的方法82测试管理3总体测试要约：确定与用户的bug流程(上线&运维基础管理3总体测试要约：确定测试的范围和目标(举例)

测试分类测试范围覆盖交付目标1功能测试(含单元/集成/接口/报表/测试)1）覆盖全部网元/动作，支持各种业务；

2）覆盖所有接口和报表；

3）覆盖所有产品无关的功能点；1、业务覆盖率100%；

2、接口连通性100%；

3、C类以上Bug修复率100%；2模拟测试渠道为营业厅办理的业务模拟测试通过率95%；3性能测试覆盖70%的业务量的主要业务；主要业务响应时间高于规范标准；资源使用合理；4安全性/兼容性测试主要业务抽取5种，覆盖身份验证、权限操作、密码安全；覆盖IE6、7、8及vista、xp、win7；安全性、兼容性用例通过率100%5容错性测试双机备份、单点故障等通过率100%83基础管理3总体测试要约：确定测试的范围和目标(举例)测试分测试管理3总体测试要约：确定总体测试时间计划84测试管理3总体测试要约：确定总体测试时间计划84基础管理3总体测试要约：确定测试人员安排及组织结构85基础管理3总体测试要约：确定测试人员安排及组织结构85测试管理4、测试度量与评估：

项目期间bug管理1.BUG统一录入BUG管理平台;2.每天实时统计各测试人员BUG提交情况；3.每日根据实时汇总的BUG跟踪表统计BUG新增情况与积压延期情况4.修改后的BUG要及时跟进测试5.每日进行BUG处理情况接口人会议86测试管理4、测试度量与评估：项目期间bug管理86配置管理87

配置管理07

787配置管理87配置管理07787配置管理内容提要软件配置管理的概念软件配置管理计划软件配置标识变更管理版本管理配置审核配置状态报告软件配置管理工具88配置管理内容提要软件配置管理的概念88配置管理一、软件配置管理的概念（一）软件配置项的概念1、软件配置项：配置管理的对象称为软件配置项。表1软件配置项的分类、特征和举例分类特征举例环境类软件开发环境及软件维护环境编译器、操作系统、编辑器、数据库管理系统、开发工具（如测试工具）、项目管理工具、文档编辑工具定义类需求分析及定义阶段完成后得到的工作产品需求规格说明书、项目开发计划、设计标准或设计准则、验收测试计划设计类设计阶段结束后得到的产品系统设计规格说明、程序规格说明、数据库设计、编码标准、用户界面标准、测试标准、系统测试计划、用户手册编码类编码及单元测试后得到的工作产品源代码、目标码、单元测试数据及单元测试结果测试类系统测试完成后的工作产品系统测试数据、系统测试结果、操作手册、安装手册维护类进入维护阶段以后产生的工作产品以上任何需要变更的软件配置项89配置管理一、软件配置管理的概念（一）软件配置项的概念分类特配置管理2、软件配置

软件配置是一个软件产品在生存期各个阶段的不同形式（记录特定信息的不同媒体）和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合。初始系统机型1机型2机型n操作系统1操作系统2用户1用户2图1不同用户有自己的工作环境90配置管理2、软件配置初始系统机型1机型2机型n操作系统1操作配置管理（二）软件配置管理1、什么是软件配置管理（1）ISO9000-3:1997配置管理是一个管理学科，它对配置项（包括软件项）的开发和支持生存期给与技术上的和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险大小。（2）W.Babich的解释软件配置管理能协调软件开发，使混乱减到最小，目的是最有效的提高生产率。（3）GB/T11457:1995《软件工程术语》国家标准

A.表示和确定系统中配置项的过程，在系统整个生存期内控制这些配置项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。

B.对下列工作进行技术和行动指导与监督的一套规范：

——对配置项的功能特性和物理特性进行标识和文件编制工作；

——控制这些特性的更动情况；

——记录并报告这些更动进行的处理和实现的状态。91配置管理（二）软件配置管理91配置管理2、软件配置管理的任务——制定软件配置管理计划——确定配置标识规则——实施变更控制——报告配置状态——进行配置审核——进行版本管理和发行管理92配置管理2、软件配置管理的任务92配置管理二、软件配置管理计划配置管理计划标准——IEEE828-19901．引言——配置管理计划的目的、适应范围、使用要求——项目概述——项目中需特别关注的配置管理问题和风险——软件配置管理严格性要求的等级——限制和假设——术语——参考文件93配置管理二、软件配置管理计划配置管理计划标准——IEEE配置管理2、软件配置管理——配置管理的组织结构——职责和权限——指令和方针——参照的规程（组织的规程或客户的规程）——遵循的标准3、软件配置管理活动——配置管理活动——变更管理和配置控制——配置状态说明——配置审核——接口和子合同方控制94配置管理2、软件配置管理94配置管理4、软件配置管理进度安排——软件配置管理重要事件的顺序——软件配置管理各项活动间的依赖关系5、软件配置管理所需的资源——采用的工具——使用的设备——所需的培训——对其他人员的要求6、软件配置管理计划的维护——维护的职责——计划更新的条件和审批——计划变更的交流和通报95配置管理4、软件配置管理进度安排95配置管理三、软件配置标识（一）确定配置项1、

系统规格说明2、软件项目计划3、软件需求规格说明书a.图形分析模型b.处理规格说明c.原型d.数学规格说明4．初步用户手册5．设计规格说明书a.数据设计描述b.体系结构设计描述c.模块设计描述d.接口设计描述e.对象描述（采用面向对象技术时）6．源代码清单7、测试规格说明

a.测试计划和步骤

b.测试用例和记录的结果8、操作和安装手册9、可执行程序

a.模块可执行代码b.连接的模块10、数据库描述

a.模式和文件结构

b.初始内容11、联机用户手册12、维护文档

a.软件问题报告

b.维护请求

c.工程变更指令13.软件工程标准和规程96配置管理三、软件配置标识（一）确定配置项7、测试规格说明9配置管理（二）配置项命名及其相关信息1、配置项命名。命名的基本要求：唯一性；可追溯性。例：CODE是根结点为PCL_TOOLS树结构的第六层结点，对其命名为：PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE/CODE

97配置管理（二）配置项命名及其相关信息

97配置管理2、配置项的相关标识信息每一配置项的有关信息：——组名——项名——项标识（文件名或命名规则）——版本编号规则——什么情况下纳入控制之下，或——版本号——所遵循的变更控制规程98配置管理2、配置项的相关标识信息98配置管理3、配置库记录与配置相关的所有信息利用库中的信息可评价变更的后果可利用库中的信息查询，例如：那些客户已提取了某个特定的系统版本？运行一个给定的系统版本需要什么硬件和系统的哪些版本?一个系统到目前已生成了多少版本，何时生成的？如果某一特定的构件变更了，会影响到系统的那些版本？一个特定的版本曾提出过那几个变更请求？一个特定的版本有多少已报告的错误？99配置管理3、配置库99配置管理三类库配置库（1）开发库：存放开发过程中需要保留的各种信息，供开发人员个人专用。（2）受控库：在软件开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。（3）产品库：在开发的软件产品完成系统测试之后，作为最终产品存入库内，等待交付用户或现场安装。100配置管理三类库配置库100配置管理4、配置基线基线是软件生存期各开发阶段末尾的特定点，也称为里程碑。101配置管理4、配置基线基线是软件生存期各开发阶段末尾的特定点配置管理

三种常见基线

——功能基线在系统分析和软件定义阶段结束时，经过正式评审和批准的系统设计规格说明中对被开发软件系统的规格说明；经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对被开发软件系统的规格说明；由下级申请及上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。

——分配基线在软件需求分析阶段结束时，经正式评审和批准的软件需求规格说明。

——产品基线在软件组装与系统测试阶段技术时，经正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。102配置管理三种常见基线102配置管理四、版本管理1、软件版本：包含两种不同含义（1）为满足不同用户的不同使用要求，如适用于不同运行环境或不同平台的系列产品。（2）软件产品投入使用以后，经过一段时间运行提出了变更的要求，需要做较大的修正或纠错，增强功能或提高性能。2、版本标识版本管理也称版本控制。版本标识方法：（1）号码版本标识（2）符号版本标识：把重要的版本属性有选择地给出。如：V1/VMS/DBServer103配置管理四、版本管理1、软件版本：包含两种不同含义103配置管理五、配置审核（一）什么是配置审核它是指对于存储配置项及相关记录的软件基线库的结构、内容和设施进行检验，其目的在于验证基线是否符合描述基线的文档。验证包括：配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象；是否保持了可追溯性。配置标识的准则是否得到了遵循；变更控制规程是否以遵循，变更记录是否可供使用配置审核工作主要集中在两个方面，即：功能配置审核——验证配置项的实际功效是与其软件需求一致的。物理配置审核——确定配置项符合预期的物理特性，即特定的媒体形式。104配置管理五、配置审核（一）什么是配置审核104配置管理（二）为什么要实施配置审核

确保软件配置管理的有效性，不允许出现任何混乱现象。例如：——防止出现向用户提交了不适合的产品，如交付了用户手册不 适当的版本；——发现不完善的实现，如开发出不符合初始规格说明或未按变 更请求实施变更；——找出各配置项间不匹配或不相容的现象；——确认配置项已在所要求质量控制审查之后作为基线入库保存；——确认记录和文档保持着可追溯性。105配置管理（二）为什么要实施配置审核105配置管理六、配置状态报告（一）什么是配置状态报告

1、配置状态报告任务：有效的记录和报告管理配置所需要的信息目的：及时、准确的给出软件配置项的当前状况，供相关人员了解，以加强配置管理工作。

2、需要跟踪捕捉的状态报告信息可以是：配置项的当前标识已交付软件的配置变更请求或问题报告的状态已获准变更的状态106配置管理六、配置状态报告（一）什么是配置状态报告106最佳实践107

最佳实践08

8107最佳实践107最佳实践088107最佳实践软件研发的管理实践不同的项目需要不同的方法论，一个项目的最佳过程是这个项目所能负担的最小过程。——AlistairCockburn108最佳实践软件研发的管理实践108最佳实践本章提纲1IBM-Rational业务驱动开发的过程管理2微软公司的软件开发过程模式3敏捷模型的软件研发管理4面向构件的软件研发5软件研发的自定义体系109最佳实践本章提纲1IBM-Rational业务驱动开发的最佳实践敏捷模型的软件研发管理1敏捷方法的过程模型2敏捷过程的最佳实践110最佳实践敏捷模型的软件研发管理1敏捷方法的过程模型110最佳实践敏捷方法的过程模型主张简单、轻装前进。拥抱变化，这种变化是不断递增的。可持续性，简单的说，在开发的时候就能想象到未来。项目投资产生最大的效益或回报。有目的的建模。多种模型。高质量的工作、快速反馈。软件是项目的主要目标，文档是次要的。111最佳实践敏捷方法的过程模型主张简单、轻装前进。111最佳实践极限编程生命周期112最佳实践极限编程生命周期112最佳实践测试驱动开发113最佳实践测试驱动开发113最佳实践敏捷过程的最佳实践编程简单设计、测试、重构、编码标准团队实践代码集体所有、持续集成、隐喻、编码标准、每周40小时工作制、结对编程、小型发布过程现场客户、测试、计划博弈、小型发布起始阶段细化阶段构建阶段交付阶段需求用户素材小型发布先行测试测量分析CRC卡片迭代计划任务计划、迭代编程计划博弈设计系统隐喻单元测试重构持续集成实现编码标准简单设计集体代码所有权运行所有测试114最佳实践敏捷过程的最佳实践编程简单设计、测试、重构、编码标准最佳实践面向构件的软件研发1面向构件软件研发的思想2面向构件软件研发的阶段划分115最佳实践面向构件的软件研发1面向构件软件研发的思想115最佳实践面向构件软件研发的思想1．从传统的关注点分离到构件组装2．以构件为中心组织软件研发。3．高度关注可复用性和软件研发知识积累4．高度并行的开发过程116最佳实践面向构件软件研发的思想1．从传统的关注点分离到构件组最佳实践基于构件描述的网状软件结构117最佳实践基于构件描述的网状软件结构117最佳实践面向构件软件研发的阶段划分需求阶段。捕获需求、识别业务构件、归纳业务构件需求。分析与高层设计阶段。分析业务构件、识别服务构件，归纳服务构件的需求并完成架构设计。并行开发与测试阶段。提交、发布与部署阶段。应用管理。118最佳实践面向构件软件研发的阶段划分需求阶段。捕获需求、识别业提问与解答环节Questionsandanswers提问与解答环节119结束语

感谢参与本课程，也感激大家对我们工作的支持与积极的参与。课程后会发放课程满意度评估表，如果对我们课程或者工作有什么建议和意见，也请写在上边结束语

120软件研发项目管理2013-2-20软件研发项目管理2013-2-20标题添加点击此处输入相关文本内容点击此处输入相关文本内容前言点击此处输入相关文本内容标题添加点击此处输入相关文本内容标题添加点击此处输入相点击此处输入前言点击此处输入标题添加点122研发项目管理基础1计划管理2需求管理3设计管理4开发管理5测试管理6目录配置管理7最佳实践8123研发项目管理基础1计划管理2需求管理3设计管理4开发管理5测

基础管理01

1124基础管理0113总纲与规范六为法需求必为准团队必为本计划必为纲绩效必为证质量必为出变化必为形125总纲与规范六为法需求必为准4总纲与规范七定法兵马未动、合约先行（定需求）可行的做可行事（定技术方案）谋定而后动（定计划）专业的人做专业的事（定人员）沟通无止境、共识促发展（定共识）死亡之地不可不察也（定风险）应对随形、修道保法（定变更）126总纲与规范七定法兵马未动、合约先行（定需求）5总纲与规范三出路以正合（用人之术，诸如选育用留）以曲制（规律之术，诸如过程方法）以奇胜（变化之术，诸如动静之理）127总纲与规范三出路以正合（用人之术，诸如选育用留）6总纲与规范兵法一曰道目的二曰天制度三曰地需求四曰将专业角色五曰法过程128总纲与规范兵法一曰道目的7基础管理----过程管理过程的简单描述129基础管理----过程管理过程的简单描述8基础管理----过程管理软件研发的分类和组成软件基本过程：软件获取、供应、开发、运行和维护的过程，包括需求分析、软件设计、编码等过程。软件支持过程：对软件主要过程提供支持的过程，包括文档编制过程、配置管理过程、质量保证过程、验证和确认过程（测试过程）、评审过程等。软件组织过程：对软件主要过程和支持过程的组织保证过程，包括管理过程、基础设施过程、改进过程和培训过程。130基础管理----过程管理软件研发的分类和组成软件基本过程：软基础管理----过程管理ISO/IEC15504软件生存周期过程131基础管理----过程管理ISO/IEC15504软件生存周期基础管理----过程规范软件研发规范的建立软件能力成熟度模型（CMM/CMMI）IBM-Rtaional统一过程（RUP）极限编程（eXtremeProgramming，XP）微软软件框架（MSF）132基础管理----过程规范软件研发规范的建立软件能力成熟度模型基础管理----过程规范瀑布模型螺旋模型、增量模型、迭代模型V模型并发过程模型极限编程（XP）IBM-Rational统一过程（RUP）软件研发模型133基础管理----过程规范瀑布模型软件研发模型12基础管理----过程规范不是好的东西都能用，适用的才是最好的!需要我们根据自己人员的水平、公司情况、业务状况综合确定适合自己的研发过程134基础管理----过程规范不是好的东西都能用，13基础管理135

计划管理02

2135基础管理14计划管理02214计划管理软件研发的项目管理有效的项目管理是在用来实现项目具体目标的规定时间内，对组织机构资源进行计划、引导和控制工作。——《项目管理知识指南》136计划管理软件研发的项目管理15计划管理WBS：

项目计划形成之前，最好先画WBS表（WorkBreakdownStructure），主要原理是：将任务逐级分解直至个人，在矩阵中体现为：先确定横向有多少结点，再将每一结点任务逐渐细化直到个人，工作分解图（WBS）实际上就是将一个复杂的开发系统分层逐步细化为一个个工作任务单元，这样可以使我们将复杂、庞大的、不知如何下手的大系统划分成了一个个独立的我们能预测、计划和控制的单元，从而也就达到了对整个系统进行控制的目的。137计划管理WBS：项目计划形成之前，最好先画WBS表（WBS-工作分解结构1项目范围规划

1.1 确定项目范围

1.2 获得项目所需资金

1.3 定义预备资源

1.4 获得核心资源

1.5 项目范围规划完成2分析/软件需求

2.1 行为需求分析

2.2 起草初步的软件规范

2.3 制定初步预算

2.4 工作组共同审阅软件规范/预算

2.5 根据反馈修改软件规范

2.6 确定交付期限

2.7 获得开展后续工作的批准(概念、期限和预算)2.8 获得所需资源

2.9 分析工作完成3设计

3.1 审阅初步的软件规范

3.2 制定功能规范

3.3 根据功能规范开发原型

3.4 审阅功能规范

3.5 根据反馈修改功能规范

3.6 获得开展后续工作的批准

3.7 设计工作完成4开发

4.1 审阅功能规范

4.2 确定模块化/分层设计参数

4.3 分派任务给开发人员

4.4 编写代码

4.5 开发人员测试(初步调试)4.6 开发工作完毕……计划管理138WBS-工作分解结构1项目范围规划 计划管理17计划管理创建WBS的基本法则每个工作工作单元在WBS只能出现一次概要任务是对其下所有任务的总结每个WBS的条目都有单独的人员负责与实际要做的工作情形保持一致建立WBS时应让项目组员参予每个WBS条目都应备案WBS既要灵活又要不失控制139计划管理创建WBS的基本法则每个工作工作单元在WBS只能出现计划管理项目估算令人烦恼的项目估算：这个项目需要多长时间？这个模块大概多久完成？需要花费多少人力才能完成这个项目？项目的总成本大概为多少？

……140计划管理项目估算令人烦恼的项目估算：19计划管理项目成本的组成1.项目成本的组成（1）直接成本人力成本硬件设备软件费用（2）间接成本项目管理成本一般管理成本141计划管理项目成本的组成1.项目成本的组成20计划管理责任矩阵用距阵的形式列出对某项任务负责的人或资源。任务管理人员项目经理分析人员项目范围规划1.1确定项目范围A1.2获得项目所需资金A1.3定义预备资源A1.4获得核心资源A分析/软件需求2.1行为需求分析A2.2起草初步的软件规范A2.3制定初步预算A2.4工作组共同审阅软件规范/预算AP2.5根据反馈修改软件规范A2.6确定交付期限A2.7获得开展后续工作的批准AP2.8获得所需资源A142计划管理责任矩阵用距阵的形式列出对某项任务负责的人或资源。任计划管理项目软硬件资源管理1.软件资源管理操作系统编译器应用软件测试工具……2.硬件资源管理服务器PC……143计划管理项目软硬件资源管理1.软件资源管理22计划管理10种常见的风险No.软件风险相应对策1人员不足录用优秀人才；人员应适应岗位需要；全面考虑团队建设；骨干人员工作要协调；实施培训；预先安排关键人员的使用计划2进度计划和预算不准确详细评估多种资源成本和进度；依成本进行设计；采用渐增式开发；软件复用；纯净需求3开发了错误的软件功能进行组织分析；实施任务分析；进行用户调查；开发原型；及早编制用户手册4开发了不适用的用户接口开发原型；制作脚本；作业分析；弄清了用户特征(功能性、风格、工作负荷)5只追求表面效果，需求中含有一些不必要的功能（镀金）纯净需求；开发原型；成本－效益分析；依成本进行设计6需求不断变更重大变更设限；信息隐蔽；渐进式开发7外供部件不足制定基准点；检验；参考基准检查；兼容性分析8外包任务问题参考基准检查；发包前审核；未发包合同；竞标设计或开发原型；建立团队9实时性能达不到要求模拟；制定基准；建模；开发原型；安装测量装置；调准10误解计算机科学能力技术分析；成本－效益分析；开发原型；参考基准检查144计划管理10种常见的风险No.软件风险相应对策1人员不足录用计划管理项目跟踪和控制1.了解成员的工作情况2.调整工作安排，合理利用资源3.促进计划内容的完善4.促进项目经理对人员的认识5.促进对项目工作量的估计6.统计并了解项目总体进度7.有利于人员考核145计划管理项目跟踪和控制1.了解成员的工作情况24计划管理现代软件研发项目管理路线图概览146计划管理现代软件研发项目管理路线图概览25计划管理项目预算与成本1、项目成本=直接成本*2.5直接成本为prj中的成本2、项目工期=基本工期+（悲观时间-乐观时间）/63、项目工期较长，可以分解为多个项目，每个项目不超过6个月，6个月内按两周做计划。4、任务分解一般两周:过粗不利分配工作,过细不利于人员的主动性.5、要识别任务关键路径,根据人员情况并行或串行。147计划管理项目预算与成本1、项目成本=直接成本*2.5直接成计划管理WBSCHart148计划管理WBSCHart27计划管理ChartEXPERT149计划管理ChartEXPERT28计划管理关键路径实例-Microsoftproject150计划管理关键路径实例-Microsoftproject需求管理151

需求管理033151需求管理30需求管理03330需求管理软件研发的需求管理开发软件系统最为困难的部分就是准确说明开发什么。——弗雷德里克·布鲁克斯152需求管理软件研发的需求管理31需求管理软件需求工程

所有与需求直接相关的活动统称为需求工程，需求工程分为了两个部分：需求开发和需求管理。其中，需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分，而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪

软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。153需求管理软件需求工程所有与需求直接相关的活动需求管理软件需求工程

业务需求（businessrequirement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。

用户需求(userrequirement)文档描述了用户使用系统而完成的任务的集合，用户需求在用户案例（usercase）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。软件需求(fsoftwarerequirement)定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。154需求管理软件需求工程业务需求（businessrequi需求管理需求开发需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。获取数据分析、处理目标系统模型需求获取系统分析员从数据流和数据结构出发，找出系统各元素之间的联系、接口特征及设计限制、能否满足功能需求155需求管理需求开发需求开发的目的是通过调查与分析，获取用户需求需求管理需求获取的方法需求研讨会头脑风暴用例模型访谈角色扮演原型法156需求管理需求获取的方法需求研讨会35需求管理基于用例的需求获取执行者的识别谁使用系统的主要功能？谁将提供、使用和删除信息？谁负责维护、管理并保持系统正常运行？谁会对某一特定需求感兴趣？系统的外部资源是什么？系统需要和哪些外部系统交互？用例的识别某个执行者要求系统为其提供什么功能？该执行者需要做哪些工作？执行者需要阅读、创建、销毁、更新或存储系统中哪些（类）信息？系统中的事件一定要告之执行者吗？执行者需要告诉系统一些什么吗？那些系统内部的事件从功能的角度代表什么？由于新功能的识别，执行者的日常工作被简化或效率提高了吗？系统需要什么样的输入输出？输入在哪里？输出去往哪里？该系统的当前情况存在哪些问题？157需求管理基于用例的需求获取36需求管理需求确认为什么需要需求评审？在哪个阶段发现成本率需求1设计3-6编码10功能测试15-40验收测试30-70发布之后40-1000修订一个缺陷的相关成本158需求管理需求确认为什么需要需求评审？在哪个阶段发现成本率需求基础管理需求跟踪需求的标识<需求类型><需求#>需求类型可以是：F=功能需求，D=数据需求，B=行为需求，I=接口需求；O=输出需求。

例：需求标识为F03的需求表示编号为3的功能需求。159基础管理需求跟踪需求的标识例：需求标识为F03的需求表示编号基础管理160基础管理39设计管理161

设计管理04

4161设计管理40设计管理04440设计管理架构开发方法162设计管理架构开发方法41设计管理架构开发方法163设计管理架构开发方法42设计管理架构开发方法164设计管理架构开发方法43设计管理架构是软件的基石架构是软件的基础，一个良好的架构可以让软件有更长久的生命力，能发挥出更出色的性能；架构师要求对业务有深入的了解，这样才能让架构更符合软件的需要，更能发挥软件的特点。165设计管理架构是软件的基石架构是软件的基础，一个良好的架构可以设计管理166设计管理45设计管理167设计管理46设计管理168设计管理47设计管理169设计管理48开发管理

开发管理055170开发管理开发管理05549开发管理1.开发开发的目的包括：对照开发子系统的分层结构定义代码结构;以构件（源文件、二进制文件、可执行文件以及其他文件等）的方式开发类和对象;对已开发的构件按单元来测试;将各开发员（或团队）完成的结果集成到可执行系统中。171开发管理1.开发开发的目的包括：对照开发子系统的分层结构定开发管理2.过程策略里程碑：最初操作性能最初操作性能里程碑确定产品是否已经可以部署到Beta测试环境。在最初操作性能里程碑，产品随时可以移交给产品化团队。此时，已开发了所有功能，并完成了所有Alpha测试（如果有测试）。除了软件之外，用户手册也已经完成，而且有对当前发布版的说明。评估标准该产品发布版是否足够稳定和成熟，可部署在用户群中？是否已准备好将产品发布到用户群？实际的资源耗费与计划的相比是否仍可以接受？如果项目无法达到该里程碑，产品化可能要推迟一个发布版。172开发管理2.过程策略里程碑：最初操作性能最初操作性能里程碑确开发管理最佳开发实践新概念与最佳实践可持续开发节奏团队激励障碍列表持续集成产品燃尽图Sprint燃尽图173开发管理最佳开发实践新概念与最佳实践52开发管理

可持续开发节奏的相关概念

可持续的开发节奏是一个开发团队可长期（可以认为是永久）保持的开发节奏为了保持可持续的开发节奏，适当的休假可以让团队及时恢复精力。可持续的开发节奏并非禁止加班，但必须是偶然事件而非经常性事件174开发管理

可持续开发节奏的相关概念

可持续的开发节奏是一个开开发管理讨论当项目进度对于完成当前的迭代目标面临压力时，作为ScrumMaster，你会采取以下哪种方式？175开发管理讨论当项目进度对于完成当前的迭代目标面临压力时，作为开发管理ScrumMaster要关注团队的健康

高强度的开发节奏如果超过了团队可承受的范围，必然影响团队的健康（包括心理和生理健康）。ScrumMaster应该关注团队的健康状况。选择可持续的开发节奏，应该以团队能够感觉舒适地完成迭代目标为前提。176开发管理ScrumMaster要关注团队的健康

高强度的开开发管理不可持续开发节奏的影响177开发管理不可持续开发节奏的影响56开发管理不可持续开发节奏的影响Defect大量增加：持续加班状况下代码质量很难保证，必然导致defect数量增加。工作效率降低：研究表明，当人疲劳时工作效率将急剧下降。团队士气低下：长期的高强度工作必然使团队身心疲惫，士气低落。开始相互推诿责任：长期高负荷工作下，导致出现问题后开始相互埋怨。放弃探索最佳实践方法：磨刀不误砍柴工，最佳实践方法可以事半功倍。然而长期高强度工作会逐渐放弃花时间去“磨刀”。178开发管理不可持续开发节奏的影响Defect大量增加：持续加班开发管理障碍列表在敏捷项目管理中的意义

及时将团队的注意力引导向最重要的问题。集思广益。由团队成员一起讨论解决，而不是由传统意义上的项目经理独自来协调与分配。提高团队的自主性。与风险管理结合，对即将或已经发生的风险采取积极的应对态度。179开发管理障碍列表在敏捷项目管理中的意义

及时将团队的注意力引开发管理团队激励180开发管理团队激励59开发管理团队阶段回顾181开发管理团队阶段回顾60开发管理

什么是激励

激励=活力+指引+坚持182开发管理

什么是激励

激励=活力+指引+坚持6开发管理什么是团队–讨论：一群个体与一个团队的区别

一群个体避免交流与冲突自我中心低投入被动工作一个团队彼此信任有共同目标开诚布公互相帮助有原则有乐趣团结积极交流倾向于解决问题183开发管理什么是团队–讨论：一群个体与一个团队的区别

一群个体开发管理

团队绩效曲线

184开发管理

团队绩效曲线

63开发管理开发

详细设计\开发\单元测试为专业开发开发时间

任务<=两周；版本>=2周<=2月；这是一种健康节奏,不能经常加班。最佳开发实践

可持续开发节奏、团队激励、障碍列表、持续集成、产品燃尽图、Sprint燃尽图任务分配时间分配任务时按规划时间/1.2计算。如规划10天，10/1.2=8天，则安排8天完成，以保留时间贮备

在分配任务时1、以需求为主线（一个部分的需求、设计、开发、测试由一个人完成）2、以健康节奏（按120/100原则分配，具体因人而异3、任务分配在两周之内4、版本控制在两个月内5、行动之前落实承诺

开发主管在分配任务时1、选：胜任力2、定：定好目标，获得承诺3、育：培训4、用：定好绩效（工作节奏）5、留：奖惩（按绩效）总结

185开发管理开发详细设计\开发\单元测试为专业测试管理

测试管理066186测试管理测试管理06665测试管理

测试测试的目的在于：核实对象之间的交互。核实软件的所有构件是否正确集成。核实所有需求是否已经正确实施。确定缺陷并确保在部署软件之前将缺陷解决。187测试管理测试测试的目的在于：核实对象之间的交互。核实软件的测试管理1

软件工程与测试模型

不同的开发模式适配不同的测试模型和测试过程。开发流水线产品平台技术平台规划需求设计实现测试部署测试需求测试设计测试执行测试执行188测试管理1软件工程与测试模型不同的开发模式适配不同的测试测试管理1.1

测试模型1：瀑布模型瀑布模型的核心思想是按工序将问题化简，将功能的实现与设计分开，采用结构化的分析与设计方法将逻辑实现与物理实现分开。软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试、运行维护。规定活动自上而下、相互衔接的固定次序，逐级下落。189测试管理1.1测试模型1：瀑布模型瀑布模型的核心思想是按工测试管理1.2测试模型2：V模型V模型是最广为人知的测试模型由PaulRook在2０世纪８０年代后期提出的，旨在改进软件开发的效率和效果。从左到右，描述了基本的开发过程和测试行为非常明确地标明了测试过程中存在的不同级别，描述了这些测试阶段和开发过程期间各阶段的对应关系190测试管理1.2测试模型2：V模型V模型是最广为人知的测试模型测试管理1.3

测试模型3：W模型测试伴随整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法很好的支持迭代开发。191测试管理1.3测试模型3：W模型测试伴随整个软件开发周期，测试管理1.4

测试模型4：X模型很好地处理测试与开发的交接过程（交接的过程是一个时间段，而不是一个点）左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，给有经验的测试人员在测试计划之外发现更多的软件缺陷。192测试管理1.4测试模型4：X模型很好地处理测试与开发的交接测试管理2测试组织产品组/产品线测试组开发组项目1项目2项目3优势：1、与业务结合紧密（用例）；2、与代码结合紧密（白盒）；缺点：1、测试资源未统一动态调配，使用有浪费；2、测试技能的统一提升和培训少。193测试管理2测试组织产品组/产品线测试组开发组项目1项目2项测试管理2测试组织规模194测试管理2测试组织规模73测试管理2走向成熟：组织成熟怎么算组织成熟？195测试管理2走向成熟：组织成熟怎么算组织成熟？74测试管理2走向成熟：技术成熟：工具平台196测试管理2走向成熟：技术成熟：工具平台75测试管理2走