软件工程1-4.敏捷视角下的过程.ppt
软件工程,第一部分 软件过程 第4章 敏捷视角下的过程Chapter 4 Agile Development,敏捷含义：轻巧、机敏、迅捷、灵活、活力、高效2001年Kent Beck和其他16位知名软件开发者、软件工程作家、软件咨询师（被称为敏捷联盟）共同签署了“敏捷软件开发宣言”,敏捷开发,敏捷开发,The Manifesto for Agile Software Development,“We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is,while there is value in the items on the right,we value the items on the left more.”,Kent Beck et al,敏捷方法：为了克服传统软件过程中认识和实践的弱点而生。敏捷方法能带来许多好处，但它并不适用于所有项目、所有人、所有情况；并不完全和传统软件工程实践对立；也不能作为超越一切的哲学理念而用于所有软件工作。,敏捷开发,现代生活中，市场情况变化快，用户需求不断变更，很多情况下我们必须足够敏捷地去响应不断变化、无法确定的商业环境。这样，我们需要完全抛弃软件工程的原理、概念、方法和工具吗？,敏捷开发,绝对不是,Alistair Cockburn认为惯例过程模型存在主要缺点：忘记了开发计算机软件的人员的弱点。Alistair Cockburn认为过程模型可以“利用纪律或者宽容来处理人的这一共同弱点”。大多数惯例过程模型选择了纪律。显而易见，宽容易于被接受，但可能导致工作效率低下。,敏捷开发,4.1 敏捷是什么,普遍存在的变化是敏捷的基本动力，软件工程师必须加快步伐以适应快速变化。敏捷不仅仅是有效地响应变化，它还信奉宣言中的理念：鼓励组员之间、技术和商务人员之间，所有与项目有关的人之间有效沟通；强调快速交付而不是中间产品；将客户作为开发组成员；计划是有局限的，它必须是可以调整的。,4.1 敏捷是什么,敏捷联盟为希望达到敏捷的人们定义了12条原则：我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。,4.1 敏捷是什么,可工作的软件是首要的进度度量标准。敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。不断地关注优秀的技能和好的设计会增强敏捷能力。简单使未完成的工作最大化的艺术是根本的。最好的构架、需求和设计出自于自组织的团队。每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。,4.1 敏捷是什么,4.2 敏捷过程是什么,敏捷过程强调的3个关键假设：提前预测哪些需求是稳定的和那些需求会变化非常困难。同样，预测项目进行中客户优先级的变化也很困难。对很多软件来说，设计和构建是交错进行的。事实上，两种活动应当顺序开展以保证通过构建软件来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。从制定计划的角度看，分析、设计、构建和测试并不像我们设想的那么容易预测。,4.2 敏捷过程是什么,那如何建立能解决不可预测性的过程？答案：过程的自适应性，即敏捷过程必须具有自适应性。,4.2.1 敏捷开发的立场,敏捷开发和传统软件工程的关系：对立？Jim Highsmith对传统软件工程的评价“传统方法学家陷入了误区，乐于生产完美的文档而不是满足业务需要的可运行系统”Jim Highsmith对敏捷开发过程的评价“轻量级方法者或者说敏捷方法学家是一小撮自以为了不起的黑客，他们妄图将其手中的玩具软件放大盗企业级软件而制造出一系列轰动”。,4.2.1 敏捷开发的立场,敏捷开发和传统软件工程的关系：兼容两派的优点则双方都能得到很多好处，而相互毁谤则两者都将一无所获。,4.2.2 人的因素,敏捷软件开发的拥护者花费了很多精力强调“人的因素”在成功敏捷开发中的重要性。,4.2.2 人的因素,敏捷软件开发团队成员及团队自身必须具备以下特点：基本能力。和传统软件工程中一样，敏捷开发中，能力指个人内在才能、特定的软件相关技能、对所选过程的全局知识。共同目标。虽然任务不同，但同一个目标是在一定时间内向用户提交可运行的软件增量。精诚合作。与项目有关的人员必须合作。决策能力。应赋予项目组在技术和项目问题上的自主决策权。模糊问题解决能力。相互信任和尊重。自我组织。三重含义：敏捷团队组织自身以完成工作；团队组织最能适应当前环境的过程；团队进行最好的进度安排以完成软件增量交付。,4.3 敏捷过程模型,软件工程的历史：类似春秋战国百花齐放百家争鸣。每一种软件工程过程、技术、方法都是轰轰烈烈地出现，接着被新的（期望是）更好的所替代。敏捷运动也如此。下面介绍的敏捷方法都遵循“敏捷软件开发宣言”和12条原则。极限编程、自适应软件开发、动态系统开发方法、Scrum、Crystal、特征驱动开发、敏捷建模,4.3.1 极限编程,极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期与Ward Cunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月，Kent终于在为Daimler Chrysler所做的一个项目中引入了新的软件开发观念XP。,4.3.1 极限编程,为什么称为“Extreme”（极限）“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。,策划,设计,编码,测试,软件增量 项目速度估算,发布,用户故事 权值 验收测试准则迭代计划,结对编程,连续集成,4.3.1 极限编程,简单设计 CRC卡,Spike解决方案 原型,重构,验收测试,单元测试,4.3.1 极限编程,4.3.1 极限编程,策划策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”。每个故事被用户表明权值（优先级）。客户和XP团队协商把故事如何分配到要开发的下一个发行版本中（下一个软件增量）。XP团队对待开发的故事进行排序：所有选定故事将在几周之内尽快实现；具有最高价值的故事首先实现；高风险故事首先实现。,4.3.1 极限编程,策划项目的第一个发行版本（也称一个软件增量）发布后，计算项目速度。简而言之，项目速度就是第一个发行版本的故事数量。项目速度将用于：帮助建立后续版本的发布日期和进度安排；确定是否对整个开发项目中的所有故事有过分承诺，如果有过分承诺，则调整软件发行版本的内容或者改变最终交付日期。开发过程中用户可以增删改故事。,4.3.1 极限编程,The most widely used agile process,originally proposed by Kent BeckXP PlanningBegins with the creation of“user stories”Agile team assesses each story and assigns a costStories are grouped to for a deliverable incrementA commitment is made on delivery dateAfter the first increment“project velocity”is used to help define subsequent delivery dates for other increments,4.3.1 极限编程,设计XP设计严格遵循KIS（Keep It Simple）原则。设计为故事提供不多也不少的实现原则，不鼓励额外功能性设计（因开发者假定以后会用到）。鼓励使用CRC（类责任协作者），也是XP过程唯一的设计工作产品。如果在某个故事设计中碰到困难，立即建立相应的可执行原型，实现并评估原型（称为Spike解决方案）。鼓励对构建技术、设计技术的重构。,4.3.1 极限编程,XP DesignFollows the KIS principleEncourage the use of CRC cards(see Chapter 8)For difficult design problems,suggests the creation of“spike solutions”a design prototypeEncourages“refactoring”an iterative refinement of the internal program design,4.3.1 极限编程,编码XP推荐在故事开发和基本设计完成之后，团队不应直接开始编码，而是开发一系列用于检测本次软件增量的所有单元测试。编码活动中关键概念之一：结对编程。建议两个人面对同一台计算机共同为一个故事开发代码。持续集成（书上的连续集成）。每日持续集成。,4.3.1 极限编程,XP CodingRecommends the construction of a unit test for a store before coding commencesEncourages“pair programming”,4.3.1 极限编程,测试在编码之前建立单元测试。所建立的单元测试应对使用一个可以自动实施的框架（如Junit），要支持回归测试。一旦将个人的单元测试组织到一个“通用测试集”，每天都可以进行系统的集成和确认测试。持续集成（书上的连续集成）。按日持续集成。XP验收测试，也称客户测试。验收测试根据本次软件增量中所实现的用户故事而确定。,4.3.1 极限编程,XP TestingAll unit tests are executed daily“Acceptance tests”are defined by the customer and excuted to assess customer visible functionality,Practices of XP,Customer Team MemberUser storiesShort Cyclesiteration planrelease planAcceptance TestsPair Programming,Practices of XP,Test-Driven DevelopmentCollective Ownership(集体所有制，集体拥有代码)Continuous IntegrationSustainable Pace(可持续的速度)Open WorkspaceThe Planning GameSimple DesignRefactoringMetaphor(系统比喻，XP过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识),4.3.1 极限编程,4.3.1 极限编程,作业,P73:4.12、4.16,
