敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。

敏捷宣言

  • 个体与交互 重于 过程和工具
  • 可用的软件 重于 完备的文档
  • 客户协作 重于 合同谈判
  • 响应变化 重于 遵循计划

敏捷原则

  1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
  2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
  3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
  4. 项目过程中，业务人员与开发人员必须在一起工作。
  5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
  6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
  7. 可用的软件是衡量进度的主要指标。
  8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持持续稳定的进展速度。
  9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
  10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
  11. 最佳的架构、需求和设计出自于自组织的团队。
  12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

敏捷方法和技术

Scrum

Scrum是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。

Scrum3355

  • 三个角色
    • Scrum Master：确保Scrum被理解并实施
    • Product Owner（产品负责人）：最大化产品以及开发团队工作的价值
    • Team（团队）
      • 自组织团队
      • 全功能团队：具有不同只能专业或多学科技能的团队
    • “猪”角色：全身投入项目和Scrum过程的人；
    • “鸡”角色：参与每一个冲刺的评审和计划，并提供反馈。
  • 三个工件：Product Backlog（产品代办事项）、Sprint Backlog（冲刺待办事项）、可交付产品增量
  • 五大仪式（事件）：Sprint（冲刺）、Sprint Planning（冲刺计划）、Sprint Daily Standup（每日站会）、Sprint Review（冲刺评审）、Sprint Retrospective（冲刺回顾）
  • 五大价值观：Courage（勇气）、Openness（开放）、Focus（专注）、Commitment（承诺）、Respect（尊重）

Scrum的三大支柱

  1. 透明性（Transparency）
  2. 检验（Inspection）
  3. 适应（Adaptation）

极限编程（eXtreme Prgramming，XP）

极限编程是一种软件工程方法学，是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。

极限编程的目标：降低因需求变更而带来的成本。

极限编程四个价值：沟通、简单、回馈、勇气。

极限编程五个原则

  1. 快速反馈
  2. 假设简单
  3. 增量变化
  4. 拥抱变化
  5. 高质量的工作

极限编程12个核心实践

  1. 短交付周期
  2. 计划游戏
    • 软件发布计划（ReleasePlanning）
    • 周期开发计划（IterationPlanning）
  3. 结对编程
  4. 可持续的节奏
  5. 代码集体所有
  6. 编码规范
  7. 简单设计
  8. 测试驱动开发
  9. 重构
  10. 系统隐喻
  11. 持续集成
  12. 现场客户

精益软件开发（Lean Software Development）

精益原则

  1. 尊重一线人员
  2. 消除浪费
  3. 增强学习
  4. 尽量延迟决定
  5. 嵌入质量
  6. 快速交付
  7. 整体优化

测试驱动开发（TDD，Test-Driven Development）

测试驱动开发要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。

测试驱动开发的口号：不可运行/可运行/重构

测试驱动开发基本过程

  1. 快速新增一个测试
  2. 运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过
  3. 做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法
  4. 运行所有的测试，并且全部通过
  5. 重构代码，以消除重复设计，优化设计结构

测试驱动开发优势

  1. TDD根据客户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。因为关注用户反馈，可以及时响应需求变更，同时因为从使用者角度出发的简单设计，也可以更快地适应变化。
  2. 出于易测试和测试独立性的要求，将促使我们实现松耦合的设计，并更多地依赖于接口而非具体的类，提高系统的可扩展性和抗变性。而且TDD明显地缩短了设计决策的反馈循环，使我们几秒或几分钟之内就能获得反馈。
  3. 将测试工作提到编码之前，并频繁地运行所有测试，可以尽量地避免和尽早地发现错误，极大地降低了后续测试及修复的成本，提高了代码的质量。在测试的保护下，不断重构代码，以消除重复设计，优化设计结构，提高了代码的重用性，从而提高了软件产品的质量。
  4. TDD提供了持续的回归测试，使我们拥有重构的勇气，因为代码的改动导致系统其他部分产生任何异常，测试都会立刻通知我们。完整的测试会帮助我们持续地跟踪整个系统的状态，因此我们就不需要担心会产生什么不可预知的副作用了。
  5. TDD所产生的单元测试代码就是最完美的开发者文档，它们展示了所有的API该如何使用以及是如何运作的，而且它们与工作代码保持同步，永远是最新的。
  6. TDD可以减轻压力、降低忧虑、提高我们对代码的信心、使我们拥有重构的勇气，这些都是快乐工作的重要前提。
  7. 快速的提高了开发效率

