软件工程理论与实践 课件 第2章 敏捷软件开发-1

第2章敏捷软件开发

目录22.1敏捷方法2.2Scrum2.3看板2.4极限编程（XP）2.5CI／CD2.1敏捷方法概念与价值观原则与方法概述敏捷软件开发是软件开发行业的一个大流行语，它是管理软件开发项目的一种不同方式。它不是一种特定的软件开发方法，而是一组基于敏捷软件开发宣言中表达的价值和原则的方法和实践的总称。4概念及价值观敏捷软件开发开始于“敏捷软件开发宣言”。在2001年2月，17位软件开发方法学家在美国犹他州召开了长达两天的会议，制订并签署了“敏捷软件开发宣言”，该宣言给出了4个价值观：个体与交互高于过程和工具可运行软件高于详尽的文档与客户协作高于合同（契约）谈判对变更及时响应高于遵循计划5“敏捷联盟”制定的12条原则可工作的软件是进度的首要度量标准敏捷过程提倡可持续的开发速度。不断地关注优秀的技能和良好的设计会增强敏捷能力。尽量使工作简单化。

好的架构、需求和设计来源于自身组织团队。每隔一定时间,团队应该反省如何才能有效地工作,并相应地调整自己的行为。6通过尽早和持续交付有价值的软件来让客户满意需求变更可以发生在整个软件的开发过程中经常交付可工作的软件

业务人员和开发人员应该天天在一起工作围绕受激励的个人构建项目在团队的内部,最有效果和效率的信息传递方法是面对面交谈。不同的敏捷方法最广泛使用的敏捷方法包括：Scrum极限编程（XP）看板（Kanban）特征驱动开发精益软件开发水晶（Crystal）动态系统开发方法7敏捷软件开发方法如左图，是敏捷开发流程的举例。82.2Scrum概述Sprint每日站会用户故事Backlog结对编程2.2.1概述Scrum中的三种角色产品经理：产品经理负责规划产品，并将研发这种产品的愿景传达给团队。敏捷主管（ScrumMaster）：ScrumMaster帮助团队尽其所能地完成工作。ScrumMaster对团队成员在做的事情没有指挥权，但对这一过程拥有指挥权。Scrum团队：Scrum团队由5~7名成员组成。与传统的开发团队不同，成员们没有固定角色。团队成员间相互帮助、共享成果，旨在完成全部的工作。Scrum团队需要做好整体规划，并为每次迭代划分合适的工作量。10Scrum有一套其独特且固定的管理方式，从角色、工件和不同形式的会议三个维度出发，来保证执行过程更高效。例如在每次Sprint开始前会确立整个过程：迭代规划、每日站会、迭代演示和回顾，并在Sprint期间用可视化工件确认进度和收集客户反馈。2.2.1概述11Scrum的会议步骤整理产品需求清单确定迭代规划梳理产品需求清单每日站会迭代演示迭代回顾2.2.1概述Scrum项目所需的常用工件Scrum任务板：用户可以用Scrum任务板使Sprint任务清单形象化。任务板可以用不同的形式来呈现，比较传统的做法有索引卡，便利贴或白板。Scrum任务板通常分为三列：待办事项，正在进行中和已完成。团队需要在整个Sprint过程中不断更新。用户故事：用户故事是从客户角度对软件提出功能的描述。它包括用户类型细分，他们想要什么以及他们为什么需要它。燃尽图：纵轴表示任务总量估计，横轴表示迭代时间。剩下工作可以通过不同的点位或者其他的指标来表示。122.2.2SprintSprint（冲刺）是Scrum团队一起完成增量工作的实际时间段。敏捷专家DaveWest建议，工作越复杂，未知数越多，冲刺应该越短。但这实际上取决于具体的团队情况所有的事件——从计划到回顾——都发生在Sprint阶段。一旦一个Sprint的时长被确定，它就必须在整个开发期间保持一致。132.2.3每日站会14这是一个每天在同一时间（通常是上午）和地点举行的超短会议，以保持会议的简单性。每日Scrum的目标是让团队中的每个人都保持同步，与Sprint目标保持一致，并为接下来的24小时制定计划。一种常见的开站会的方法是让每个团队成员回答如下三个关于实现Sprint目标的问题：我昨天做了什么？我今天计划做什么？有什么问题吗？2.2.4用户故事3C原则卡片（Card）：用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。确认（Confirmation）：通过验收测试确认用户故事被正确完成。15实际开发流程中，最为重要的是做好用户故事的划分。用户故事是从用户的角度来描述用户渴望得到的功能。用户的三个要素：角色：谁要使用这个功能活动：需要完成什么样的功能商业价值：为什么需要这个功能，这个功能带来什么样的价值INVEST原则独立性（Independent）

