《软件项目管理原理与实践》 课件 第10章 敏捷项目管理.pdf

第10章敏捷项目管理内容提要 10 概述O 10.1.1 敏捷概述O 10.1.2 敏捷项目管理的焦点o 10.1.3 敏捷项目管理指导原则o 10.1.4 敏捷流程架构 10.2 管理的角色与职责O 10.2.1 角色o 10.2.2 职责 10.3 敏捷项目管理的特征O 10.3.1 敏捷方法的特点o 10.3.2 敏捷方法的核心思想o 10.3.3 敏捷项目管理方式2内容提要)104主要敏捷方法O 10.4.1 XP极限编程o 10.4.2 Sc rum 工具o 10.4.3 Co c kbum的水晶系列方法O 10.4.4 开放式源码O 10.4.5 Co ad的功用驱动开发方法o 10.4.6 自适应软件开发方法o 10.4.7 DevOps10.5案例分析：敏捷开发技术在电子商务软件的应O 10.5.1 项目背景说明O 10.5.2 项目组织机构o 10.5.3 项目实施过程o 10.5.4 项目实施效果 10.6小结3Plan:Start*FinishFinishSo urc e:Do ug DeCarl o-eXt reme Pro j ec t Management:Using Leadership,Princ ipl es,and To o l s t o Del iver Val ue in t he Fac e o f Vo l at il it y5极限项目管理The Path to SuccessAdo pt a When diso rder q uant um is t he real it y.mindsetThen,facilitate and manage the flow of emotions,thoughts and interactions.And yo u w il l gain and sust ain c o mmit ment.And pro duc e a val ued o ut c o me.6敏捷项目管理敏捷项目管理(Agile Project Managements APM)是近来流行的项目管理方法论。APM是该领域的新概念，敏捷宣言是所有 APM模型的指导原则。O多数APM模型源于软件开发，因此对软件开发实践的针 对性很强。O原型和适应性项目框架是APM模型中仅有的适用于所有 类型的项目的模型。O由于开发周期短，对需求管理恰当，敏捷项目管理正在 从软件研发行业延伸到已经采取项目化管理的大部分行 业中。7敏捷项目管理敏捷方法允许软件开发者更快速地反应，提 供更好的方法处理变化和捕捉机会，弱化了 经典的软件生命周期，允许开发团队在同一 软件系统的不同部分开展工作。O刚开始开发软件时，并不需要一个完整的软件需求说明,很可能只有一个关于这个软件基本想法的简短描述。O以此作为起点，团队开始根据现实情况的要求创建需求 规格说明、编码和测试。O可能第一天编码，第二天撰写软件需求规格说明，第三 天调试程序。8敏捷软件开发开始，敏捷软件开发并没有一套固定的步骤,更多体现为一套准则。O敏捷方法的创始者确定了两条基本准则。O以通过快速响应为客户提供高质量的软件为目标，使开 发的软件能适应不断变化的环境。O之后，敏捷软件开发已经形成一套有关最佳实践和方法 的论著，但这些并不是经典软件工程中那些固定的技术。O敏捷软件工程是一种态度、一种管理风格而不是硬性规9敏捷属性Agility Attributes10Traditional vs Agile PlanningDel iver(pro babil ist ic)Def ineReq uirement s Dat a-driven2 Dec isio nsFreq uent 1Feedbac k 1 Lo o ps 1/Fo c us o n w o rkt he w o rkerFreq uent Del ivery Buil t-in.Qual it y10概念及简介敏捷项目管理的概念来源于敏捷软件开发。随着敏捷软件开发的发展，极限项目管理(Extreme Project Management)和敏捷项目 管理(Agile Project Management)的概念和 方法被相继提出，并仍在不断发展。实际上，敏捷项目管理只是各种敏捷软件开发方法相应 项目管理的统称。敏捷项目管理(Agile Project Management f APM)是近来流行的项 目管理方法论。APM是该领域的新概念，敏捷宣言是所有APM模型的指导原则。210.1概念及简介 1 0.1.1 敏捷概述 1.敏捷简介O多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改(code and fix)”。口设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复 杂时，要想加入新的功能就越来越困难。同时，错误故障越来越多，越来越难于排除。一个典型的标志，就是当系统功能完成后有一个很长的测试阶 段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的 影响。13敏捷简介我们使用这种开发模式已有很长时间了，不过我 们实际上也有另外一种选择，那就是“正规方法(methodology)”。o这些方法，对开发过程有着严格而详尽的规定，使软件开发更有可 预设性并提高效率，这种思路是借鉴了其他工程领域的实践。这些正规方法已存在了很长时间了，但是并没有 取得令人瞩目的成功，甚至就没怎么引起人们的 注意。O对这些方法最常听见的批评就是它们的官僚繁琐，要是按照它的要 求来，那么有做太多的事情需要做，而延缓整个开发进程。O所以它们通常被认为是“繁琐滞重型”方法，或“巨型(mo numental)”方法。14软件开发的发展瀑布模型湍鬻累黑“自适应软件开Co nc ept o f 发”概念Adapt ive So f t w are Devel o pment(Edmn ds,EA)快速应用开发Rapid App.Devel o pment(James Mart in)1970 19741980Sc rum(Ken Sc hw aber,Jef f Sut herl and)DSMD动态系统开发方法(DSDM Co nso rt ium)Adapt ive So f t w are Devel o pment(ASD)自适应软件开发(ASD)(Jim Highsmit h,Sam Bayer)FDD特征驱动开发(Jef f De Luc a)20031980Agil e Manif est o 敏捷宣言1995 19962000 2001水晶系列方法 Cryst al Cl ear(Al ist air Co c kburn)极限编程XP.(Kent Bec k,Ward Cunningham and Ro m Jef f ries)精益软件开发Lean SW Dev.Marry&To m Po ppendiec k)15敏捷简介Scrum Lean software development Kanban(process+method)Extreme Programming(XP)Continuous Integration(Cl)Continuous Delivery(CD)Feature Driven development(FDD)Test Driven Development(TDD)Crystal ClearLight w eight appro ac hesScrum-of-ScrumsScrum at Scale(Scnim9Scale)Large-scale Scrum(LeSS)Scaled Agile Framework(SAFe)Disciplined Agile Delivery(DAD)Dynamic Systems Development Method(DSDM)Agile Project Management(AgilePM)Agile Unified Process(AUP)Open Unified Process(OpenUP)Ful l er appro ac hes(beyo nd 1 t eam)16Agile in the Software Engineering EvolutionDeveloping for 1,2,3.usersProgrammer(s|Computer scientistProgrammerFrequent collaboration;Face-to-face communication between the programmer and user(s);Many iterationsvebper is also the userDevelopment of larger multi-users systemsProblem:Old way of working doesnt work anymoreNeeds,Scalability,Ana fysis,Maneability,Job SpecialisationNeed for scoktbtktyNeed for better analysisNeed for ben&systemsUgly systems&kt of reworkSolution,Structured approdches/methodologies(-scalable by nature),Job specialisation:AnalystLater,further specialisation of the role of analyst(BA,BPA,FA,AGILE:Developer dee bps the wanted and demanded software for the end-user”Blame the methodologies(and not on the people).Dump them.Cut all the oerload.Back to the core idea&start from a blank slate.AnalystBusiness Stakeholderstake over the direction of fT projectsBooming IT-Lots of neophytesUsing methodolqgies and methods in defined&structured projectsWrong application of methodologies and met hods(by the book)Micro man 革 be entExcessive control and administration*Throw-it-over-the waif-cukureLack of col labor at ion between analysts and developers in earl/stages.Impoverishment of developers jobLittle regard for needed work conditions(environment,information,time,disturbances,.)Worshipping technologies.Knowing and applying methods asthe are described stiff ice to do thejob.*7ou ask.We deliver*Very superficial training in Systems Analysts and Software Engineering(loss of knowledge)Programming software goodies for end-users*conceiving and developing larger systemsStill expecting the business stake ho kiers to communicate what they want and assuming that delivering that willsolw the problem and satisfy them.Ignored strengths of traditional software development methods.Forgot lessons learned by traditional software development methods.18df Evolution of software developmentTRAD WATERFALLParo Mel c t evel o pmo nt.exped t o o l sAGILE SCRUMTeam-based devel o pment,c o 8abo raf ive t o o l sCODELESS WORKSHOPReai-t ime devel o pment.Co del ess t o o l sRESOURCES1|fl|T|T)：T|T|司加加同同侨苗苗同同吊mTOOLS十 种 API AFI APISKILLSMBCOSTS$TIME TO MARKETo o o eo o oo o o o。19902 0002 010$1920敏捷简介1960197019801990 2000 2010 202021A Waterfall So ftware Develo pment Meth o do lo gyThe met h o do l o gy is essent ial l y a Wat erf al l mo del w it h ext remel y sho rt t imel ines.To pCo ders So ftware Develo pment Meth o do lo gyAn Agile So ftware Develo pment Meth o do lo gy!_!Iteratio n 1Iteratio n 2Cro wdBuild So ftware Develo pment Meth o do lo gyIteratio nDesign,Buil d,Test&Depl o y are do ne in paral l el6gBuil d is do ne by t he c ro w dIteratio n 2TimeDemingPDSA To yo t aIt erat ive&inc rement al devel o pment-X-15 hyperso nic j etAllistair CockburnCryst al1993 Jennifer StapletonDynamicSyst emsDevel o pment Met ho dJeff De LucaFeat ure Driven Devel o pmentTo yo t a Pro duc t io n Syst emNew Pro duc t Devel o pment GameRef ac t o ringSc rum1950sTOYOTAHirotaka TakeuchiBill OpdykePairPro grammingIkujiro Nonaka23雪鸟城、敏捷宣言.犹他州（Utah）的雪鸟城（Snowbird）位于盐湖城外约25 英里的地方,2001年2月11日至13日,就在这里，一个滑雪 胜地，17个人聚到一起，交谈、滑雪、休闲，当然还有聚 餐。制定并签署了行业历史上最重要的文件之一：关于编 码集的独立宣言。Understanding The Agile ManifestoA Brief&Bold Guide to Agile24敏捷软件开发宣言的签署，推动了敏捷方法的发展，敏捷宣言本质是揭示一种更好的软件开发方法，启迪人们 重新思考软件开发中的价值和如何更好的工作。2510.1概念及简介敏捷软件开发宣言的签署，推动了敏 捷方法的发展，敏捷宣言本质是揭示一种 更好的软件开发方法，启迪人们重新思考 软件开发中的价值和如何更好的工作。敏捷宣言26敏捷软件开发宣言四大核心价值(1)个人和互动高于流程和工具。(2)工作软件高于理解文档。(3)客户协作高于合同协商。(4)变化响应高于计划遵循。27敏捷软件开发宣言12条原则(1)通过早期和连续型的高价值工作交付满足“客户”。(2)大工作分成可以迅速完成的较小组成部门。(3)识别最好的工作是从自我组织的团队中出现的，(4)为积极员工提供他们需要的环境和支持，并相信他们可以完成工 作。(5)创建可以改善可持续工作的流程。(6)维持完整工作的不变的步调。(7)欢迎改变的需求，即使是在项目后期。(8)在项目期间每天与项目团队和业务所有者开会。(9)在定期修正期，让团队反映如何能高效，然后进行相应地行为调 整。(10)通过完成的工作量计量工作进度。(11)不断地追求完善。(12)利用调整获得竞争优势。28.敏捷开发方式简介人是最重要的个体和交互胜过过程和工具Y过程和工具，过犹不及花费大量时间过多的文档比缺少文档更糟/-必须与代码同步短小、主题突出敏捷宣言可以工作的软件胜过面面俱到的文档较好的做法 需要编写的文档包括结构方面的文档系统原理方面的文档直到迫切需要，并且有重大意义时才编制文档代码如何培训新的团队成员 团队少量有价值的文档（个人意见），如概念模型客户合作胜过合同谈判有序、频繁的客户反馈为为工作提供指导的合同才是好合同变化总是比计划快计划不能太远f-Y计划周期长，灵活性就小响应变化胜过遵循计划为下两周做详细的计划好的计划应该是这样的 为下三个月做粗略的计划为更长的时间做极为粗糙的计划292.与传统开发方法比较 2.敏捷开发方式与传统开发方法的比较传统开发敏捷开发302.与传统开发方法比较传统开发是一种瀑布式的流程312.与传统开发方法比较敏捷开发流程322.与传统开发方法比较二者之间的主要区别如下：O(1)敏捷开发是以人为中心，而传统开发以过程为中心。并不是 说，传统开发就没有人的参与，或者说人不是一个重要因素。应该 说的是，敏捷开发和传统开发的侧重点、中心不同。那么，为什么会是这个样子呢？因为，传统开发中，设计已经是在初始阶段完成了，在实现阶段不再修改，换 句话说，实现阶段就是对设计的完成，设计方案是不可改变的了。这样就忽略了用户的反馈、忽略了开发人员的设计的主观能动性，使得开发人 员只是专注于代码层面的事情。O(2)敏捷开发是有适应能力的，而传统开发是计划驱动的。传统开发，设计阶段完成了，整个的过程就是按照设计方案进行，在设计阶段 的后续过程中，无法再对设计方案进行修改，而敏捷开发需要一次次的迭代完 成，正是这些迭代完成了对客户真实需求的软件的演进。33瀑布模型和敏捷开发流程AGILEINITIATIONANALYSISDESIGNCONSTRUCTIONTESTINGINITIATIONANALYSISDESIGNCONSTRUCTIONTESTINGWATERFALL MODEL34传统软件开发敏捷软件开发基础假定管理风格 知识管理 交流开发模型组织结构 质量控制可以完整描述系统需求,系统是可预测的，通过 周密、完整的计划来开 发软件命令和控制显式正式生命周期模型（瀑布或其 他变种）机械的（正式的）大型组织 严格的计划和控制，后 期大量测试基于需求变更和快速反馈 通过小团队持续设计、测 试、改进完成高质量的软 件开发领导力和合作非正式非正式演进-交付模型灵活的小型组织持续演进需求、设计、方 案，持续测试3510.1.2敏捷项目管理的焦点 主管期望在项目管理流程中得到什么呢？主管想得到3个关键的东西：。首先，主管希望这个流程是可靠的，每个项目都可以产 生创新的结果。O第二，主管希望这个流程是可预见的，这样他可以有效 地计划和管理诸如财务管理、人员配备和产品投放等企 业活动。O第三，主管想得到可信的、符合实际的信息，因为构想 可能是错的、商业模式可能是错的、人们可能遇到不能 跨越的障碍、项目进展并不总是一帆风顺。如果项目需要终止，他想及早结束而不是等到后期才结 束。可信的进度报告可以让经理尽早采取适当的措施。3610.L2敏捷项目管理的焦点 可靠但不重复O在评估项目绩效时，不能区分高度不确定性和高度确定性的项目环 境会造成很多混乱。O这种混乱源于两个地方，即范围的定义、估计和限制之间的区别。O可靠流程将重点放在输出，而不是输入。可靠性是以结果为推动力,重复性是以输入为推动力。O敏捷项目中需要考虑的正确范围不是限定的要求，而是清晰明白的 产品构想。O“整个产品是否符合客户或者产品营销的构想？”混乱的另一个源 泉是将成本和进度看作是估计，而不是限制。进度报告O敏捷项目管理并不放弃控制，它确定了责任，修订了对控制内容的 定义。3710.L2敏捷项目管理的焦点(1)可靠但不重复O在评估项目绩效时，不能区分高度不确定性和高度确定性的项目环 境会造成很多混乱。O这种混乱源于两个地方，即范围的定义、估计和限制之间的区别。O可靠流程将重点放在输出，而不是输入。O可靠性是以结果为推动力，重复性是以输入为推动力。敏捷项目中 需要考虑的正确范围不是限定的要求，而是清晰明白的产品构想。O“整个产品是否符合客户或者产品营销的构想？”混乱的另一个源 泉是将成本和进度看作是估计，而不是限制。(2)进度报告O敏捷项目管理并不放弃控制，它确定了责任，修订了对控制内容的 定义。3810.1.3敏捷项目管理指导原则 人是受价值观驱使的，敏捷项目管理因而也 是以价值观为推动力的。一个团队可以采用敏捷做法，但如果它不接 受敏捷价值观和原则，它将不能得到敏捷开 发的潜在好处。O原则性强的领导是高效团队最为关键的特征之一。在业 绩优良的团队中，领导管理原则，而原则管理团队。敏捷宣言的核心价值观派生出6条原则，而 正是这6条原则指导着敏捷项目管理。O如果没有这些指导原则，那么，即使敏捷做法，如迭代 交付，通常也会被错误使用，甚至更糟糕的是，团队自3910.1.3敏捷项目管理指导原则 1.客户价值和创新产品O(1)提供客户价值；O(2)采用迭代的、基于功能的交付方式；。(3)支持卓越技术。2.领导一协作管理O(1)鼓励探索；O(2)建立适应能力(自我组织、自律)强的团队;O(3)简单化。40敏捷项目管理指导原则 这6条原则有效地组合在一起，组成了一个原则体系。虽然,各条原则分开来也可能有帮助，但6条原则合在一起则可 以创造一个促进突发结果的环境。10.1.4 敏捷流程架构 流程也许不如人那么重要，但绝非不重要。像其他事物一样，流程必须与企业目标联系起来。如果企业目标是重 复性的制造，那么常规性流程是完全适当的，而如果企业目标是可靠 的创新，则流程架构必须是有机的、灵活的和容易改变的。敏捷流程架构需要体现其核心原则，除了支持企业目标外，该架构还 需要：O(1)支持构想、探索、适应文化；O(2)支持自我组织、自律的团队；O(3)根据项目的不确定性程度，尽量提高可靠性和连贯性；O(4)保持灵活和易于变化；O(5)支持流程的透明化；o(6)与学习结合起来；o(7)将支持各个阶段的做法包括在内；o(8)提供管理检查点(Ch ec kpo in t)、对该构架进行评估。4210.1.4 敏捷流程架构该架构中各阶段的命名与传统的阶段命名（如开始、计划、定义、设计、构建、测试）完全不同，其意义重大。O第一，“构想”代替较传统的“开始”，指出构想的重要性。O第二，推测阶段代替计划阶段。每个词都传达一定的意义，而各个意义来 自他们长期的系统用法。“计划”一词已经与预测和相对确定性相关联，而“推测”表示未来是不确定的。许多面临不确定未来的项目经理仍在试 图“计划”排除该不确定性。我们必须学会推测和适应，而不是计划和建 造。O第三，敏捷项目管理模式用探索代替通常的设计、构建和测试阶段。以迭 代交付的方式，很明显探索是非线性的、并存的、非瀑布式的模式。在推 测阶段提出的问题需要“探索”。鉴于结果不能完全预测，推测暗示着灵活性的需求基 于现实。O敏捷项目管理模式强调执行以及探索性而非确定性。O实施敏捷项目管理的团队密切关注构想、监控信息，从而适应当前情况，这就是适应阶段。最后，敏捷项目管理模式以结束阶段收尾，这个阶段的、一.11?r（-1=1，.、JU.，,一、i43敏捷项目管理流程敏捷项目管理模式的结构：构想一推测一探 索一适应一结束I构想 I巳口太噂最终产品 构想，需要确定产品构想、项目范围、项目社团 以及团队共同工作的方式。O构想阶段为客户和项目团队创造构想，该构想包括提供什么、谁提 供和如何提供。O如果没有构想，其他的项目启动活动都是无用之功。O用商业话语来说，构想是项目早期“成功的关键因素”。首先，我们需要构想提供什么，即产品及项目范 围构想。其次，我们需要构想参与的人是谁，客户、产品 经理、项目团队成员和利益相关方组成的社团。最后，项目团队成员必须构想他们打算如何共同 工作。452.推测 推测，需要制定基于功能的发布计划、里程 碑和迭代计划，确保交付构想的产品。O“推测”一词首先让人们想到不计后果的冒险景象，但 实际上字典对它的定义是“根据不完全的事实或者信息 猜测某事”，这正是这个阶段要做的事情。O“计划”一词具有确定和预测的含义，而计划的更有用 的定义，至少对于探索性项目来说，是基于不完全的信 息推测或者猜测。人们认为制定计划可以产生确定性，但事实 远非如此。O他们带来的只不过是衡量他们绩效的东西，而一旦这个 衡量尺度与现实出现偏差，他们又不能重新计划。462.推测敏捷项目管理更多的是构想、探索，而不是 计划、执行，它迫使我们面对这样的现实：O不稳定的商业环境和变化多端的产品开发环境。推测阶段实际上是构想阶段的延伸并与它相 互影响，它包括：O(1)收集初始的、广泛的产品要求。O(2)将工作量定义为一个产品功能清单。O(3)制订一个交付计划(发布、里程碑、迭代)，包 括那些功能的进度表和资源分配。O(4)在估计项目成本这个计划中加入风险降低策略，并生成其他必要的行政管理和财务信息。473.探索探索，需要在短期内提供经测试的功能，不 断致力于减少项目风险和不确定性。探索阶段提供产品功能。从项目管理的角度看，此阶段 有三个关键的活动区域。第一，是通过管理工作量和使用适当的技术方法和风险降低策 略，交付计划的功能。第二，是建立协作的、自我组织的项目社团，这是每个人的责 任但需要由项目经理推动。第三，是管理团队与客户、产品经理和其他利益相关方的相互 父流。48敏捷项目管理的构想和探索周期探索，需要在短期内提供经测试的功能，不 断致力于减少项目风险和不确定性。构想周期产品构想项目范围 和界限探索周期审查和适应 开发发布计划产品：模拟、模型、实际产品、工程面 包板、关键中间件494.适应适应，需要审核提交的结果、当前情况以及团队的绩效,必要时做出调整。O适应意味着修改或改变而不是成功或失败。如果项目的指导哲学认为，适 应变化比执行计划更重要，则将失败归罪于计划的变更是不会有任何结果 的。O非常特别的流程并不能从错误中吸取教训，而吸取教训是敏捷项目管理的 关键。O自构想阶段以后，其循环通常是“推测-探索-适应”，每次迭代都不断对 产品进行提炼。O但要是团队收集到新的信息，定期地回到构想阶段也很有必要。在适应阶段，需要从客户、技术、人员和流程绩效、以及 项目状况等方面对结果进行评估。O该分析将会对比实际结果和计划的结果，但更重要的是，要根据项目得到 的最新信息，思考实际的与修订后的项目前景。O修改后的结果将返回、融入到重新计划工作中，开始新的迭代。505.结束，结束，表明终止项目、交流主要的学习成果 并庆祝.在某种程度上方项目根据开始和结束来界定O。许多组织由于没有明确项目的终结点，通常在客户之间 会造成理解问题。项目应该以庆祝方式结束。O结束阶段以及每次迭代末尾的“小型”结束的主要目标,是学习并将学到的东西融入到下一次迭代工作中，或 者传递给下一个项目团队。515.结束在敏捷项目管理的每个阶段中，都有与敏捷 价值观和指导原则相一致的具体做法。O这些做法，应该看作是一个“做法系统”，因为它们作 为一个系统相互补充，与价值观和原则保持一致。O但它们并不局限于保持一致，它们还着眼于实施。O没有做法的原则只是个空壳，而没有原则的做法，往往 会毫无判断地被生搬硬套。没有原则，我们就不知道如何实施做法，比 如说，没有简单原则，我们往往会过多地看 重做法的形式和仪式。O原则指导做法，做法用实际例子证明原则，它们是相辅Xr-r AA525.结束在选择和使用这些做法时，采用了如下指导 原则：O(1)简单的；O(2)再生的而非常规性的；O(3)与敏捷价值观和原则一致的；O(4)集中于交付活动(增值)而非合规活动；O(5)最少数量(刚刚可以完成工作)的；o(6)相互支持的(做法系统)。5310.2管理的角色与职责 10.2.1 角色 在敏捷项目管理中主要的角色：。项目经理、主任业务分析师、项目团队和产品所有者。工项目经理O在敏捷世界中把项目经理描述成项目领导者 2.业务分析师O业务分析师是产品管理、营销、会计等的一部分或需要 向这些机构报告，而项目团队需要向首席信息官(Chief Information Officer,CIO)或者首席技术官(Chief Technology Officer,CTO)报告。5410.2管理的角色与职责3,产品所有者。从项目投资组合的角度看，这个角色是主要的派遣人，如果当前的冲刺中有与功能有关的问题出现时，他也是 整个项目团队的联系点。号4.项目团队O项目团队成员从他们的日常活动继承了项目的衡量标准,他们会在团队、产品所有者和其他项目利益相关者中传 播这种衡量标准。5510.2.2 职责 10.2.2 职责.(1)清除障碍在敏捷项目管理中有两种机制来处理这些障 碍。O第一个，是每日例会，在这里人们将问题表达出来并且 寻求解决的方案。第二个，是项目经理的角色，他负责处理那些阻碍团队 进展的问题。5610.2.2 职责(2)制定迭代计划。迭代的时间通常为26周，越短越好，尤其是在项目的 早期阶段。迭代1迭代2迭代3迭代4在前面 迭代中 定义在前面 迭代中 定义UCA场景1UCB场景1UCC 场景3UCC 场用4UCB9UCB场景3UCC场景1UCC场景2UCA场景2已计划5710.2.2 职责.(3)回顾O回顾并不是学习教训。传统的“学习-教训I-总结”安排在项目的末尾进行。O敏捷项目在迭代与迭代之间执行回顾。(4)评估。敏捷项目中，只有开发团队才能估算结果。敏捷项目经 理要获取并跟踪估算的结果。采用哪种估算的方法，选择哪种评估技巧要以易用以及能快速 采用为准。5810.2.2 职责(5)报告。在敏捷项目中，报告的力量极为强大，因为团队可以分 享内部和外部所完成的需求，项目的进展以及系统的质 量。(6)每日例会O主持会议包括确保团队成员以同事的方式互相报告状态,在会议上提出可能阻碍问题需进行记录，列入项目经理 需要做的工作列表中。5910.2.2 职责(7)领导在迭代中，需要发挥领导技能让团队前进。O团队中典型的问题都是这样的，琐碎的或者非常具有挑 战的未被解决的瑕疵、没有开发人员主动去解决生成的 崩溃问题、开发人员结对的时间太长而需要其他人员更 多地融合以及需要对需求进行协商等。敏捷项目经理提醒团队成员吧工作做好、随时了解关键 条目的最新状态并且记录已完成的事项。6010.3敏捷项目管理的特征 10.3.1敏捷方法的特点 敏捷型方法主要有两个特点敏捷型方法是“适应性(Adaptive)”而非“预设性(Predictive)”的敏捷型方法是“面向人的(People-Oriented”而非“面向过程的(Process-Oriented)6110.3敏捷项目管理的特征 1.适应性和预设性O软件过程不可能照搬其它工程领域原有的方法，需要有 适应其特点的新的开发方法。6210.3敏捷项目管理的特征 2.面向人而非面向过程，敏捷方法特别强调开发中相关人员之间的信O项目失败的原因最终都可以追溯到信息没有及时准确地 传递到应该接受它的人。在开发过程中，项目的需求是在不断变化的,管理人员之间、开发人员之间以及管理人员 和开发人员之间，都必须不断地了解这些变 化，对这些变化做出反应，并实施在随后的 开发过程中。63当前，软件开发敏捷度的推进，反映了对软 件工艺化的认同。面对不可避免的变化的需求时，敏捷软件开发的目的，是为了提升软件的灵活性、适应性。O这是通过推行“小增量”开发来生产软件，在快速迭代 过程中获得反馈，并根据需要对软件不断调整来实现的O敏捷软件开发团队，有自己的工作方式，根 据手上的项目选择他们需要的方法来开发软 件，并根据项目实际情况调整开发过程。O实际上，软件开发过程中，敏捷开发团队需要像他们开 发软件那样敏捷地改进其方法。6410.3.2敏捷方法的核心思想；1,核心思想o 敏捷软件开发(Agile Software Development)是一组强调在不确定和混乱的情况下适应软件需求快速变 化的、基于迭代式开发的软件开发方法、实践。当前，敏捷方法是一种主流软件开发方法，广泛应用于各种 软件开发中，也包括很多规模较大的软件开发中。O 敏捷软件开发主要由有经验的软件工程师和咨询师提出，而非来自于学术界的研究成果。在2001年“雪鸟会议”期间，与会者形成了一些关于软件开 发的共同观点，即敏捷宣言“个体和互动胜过流程和工具，可以工作的软件胜过详尽的文档，客户合作胜过合同谈判；响应变化胜过遵循计划”。该宣言定义了，敏捷软件开发的核心价值观和原则，而这些 原则具体是由敏捷实践、敏捷实践的组合，即敏捷方法来实 血的_651.核心思想敏捷方法的核心思想，主要有下面三点：O(1)敏捷方法是适应型，而非可预测型。与传统方法 不同，敏捷方法拥抱变化，也可以说它的初衷就是适应 变化的需求，利用变化来发展，甚至改变自己，最后完 善自己。O(2)敏捷方法是以人为本，而非以过程为本。传统方 法以过程为本，强调充分发挥人的特性，不去限制它。并且软件开发在无过程控制和过于严格繁琐的过程控制中取得 一种平衡，以保证软件的质量。O(3)迭代增量式的开发过程。敏捷方法以原型开发思 想为基础，采用迭代增量式开发，发行版本小型化。口它根据客户需求的优先级和开发风险，制定版本发行计划，每 一发行版都是在前一成功发行版的基础上进行功能需求扩充，最后满足客户的所有功能需求。662.基本特征我们把软件开发过程中拥有大量中间产品(如需求规约、设计模型等)和复杂控制的软件开发方法称为重型方法。O由此，我们称中间产品较少的方法为轻型方法。O从表象来看，重型方法注重开发文档的完备性和充分性；而敏捷型方法认 为最根本的文档应该是源码，而不是繁琐的文档。从实质上说，有如下两方面更深层次的区别，O(1)敏捷型方法的思想是“自适应”的，而非如“预设”的重型方法试 图预先固定需求并拟定详细开发计划。敏捷型方法适应需求的变化，甚至可以说其初衷就是针对变化的需求的。O(2)敏捷型方法的思考角度是“面向人”的，而非“面向开发过程”的O 重型方法在实践原则中总是把开发者看作是一个泛化的生产要素，而忽视了作为决定性因 素的人的特殊性；而敏捷型方法则强调以人为本，并贯穿实践始终。由上可知敏捷型方法其实是软件开发方法论从无到重型再进一步发展的成果。673.适用范围 实际上，满足工程设计标准的唯一文档是源代码清单。软 件项目的设计，是一个抽象的概念。O它涉及了程序的概括形状、结构以及每一模块、类和方法的详细形状。系 统设计得到了有关系的一个清晰的“图像”，这一图像可以保持到首次发 布。O但随着项目的开发，程序“片段”就可能像不断腐化的“面包碎片”，发 出“臭味”，并不断蔓延和积累，