《ch软件过程管理实用教案》由会员分享，可在线阅读，更多相关《ch软件过程管理实用教案（89页珍藏版）》请在金锄头文库上搜索。
1、本章(bnzhn)内容提要软件过程与过程管理CMMI概述(ish)CMMI的成熟度等级及其过程域CMMI的应用PSP，TSP与CMMI敏捷软件开发方法第1页/共88页第一页，共89页。第四节CMMI的应用(yngyng)实施CMMI过程改进的两种方法(fngf)阶段表示连续表示CMMI评估第2页/共88页第二页，共89页。实施(shsh)CMMI(shsh)CMMI过程改进的两种方法CMMI模型支持两种实施过程改进的方法，一种称为(chnwi)阶段表示，一种称为(chnwi)连续表示。阶段表示（StagedRepresentation）为过程改进提供了一个预定义的路线图，即从成熟度等级1到成熟
2、度等级5逐级增加，要达到某一成熟度等级，必须满足该等级（及其以下等级）上所有过程域的目标。第3页/共88页第三页，共89页。连续表示（ContinuousRepresentation）支持单个过程域的改进，可理解为一个过程域接着一个过程域实施改进。在每个过程域上从能力(nngl)等级0到能力(nngl)等级5逐级增加。实施CMMICMMI过程(guchng)(guchng)改进的两种方法第4页/共88页第四页，共89页。阶段(jidun)表示和连续表示的对比阶段表示是从CMM模型继承而来，已经过多年的实践检验。它提供了一个明确的、被证实的过程改进路径，遵循这条路径不需要(xyo)过多的讨论和争
3、论。而且由于它的明确性和统一性，有助于进行跨组织的比较。连续表示的优点是提供了灵活性。用户可根据具体的业务目标来选择需要(xyo)实现的过程域及其实现次序。第5页/共88页第五页，共89页。CMMI评估(pn)成熟度等级的评估由美国卡内基梅隆大的软件工程研究所授权的主任评估师领导一个评审小组进行，其成员大部分来自企业内部。评估过程包括员工培训（企业的高层领导也要参加）、问卷填写和统计、文档审查、数据分析、与企业的高层领导讨论(toln)和撰写评估报告等。评估结束由主任评估师签字生效。评估结果报告给SEI，但SEI不会发“认证”证书。第6页/共88页第六页，共89页。CMMI评估(pn)一般有两
4、种类型的评估：软件过程评估和软件能力评价。软件过程评估用于确定机构当前过程的状态，决定一个机构所面临的高优先级的过程相关问题，并且获得(hud)机构对软件过程改进的支持。软件能力评价用来确定合格的软件项目承制方，或用来监督在目前的软件项目中正在进行软件过程的状态。第7页/共88页第七页，共89页。软件过程(guchng)评估方法判断一个组织当前的软件过程的能力状态，并发现(fxin)过程中的缺陷。判断并确定一个组织面对的与软件过程相关的改进策略。利用组织的支持来对该组织的软件过程进行有效的改进。第8页/共88页第八页，共89页。软件(runjin)能力评价方法判断有意承担某个软件(runjin
5、)项目的软件(runjin)组织（投标者）的过程能力。利用评价结果确定选择某一承包者的风险。判断已进行的软件(runjin)过程所处的状态是否正确或是否正常。推动承包者在工作过程中改进他们的软件(runjin)过程。第9页/共88页第九页，共89页。过程评估(pn)和能力评价步骤挑选队伍：成员必须具有专业的软件工程和管理方面的知识，并接受过基本(jbn)CMM/CMMI概念和特定评估及评价方法的训练。问卷调查：让来自被评估单位的代表完成软件过程成熟度问卷并回答评估评价组提出的诊断性问题。响应分析：明确哪些回答与问题的答案相吻合，并确定须进一步调查的领域。第10页/共88页第十页，共89页。现场
6、调查：从响应分析的结果出发，评估小组进行提问、检查、协商等，以获取专业性的结论，说明软件过程的KPA是否达到了应有的目标。评估小组提供一个定义软件过程优缺点的结果清单。对于软件过程评估来说，这些结果将成为过程改进的基础和参考(cnko)；对于软件能力评价来说，这些结果为决策者提供风险分析的技术基础。过程评估(pn)和能力评价步骤第11页/共88页第十一页，共89页。评估小组完成KPA基本概况的描述文件(wnjin)，给出组织已经满足的KPA目标和尚未满足的KPA目标。过程评估和能力(nngl)评价步骤第12页/共88页第十二页，共89页。软件过程评估和软件能力(nngl)评价之间的不同软件过程
7、评估和软件能力评价的结果可能不同（主要是因为评估和评价的侧重点不一样，而且被评估和被评价的组织、项目、软件产品都会发生变化，因此，应该考虑评估和评价的Context）。软件过程评估和软件能力评价在出发点和目标(mbio)上是不同的（导致成熟度提问单的内容组织不一样，收集的信息不一样，结论的评价不一样）。第13页/共88页第十三页，共89页。软件过程评估是在一个开放的、互相协作的环境下进行的。而软件能力(nngl)评价往往是在有较大阻力的环境中进行的。（过程评估是为了提高管理者和工程师的工作水平，而能力(nngl)评价是为了表明一个软件组织的实际软件过程能力(nngl)，为选择承包者和减少费用服
8、务）。软件过程评估和软件能力(nngl)评价之间的不同第14页/共88页第十四页，共89页。CMMI评估(pn)的注意事项筹备必备机构SEPG：负责过程(guchng)的定义和策划。SQA：负责审核软件过程(guchng)的实施情况；产品质量的审核和控制。确定合适的目标对指定的KPA作评估或诊断，2级时也可要求对3级的KPA进行评估。有些组织一开始可能并不想进行评分和评级，而是希望评估组从其现有的实践中确定最佳实践，作为组织的标准实践进行推广。第15页/共88页第十五页，共89页。确定范围部门：哪些部门参加。项目：选择合适的项目。KPA：确定对那些KPA进行评估。人数：为了保证评估取证有足够的
9、可信度，人数总和应该超过(chogu)组织人数的20。约束对不参加的部门，评估组无权进行访谈或取证。CMMI评估(pn)的注意事项第16页/共88页第十六页，共89页。w对不参加的人员，评估组无权进行访谈或取证(qzhn)。w经费和预算不得超过某个限度。w进度安排应该在一个适当的期限内。w期望w要求评估师签署结论性证明文件。w要求评估组指明每个KPA的优缺点，哪些实践有待改进。w要求评估组提出下一步过程改进的计划和大致的日程安排。CMMI评估(pn)的注意事项第17页/共88页第十七页，共89页。承诺组织主管保证参加(cnji)评估的人员不会影响评估活动的正常进展。保证为评估工作提供相应的后勤
10、服务。向评估组授权“开工令”（从某日起开始工作）。CMMI评估(pn)的注意事项第18页/共88页第十八页，共89页。准备待审文档-组织级文档软件生存期模型研发(ynf)过程的各种方针项目遵循的规程选用的标准裁剪指南标准报表标准测量集CMMI评估(pn)的注意事项第19页/共88页第十九页，共89页。-项目级文档软件开发计划(jhu)软件质量保证计划(jhu)软件配置管理计划(jhu)项目在实施中遵循的规程测量计划(jhu)培训教材CMMI评估(pn)的注意事项第20页/共88页第二十页，共89页。-实现级文档会议概要：评审会等项目管理过程的状态报告：月度报告等各类变更申请(shnqng)测试
11、记录开发过程中产生的各类工作产品：设计文档，源代码清单等。CMMI评估(pn)的注意事项第21页/共88页第二十一页，共89页。影响CMMI过程改进(gijn)成败的因素过程改进必须有高级主管的支持与委托，并积极地管理过程改进的进展。获取中层管理的支持，以方便地获取过程改进的资源（人员、时间、经费和设备）。基层技术人员的参与和支持极端重要。利用定量的可观察数据尽快使过程改进的成果可见，从而激励参与者的兴趣。按照软件过程改进对企业(qy)文化的要求进行变革，要求软件过程改进为商业利益服务，并与企业(qy)其他部分协调。第22页/共88页第二十二页，共89页。第五节PSP，TSP与CMMIPSP的
12、产生CMM/CMMI只关注“做什么”，而不关注“怎么做”，未提供实现各过程域所需要的知识和方法。为了解决上述问题(wnt)，CMU-SEI在基础上提出了PSP/TSP。第23页/共88页第二十三页，共89页。PSP的产生(chnshng)1995年，CMU-SEI的Watts s. Humphrey领导开发出PSP（Personal Software Processes），被认为是由定性软件工程走向定量软件工程的标志。PSP是一种(y zhn)可用于控制、管理和改进软件工程师个人工作方式的自我改善过程，是一个包括软件开发表格、指南和规程的结构化框架。第24页/共88页第二十四页，共89页。PS
13、P关注点如何制订计划如何控制质量如何与其他人相互协作如何预防缺陷(PSP重点)关键(gunjin)是如何提高设计质量第25页/共88页第二十五页，共89页。PSP中的个人(grn)任务为每一个项目/模块制订开发计划；记录开发时间；跟踪错误；在工程(gngchng)摘要报表中保留数据；使用已有的数据计划以后的项目/模块；分析已有的数据以改进开发过程，不断提高开发水平。第26页/共88页第二十六页，共89页。PSP的使用(shyng)效果参加PSP培训的104位软件(runjin)人员在应用了PSP后:软件(runjin)中总的差错数减少了；在测试阶段发现的差错减少了；生产效率提高了第27页/共8
14、8页第二十七页，共89页。PSP过程(guchng)PSP是一个软件过程的描述、测量和改进方法的结构化集合，它可以为软件工程师带来更少的错误代码、更好的预算和计划以及更高的生产率，从而能够帮助软件工程师改善其个人性能。PSP提供了帮助软件工程师开发软件的表格、脚本和标准，以估算和计划软件工程师的工作，以便软件工程师可以更加清楚自己(zj)的个人技术并且提升个人表现。PSP显示了如何定义过程及如何测量其质量和生产率。第28页/共88页第二十八页，共89页。PSP过程(guchng)PSP不依赖于任何技术(jsh)（语言、工具和设计方法），它：示范了软件过程原则；帮助工程师做正确的计划；告诉工程师
15、怎样提高软件质量；建立个人软件过程提升的度量标准；确定过程改进在工程师表现中的影响。第29页/共88页第二十九页，共89页。PSP过程(guchng)改进第30页/共88页第三十页，共89页。PSP0（个人过程(guchng)基线）PSP0是过程基线，目的是为了在个人的工作中引入表格和脚本，以便工程师按照测量和报告格式记录软件过程。PSP0-1.目前过程：记录软件工程师在工程中使用的具有代表性的软件开发方法。PSP0-2.时间记录：记录软件工程师在不同的软件开发阶段（计划(jhu)、设计、编码、编译和测试、维护）所花费的时间。第31页/共88页第三十一页，共89页。wPSP0-3.失误记录：按
16、照一致的格式记录软件工程师引入软件中的缺陷，并记录软件工程师尝试(chngsh)解决问题的方法和步骤。wPSP0-4.错误分类标准：一方面为软件工程师提供在系统中可观察到的典型缺陷种类列表，有助于软件工程师把典型缺陷标准化；另一方面提供一种预定义的步骤和工具方便软件工程师对新的缺陷进行归类和记录。PSP0（个人(grn)过程基线）第32页/共88页第三十二页，共89页。PSP0可以通过增加(zngji)下列过程而扩展到。PSP0.1-1.代码规范：通过对设计过程、开发过程和设计语言结构进行规范，约束具有不同技术背景和软件开发风格的软件工程师。由组织统一制订设计方法和编码标准。PSP0.1-2.
17、代码规模度量：测量代码的长度、功能、复杂度、再利用数、冗余数等。一般基于某种测量标准进行，如LOC，软件工程师应该了解LOC及相关测量概念。（个人过程(guchng)基线）第33页/共88页第三十三页，共89页。PSP0.1-3.过程优化计划：针对(zhndu)已经记录的软件过程中的问题和经验教训，帮助软件工程师给出软件过程能力的改进建议，并以结构化的方式表达软件过程、问题、建议教训、改进建议等项目。（个人过程(guchng)基线）第34页/共88页第三十四页，共89页。PSP1（个人计划(jhu)过程）PSP1在PSP0的基础上增加了计划步骤：PSP1-1.规模估计：分为代码规模估算、时间估
18、算、资源估算。（1）代码规模估算：软件工程师可以凭借PSP0级代码规模测量经验预测他们将要(jingyo)写的任务模块或算法的可能规模。（2）时间估算：PSP0级时间测量过程可以总结出不同复杂度模块的编写时间，凭借这些经验，软件工程师可以针对当前系统的模块结构层次给出完成每个模块的估算时间（乐观时间、最可能时间、悲观时间）。第35页/共88页第三十五页，共89页。（3）资源估算：对于软件开发的一段生存期，软件工程师预测所需要的软件、硬件和人力资源，其中人力资源预测包括人力需求、人力成本估算和项目管理标准。PSP1-2.状态报告：对软件工程师的工作进行跟踪，检查规模估计与实际(shj)状态之间的
19、差异。PSP1（个人(grn)计划过程）第36页/共88页第三十六页，共89页。在PSP1的基础上引入了任务计划和安排。PSP1.1-1.任务计划及安排：基于PSP1中的规模估计数据制订软件(runjin)项目的需要完成的任务计划，并将任务按时间段分配给不同的人力资源。一般采纳网络安排技术，如PERT(ProgramEvaluationandReviewTechniques)和CPM(CriticalPathMethod)，软件(runjin)工程师应该理解网络安排技术和计划策略。（个人(grn)计划过程）第37页/共88页第三十七页，共89页。PSP2（个人(grn)质量管理）PSP2强调提
20、高质量，引入了缺陷管理。PSP2-1.代码审查。对代码进行检查和分析，以发现程序缺陷。PSP2-2.设计审查。设计审查要求提供一些评估设计质量的指标，如：代码重用率、代码冗余、代码完整性和协作性。设计的一致性检查主要涉及(shj)：结构化（控制和数据）一致性、耦合一致性、可移植和互用一致性。第38页/共88页第三十八页，共89页。（个人质量(zhling)管理）在基础上增加了设计模板。设计模板提供了设计过程的完全标准化，并且连同缺陷预防、过程分析和过程基准一起形成了各种设计检验技术。可类似地将此方法应用到许多(xdu)过程阶段之中去，包括：需求说明、文档和测试等。第39页/共88页第三十九页，
21、共89页。PSP3（循环(xnhun)个人过程）PSP3将个人软件过程的应用拓展到大规模程序开发当中。将开发大型程序的个体过程细分为可以应用PSP2的片段，遵照PSP2过程循环增量地开发大型程序，从而(cngr)支持迭代式的开发。在任何时间点，只有一个PSP2级过程是活动的。第40页/共88页第四十页，共89页。TSP软件开发通常是以团队形式进行的，因此仅有PSP是不够的。CMU-SEI又以PSP为基础，开发了TSP（TeamSoftwareProcesses ），即小组软件过程。TSP指导项目组中的成员如何有效规划和管理所面临的项目开发任务，并且使软件开发队伍始终(shzhng)以最佳状态来
22、完成工作。第41页/共88页第四十一页，共89页。TSP实施集体管理与自我管理相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对小组开发过程进行定义、度量和改进。小组远不只是一群有才能的个人的集合。为了建立并保持(boch)高效率的工作关系，小组需要共同的目标，大家一致同意的行动计划和适当的领导，小组成员要在需要的时候乐于寻求帮助。TSP第42页/共88页第四十二页，共89页。TSP实施(shsh)条件需要有高层主管和各级经理的支持，以取得必要的资源。整个(zhngg)软件开发小组至少应在CMM的第二级（已管理级）。全体软件开发人员必
23、须经过PSP的培训，并有按TSP工作的愿望和热情。开发小组成员应在2到20个人之间。经验表明，48个人的小组工作效率最高。第43页/共88页第四十三页，共89页。TSP的管理(gunl)原则TSP遵循集体管理和自己管理自己相结合的原则。在每一项目阶段开始要作好工作计划。要有明确定义的目标，努力完成已经接受的委托任务。应定期(dngq)追踪项目进展状态并进行定期(dngq)汇报。按自己管理自己的原则管理软件过程。按集体管理的原则进行管理，全体成员都要参加和关心小组工作的规划、进展的追踪和决策的制订等项工作。第44页/共88页第四十四页，共89页。TSP的循环(xnhun)开发策略TSP通过循环开
24、发策略完成产品。先在第一个周期中开发出最小的合理产品，再决定(judng)在接下来的每一个周期中要加进去的功能。这样的步骤可以保证得到一系列最终产品的可运行的前期版本。每个周期包括7个步骤：决定(judng)策略、进行计划、考虑需求、设计、实现、测试和最终检查。第45页/共88页第四十五页，共89页。TSP度量(dling)要素对软件开发小组进行度量的基本要素：所编文档页数；所编代码行数；花费在各个开发阶段或各个开发任务上的时间(shjin)；在各个开发阶段中注入和改正的差错数目；在各个阶段对最终产品增加的价值。第46页/共88页第四十六页，共89页。TSP度量(dling)要素TSP有关质量
25、度量的经验原则：软件设计时间应大于软件实现时间；设计评审时间至少应占一半以上的设计时间；代码(dim)评审时间应大于编制代码(dim)的时间；每千行源程序在编译阶段发现的差错不应超过10个；每千行源程序在测试阶段发现的差错不应超过5个。第47页/共88页第四十七页，共89页。PSP、TSP与CMMI之间的关系(gunx)PSP、TSP和CMMI为软件(runjin)产业提供了一个集成化的、三维的软件(runjin)过程改革框架。第48页/共88页第四十八页，共89页。PSP注重于个人的技能，能够指导软件工程师保证自己的工作质量(zhling)，估计和规划自身的工作，度量和追踪个人的表现，管理自
26、身的软件过程和产品质量(zhling)。经过PSP的学习和实践，软件工程师们能够在他们参与的项目中更为高效和高质量(zhling)地完成工作，从而保证了项目整体的进度和质量(zhling)。PSP、TSP与CMMI之间的关系(gunx)第49页/共88页第四十九页，共89页。TSP注重团队的高效工作和产品交付能力，结合PSP的工程技能，使软件工程师将个体过程结合进小组软件过程，并通过指导管理层如何支持和授权项目小组，坚持团队的高质量的工作，并且依据数据进行项目管理，以达到(ddo)生产高质量产品的目的。PSP、TSP与CMMI之间的关系(gunx)第50页/共88页第五十页，共89页。CMMI
27、注重于组织能力和成熟度的提高，它提供了评价组织的能力、改进(gijn)组织过程的管理方式，比TSP具有更高的层次。CMMI关注“做什么”，PSP和TSP则提供了“怎么做”。PSP、TSP与CMMI之间的关系(gunx)第51页/共88页第五十一页，共89页。第六节敏捷(mnji)软件开发方法核心思想：敏捷软件开发方法的思想是现代管理(gunl)理念的延伸，其核心是以人为本，发挥人的主观能动性。敏捷软件开发方法认为，对项目最重要的影响因素是人，而不是过程和技术。不能把人员当做由过程驱动的“可插拔替换的编程单元”，而要发挥人的能动性，建立紧密协作的、自组织的团队。第52页/共88页第五十二页，共8
28、9页。核心思想以过程为核心（而不是以人为核心）的软件组织为了少犯错误，保证项目成功，而从项目开发经验中总结和定义了许多过程，用于约束开发行为，避免重复相同的错误。由于项目的复杂性和多样性，这种过程定义会越来越多，最终形成一个庞大的、笨重的过程集合，这样的过程集合会降低(jingd)开发效率和产品质量，增加开发成本。第53页/共88页第五十三页，共89页。敏捷(mnji)软件开发宣言我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为(rnwi)：人和交互重于过程和工具可以工作的软件重于面面俱到的文档客户合作重于合同谈判随时应对变化重于遵循计划虽然右项也有其价值，
29、但我们认为(rnwi)左项更加重要。第54页/共88页第五十四页，共89页。人和交互(jioh)重于过程和工具只有好的过程而缺乏合格的人员，不能保证项目不失败。优秀的人员不一定是顶尖的技术人才，但一定能和其它人员良好地协作。拥有(yngyu)一般的技术人才，但能够有效沟通、紧密协作的团队比那种虽拥有(yngyu)技术精英，但不能有效沟通的团队更有可能取得成功。第55页/共88页第五十五页，共89页。工具虽然重要，但那种最先进的、大而复杂的工具不一定(ydng)适合组织的需要，而且可能会给组织带来负面影响。先尝试小而灵便的工具。首先要致力于建立团队，然后让团队根据自己的需要配置工具环境。人和交互
30、重于过程(guchng)和工具第56页/共88页第五十六页，共89页。可以工作(gngzu)的软件重于面面俱到的文档过多的文档会带来许多负面影响。需花费许多资源来产生这些文档并保持它们之间的一致性（特别是文档与编码之间的一致性）。如果不一致，文档将成为产生混乱的根源。应该书写一些文档来描述系统的基本结构和原理，但文档一定要短而精炼，只用来描述总体设计原理和最高层次的系统结构。代码已包含了最丰富(fngf)的、且无歧义的系统信息。第57页/共88页第五十七页，共89页。当有新的成员加入项目团队，通过与他不断地交流和密切地合作来使他熟悉当前项目，而不是让他阅读大量文档。不要去产生文档，除非有紧迫而
31、明显(mngxin)的需求。可以(ky)工作的软件重于面面俱到的文档第58页/共88页第五十八页，共89页。客户合作(hzu)重于合同谈判软件项目的成功依赖于客户频繁的反馈，而不是依赖于与客户达成的合同或协议。合同中所规定的需求、进度和成本很容易变得没有意义，因为项目处在持续不断的变化中。客户必须每天与开发团队一起(yq)工作，对开发团队的工作及时提供反馈。第59页/共88页第五十九页，共89页。随时应对(yngdu)变化重于遵循计划由于项目中存在很多不确定因素，应对变化的能力常常决定了项目的成败。计划必须是灵活的，能够(nnggu)适应业务和技术的变化。一个比较好的计划策略是：对未来两星期的
32、工作制定详细的计划；对未来3个月的工作制定很粗略的计划；对更远的时间段，则制定最初级的计划。第60页/共88页第六十页，共89页。敏捷(mnji)原则由敏捷软件开发宣言的思想衍生出敏捷软件开发的12条原则。（1）我们最优先要做的是通过尽早地、持续地交付有价值的软件来满足客户(kh)的需要。有统计数字表明，越早、越频繁地向用户交付软件，软件的质量就越好。敏捷开发方法力求项目开始几周后，就向用户交付一个最初的系统，以后每隔两周就交付一个增加了功能的系统。第61页/共88页第六十一页，共89页。w对于每次交付的软件，客户可以将其投入应用(yngyng)，如果软件的功能还不足以满足应用(yngyng)
33、的需要，就只对其进行审查，并提出修改意见。敏捷(mnji)原则第62页/共88页第六十二页，共89页。敏捷(mnji)原则（2）欢迎需求的变化(binhu)，即使到了开发的后期。敏捷过程能够驾驭变化(binhu)，为客户创造竞争优势。使用敏捷过程的开发组织欢迎需求的变化(binhu)，因为他们认为需求变化(binhu)可以让它们更多地了解市场。敏捷开发组织采用各种方法和技术，使软件的结构高度灵活，需求的变化(binhu)对系统的影响被最小化。第63页/共88页第六十三页，共89页。敏捷(mnji)原则（3）频繁交付(jiof)可以工作的软件，从几个星期到几个月，时间越短越好。敏捷开发组织不满足
34、于交付(jiof)文档和计划，他们的目标是频繁地交付(jiof)可以工作的软件，从而满足客户的需要。第64页/共88页第六十四页，共89页。（4）在整个项目开发期间，业务人员和开发人员必须(bx)每天工作在一起。软件项目必须(bx)被不断地调整和引导，这要求用户、开发者和其他利益干系人要频繁地交流。敏捷(mnji)原则第65页/共88页第六十五页，共89页。敏捷(mnji)原则（5）围绕斗志高昂的人构建项目，给他们提供所需的环境和支持，并且信任他们能够完成任务。在一个敏捷项目中，人员被认为是最重要的因素，其它所有因素（过程、环境、管理等）都被认为是次要的，当这些因素对人员造成不利影响时，就必须
35、对其做出改变(gibin)。例如，如果某些过程步骤对团队人员来说是个障碍，那么过程就必须改变(gibin)。第66页/共88页第六十六页，共89页。（6）在团队内部，最有效率和最有效果的信息传达方式(fngsh)就是面对面的交流。在敏捷项目中，主要的交流方式(fngsh)就是交谈。文档在必要的时候会被创建，但不会试图用文档来捕获所有项目信息。在敏捷项目组中，默认的交流方式(fngsh)是交谈，而不是文档。敏捷(mnji)原则第67页/共88页第六十七页，共89页。（7）可以工作的软件是进度的主要度量标准。对于敏捷项目来说，进度的度量标准是当前可满足用户(yngh)需求的软件的量，而不是当前项目
36、所处的阶段、文档数量或基础代码的数量。项目完成了30%的含义是30%的用户(yngh)所需功能已被实现。敏捷(mnji)原则第68页/共88页第六十八页，共89页。（8）敏捷过程提倡可持续开发。出资人、开发者和用户应该共同维持(wich)一个稳定的开发速度。敏捷小组会在整个项目开发期间保持一个适当的、可持续的开发速度，从而维持(wich)最高的质量标准。敏捷项目不会使开发者感到疲惫不堪。敏捷(mnji)原则第69页/共88页第六十九页，共89页。（9）对卓越技术和良好设计的不断追求有助于提高敏捷性。敏捷开发团队认为提高质量会加快开发进度。因此要保持软件的精简(jngjin)和健壮。敏捷开发团队
37、的每个成员都要致力于开发高质量的代码，不能把混乱的、底质量的代码留到以后去修改。敏捷(mnji)原则第70页/共88页第七十页，共89页。（10）简单尽量减少工作量的艺术是至关重要的。敏捷开发方法总是选择达到目标的最简单途径。敏捷开发团队并不花费大量(dling)精力去预防将来可能出现的问题，而是专注于对当前工作采用最简单、最高质量的解决方案，并相信将来如果问题出现，可以很方便地进行修改。敏捷(mnji)原则第71页/共88页第七十一页，共89页。（11）最好的架构(jiu)、需求和设计都出自于自组织的团队。敏捷开发团队是自组织的团队。职责并非是从团队外部加给每一个团队成员，而是团队作为一个整
38、体接受职责并自己决定怎样去完成它。敏捷开发团队成员在项目的各个方面（架构(jiu)、需求、测试等）都是共同负责的，不会出现某一人单独负责一方面任务的情况。敏捷(mnji)原则第72页/共88页第七十二页，共89页。（12）每隔一定(ydng)时间，团队都要总结怎样更有效率地工作，然后相应地调整自己的行为。敏捷开发团队认识到环境在不断地改变，因此团队也需要不断地对组织、规则、惯例和各种关系进行调整，以保持自身的敏捷性。敏捷(mnji)原则第73页/共88页第七十三页，共89页。极限(jxin)编程实践符合敏捷软件开发思想和原则的具体实践方法有多种，如极限(jxin)编程（XP）、Scrum、Cr
39、ystalMethods、FDD等。极限(jxin)编程（ExtremeProgramming，XP）是最著名的敏捷开发方法，它由一系列简单的、互相依赖的最佳实践组成。第74页/共88页第七十四页，共89页。客户(kh)也是开发团队成员客户作为开发团队的成员，与开发人员密切合作，共同(gngtng)解决存在的问题。第75页/共88页第七十五页，共89页。短交付(jiof)周期XP项目每两周向客户交付一次软件，所交付的软件涉及客户的一部分需求，客户要及时作出反馈。为了实现短交付周期，项目组需要制定(zhdng)迭代计划和发布计划。两周为一个迭代周期，迭代代表向用户的一次产品交付，是用户所需功能的
40、一个集合。六个迭代（约三个月时间）形成一个发布（Release），发布是一个主要的产品交付，会被集成到最终产品中。第76页/共88页第七十六页，共89页。项目组必须(bx)为每次迭代和发布制定预算。用户根据预算来选择迭代和发布中所包含的功能。短交付(jiof)周期第77页/共88页第七十七页，共89页。结对编程两个程序员用一台电脑一起工作，其中一人操作键盘，输入程序，另一人与他密切交流，检查错误和需要改进的地方。两人的角色频繁互换。所编写的代码由两人共同负责。每个程序员至少每天更换一次配对的对象，这样当一个迭代结束后，每个程序员都与小组中所有其它程序员配过对，工作涉及到本次(bnc)迭代的所有
41、内容。第78页/共88页第七十八页，共89页。结对编程能够极大地促进知识在团队中的传播，没有(miyu)任何一个程序模块由单独一人完成，这样就保证了任何人的工作在必要时都可由其他人代替完成。经验证明，结对编程没有(miyu)降低开发团队的效率，而且大幅度地减小了缺陷率。结对编程第79页/共88页第七十九页，共89页。集体所有权代码归集体所有，团队中的所有成员都有权访问和改进项目的所有模块代码。没有一个人单独负责某一模块或技术。集体所有权可促进交流，增强团队凝聚力和发挥(fhu)集体创造力。第80页/共88页第八十页，共89页。可持续的开发(kif)速度软件项目不是短跑，而是马拉松，它需要一个可
42、持续的速度，能够保持能量和敏锐性。极限编程的一个原则是“不要加班”，但也有例外，即在一个发布周期的最后(zuhu)一周加班是允许的，因为这时可能需要加速以达到发布目标。第81页/共88页第八十一页，共89页。开放(kifng)工作空间开发小组在一个大的办公区域中一同工作，每个桌子上放两到三台电脑，墙上可以张贴状态图、任务分解(fnji)图等各种图表。这样的工作环境便于交流，每个人员都可以及时了解到小组其他人员的工作状态，知道他们是否遇到了麻烦。第82页/共88页第八十二页，共89页。计划(jhu)游戏XP项目计划的主导思想(sxing)是将业务责任和开发责任相分离。业务人员（客户）确定哪些产品
43、特征是重要的，开发人员确定实现这些特征需花费多少成本。在每个迭代或发布周期的开始，开发人员交给客户一个预算，说明在该迭代或发布周期中能够完成多少工作，客户根据这个预算选择需实现哪些产品功能。第83页/共88页第八十三页，共89页。敏捷(mnji)软件开发方法参考资料解析极限编程：拥抱变化（第二版），KentBeck著，电子工业(gngy)出版社敏捷软件开发：原则、模式与实践，RobertC.Martin著，人民邮电出版社第84页/共88页第八十四页，共89页。敏捷开发方法是针对传统的重量级开发方法的缺点而提出的，但它并没有全盘否定重量级开发方法。两种方法不是谁取代谁的关系，它们互相(hxing
44、)吸取对方的长处，将长期并存。软件组织应根据团队和项目的实际情况从两种方法中提取所需要的技术和方法，灵活应用。第85页/共88页第八十五页，共89页。本章(bnzhn)小结软件过程、软件过程管理CMMICMMI的发展(fzhn)历史CMMI的成熟度等级CMMI的关键过程域CMMI的应用PSP和TSP敏捷软件开发方法第86页/共88页第八十六页，共89页。练习题什么(shnme)是软件过程和软件过程管理？简述实施CMMI过程改进的两种表示方法及其特点。第87页/共88页第八十七页，共89页。感谢您的观看(gunkn)！第88页/共88页第八十八页，共89页。内容(nirng)总结本章内容提要。响应分析：明确哪些回答与问题的答案相吻合，并确定须进一步调查的领域。部门：哪些部门参加(cnji)。人数：为了保证评估取证有足够的可信度，人数总和应该超过组织人数的20。PSP0-1.目前过程：记录软件工程师在工程中使用的具有代表性的软件开发方法。TSP指导项目组中的成员如何有效规划和管理所面临的项目开发任务，并且使软件开发队伍始终以最佳状态来完成工作。花费在各个开发阶段或各个开发任务上的时间。感谢您的观看第八十九页，共89页。