可协商性（Negotiable）有价值（Valuable）

可以估算性（Estimatable）短小（Small）

可测试性（Testable）2.2.4用户故事右图为实际开发记录举例162.2.5BacklogBacklog的关键要点如下所述清楚地表述列表中每个需求任务给用户带来的价值,作为优先级排序的重要参考动态的需求管理而非“冻结”方式需求分析的过程是可迭代的17Backlog是Scrum中经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划。使用Backlog可以通过需求的动态管理应对变化，避免浪费，并且易于优先交付对用户价值高的需求。

2.2.6结对编程结对编程的好处程序员通常可以更快地解决问题由于两个程序员具有相同缺点和盲点的可能性要小得多,因此可出现更少的错误,可缩短测试的时间和降低测试的成本程序员之间的互相激励、帮助和监督,可降低编程的枯燥性和程序员懒惰的可能性个别的人员流动对项目进展造成的影响就会相对小。概念：结对编程,即两个程序员肩并肩地坐在同一台计算机前合作编程,在一个程序员编程的同时,另一个负责检查代码的正确性和可读性。182.3看板概述Scrum与看板的区别2.3.1概述20看板作为可视化框架可以用于敏捷方法，能够清晰地向项目成员展示整个项目进度。当需要对系统进行小幅度改动的时候，可以采用看板方法来轻量化解决这个问题，因为看板本身并不需要额外去制定流程。看板图是项目中实施看板的常见工具。2.3.1概述无论用哪种形式来创建看板图，看板都会有一个原则：划分为不同列来代表其工作状态。看板项目包括如下5条核心原则：可视化工作流程限制工作进度管理和改进流程制定明确的执行策略持续改进212.3.2Scrum与看板的区别Scrum与看板有所不同，看板对团队的个人能力要求较高，更灵活，适合新开发的产品，而Scrum适合成熟一点的产品和团队。在实际的小团队项目敏捷开发中，Scrum和看板都是不错的选择，且可视具体情况，灵活调整迭代的周期，在两种模式上进行自定义的微调。222.3.2Scrum与看板的区别如果团队需要在某特定的时间发布或推广产品，以达到一定的市场预期的话，则团队一般会将需求进行拆分和细化，拆分为较小的需求后，团队可以通过检查每个Sprint的进度并进行调整，从而预测交付时间，进而确保整个项目成功交付，这时Scrum是首选的方式。其次，由于Scrum承诺在每个Sprint内不对计划做修改，如果团队经常会应对紧急情况或者修改任务的优先级，那么看板方法因其灵活的工作流程可以更好地适应。再者，在Scrum中每个Sprint的时间长度是固定的（1~4周），并且每个Sprint结束后会交付潜在可交付产品的增量，如果项目需要有固定的交付时间（1~4周），那么Scrum是比较好的选择。最后如果团队不足5人，在人员方面可能无法发挥Scrum的最大功效或存在一定的浪费，那么建议使用看板方法。232.3.2Scrum与看板的区别24Scrum看板开发方式要求定时迭代没指定定时限迭代，可以分开计划、发布、过程改进，可以事件驱动而不是限定时限团队在每个迭代承诺一定数目的工作承诺不是必须的以速度（Velocity）作为计划和过程改进的度量数据使用开发周期作为计划和过程改进的度量数据指定跨功能团队没有指定跨功能团队，也容许专门团队工作任务细分，可于一个迭代中完成没有指定工作任务大小指定使用燃烧图没有指定任何图表2.3.2Scrum与看板的区别25Scrum看板开发方式间接限制开发中工作（每个迭代）设定开发中工作的限制（每个工作流程状态）规定估算过程没有指定任何估算方式在迭代中不能加入新工作任务只要生产力容许，可以随时加工作任务由单一团队负责SprintBacklog多个团队和团员分享看板指定3个角色（产品经理、ScrumMaster、Scrum团队）没有指定任何团队角色Scrumboard在每个迭代后重设看板反映持久开发情况规定优先化的productbacklog优先级是非必须的2.4极限编程概述XP的四个价值观2.4.1概述极限编程是一种实践性较强的规范化的软件开发方法，它强调用户需求和团队工作。XP特别适用于软件需求模糊且容易改变、开发团队人数少于10人、开发地点集中（比如一个办公室）的场合。极限编程包含了一组相互作用和相互影响的规则和实践。在项目计划阶段，需要建立合理和简洁的用户故事。在设计系统的体系架构时，可以采用CRC（Class，Responsibility，Collaboration）卡促使团队成员共同努力。代码的质量在极限编程项目中非常重要。为了保证代码的质量，可以采用结对编程以及在编码之前构造测试用例等措施。合理的测试用例及较高的测试覆盖率是极限编程项目测试所追求的目标。272.4.1极限编程XP所推崇的规则和方法如右图所示282.4.2XP的4个价值观交流：交流不仅能使相关人员更为精确的理解需求，而是能够尽可能避免因为需求变