持续集成

持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

持续集成价值

  • 减少风险
  • 减少重复过程
  • 任何时间、任何地点生成可部署的软件
  • 增强项目的可见性
  • 建立团队对开发产品的信心

持续集成要点

  1. 统一的代码库
  2. 自动构建
  3. 自动测试
  4. 每个人每天都要向代码库主干提交代码
  5. 每次代码递交后都会在持续集成服务器上触发一次构建
  6. 保证快速构建
  7. 模拟生产环境的自动测试
  8. 每个人都可以很容易的获取最新可执行的应用程序
  9. 每个人都清楚正在发生的状况
  10. 自动化的部署

持续集成原则

  1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
  2. 开发人员每天至少向版本控制库中提交一次代码。
  3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
  4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
  5. 每次构建都要100%通过。
  6. 每次构建都可以生成可发布的产品。
  7. 修复失败的构建是优先级最高的事情。

Kanban

看板管理是在工序管理中，以卡片为凭证，定时定点交货的管理制度。一般分为：

  • 在制品看板，它用于固定的相邻车间或生产线；
  • 信号看板，主要用于固定的车间或生产线内部；
  • 订货看板 (亦称“外协看板”)，主要用于固定的协作厂之间。

看板的优势

  • 可视化你的工作流程
  • 限制WIP中的tasks数量
  • 管理并优化流程
  • 量化开发周期
  • 缩短开发周期
  • 变push system (just in case) 为 pull system (just in time)
KanbanScrum
持续集成，无规定周期定时迭代
可在任何时候更改和添加任务在一个Sprint开始后不可更改或添加任务
没有指定角色三个主要角色
cycle time以速度作为过程衡量数据
每个阶段限定task数目没有限定task数目
无需细化task必须细化task

敏捷开发实践

用户故事

用户故事三要素，格式：作为一个<角色>, 我想要<活动>, 以便于<商业价值>

  1. 角色：谁要使用这个功能。
  2. 活动：需要完成什么样的功能。
  3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

Ron Jeffries的3个C：

  • 卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
  • 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
  • 确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

六个特性（INVEST，Independent, Negotiable, Valuable, Estimable, Small, Testable）

故事点

故事点是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。

故事点包含的内容

  • 要开展的工作的数量
  • 工作的复杂度
  • 要开展的工作中存在的任何风险或不确定性

敏捷估算

敏捷估算的步骤

  1. 找一个参考基准，作为一个故事点。比如：把开发一个简单的查询页面工作量作为基准，定义为一个故事点。
  2. 拿其它的故事和基准进行比较，估算他们之间的倍数，从而得到其它故事的故事点数。比如：查看个人基本信息这个故事和开发一个简单的查询页面的规模差不多大，所以它也是1个点，录入个人基本资料的这个故事要复杂一些，大概时3个点。
  3. 累计产品backlog中的所有故事，得到所有故事总的故事点数。

敏捷估算要点

  1. 相对估算，使用故事点作为单位，故事点是一个相对倍数。
  2. 估算规模，规模的计量单位是故事点，规模和时间、周期无关，和人天，人时无关。
  3. 敏捷估算关注团队的速度，不关注单个人的速度。
  4. 通过总规模和团队速度，推算周期。

更多参考Scrum中文网

⤧  Next post 【DSA】数据结构与算法 07 动态规划 ⤧  Previous post 【DB】数据库 02 MySQL