敏捷视角下的过程课件.ppt

《敏捷视角下的过程课件.ppt》由会员分享，可在线阅读，更多相关《敏捷视角下的过程课件.ppt（24页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、第1页，此课件共24页哦4.1 敏捷是什么 和许多管理方法概念不同，“敏捷”是从整体能力或表现的角度着眼的，它昭示了一种经营方式，这是理解其意义的要点。敏捷性有两个基本对象：整个企业（或组织）及对企业中的人：对于公司，敏捷是有利于在顾客机会持续而不可预测地变化的竞争环境中运作的能力。对于个人，敏捷是对公司底线的作用能力，这个底线就是为响应不可预测地变化的顾客机会经常地重组其人与技术资源。敏捷软件开发不是一个具体的过程，而是一个涵盖性术语（umbrella term），用于概括具有类似基础的方式和方法。这些方法，其中包括极限编程（Extreme Programming）、动态系统开发方法（Dyn

2、amic System Development Method）、SCRUM、Crystal和Lean等，都着眼于快速交付高质量的工作软件，并做到客户满意。第2页，此课件共24页哦敏捷原则：1.优先级最高的是，通过早期和持续交付有价值的软件来满足客户。2.欢迎变更需求，即使在开发的后期提出。敏捷过程为客户的竞争优势而控制变更。3.以两周到两月为周期，频繁地交付可运行的软件，首推较短的时间定量。4.在整个项目过程中，每一天开发人员都要和业务人员合作。5.由个体推动项目的建设，为个体提供所需的环境，支持和信任。6.在开发团队中或开发团队间传递信息的最为有效和高效的方法是面对面的交谈。7.衡量进展的重

3、要尺度是可运行的软件。8.敏捷过程提介可持续的开发。9.发起人，开发者和用户应该步调一致。10.不断地关注技术上优越的设计会提高敏捷性。11.简洁是最重要的，简洁就是尽量减少工作量的艺术。12.最佳的架构，需求和设计来自于自组织的团队。13.团队要定期反省如何使工作更有效，然后相应地调整行为。第3页，此课件共24页哦4.2 敏捷过程是什么 任何一个敏捷过程都可以由所强调的三个关键假设而识别出来：提前预测哪些需求是稳定的以及哪些需求会变化非常困难。同样，预测项目进行中客户优先级的变化也很困难。对很多软件来说，设计和构建是交错进行的。事实上两种活动应当顺序开展。从制定计划的角度来看，分析、设计、构

4、建和测试并不像我们所设想的那么容易预测。4.2.1 敏捷开发的立场 将敏捷软件开发作为许多传统软件工程的对立面，它们在优越性和适用性方面存在着许多争论。没有人反对敏捷，真正问题在于“什么是最佳实现途径”。敏捷学派内部，针对敏捷问题，也提出了很多有细微差异的过程模型。第4页，此课件共24页哦4.2.2 人的因素 敏捷软件开发的拥护者花费了很多精力强调“人的因素”在成功敏捷开发中的重要性。敏捷开发团队及成员必须具备以下一些特点：基本能力共同目标精诚合作决策能力模糊问题解决能力相互信任和尊重自我组织第5页，此课件共24页哦4.3 敏捷过程模型4.3.1 极限编程（eXtreme Programmin

5、g）XP（eXtreme Programming）方法是最引人注目的一种轻型开发方法。它规定了一组核心价值和方法，消除了大多数重量型过程的不必要产物，建立了一个渐进型开发过程。该方法将开发阶段的4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。它把软件生命周期划分为用户故事、体系结构、发布计划、交互、接受测试和小型发布6个阶段。XP开发模型与传统模型相比具有很大的不同，其核心思想是交流（Communication）、简单（Simplicity）、反馈（Feedback）和进取（Aggressiveness）。XP开发小组不仅包括开发人员，还包括管理人

6、员和客户。该模型强调小组内成员之间要经常进行交流，在尽量保证质量可以运行的前提下力求过程和代码的简单化；来自客户、开发人员和最终用户的具体反馈意见可以提供更多的机会来调整设计，保证把握正确的开发方向。第6页，此课件共24页哦策划设计编码测试重构用户故事 权值 验收测试准则迭代计划简单设计CRC卡Spike解决方案原型结对编程连续集成单元测试验收测试软件增量 项目速度估算发布极限编程过程第7页，此课件共24页哦XP有四个核心价值是我们应该注意沟通：问题往往是由于开发人员与设计人员、设计人员与沟通：问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的客户之间的沟通不畅造成的简单：应