更导致的不一致.简单：简单是XP推崇的理念，一切都使用最简单、最小代价的方式达到目的，以及用最简洁的达到客户的要求。反馈：及时高效的反馈能够确保开发工作的正确性，并能够在发生错误时更及时地纠正偏差。勇气：敏捷方法要求与其他人密切的合作，充分信任他人，也信任自己，这需要勇气292.4.3XP的 12个核心实践完整的团队

结对编程计划策略

设计改进系统隐喻

持续集成小型发布

集体所有权测试驱动

编码标准简单设计

工作安排302.5CI/CD概述CI/CD的优势2.5.1CI/CD概述CI/CD是一套使软件开发的构建、测试和部署阶段自动化的方法。自动化可缩短交付时间，并提高整个开发生命周期的可靠性。CI/CD中的CI代表持续集成。CD是指连续交付或连续部署，具体取决于团队选择如何推动代码更改以进行生产。持续集成和持续交付是CI/CD中的两个不同流程，具有不同的用途CI完成自动构建和测试步骤，以确保代码更改能够可靠合理地合并到代码仓库中CD提供了向最终用户交付代码地快速无缝方法CI／CD的目标是帮助开发人员以速度和效率交付软件。团队不断将代码交付到生产中，运行新功能和错误修复的持续流程。CI／CD概览如图所示322.5.1CI/CD概述持续集成（CI）：持续集成是不断将更新集成到代码库的方法。CI提供一个一致的自动化流程，包括构建、测试和合并新软件。持续交付（CD）：持续交付是指持续地将各类更改(包括新功能、缺陷修复、配置变化等)安全、快速、高质量地落实到生产环境或用户手中的能力。持续交付从持续集成结束的地方开始。CD使开发人员能够随时向不同的环境和最终用户部署常规软件更改。所有进入CD过程的代码必须首先通过CI。持续测试：持续测试是运行自动测试的方法，而代码更改则通过CI和CD进行。332.5.1CI/CD概述单个CI/CD过程可以具有多种类型的测试单元测试（确保单个功能在构建过程中正确执行的CI测试）集成测试（检查组件和服务是否都协同工作）功能测试（确保功能按团队预期执行）验收测试（性能、可扩展性、应力、容量等）静态代码分析（检查语法问题和漏洞）自动测试（如API测试和安全测试）并非每个CI/CD过程都需要有所有这些测试，但持续测试的目标始终相同。342.5.2CI/CD的优势更快、更可靠的版本发布更高的可见性早期错误检测快速反馈循环更快乐的开发和运维团队352.6DevOps概述生命周期敏捷软件开发、CI/CD和DevOps工具概述DevOps是从敏捷发展起来的。它添加了新的过程和工具，将CI/CD的持续迭代和自动化扩展到软件交付生命周期的其余部分。在流程的每一个步骤中，它实现了开发和运维之间的密切协作。37