第3章 敏捷开发

3.4.1 极限编程（续）
软件工程
3.4.1 极限编程（续）
• 策划
– 把任务细分，尽量在三周内完成。如果完不成， 则再进行细分。细分后做以下工作：1）尽快 实现每个任务。2）重要者优先。3）高风险优 先。 – 项目第一个发行版本后，利用已有数据计算进 度，以用来安排 1） 后续工作的进度。 2） 重 新审视以前的安排。
软件工程
敏捷软件开发宣言
普遍存在的变化是敏捷的基本动力
软件工程
敏捷联盟定义的敏捷原则
1. 目的是尽快、尽好地交付软件产品。
2. 变更是常事，并且欢迎。
3. 经常有阶段性的成果提交，类似增量开发
4. 业务人员和开发人员紧密团结。 5. 充分相信个人。
6. 团队经常交流。
敏捷联盟定义的敏捷原则
7. 衡量进度的标准是有可见的成果。
部包含。
软件工程
3.3 敏捷过程（续）
• 为什么会用到敏捷过程？
–现实的软件开发过程中，存在三个普遍
的问题（这不是假设），正是这些问题
为敏捷开发的发育成长提供了土壤。
软件工程
三个关键假设
1. 提前预测需求或变化很难，预测优先级也存在困
难。 2. 理论上讲，是先有设计，后有构建。但实际上这 两步是交替反复的，因为设计者是人，不是神。 3. 从客观角度和软件开发的经验来讲，软件开发和 传统的模型差异甚大，几大要素都有不断的调整、 变化，而这正是敏捷的内涵。
软件工程
软件工程
3.4.3 动态系统开发方法
• 动态系统开发（Dynamic System Develoment
Method, DSDM）---通过在可控项目环境中使用 增量原型开发 • 模式完全满足对时间有约束的系统的构建和维护。 • 特点：在每个增量的环节，并不完全完成任务。 留下20%在以后完成。
人的力量。能应付以后的人士变动。
软件工程
3.4.1 极限编程（续）
• 测试
– 经常的测试。 – 快速的测试。 – 阶段性的测试。
– 便于及时发现问题。
– XP验收测试，生产客户可见的测试集。
软件工程
3.4.1 极限编程（续）
• 极限编程实践
1. 完整团队
– XP 项目的所有参与者（开发人员、业务分析
软件工程
3.4.1 极限编程（续）
• 用户故事
– 问题描述：
• “作为……（谁），我想要…… （做什么），为了……（为什么）”。
• 验收条件
– 可作为验收测试用例的具体例子。这也是我们 常说的实例化需求，也是为了避免误读，让抽 象的需求变得具体和可测试。
• 举例：
用户故事：
软件工程
假设要开发一个基金交易系统，其中一个用户故事是“当投资者申 购基金后，他/她将在T+2收到交易确认短信，期间如果遇到周末或 假期将顺延”（T是交易日的意思，T+2即两个交易日后）。
个——非常值得胜任的——人编写的。
11. 隐喻 – 团队提出一个程序工作原理的公共景像。
软件工程
3.4.1 极限编程（续）
• 极限编程实践
12. 可持续的速度
– 团队只有持久才有获胜的希望。他们以能够长
期维持的速度努力工作。他们保存精力，他们
把项目看作是马拉松长跑，而不是全速短跑。
软件工程
3.4.2 自适应软件开发
软件工程
3.4 敏捷过程模型
• 极限编程
• 自适应软件开发
• 动态系统开发
• Scrum
• Crystal
• 特征驱动开发
软件工程
3.4.1 极限编程
• 极限编程（eXtreme Programming, XP）。
• 包含以下一些基本活动，力求用最少的精
力活动最大的成果，运用已有成果、方法。
软件工程
• 自适应软件开发（Adaptive Software Development, ASD) • ASD 的三个重点： – 思考---启动项目并完成自适应循环策划。 – 协作---但同时鼓励个人主义。 – 学习---三种方式，焦点组（学习用户反馈的信息）， 正式技术评审（自我审视），事后剖析（回望自己团 队前面的工作）。
3.4.4 Scrum 模型
• Scrum原则与敏捷宣言一致
–开发工作和开发人员分为“清晰的、低耦合的部分或 包” –坚持在产品构建过程中进行测试和文档化 –Scrum过程提供“在任何需要的情况下都能完成产品的 能力”
软件工程
3.4.4 Scrum 模型（续）
• 特点：包括一系列软件过程模式，每一模式定义
软件工程
3.4.4 Scrum 模型
• Scrum原则与敏捷宣言一致：
–组织小型团队以达到“沟通最大化、负担最小化、 非语言描述、非形式化知识” –过程对技术和业务变化必须具有适应性，以“保 证制造具有最好可能的产品” –过程生产频繁发布“可检查、可调整、可测试、 可文档化、可构建”的软件增量
软件工程
软件工程
3.4.3 动态系统开发方法（续）
• DSDM定义的环节：
– 可行性研究---前奏曲，评价采用体系对工作顺利完成的可能 – 业务研究---确定研究的具体内容
– 功能模型迭代---开发一系列增量原型。目的，诱导用户提出
新的要求，某种程度上炫耀自己的实力。 – 设计和构建迭代---充实功能模型，提供具体可用的实实在在 的功能，并充分考虑工程的因素。 – 实现---将最终软件增量置于可操作环境。
– 团队
• 责任：开发软件功能
– ScrumMaster
• 对Scrum 过程负责，想所有项目参与者讲授Scrum 方法，负责实施Scrum确保其既符合企业文化，又 能交付预期利益，还需督促全体成员遵从Scrum规 则和实践。
软件工程
3.4.4 Scrum 模型（续）
• ScБайду номын сангаасum严格区分这两类人：
一系列开发活动。 • 包括：
– 待定项—诱发新的需求。 – 冲刺---短时间内完成特定的任务。 – 例会---总结，展望。 – 演示---交付部分软件增量。
所有实践围绕一个迭代、增量的过程骨架展开
软件工程
软件工程
3.4.4 Scrum 模型（续）
• Scrum方法中只有三种角色：
– 产品负责人
• 代表每位利益相关者的权益，并为项目产出的软件 系统负责。规划项目初始总体要求、投资回报目标 和发布计划，开发优先级确定
– 对承担项目责任的人赋予权利，使其完成必要
工作，确保项目成功；
– 无责任人员则无权对项目施加不必要的干涉。
软件工程
3.4.5 Crystal
• 目的是开发一种提倡“机动性的”的软件 开发方法
软件工程
3.4.6 特征驱动开发
• 特征驱动开发（Feature Driven Develoment, FDD)。 • 特征:能在更短时间内完成的小功能。
– 随时改进糟糕的代码。保持代码尽可能的干
净、具有表达力。
软件工程
3.4.1 极限编程（续）
• 极限编程实践
8. 持续集成
– 团队总是使系统完整地被集成。
9. 集体代码所有权
– 任何结对的程序员都可以在任何时候改进任
何代码。
软件工程
3.4.1 极限编程（续）
• 极限编程实践
10. 编码标准
– 系统中所有的代码看起来就好像是被单独一
师、测试人员等等）一起工作在一个开放的
场所中，他们是同一个团队的成员。这个场
所的墙壁上随意悬挂着大幅的、显著的图表
以及其他一些显示他们进度的东西。
软件工程
3.4.1 极限编程（续）
• 极限编程实践
2. 计划游戏
– 计划是持续的、循序渐进的。每2周，开发人
员就为下2周估算候选特性的成本，而客户则
根据成本和商务价值来选择要实现的特性。
验收条件：
实例1：成功申购，没有假期顺延情况（快乐路径）
假设投资者张三（男）在2017年9月25日申购了沪深300指数基金 1000元，当天该基金单位净值为2.5000，申购费率是1.5%； 当申购成功后； 那么他在2017年9月27日收到短信，内容为“张三先生，您于201 7年9月25日申购了沪深300指数基金1000元，单位净值为2.5000 ，份额为394份，交易成功，份额已登记于您名下。”
软件工程
3.3 敏捷过程（续）
• 解决这些问题，就要求不断反馈，不断调
整，即工程学中的自适应。自适应必须有
一定的速度和质量，即每一次适应要有必
要程度的提高（具有必要的增量）。
• 换言之，有自适应和增量提高的过程即是
敏捷过程。
软件工程
3.3 敏捷过程（续）
• 敏捷本身的理念是受人称道的，但其中自适应的程度的把 握有不同的意见。 • 敏捷过程中人的因素：特别看重个人。 – 要求： 1. 必要的基本能力。 2. 共同目标。大家要认同这个目标，并为之奋斗。 3. 精诚合作，互相交流。 4. 决策能力，充分需要和充分享受。 5. 模糊问题解决能力。 6. 相互信任和尊重，主要指要包容。 7. 自我组织的能力。如何分配，如何适应，如何安排 进度。
第3章 敏捷开发
王美红
软件工程
问题……
• 什么是敏捷？
一种理念 一系列开发指南
软件工程
软件工程
主要内容
• 敏捷是什么？
• 敏捷过程是什么？
• 敏捷过程模型
软件工程
3.1 敏捷是什么？
• 通俗地讲，敏捷是指在软件的开发活动中，
坚持一些基本原则，灵活运用各种方法，
快速地开发出令客户满意的产品。
• 敏捷是一种态度，是敏捷建模者们坚持的 价值观、敏捷建模者们相信的原则、敏捷 建模者们应用的实践组成的集合。
软件工程
3.4.1 极限编程（续）
• 设计
–保持尽量简洁。
–尽量使用已有构件。
–在前进中调整。
软件工程
3.4.1 极限编程（续）
• 编码
– 常规工作中，先编码，然后开发检测实例。在
XP中，提倡先开发检测实例，然后编码。好处：
有一个航标指引你前行。--测试驱动
– 提倡结对编程，好处：两个人的力量大于一个
尽可能少的代码。
软件工程
3.4.1 极限编程（续）
• 极限编程实践
5. 结对编程
– 所有的产品软件都是由两个程序员、并排坐
在一起在同一台机器上构建的。
软件工程
3.4.1 极限编程（续）
• 极限编程实践
6. 测试驱动开发
– 程序员以非常短的循环周期工作，他们先增
加一个失败的测试，然后使之通过。
7. 改进设计
软件工程
3.4.6 敏捷建模
8. 保持稳定的但较快的速度。 9. 时刻注意新技术。 10.简单，必须的。 11.软件的核心内容出自本团队的手笔。
软件工程
12.团队经常开展自我总结，并对工作安排适
时调整。
软件工程
3.2 敏捷及变更的成本费用
软件工程
3.3 敏捷过程
• 基于敏捷原则进行的软件开发过程，视为
敏捷过程。
• 所谓“基于”，是指充分考虑，而不是全
软件工程
3.4.1 极限编程（续）
• 极限编程实践
3. 客户测试
– 作为选择每个所期望的特性的一部分，客户
定义出自动验收测试来表明该特性可以工作。
软件工程
3.4.1 极限编程（续）
• 极限编程实践
4. 简单设计
– 团队保持设计恰好和当前的系统功能相匹配。
它通过了所有的测试，不包含任何重复，表
达出了编写者想表达的所有东西，并且包含
软件工程
实例2：成功申购，有假期顺延情况（快乐路径） 假设投资者张三（男）在2017年9月29日申购了沪深300指数基金1000元，当天该基金单位 净值为2.5000，申购费率是1.5%； 当申购成功后； 那么他在2017年10月10日收到短信，内容为“张三先生，您于2017年9月29日申购了沪深3 00指数基金1000元，单位净值为2.5000，份额为394份，交易成功，份额已登记于您名下。 ” （因为2017年9月30日至2017年10月8日为假期，即非交易日，交易确认顺延） 实例3：成功申购，在假期内申购（快乐路径） 假设投资者张三（男）在2017年10月5日申购了沪深300指数基金1000元，当天该基金单位 净值为2.5000，申购费率是1.5%； 当申购成功后； 那么他在2017年10月11日收到短信，内容为“张三先生，您于2017年10月9日申购了沪深3 00指数基金1000元，单位净值为2.5000，份额为394份，交易成功，份额已登记于您名下。 ” （因为2017年9月30日至2017年10月8日为假期，即非交易日，假期内的申购日将顺延到假 期后第一个交易日） 实例4：申购失败（意外场景） 假设投资者李四（女）在2017年9月11日申购了沪深300指数基金1000元，当天该基金不可 申购； 当交易确认后； 那么她在2017年9月13日收到短信，内容为“李四小姐，您于2017年9月11日申购了沪深30 0指数基金1000元，由于当天本基金不可申购，交易失败，申购款1000元将在2个交易日后 全款退还到您申购的银行卡。”