7、该尽量保持代码的简单，只要它能工作就可以与简单：应该尽量保持代码的简单，只要它能工作就可以与其实现一个复杂的的系统，不如设计一个能够满足目前需其实现一个复杂的的系统，不如设计一个能够满足目前需要的、简单的系统，因为你所考虑的情况可能永远都不会要的、简单的系统，因为你所考虑的情况可能永远都不会发生。发生。反馈：尽快获得用户的反馈，并且越详细越好，使得开发人员反馈：尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。能够保证自己的成果符合用户的需要。勇气：这是最重要的核心价值。因为勇气：这是最重要的核心价值。因为XP强调要强调要拥抱变化拥抱变化，因，因此对于用户的反馈

8、，要勇于对自己的代码进行修改，丢掉坏的此对于用户的反馈，要勇于对自己的代码进行修改，丢掉坏的代码。代码。第8页，此课件共24页哦 XP的适用环境：的适用环境：XP弱化针对未来需求的设计，非常注重当前的简化弱化针对未来需求的设计，非常注重当前的简化.它的实践，有一个非常关它的实践，有一个非常关键的假设就是：开发人员只注重眼前需求，依赖重构来适应需求的变动，这样所带键的假设就是：开发人员只注重眼前需求，依赖重构来适应需求的变动，这样所带来的风险、开销要小于需求变化使得事先充分设计失效的代价；反之，实施来的风险、开销要小于需求变化使得事先充分设计失效的代价；反之，实施XP就就 是不明智的是不明智的.

9、因此因此,XP适合规模小、进度紧、需求变化大、质量要求严的项目。适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的 代价来满足用户代价来满足用户未来的需求，未来的需求，XP在平衡短期和长期利益之间做了巧妙的选择。在平衡短期和长期利益之间做了巧妙的选择。第9页，此课件共24页哦策划：策划：策划活动开始于建立一毓描述待开发软件必要特征与功能的“故事”（用户故事），每个故事标明优先级。并评估每个故事的成本，若成本超个3个开发周期，则要求进一步细分。故事的排序：所有故

10、事将在几周之内尽快实现具有最高价值的故事将移到进度表的前面并首先实现高风险故事将首先实现项目速度用于：帮助建立后续发行版本的发布日期和进度安排确定是否对整个开发项目中的所有故事有过分承诺第10页，此课件共24页哦简单设计简单设计(Simple Design)：XP的设计严格遵循KIS（keep it simple)传统的软件工程要求：前提是需求不变化，或者很少变化；而XP认为：需求是会经常变化的，因此设计不能一蹴而就而应该是一项持续进行的过程。XP鼓励使用CRC卡 XP鼓励使用既是构建技术又是设计技术的“重构”。XP设计实际上不使用符号并且几乎不产生工作产品。XP中心观念是设计在编码开始前后同

11、时发生。Kent Beck认为对于XP来说，简单设计应该满足以下几个原则：成功执行所有的测试；不包含重复的代码；向所有的开发人员清晰地描述编码以及其内在关系；尽可能包含最少的类与方法第11页，此课件共24页哦代码重构代码重构(Refactoring)XP：强调代码重构在其中的作用，认为应该经常进行重构，通常有两个关键点应该进行重构：对于一个功能实现前和实现后。代码重构是指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高 性能。重构不是XP所特有的行为，在任何的开发过程中都可能并且应该发生。成对编程成对编程(Pair Programming)XP：认

