《敏捷开发培训(agiledevelopment)》由会员分享，可在线阅读，更多相关《敏捷开发培训(agiledevelopment)（60页珍藏版）》请在金锄头文库上搜索。
1、2018/9/16,1,Agile Development 敏捷开发,Jack Ding () 09/28/2010,2018/9/16,2,Content,Agile Development介绍 RUP XP Scrum,2018/9/16,3,Agile Process - 敏捷的开发流程,Agile Process (敏捷的开发流程) 是一种软件开发流程的泛称，几项共通的特性 ： 客户与开发人员形成密切合作的团队，因为客户无法于初期定义完整的规格，而开发人员于开发过程中也常常无法知悉外在环境或业务的变动，所以需要两者密切合作方能开发适用的软件。 项目最终的目标是可执行的程序，因此所有的中
2、间产品必须经过审慎评估，确认有助于最终目标，才需要制作中间产品。 采用 Iterative 与 Incremental 方式分阶段进行，密集 review 是否符合需求。 流程可以简单，但规划与执行必须严谨。 强调团队合作，赋予高度的责任，团队有自主权得以因应变化做调整,2018/9/16,4,Agile Development,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法 在敏捷开发中，项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征 。,2018/9/16,5,敏捷开发核心价值 (Core Value),Individuals and interact
3、ions over processes and tools 个人和交流重于过程和工具 Working software over comprehensive documentation 正在运行的软件本身重于复杂的文档 Customer collaboration over contract negotiation 与客户的沟通和交流重于使用合同约束客户 Responding to change over following a plan 对变化的快速响应重于跟随计划,2018/9/16,6,敏捷开发原则(Principles),最高目标是通过快速的和经常的发布软件满足客户的需要 提交软件的周
4、期为几个星期到几个月 产生正确的软件是衡量进度的首要标准 主动接受需求的改变而不是拒绝 商务人员和开发人员工作在一起 个人必须有动力，要创造环境支持他们的要求，信任他们 最有效的交流方法是面对面的交流 最好的结构，需求和设计来自于自组织的团队（self-organizing team），允许任何人提出想法和建议 持续改进设计和编码 鼓励正常工作，减少长时间加班 保持简单，减少不必要的部分，认识到简单的设计比复杂的设计更难（simple design is harder to produce） 定期调整过程，获得更高效率,2018/9/16,7,敏捷开发的设计原则,SRP 单一职责原则SRP：S
5、ingle Responsibility Principle OCP 开放封闭原则OCP：OpenClose Principle LSP Liskov替换原则LSP：Liskov Substitution Principle DIP 依赖倒置原则DIP：Dependency Invertion Principle ISP 接口隔离原则ISP：Interface Separate Principle,2018/9/16,8,敏捷开发-迭代计划,最新版本,验收测试,发布计划,迭代计划,开发,项目周期,2018/9/16,9,敏捷开发-迭代计划,2018/9/16,10,名词解释,2018/9/16
6、,11,名词解释,2018/9/16,12,名词解释,2018/9/16,13,1. RUP,2. XP,3. Scrum,2018/9/16,14,RUP- Rational Unify Process,RUP 为 IBM Rational 提出的软件开发流程 内容含盖 Business modeling, Requirement Modeling, Logical Design, Implementation, Testing, Deployment 等软件开发生命周期的直接工作 与 Project Management, Change & Configuration Management
7、，Environment support 等支持性工作。,2018/9/16,15,RUP 的主要精神,项目进行采用 Iterative 程序分阶段渐进地完成项目功能； 广泛使用 Visual Modeling 于商业需求分析、系统分析与系统设计； 强调架构设计； 对每项工作所需要的技术、工具、做法、模板、检查项目均有详细的定义，架构完备且具有可调整的弹性。,2018/9/16,16,1. RUP,2. XP,3. Scrum,2018/9/16,17,XP - eXtreme Programming,极限编程，最轻量级的开发流程，其最主要的精神是在客户有系统需求时，给予及时满意的可执行程序，
8、所以最适合需求快速变动的项目 强调客户所要的是 workable 的执行码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以 side-by-side 的方式一起工作,2018/9/16,18,XP强调4个因素,交流(communication)，XP要求程序员之间以及和用户之间有大量而迅速的交流 简单（simplicity），XP要求设计和实现简单和干净 反馈（feedback）通过测试得到反馈，尽快提交软件并根据反馈修改 勇气（courage）。勇敢的面对需求和技术上的变化,2018/9/16,19,XP 开发流程,开发人员随时可以和客户进行有效沟通，撰写 user stor
9、ies 以确认需求。 简易快速的系统设计，撰写独立的验证程序以解决特殊困难的问题，找出算法即可丢弃验证程序。 规划多次小型阶段的项目计划，以最快速度完成每一阶段的程序交付客户，客户负责 Acceptance tests； Coding 前必须完成 Unit Test 与 Acceptance tests 程序，所有模块整合前都须经过 Unit Tests； 开发人员必须快速响应 Bug 与需求变更； 要求二人一组使用一台计算机设计程序，当一人 coding 时，另一人负责思考与设计； 程序必须符合程序规范，并常做程序的重构 (Refactoring)。,2018/9/16,20,XP原则和实践
10、-Planning-user stories,user stories User stories类似use case， 描述用户所见的系统功能，但避免使用大量的文档，user stories由用户编写（不仅限于描述用户界面）。User stories使用用户的语言编写，不使用技术性的语言，每个user stories限于几句话。User stories用于在release plan会议上对开发时间进行评估，也用于产生验收测试（acceptance test），必须使用可以自动进行的验收测试保证软件的正确性。User stories与传统的用户需求的区别在于详细的程度，user stories并
11、不会确定需求的每个细节，它只是用来简单的描述系统功能，供开发人员进行估计开发进度，在开发过程中开发人员和用户会不断的交流以讨论细 节问题。User story应该专注于功能，不应该过分注重用户界面等细节。一般一个user storiy在1-3周的时间完成，如果估计超过3周，说明user story太大了，需要细分 .,2018/9/16,21,XP原则和实践-Planning-release plan,release plan 召开一个 release plan会议，产生release plan。Release plan将用于指定每个iteration的计划。开发人员对每个user story
12、估计开发时间（在不被打断，无其他工作情况下的开发时间，包括测试），用户对user stories给出优先级，release plan会议并不制订每个iteration的计划。Release plan要用户，开发人员和管理者都同意，在完成功能范围（scope），使用资源（resource）,时间（time）和质量(quality)上达 成一致（一般质量是不能改变的）,2018/9/16,22,XP原则和实践-Planning-small release,small release often and small release是XP的一个原则，每个release完成一些用户有意义的功能集合，尽快
13、的提交给用户以获得反馈，及时调整，提交的越晚，调整越困难。,2018/9/16,23,XP原则和实践-Planning-project velocity,project velocity 团队在开发过程中要收集数据，以便于对自己的开发速度进行评估，用于以后的releazse plan,2018/9/16,24,XP原则和实践-Planning-iteration,iteration 每个small release的周期称为iteration，每个iteration约为1-3周，在一个项目中保持每个iteration的时间相等，不要超前制定计 划，每个iteration的计划在iteration
14、的开始时制定。这样能够更灵活的应付变化。不要急于完成本次iteration没有包括的功能。要 注重每个iteration的时间限制，当团队觉得不能按时完成iteration时，召开一次iteration plan会议，重新评估，减少一些user stories。,2018/9/16,25,XP原则和实践-Planning-iteration plan,iteration plan 在每个 iteration开始的时候召开会议，从release plan中选择还没有实现的用户最迫切需要的user stories。上一个iteration中没有通过验收测试的功能也要在这个iteration中实现。
15、可以根据上一个iteration的实践调整团 队速度。User stories和失败的测试被分解成programming task，task使用技术语言编写，作为iteration plan的详细描述。程序员主动领取task并估计完成时间，每个task应该在1-3天内完成，超过3天的task应该被细分。如果整个团队需要的时间 多于或少于规定的iteration时间，调整user stories。,2018/9/16,26,XP原则和实践-Planning-move people around,move people around 不要使每个开发人员局限于一项工作，不要使某项工作依赖于一个开发人
16、员，增加知识共享，减少信息孤岛，多进行交流和培训。当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的，鼓励开发人员在不同iteration中开发不同的模块。,2018/9/16,27,XP原则和实践-Planning-stand-up meeting,stand-up meeting 每天工作 开始之前，开5-10分钟的stand-up会议（站立会议），站立的目的是为了强迫节省时间，会议的目的是交流，提出存在的问题，但不要在会议上解决问 题。开一个所有人员参加的短会比多个个别人员参加的会议要高效。在会议上提出的问题可以由少数人讨论解决，这个少数人参加的会议如果涉及到代码，可以在计算机前讨论。,2018/9/16,28,XP原则和实践-Planning-fix XP when it breaks,fix XP when it breaks XP并不是一成不变的，当团队觉得需要修改的时候，可以根据自己的情况进行修改，任何修改都要经过整个团队的讨论和达成一致,2018/9/16,
