《敏捷开发基础PPT课件》由会员分享，可在线阅读，更多相关《敏捷开发基础PPT课件（31页珍藏版）》请在金锄头文库上搜索。
1、专家敏捷宣言专家敏捷宣言-MartinFowlerl“在软件开发中,一个非常重要但却比较难做到的一点就是要确保我们开发的软件是正确的-即做正确的事。l我们发现我们很难准确地预先知道什么是我们想要的以及什么是正确的。l但是当有一个参照物存在的时候,人们就比较容易指出其中的不足之处,并且提出改进建议。l“敏捷”开发就是通过利用人们的这种行为方式来处理这类有明确目标和改进意见的需求。”Page 1软件的根本问题l我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。l如果这是事实，那么软件开发总是非常困难的。天生就没有银弹。l现代软件系统中无法
2、规避的内在特性：复杂性、一致性、可变性和不可见性。没有银弹软件工程中的根本和次要问题FREDERICK P. BROOKS, JR.Page 2一致性lSE列出的规格是用户想要的么？列出的规格是用户想要的么？l项目组的设计和项目组的设计和SE的想法一致么？的想法一致么？l对于命令行接口，网管和主机理解对于命令行接口，网管和主机理解的是一致的么？的是一致的么？l主机软件和单板软件理解的一致么主机软件和单板软件理解的一致么？l合版本为什么经常编译不过？合版本为什么经常编译不过？Page 3可变性l变更主要来源于：变更主要来源于：p1.客户需求不明确p2.需求理解错误p3.设计不能满足需求p4.开发
3、人员未能正确理解SE分解分配的需求Page 4敏捷的概念l敏捷是一种强调轻量的过程方法论，它强调拥抱变化而不是与之敏捷是一种强调轻量的过程方法论，它强调拥抱变化而不是与之对抗，通过有效的沟通发挥群体的智慧。对抗，通过有效的沟通发挥群体的智慧。l敏捷方法论采用迭代敏捷方法论采用迭代/增量开发的过程模型。增量开发的过程模型。l敏捷门派众多，敏捷门派众多，2001年，成立敏捷联盟，并发布了宣言和原则年，成立敏捷联盟，并发布了宣言和原则敏捷宣言敏捷宣言个体和交互个体和交互胜过胜过过程和工具过程和工具可以工作的软件可以工作的软件胜过胜过面面俱到的文档面面俱到的文档客户合作客户合作胜过胜过合同谈判合同谈判
4、响应变化响应变化胜过胜过遵循计划遵循计划虽然右边的也有价值，但是我们认为左边的具有更大的价值虽然右边的也有价值，但是我们认为左边的具有更大的价值Page 5谁在用敏捷？l微软微软p大规模使用，敏捷列入新员工培训课程lNokiaSimensp超过40个产品使用敏捷流程，最大的项目约500名开发人员，跨地域、时差lIBMp项目经理可以自主选用瀑布或者敏捷流程，将为华为提供敏捷顾问和工具lEricssonp从第一代GSM基站开发就采用增量式迭代开发，使用敏捷的部分实践lGooglep大部分项目敏捷，部分采用传统方法开发lWikipWiki的发明人是敏捷宣言的发起人之一，Wiki的灵感来源于敏捷的“集
5、体代码所有权”思想l神舟飞船软件系统神舟飞船软件系统p在敏捷宣言发表之前即采用敏捷的思想lBT：pHuawei to propose how we can meet the agile requirements of BT.Page 6迭代的概念l相对于传统的瀑布式开发，迭代开发把软件生命周期分成很多个小周期相对于传统的瀑布式开发，迭代开发把软件生命周期分成很多个小周期（一般不大于（一般不大于2个月，建议个月，建议2周），每一次迭代都可以生成一个可运行、可周），每一次迭代都可以生成一个可运行、可验证的版本，并确保软件不断的增加新的价值。验证的版本，并确保软件不断的增加新的价值。Page 7什么
6、是迭代开发l迭代的主要目的迭代的主要目的1.验证关键设计方案，避免重大的设计风险（主要设计点）2.尽快确认和澄清客户需求（主要需求点）3.缩短验证周期（只有在小粒度迭代上才可能实现），提供灵活的特性交付能力。l我们的版本开发是不是迭代？我们的版本开发是不是迭代？p宏观上讲，我们也是迭代开发，但颗粒度太大，存在问题。p周期太长，验证反馈太慢，长周期要承担更多的需求变更风险，导致恶性循环p没有真正识别主要需求点和主要设计点，无法尽快确认需求和避免设计风险。p不具备快速验证的能力p对于大部分的产品，我们应用迭代的主要诉求在2，3两点Page 8小批量交付特性集 AA1A2A3 =特性集 BB1B2B
7、3 =特性集 CC1C2C3 =JanFebMarAprMayJunJulA1B1C1A2B2C2A3B3C3JanFebMarAprMayJunJulA1B1C1A2B2C2A3B3C3传统方法: “每件事都很重要！一次就要全部做好！”迭代开发: “优先级 & 关注点!”Page 9如何处理变化和延迟计划Week1传统模式下的延迟方式迭代模式下的延迟方式Week2Week3Week4Week1 Week2 Week3 Week4 Week5 Week6 Week7 Week8Week1 Week2 Week3 Week4 Week5 Week6 Week7 Week8Page 10敏捷与迭代
8、的关系l敏捷强调软件的需求、设计、计划都是复杂的，以至于敏捷强调软件的需求、设计、计划都是复杂的，以至于不可能一次就精确的完成，所以要通过快速的反馈对需不可能一次就精确的完成，所以要通过快速的反馈对需求、设计、计划进行修正。求、设计、计划进行修正。l迭代是敏捷建立持续的快速反馈机制的技术手段。迭代是敏捷建立持续的快速反馈机制的技术手段。Page 11敏捷与迭代的关系（续）l随着软件交付周期的日益加快，迭代化开发已经成为大多数软件开发团队随着软件交付周期的日益加快，迭代化开发已经成为大多数软件开发团队的必选项。但是迭代对整个团队的需求、架构、协同及测试能力都提出了的必选项。但是迭代对整个团队的需
9、求、架构、协同及测试能力都提出了更高的要求，现在许多开发团队都在试图导入迭代化开发的过程中，敏捷更高的要求，现在许多开发团队都在试图导入迭代化开发的过程中，敏捷可是被看成迭代化开发的一种导入方式，这不过敏捷的范围其实比迭代化可是被看成迭代化开发的一种导入方式，这不过敏捷的范围其实比迭代化开发更大一些。开发更大一些。敏捷的三个要素是敏捷的三个要素是迭代开发、坦诚合作和自适应性迭代开发、坦诚合作和自适应性。坦诚合作坦诚合作其实才其实才是敏捷的精髓，如是敏捷的精髓，如Ivar所说，敏捷其实是有关所说，敏捷其实是有关SocialEngineering的。敏的。敏捷的主要贡献在于他更多地思考了如何去激发
10、开发人员的工作热情，这是捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。在软件工程几十年的发展过程中相对被忽略的领域。Page 12敏捷宣言遵循的原则迭代l我们最优先要做的是通过尽早的、持续的交付有价值的软件来我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意使客户满意l即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。为客户创造竞争优势。l经常性地交付可以工作的软件，交付的间隔可以从几个星期到经常性地交付可以工作的软件，交付的间隔可以从几个
11、星期到几个月，交付的时间间隔越短越好。几个月，交付的时间间隔越短越好。l工作的软件是首要的进度度量标准。工作的软件是首要的进度度量标准。Page 13敏捷宣言遵循的原则团队运作l在团队内部，最具有效果且富有效率的传递信息的方法，就是面对在团队内部，最具有效果且富有效率的传递信息的方法，就是面对面的交谈。面的交谈。l在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。l围绕被激励的个体来构建项目。给他们提供所需的环境和支持，并围绕被激励的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。且信任他们能够完成工作
12、。l敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。保持一个长期的、恒定的开发速度。l不断地关注优秀的技能和好的设计会增强敏捷能力不断地关注优秀的技能和好的设计会增强敏捷能力l简单简单-使未完成的工作最大化的艺术使未完成的工作最大化的艺术-是根本的是根本的Page 14敏捷宣言遵循的原则自组织团队l最好的构架、需求和设计出自于自组织的团队。最好的构架、需求和设计出自于自组织的团队。l每隔一定时间，团队会在如何才能更有效地工作方面进每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地
13、对自己的行为进行调整。行反省，然后相应地对自己的行为进行调整。Page 15敏捷：需求&计划管理lSE与开发团队坐在一个实验室，端到端的参与开发过程。与开发团队坐在一个实验室，端到端的参与开发过程。l每次迭代开始前，每次迭代开始前，SE和开发人员、测试人员一起，花半天到一天的和开发人员、测试人员一起，花半天到一天的时间，对需求的优先级、风险、依赖情况、工作量进行评估，从中时间，对需求的优先级、风险、依赖情况、工作量进行评估，从中挑选出部分需求，以挑选出部分需求，以story的形式放入迭代中。的形式放入迭代中。lSE要负责将需求细化至可以直接编码的程度，并负责编写测试用例，要负责将需求细化至可以
14、直接编码的程度，并负责编写测试用例，一旦软件通过这些测试，就视为需求已正常实现。一旦软件通过这些测试，就视为需求已正常实现。l开发过程中，开发过程中，SE负责随时解答开发人员关于需求的疑问，并根据测负责随时解答开发人员关于需求的疑问，并根据测试结果输出最终的规格文档。试结果输出最终的规格文档。Page 16敏捷：需求&计划管理 续l每一天，项目的进展都通过每一天，项目的进展都通过burndownchart进行更新进行更新,所有需所有需求都以测试通过作为唯一的完成求都以测试通过作为唯一的完成标记标记l每一天，项目组成员都要参加一个每一天，项目组成员都要参加一个15分钟左右的站立会议，彼此通报最新
15、分钟左右的站立会议，彼此通报最新进展、下一步计划以及所遇到的困难进展、下一步计划以及所遇到的困难Page 17敏捷：质量管理l每一次迭代结束，项目组坐在一起对迭代进行回顾，回答两个问题：每一次迭代结束，项目组坐在一起对迭代进行回顾，回答两个问题：p我们的成功经验是什么？p有什么能改进？l针对项目组当前的问题，自主决策改进方案，并在下一个迭代中实针对项目组当前的问题，自主决策改进方案，并在下一个迭代中实施，即使改进方案无效，也可以在下一个迭代回顾时发现，最多浪施，即使改进方案无效，也可以在下一个迭代回顾时发现，最多浪费一个迭代周期。费一个迭代周期。l自我决策改进方案，以适应复杂的需求、人员状况，
16、是敏捷团队的自我决策改进方案，以适应复杂的需求、人员状况，是敏捷团队的最大特点。最大特点。Page 18敏捷实践Page 19敏捷实践Page 20敏捷是聪明的工作l敏捷是关于以下三件事情的：敏捷是关于以下三件事情的：l最重要的，敏捷是一门社会工程学。这是敏捷最大的特点。它关注最重要的，敏捷是一门社会工程学。这是敏捷最大的特点。它关注的是，如何以一个团队的形式开展工作，如何激励团队成员，如何的是，如何以一个团队的形式开展工作，如何激励团队成员，如何相互合作等等。相互合作等等。l敏捷是轻量级的。敏捷非常依赖隐性知识，敏捷认为，只要有掌握敏捷是轻量级的。敏捷非常依赖隐性知识，敏捷认为，只要有掌握足
17、够知识的人，就可以开发出优秀的软件。足够知识的人，就可以开发出优秀的软件。l敏捷提供技术实践。这其实是敏捷中贡献最微弱的部分。敏捷提供技术实践。这其实是敏捷中贡献最微弱的部分。l敏捷的本质是变得敏捷的本质是变得“聪明聪明”，聪明就是做正好合适的事，不是找，聪明就是做正好合适的事，不是找更广的解决方案，而是正好更广的解决方案，而是正好。-IvarJacobsonPage 21对敏捷常见的误区l敏捷不写文档敏捷不写文档l敏捷不适合大型软件开发，尤其是高质量要求领域敏捷不适合大型软件开发，尤其是高质量要求领域l敏捷和敏捷和CMM对立对立l敏捷导致对人员的极度依赖敏捷导致对人员的极度依赖l敏捷导致管理
18、者无法看到项目组的进展，从而导致失控敏捷导致管理者无法看到项目组的进展，从而导致失控敏捷是银弹！？Page 22敏捷不能解决问题，只能让问题暴露得更早l敏敏捷方法是项目的救星吗？不，捷方法是项目的救星吗？不，我认为它依然会失败。敏捷开发我认为它依然会失败。敏捷开发可以带给你的一件事情是：让这可以带给你的一件事情是：让这些项目失败的更快、损失些项目失败的更快、损失的更少，的更少，因为你可以将时间和精力用于开因为你可以将时间和精力用于开始做下一件事情。始做下一件事情。KentBeckPage 28总结l软件是复杂的，由此引发了一致性和可变性的问题。随着软件规模的日益软件是复杂的，由此引发了一致性和
19、可变性的问题。随着软件规模的日益膨胀，参与的人日益增加，软件的本质问题越来越突出。膨胀，参与的人日益增加，软件的本质问题越来越突出。l复杂性：复杂性：p采用分而治之的思想，把一个大的软件划分为多个小特性，降低了每一轮迭代搜需面临的复杂度。l一致性：一致性：p按照特性组织团队，发挥群体智慧，团队共同拥有代码，共同为需求、架构、设计、测试负责。p通过持续的反馈（迭代、面对面的沟通）消除不一致。l可变性可变性p变化难以预测，过早的应对变化会导致浪费。Keep it simple。p每一个项目都是不同的，每一个人也都是不同的。敏捷团队根据团队成员和项目需求的特性，自己决定流程、方法和工具。Page 29Page 30参考书籍l敏捷软件开发敏捷软件开发原则原则模式与实践模式与实践l重构重构l人月神话人月神话l编写有效用例编写有效用例l人件人件l修改代码的艺术修改代码的艺术lScrum敏捷项目管理敏捷项目管理Page 31
