敏捷开发&极限编程详解

故事包括这样一些字段： ID - 统一标识符，就是个自增长的数字而已。 Name（名称） - 简短的、描述性的故事名。 Priority (优先级） Initial estimate（初始估算）- 最小的单位是故事点（story point），一般大致 相当于一个“理想的人天（man-day）”。 5. How to demo（如何做演示）——它大略描述了这个故事应该如何在sprint 演 示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做， 就应该得到……的结果 ”。 6. Notes（注解）——相关信息、解释说明和对其它资料的引用等等。一般都非 常简短。
• 包容变化：“包容变化”这一原则就是强调不要对变化
采取反抗的态度，而应该包容它们。
XP (4)方法
XP (5)争议
• 极限编程也有其被争论的一面： • 没有书面的详细的规格说明书 • 客户代表被安排在专案中 • 程序员以结对的方式工作 • 测试驱动的开发 绝大多数设计活动都匆匆而过，并渐进式的，开始一个“最 简单的可能工作的东西”并当其需要时（测试失败）才增加 复杂性。单元测试促成为了设计纪律。
Sprint backlog (2)
确定sprint目标 • Sprint目标需要回答这个根本的问题，“我们为什 么要进行这个sprint？为什么我们不直接放假算 了？” • Sprint目标应该是尚未达成的。“打动CEO‖这个 目标不错，可如果这个系统已经给他留下了深刻 印象，那就算了。这种状况下大家都可以放假回 家，sprint目标依然能完成。 • 制定sprint计划的时候，这个目标在sprint中常常 会被用到。保证公司所有人（不只是顶级管理层） 知道团队在干什么，目的又是什么！
Waterfall (3)
• 瀑布模型的缺点： 1. 在项目开始的时候，用户常常难以清楚地给出所有需求； 用户与开发人员对需求理解存在差异。 2. 缺乏灵活性。因为瀑布模型确定了需求分析的绝对重要性， 但是在实践中要想获得完善的需求说明是非常困难的，导 致“阻塞状态”。反馈信息慢，开发周期长。 3. 各个阶段的划分完全固定，阶段之间产生大量的文档，增 加了工作量； 4. 风险主要集中在中后期。由于开发模型是线性的，用户只 有等到整个过程的末期才能见到开发成果。因此早期的错 误可能要等到开发后期的测试阶段才能发现，进而带来严 重的后果。
XP (1)
• 极限编程（英语：Extreme programming，缩写为XP）， 是一种软件工程方法学，是敏捷软件开发中最富有成效的 几种方法学之一。如同其他敏捷方法学，极限编程和传统 方法学的本质不同在于它更强调可适应性而不是可预测性 。XP的支持者认为软件需求的不断变化是很自然的现象 ，是软件项目开发中不可避免的、也是应该欣然接受的现 象；他们相信，和传统的在项目起始阶段定义好所有需求 再费尽心思的控制变化的方法相比，有能力在项目周期的 任何阶段去适应变化，将是更加现实更加有效的方法。
Sprint backlog (1)
• Sprint计划会议非常关键，应该算是Scrum中最重 要的活动。 • 举办Sprint计划会议，是为了让团队获得足够的信 息，能够在几个星期内不受干扰地工作。 • Sprint计划会议会产生一些实实在在的成果：
– ������ sprint目标。 – ������ 团队成员名单（以及他们的投入程度，如果不是 100%的话）。 – ������ sprint backlog（即sprint中包括的故事列表）。 – ������ 确定好sprint演示日期。 – ������ 确定好时间地点，供举行每日scrum会议。
Agile Process
Waterfall (1)
Waterfall (2)
• 1. 2. • • 瀑布模型(Waterfall Model)的特点： 需求分析->概要设计->详细设计->开发->测试->交付 阶段间具有顺序性和依赖性 必须等前一阶段的工作完成之后，才能开始后一阶段的工作； 前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确， 后一阶段的工作才能获得正确的结果。 3. 质量保证的观点 • 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。 完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行 时期对软件进行维护的重要依据。 • 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。事实 上，越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出 的代价也越高。因此，及时审查，是保证软件质量，降低软件成本的重要措施。 • 传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。在设计阶 段可能发现规格说明文档中的错误，而设计上的缺陷或错误可能在实现过程中显现出 来，在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。 4. 瀑布模型很大程度上是一种文档驱动的模型。 • 遵守瀑布模型的文档约束，将使软件维护变得比较容易一些。
• 硝烟中的Scrum和XP
terms
• • • • • • • • Agile Sprint Scrum TDD – Test Driven Development XP – eXtreme Programming Product backlog Sprint backlog Burndown chart
Agile Manifesto
• Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
Agile (1)
敏捷软件开发又称敏捷开发，是一种从九十年代开始逐渐引起广泛关注的一些新型软件开 发方法，是一种应对快速变化的需求的一种软件开发流程。 敏捷软件开发宣言(价值观）： • 个体和交互胜过过程和工具 • 可以工作的软件胜过面面具到的文档 • 可户合作胜过合同谈判 • 响应变化胜过遵循计划 敏捷开发集成了新型开发模式的共同特点，它重点强调： 1. 客户与开发者的关系是协作，不是合约。 2. 以人为本，注重编程中人的自我特长发挥。 3. 面对面的沟通（认为比书面的文档更有效）。 4. 迭代 - 频繁交付新的软件版本。 5. 紧凑而自我组织型的团队。 6. 强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的 主体。 7. 设计周密是为了最终软件的质量，但不表明设计比实现更重要，要适应客户需求的不断 变化，设计也要不断根据环境的变化，修改自己的设计。
That is, while there is value in the items on the right, we value the items on the left more.
Product backlog
• • • 1. 2. 3. 4. 产品backlog是一切的起源。从根本上说，它就是一个需求、或故事、或特性 等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的 东西，并用客户的术语加以描述。 我们叫它故事（story），有时候也叫做Product backlog条目。
ቤተ መጻሕፍቲ ባይዱ
references
• http://en.wikipedia.org/wiki/Agile_software_development • http://en.wikipedia.org/wiki/Scrum_(development) • Agile Software Development – principles, Patterns, and Practices
• 回馈：来自系统的反馈、来自客户的反馈、来自小组的反馈 • 勇气：“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是
努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。
• 尊重：尊重的价值体现在很多方面。在极限编程中，团队成员间的互相尊
重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有 的测试案例失败、或者以其他方式导致工作延期。
XP (2)价值
• 沟通：在一些正式的软件开发方法中，这一任务是通过文档来完成的。极限编程
支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。
• 简单：极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。
这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计 、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这 样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更 多的努力。
Agile (2)
Agile is about being open about what we’re capable of doing, and then doing it – Kent Beck
Agile (3)
Agile (4) 12条原则
1。我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 2。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 3。经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越 好。 4。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 5。围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够 完成工作。 6。在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 7。工作的软件是首要进度度量标准。 8。敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定 的开发速度。
Sprint backlog (3)
决定sprint要包含的故事
Sprint backlog (4)
Sprint backlog (5)
• • 在sprint中包含多少故事由团队决定，而不是产品负责人或其他人。 Work Time Estimation: 如果投入最适合的人员来完成这个故事，锁到一个屋子里， 有很多食物，在完全没有打扰的情况下工作，那么需要多久，才能给出一个经过测 试验证，可以交付的完整实现呢？ Sprint velocity 生产率计算 - 投入程度（focus factor）
9。不断地关注优秀的技能和好的设计会增强敏捷能力。
10。简单----使未完成的工作最大化的艺术----是根本的。 11。最好的构架、需求和设计出自于自组织的团队。 12。每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为 进行调整。
Agile (5)
运用敏捷要注意的问题 • 敏捷对人员的素质要求比较高 传统的分工基本上是每人负责一个模块，敏捷要求代码共 有；敏捷要求结对编程，这是对dev沟通能力的一个考验； 敏捷要求TDD，对开发人员能力要求比较高；持续的代码 重构 • 组织文化必须支持谈判 • 人员彼此信任 • 人少但是精干 • 开发人员所作的决定得到认可 • 环境设施满足成员间快速沟通之需要 • 最重要的因素恐怕是项目的规模。规模增长，面对面的沟 通就愈加困难，因此敏捷方法更适用于较小的队伍。
Agile Introduction
Agenda
• • • • • • • Agile Process Agile vs. waterfall model Product backlog Sprint backlog Daily Scrum Sprint Review & retrospective Scrum teams
XP (3)原则
• 快速反馈：当反馈能做到及时、迅速，将发挥极大的作
用。
• 假设简单：假设简单认为任何问题都可以"极度简单"地
解决。传统的系统开发方法要考虑未来的变化，要考虑代 码的可重用性。极限编程拒绝这样做。
• 增量变化：罗马不是一天建成的。一次就想进行一个大
的改造是不可能的。极限编程采用增量变化的原则。