第4章 敏捷视角下的过程

Release
sof t ware increment adjust ment s f or subsequent cycles
component s implement ed/ t est ed f ocus groups f or f eedback f ormal t echnical reviews post mort ems
4.2.1 敏捷开发的立场 将敏捷软件开发作为许多传统软件工程的对立面，它们在优越性和适用性方 面存在着许多争论。 没有人反对敏捷，真正问题在于“什么是最佳实现途径”。 敏捷学派内部，针对敏捷问题，也提出了很多有细微差异的过程模型。
4.2.2 人的因素 敏捷软件开发的拥护者花费了很多精力强调“人的 因素”在成功敏捷开发中的重要性。敏捷开发团队及 成员必须具备以下一些特点： •基本能力 •共同目标 •精诚合作 •决策能力 •模糊问题解决能力 •相互信任和尊重 •自我组织
4.3.3 动态系统开发方法 是一种提供“通过在可控项目环境中使用增量原型开发模式完全满足参时 间有约束的系统的构建和维护”的敏捷软件开发方法。像XP和ASD一样，建议 使用迭代软件过程。 •可行性研究 • •业务研究 •功能模型迭代 •设计和构建迭代 •实现
与功能的“故事”（用户故事），每个故事标明优先级。 并评估每个故事的成本，若成本超个3个开发周期，则要求 进一步细分。 故事的排序： •所有故事将在几周之内尽快实现 •具有最高价值的故事将移到进度表的前面并首先实现 •高风险故事将首先实现
项ቤተ መጻሕፍቲ ባይዱ速度用于： •帮助建立后续发行版本的发布日期和进度安排 •确定是否对整个开发项目中的所有故事有过分承诺
用户故事 权值 验收测试准则 迭代计划
简单设计 CRC卡
Spike解决方案 原型
设计 策划
重构
编码
结对编程
测试
发布 软件增量 项目速度估算 单元测试 验收测试
极限编程过程
连续集成
XP有四个核心价值是我们应该注意
沟通：问题往往是由于开发人员与设计人员、设计人 沟通：问题往往是由于开发人员与设计人员、 员与客户之间的沟通不畅造成的 简单：应该尽量保持代码的简单， 简单：应该尽量保持代码的简单，只要它能工作就可 以与其实现一个复杂的的系统， 以与其实现一个复杂的的系统，不如设计一个能够满 足目前需要的、简单的系统，因为你所考虑的情况可 足目前需要的、简单的系统， 能永远都不会发生。 能永远都不会发生。 反馈：尽快获得用户的反馈，并且越详细越好， 反馈：尽快获得用户的反馈，并且越详细越好，使得 开发人员能够保证自己的成果符合用户的需要。 开发人员能够保证自己的成果符合用户的需要。 勇气：这是最重要的核心价值。因为 强调要 强调要"拥抱 勇气：这是最重要的核心价值。因为XP强调要 拥抱 变化"，因此对于用户的反馈， 变化 ，因此对于用户的反馈，要勇于对自己的代码进 行修改，丢掉坏的代码。 行修改，丢掉坏的代码。
集体拥有代码 XP： 认为开发小组的每个成员都有更改代码的权利，所有的人对 于全部代码负责。 评论： 代码全体拥有并不意味者开发人员可以互相推委责任，而 是强调所有的人都要负责。如果 一个开发人员的代码有错误，另 外 一个开发人员也可以进行BUG的修复。 持续集成 ( Continuous Integration ) XP： 提倡在一天中集成系统多次，而且随着需求的改变，要不断 的进行回归测试。因为，这样可以使得团队保持一个较高的开发 速度，同时避免了一次系统集成的恶梦。 著名的微软公司就有每日集成 ( Daily Build ) 的成功实践。
测试驱动 ( Test-driven ) 先测试，再编码；代码未动， 先测试，再编码；代码未动，测试先行 XP： 强调“测试先行”。在编码开始之前， ： 强调“测试先行” 在编码开始之前， 首先将测试写好，而后再进行编码，直至所有 首先将测试写好，而后再进行编码， 的测试都得以通过。 的测试都得以通过。 注：测试的可自动化，集成化。 测试的可自动化，集成化。
adapt ive cycle planning
uses mission st at ement project const raint s basic requirement s
Requirement s gat hering JAD mini-specs
t ime-boxed release plan
4.1 敏捷是什么
和许多管理方法概念不同，“敏捷”是从整体能力或表现的角度着眼的， 它昭示了一种经营方式，这是理解其意义的要点。敏捷性有两个基本对象：整 个企业（或组织）及对企业中的人： 对于公司，敏捷是有利于在顾客机会持续而不可预测地变化的竞争环境中 运作的能力。 对于个人，敏捷是对公司底线的作用能力，这个底线就是为响应不可预测 地变化的顾客机会经常地重组其人与技术资源。 敏捷软件开发不是一个具体的过程，而是一个涵盖性术语（umbrella term），用于概括具有类似基础的方式和方法。这些方法，其中包括极限编程 （Extreme Programming）、动态系统开发方法（Dynamic System Development Method）、SCRUM、Crystal和Lean等，都着眼于快速交付高 质量的工作软件，并做到客户满意。
成对编程 ( Pair Programming ) XP： 认为在项目中采用成对编程比独自编程更加有效。成对编程是由两个开发 人员在同一台电脑上共同编写解决同一问题的代 码，通常一个人负责写编码， 而另一个负责保证代码的正确性与可读性。 成对编程是一种非正式的同级评审 ( Peer Review )。它要求成对编程的两个开 发人员在性格和技能上应该相互匹配
4.2 敏捷过程是什么 任何一个敏捷过程都可以由所强调的三个关键假设而识别出来： • 提前预测哪些需求是稳定的以及哪些需求会变化非常困难。同样， 预测项目进行中客户优先级的变化也很困难。 • 对很多软件来说，设计和构建是交错进行的。事实上两种活动应当 顺序开展。 • 从制定计划的角度来看，分析、设计、构建和测试并不像我们所设 想的那么容易预测。
它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和 它希望以最高的效率和质量来解决用户目前的问题， 代价来满足用户未来的需求， 在平衡短期和长期利益之间做了 最小的 代价来满足用户未来的需求，XP在平衡短期和长期利益之间做了 巧妙的选择。 巧妙的选择。
策划： 策划：策划活动开始于建立一毓描述待开发软件必要特征
XP的适用环境： 的适用环境： 的适用环境
XP弱化针对未来需求的设计，非常注重当前的简化.它的实 弱化针对未来需求的设计，非常注重当前的简化 它的实 弱化针对未来需求的设计 有一个非常关键的假设就是：开发人员只注重眼前需求， 践，有一个非常关键的假设就是：开发人员只注重眼前需求，依 赖重构来适应需求的变动，这样所带来的风险、 赖重构来适应需求的变动，这样所带来的风险、开销要小于需求 变化使得事先充分设计失效的代价；反之，实施XP就 变化使得事先充分设计失效的代价；反之，实施 就 是不明智 因此, 适合规模小、 的.因此 XP适合规模小、进度紧、需求变化大、质量要求严的项目。 适合规模小 进度紧、需求变化大、质量要求严的项目。
敏捷原则： 1. 优先级最高的是，通过早期和持续交付有价值的软件来满足客户。 2. 欢迎变更需求，即使在开发的后期提出。敏捷过程为客户的竞争优 势而控制变更。 3. 以两周到两月为周期，频繁地交付可运行的软件，首推较短的时间 定量。 4. 在整个项目过程中，每一天开发人员都要和业务人员合作。 5. 由个体推动项目的建设，为个体提供所需的环境，支持和信任。 6. 在开发团队中或开发团队间传递信息的最为有效和高效的方法是面 对面的交谈。 7. 衡量进展的重要尺度是可运行的软件。 8. 敏捷过程提介可持续的开发。 9. 发起人，开发者和用户应该步调一致。 10.不断地关注技术上优越的设计会提高敏捷性。 11.简洁是最重要的，简洁就是尽量减少工作量的艺术。 12.最佳的架构，需求和设计来自于自组织的团队。 13.团队要定期反省如何使工作更有效，然后相应地调整行为。
4.3 敏捷过程模型 4.3.1 极限编程（eXtreme Programming）
XP（eXtreme Programming）方法是最引人注目的一种轻型开发方 法。它规定了一组核心价值和方法，消除了大多数重量型过程的不必要 产物，建立了一个渐进型开发过程。该方法将开发阶段的4个活动（分 析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、 反馈修正和反复测试。它把软件生命周期划分为用户故事、体系结构、 发布计划、交互、接受测试和小型发布6个阶段 。 XP开发模型与传统模型相比具有很大的不同，其核心思想是交流 （Communication）、简单（Simplicity）、反馈（Feedback）和进取 （Aggressiveness）。XP开发小组不仅包括开发人员，还包括管理人 员和客户。该模型强调小组内成员之间要经常进行交流，在尽量保证质 量可以运行的前提下力求过程和代码的简单化；来自客户、开发人员和 最终用户的具体反馈意见可以提供更多的机会来调整设计，保证把握正 确的开发方向。
XP对于执行者的要求是比较高的 对于执行者的要求是比较高的 因为它要求开发团队必须具备熟练的代码设计 技能和严格的测试保障技术 了解面向对象和模式，掌握了重构和 了解面向对象和模式，掌握了重构和OO测试 测试 技术 习惯测试先行的开发方式等
4.3.2自适应软件开发 自适应软件开发（Adaptive Software Development）着眼于人员协作和团队自 我组织。包含思考、协作和学习三个阶段。
小型发布 ( Small Release ) XP： 强调在非常短的周期内以递增的方式发 ： 布新版本， 布新版本，从而可以很容易地估计每个迭代周 期的进度，便于控制工作量和风险； 同时， 期的进度，便于控制工作量和风险； 同时，也 可以及时处理用户的反馈。 可以及时处理用户的反馈。
用户在发布后两个工作日内， 用户在发布后两个工作日内，向项目小组提交 用户接收测试报告” 由项目经理评估测试报告， “用户接收测试报告”，由项目经理评估测试报告， 将有效的BUG提交并分配给相应的开发人员。 提交并分配给相应的开发人员。 将有效的 提交并分配给相应的开发人员 项目小组应该在下一个迭代周期结束前修 复所有用户提交的问题。 复所有用户提交的问题。
Kent Beck认为对于XP来说，简单设计应该满足以下几个原则： 成功执行所有的测试； 不包含重复的代码； 向所有的开发人员清晰地描述编码 以及其内在关系； 尽可能包含最少的类与方法
编码： 编码：
代码重构 ( Refactoring ) XP： 强调代码重构在其中的作用，认为应该经常进行重构，通常有两个 关键点应该进行重构：对于一个功能实现前和实现后。 代码重构是指在不改变系统行为的前提下，重新调整、优化系统的内部 结构以减少复杂性、消除冗余、增加灵活性和提高 性能。 重构不是XP所特有的行为，在任何的开发过程中都可能并且应该发生。
简单设计 ( Simple Design ) ：XP的设计严格遵循KIS（keep it simple) •传统的软件工程要求： 前提是需求不变化，或者很少变化； •而XP认为： 需求是会经常变化的，因此设计不能一蹴而就而应该是一 项持续进行的过程。 • XP鼓励使用CRC卡 • XP鼓励使用既是构建技术又是设计技术的“重构”。 • XP设计实际上不使用符号并且几乎不产生工作产品。 • XP中心观念是设计在编码开始前后同时发生。
第4章 敏捷视角下的过程
敏捷宣言： •个体和迭代，超越过程和工具 •工作的软件，超越完整的文档 •客户协作，超越合同谈判 •响应变更，超越履行计划
本质上讲,敏捷方法是为了克服传统软件工程中认识和实践的弱点开发而成的。 在现代经济生活中，很难甚至无法预测一个基于计算机的系统如何随时间推移 而演化。因此在很多情况下我们必须足够敏捷地去响应不断变化、无法确定的 商业环境。 利用纪律或者宽容来处理开发计算机软件的人员的弱点。