12、为在项目中采用成对编程比独自编程更加有效。成对编程是由两个开发人员在同一台电脑上共同编写解决同一问题的代 码，通常一个人负责写编码，而另一个负责保证代码的正确性与可读性。成对编程是一种非正式的同级评审(Peer Review)。它要求成对编程的两个开发人员在性格和技能上应该相互匹配编码：编码：第12页，此课件共24页哦集体拥有代码集体拥有代码XP：认为开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责。评论：代码全体拥有并不意味者开发人员可以互相推委责任，而是强调所有的人都要负责。如果一个开发人员的代码有错误，另 外一个开发人员也可以进行BUG的修复。持续集成持续集成(Contin

13、uous Integration)XP：提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。因为，这样可以使得团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦。著名的微软公司就有每日集成(Daily Build)的成功实践。第13页，此课件共24页哦测试驱动测试驱动(Test-driven)先测试，再编码；代码未动，测试先行先测试，再编码；代码未动，测试先行XP：强调强调“测试先行测试先行”。在编码开始之前，首先。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都将测试写好，而后再进行编码，直至所有的测试都得以通过。得以通过。注：测试的可自动化，集成化。注

14、：测试的可自动化，集成化。第14页，此课件共24页哦小型发布小型发布(Small Release)XP：强调在非常短的周期内以递增的方式发布新强调在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；，便于控制工作量和风险；同时，也可以及时处理同时，也可以及时处理用户的反馈。用户的反馈。用户在发布后两个工作日内，向项目小组提交用户在发布后两个工作日内，向项目小组提交“用户接收测试报告用户接收测试报告”，由项目经理评估测试报告，由项目经理评估测试报告，将有效的将有效的BUG提交并分配给相应的开发人员。提交

15、并分配给相应的开发人员。项目小组应该在下一个迭代周期结束前修项目小组应该在下一个迭代周期结束前修复所有用户提交的问题。复所有用户提交的问题。第15页，此课件共24页哦XP对于执行者的要求是比较高的对于执行者的要求是比较高的因为它要求开发团队必须具备熟练的代码设计技能和因为它要求开发团队必须具备熟练的代码设计技能和严格的测试保障技术严格的测试保障技术了解面向对象和模式，掌握了重构和了解面向对象和模式，掌握了重构和OO测试技术测试技术习惯测试先行的开发方式等习惯测试先行的开发方式等第16页，此课件共24页哦4.3.2自适应软件开发 自适应软件开发（Adaptive Software Develop

16、ment）着眼于人员协作和团队自我组织。包含思考、协作和学习三个阶段。adapti ve cycl e pl anni ng uses m i ssi on statem ent proj ect constrai nts basi c requi rem ents ti m e-boxed rel ease pl anRequi rem ents gatheri ng JAD m i ni-specscom ponents i m pl em ented/tested focus groups for feedback form al techni cal revi ew s postm o

17、rtem ssoftw are i ncrem entadj ustm ents for subsequent cycl esRel ease第17页，此课件共24页哦4.3.3 动态系统开发方法 是一种提供“通过在可控项目环境中使用增量原型开发模式完全满足参时间有约束的系统的构建和维护”的敏捷软件开发方法。像XP和ASD一样，建议使用迭代软件过程。可行性研究业务研究功能模型迭代设计和构建迭代实现第18页，此课件共24页哦DSDM Life Cycle(with permission of the DSDM consortium)第19页，此课件共24页哦4.3.4 ScrumEasel公司发

18、明，旨在寻求生产率突破名称来自英式橄榄球，每个成员都明确自己角色，环绕同一目标，集体行动、奋办拼搏公认的高生产率方法(6倍!)数十家公司、数百项目中应用被PIoP作为组织模式标准三个阶段:定义的初始过程 定义要求目标任务排序和分配最优设计经验性的开发过程(Sprint阶段)一连串联1-6周的短周期冲刺目标限定明确(可演示)集中精办最佳实现可多个开发组(4-7人)每天日常会议15-30分钟回答三个问题定义的结束过程 集成、系统测试、文档Scrum Process Fl ow (used w i th perm i ssi on)第20页，此课件共24页哦第21页，此课件共24页哦第22页，此课件共24页哦第23页，此课件共24页哦4.3.7 敏捷建模很多情况下,软件工程师必须构建大型的、业务关键的系统，这种系统的范围和复杂性必须通过建模方式保证以下事项：所有参与者可以更好地理解要做什么；有效地将问题分解给要解决它的人；对系统工程和构件过程的每一步进行质量评价AM是一种用于对软件系统有效建模和文档化的实践方法学。虽然AM提出大致的“核心”和“补充”建模原则，但其中独具特色的是：有目的的模型使用多个模型前进灯内容重于表达形式理解模型及工具第24页，此课件共24页哦