软件工程1-4.敏捷视角下的过程

《软件工程》第一部分软件过程第4章敏捷视角下的过程Chapter4AgileDevelopment•敏捷含义：轻巧、机敏、迅捷、灵活、活力、高效……•2001年KentBeck和其他16位知名软件开发者、软件工程作家、软件咨询师（被称为敏捷联盟）共同签署了“敏捷软件开发宣言”敏捷开发敏捷开发TheManifestoforAgileSoftwareDevelopment“Weareuncoveringbetterwaysofdevelopingsoftwarebydoingitandhelpingothersdoit.Throughthisworkwehavecometovalue:•Individualsandinteractionsoverprocessesandtools•Workingsoftwareovercomprehensivedocumentation•Customercollaborationovercontractnegotiation•RespondingtochangeoverfollowingaplanThatis,whilethereisvalueintheitemsontheright,wevaluetheitemsontheleftmore.”KentBecketal•敏捷方法：为了克服传统软件过程中认识和实践的弱点而生。•敏捷方法能带来许多好处，但它并不适用于所有项目、所有人、所有情况；并不完全和传统软件工程实践对立；也不能作为超越一切的哲学理念而用于所有软件工作。敏捷开发•现代生活中，市场情况变化快，用户需求不断变更，很多情况下我们必须足够敏捷地去响应不断变化、无法确定的商业环境。•这样，我们需要完全抛弃软件工程的原理、概念、方法和工具吗？敏捷开发绝对不是•AlistairCockburn认为惯例过程模型存在主要缺点：忘记了开发计算机软件的人员的弱点。•AlistairCockburn认为过程模型可以“利用纪律或者宽容来处理人的这一共同弱点”。–大多数惯例过程模型选择了纪律。–显而易见，宽容易于被接受，但可能导致工作效率低下。敏捷开发4.1敏捷是什么•普遍存在的变化是敏捷的基本动力，软件工程师必须加快步伐以适应快速变化。•敏捷不仅仅是有效地响应变化，它还信奉宣言中的理念：–鼓励组员之间、技术和商务人员之间，所有与项目有关的人之间有效沟通；–强调快速交付而不是中间产品；–将客户作为开发组成员；–计划是有局限的，它必须是可以调整的。4.1敏捷是什么•敏捷联盟为希望达到敏捷的人们定义了12条原则：1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。4.1敏捷是什么7.可工作的软件是首要的进度度量标准。8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。9.不断地关注优秀的技能和好的设计会增强敏捷能力。10.简单——使未完成的工作最大化的艺术——是根本的。11.最好的构架、需求和设计出自于自组织的团队。12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。4.1敏捷是什么4.2敏捷过程是什么•敏捷过程强调的3个关键假设：1.提前预测哪些需求是稳定的和那些需求会变化非常困难。同样，预测项目进行中客户优先级的变化也很困难。2.对很多软件来说，设计和构建是交错进行的。事实上，两种活动应当顺序开展以保证通过构建软件来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。3.从制定计划的角度看，分析、设计、构建和测试并不像我们设想的那么容易预测。4.2敏捷过程是什么•那如何建立能解决不可预测性的过程？–答案：过程的自适应性，即敏捷过程必须具有自适应性。4.2.1敏捷开发的立场•敏捷开发和传统软件工程的关系：–对立？–JimHighsmith对传统软件工程的评价“传统方法学家陷入了误区，乐于生产完美的文档而不是满足业务需要的可运行系统”–JimHighsmith对敏捷开发过程的评价“轻量级方法者或者说敏捷方法学家是一小撮自以为了不起的黑客，他们妄图将其手中的玩具软件放大盗企业级软件而制造出一系列轰动”。4.2.1敏捷开发的立场•敏捷开发和传统软件工程的关系：–兼容两派的优点则双方都能得到很多好处，而相互毁谤则两者都将一无所获。4.2.2人的因素•敏捷软件开发的拥护者花费了很多精力强调“人的因素”在成功敏捷开发中的重要性。4.2.2人的因素•敏捷软件开发团队成员及团队自身必须具备以下特点：1.基本能力。和传统软件工程中一样，敏捷开发中，能力指个人内在才能、特定的软件相关技能、对所选过程的全局知识。2.共同目标。虽然任务不同，但同一个目标是在一定时间内向用户提交可运行的软件增量。3.精诚合作。与项目有关的人员必须合作。4.决策能力。应赋予项目组在技术和项目问题上的自主决策权。5.模糊问题解决能力。6.相互信任和尊重。7.自我组织。三重含义：①敏捷团队组织自身以完成工作；②团队组织最能适应当前环境的过程；③团队进行最好的进度安排以完成软件增量交付。4.3敏捷过程模型•软件工程的历史：类似春秋战国百花齐放百家争鸣。•每一种软件工程过程、技术、方法都是轰轰烈烈地出现，接着被新的（期望是）更好的所替代。敏捷运动也如此。•下面介绍的敏捷方法都遵循“敏捷软件开发宣言”和12条原则。•极限编程、自适应软件开发、动态系统开发方法、Scrum、Crystal、特征驱动开发、敏捷建模4.3.1极限编程•极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月，Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。4.3.1极限编程•为什么称为“Extreme”（极限）•“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。策划设计编码测试软件增量项目速度估算发布用户故事权值验收测试准则迭代计划结对编程连续集成4.3.1极限编程简单设计CRC卡Spike解决方案原型重构验收测试单元测试4.3.1极限编程unittestcontinuousintegrationacceptancetestingpairprogrammingReleaseuserstoriesvaluesacceptancetestcriteriaiterationplansimpledesignCRCcardsspikesolutionsprototypesrefactoringsoftwareincrementprojectvelocitycomputed4.3.1极限编程•策划–策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”。每个故事被用户表明权值（优先级）。–客户和XP团队协商把故事如何分配到要开发的下一个发行版本中（下一个软件增量）。XP团队对待开发的故事进行排序：①所有选定故事将在几周之内尽快实现；②具有最高价值的故事首先实现；③高风险故事首先实现。4.3.1极限编程•策划–项目的第一个发行版本（也称一个软件增量）发布后，计算项目速度。简而言之，项目速度就是第一个发行版本的故事数量。项目速度将用于：①帮助建立后续版本的发布日期和进度安排；②确定是否对整个开发项目中的所有故事有过分承诺，如果有过分承诺，则调整软件发行版本的内容或者改变最终交付日期。–开发过程中用户可以增删改故事。4.3.1极限编程•Themostwidelyusedagileprocess,originallyproposedbyKentBeck•XPPlanning–Beginswiththecreationof“userstories”–Agileteamassesseseachstoryandassignsacost–Storiesaregroupedtoforadeliverableincrement–Acommitmentismadeondeliverydate–Afterthefirstincrement“projectvelocity”isusedtohelpdefinesubsequentdeliverydatesforotherincrements4.3.1极限编程•设计–XP设计严格遵循KIS（KeepItSimple）原则。–设计为故事提供不多也不少的实现原则，不鼓励额外功能性设计（因开发者假定以后会用到）。–鼓励使用CRC（类责任协作者），也是XP过程唯一的设计工作产品。–如果在某个故事设计中碰到困难，立即建立相应的可执行原型，实现并评估原型（称为Spike解决方案）。–鼓励对构建技术、设计技术的重构。4.3.1极限编程•XPDesign–FollowstheKISprinciple–EncouragetheuseofCRCcards(seeChapter8)–Fordifficultdesignproblems,suggeststhecreationof“spikesolutions”—adesignprototype–Encourages“refactoring”—aniterativerefinementoftheinternalprogramdesign4.3.1极限编程•编码–XP推荐在故事开发和基本设计完成之后，团队不应直接开始编码，而是开发一系列用于检测本次软件增量的所有单元测试。–编码活动中关键概念之一：结对编程。建议两个人面对同一台计算机共同为一个故事开发代码。–持续集成（书上的连续集成）。每日持续集成。4.3.1极限编程•XPCoding–Recommendstheconstructionofaunittestforastorebeforecodingcommences–Encourages“pairprogramming”4.3.1极限编程•测试–在编码之前建立单元测试。所建立的单元测试应对使用一个可以自动实施的框架（如Junit），要支持回归测试。–一旦将个人的单元测试组织到一个“通用测试集”，每天都可以进行系统的集成和确认测试。–持续集成（书上的连续集成）。按日持续集成。–XP验收测试，也称客户测试。验收测试根据本次软件增量中所实现的用户故事而确定。4.3.1极限编程•XPTesting–Allunittestsareexecuteddaily–“Acceptancetests”aredefinedbythecustomerandexcutedtoassesscustomervisiblefunctionalityPracticesofXP•CustomerTeamMember•Userstories•ShortCycles–iterationplan–releaseplan•AcceptanceTests•PairProgrammingPracticesofXP•Test-DrivenDevelopment•CollectiveOwnership(集体所有制，集体拥有代码)•ContinuousInte