敏捷式软件开发-学习笔记

发表于 更新于 分类于
本文字数： 3.3k 阅读时长 ≈ 3 分钟

敏捷的基本概念，scrum的实际运用的学习笔记

背景

公司的项目经理给我们培训了敏捷的相关知识，为后续团队的敏捷转型做准备，这里记录学习过程。

敏捷的起源

敏捷起源于日本的工厂生产中，日本工厂为了提高效率而采用的流程和方法。后续它的核心精神和好的理念被软件行业所吸收，最终成为了现有的敏捷软件开发方法。

敏捷开发具有的特点是：

  • 自我组织
  • 多功能
  • 持续改进
  • 灵活应对变化

敏捷宣言

我们正通过亲身实践和帮助他人实践，揭示了一些更好的软件开发方法。通过这项工作，我们认为：

  • 个体和互动高于流程和工具
  • 工作的软件高于详尽的文档
  • 客户合作高于合同谈判
  • 响应变化高于遵守计划

也就是说，尽管右项有其价值，但我们跟重视左项的价值。

敏捷宣言作者，2001年版权所有。更多详细信息请访问agilemanifesto.org

什么是敏捷

这里谈一谈我对敏捷的理解，在敏捷开发出现之前，最流行的开发方式就是瀑布流程，注重计划和流程，工具等，忽视人的作用。盘随着软件开发技术的进步，很多方面都发生了翻天覆地的改变。

在原来，可能需要十个人才能完成的工作，借助现今的工具和编程语言还有框架等工具，可能一个人一天就能完成，开发效率大大提高，开发难度向比较之前门槛降低了很多，难度降低了很多。在这种情况下，原有的非敏捷的开发模式，不能够满足现有的开发流程，所以需要一套更为先进的手段来管理，组织软件开发过程。这就是我认为敏捷的产生原因。

在敏捷开发中，强调人的作用，重视人的作用，精兵作战，讲究团队协作，团队是第一位的。敏捷的目的是更快，更高效的开发软件。忽视流程和工具还有文档，并不代表就不去使用这些，只是最重要的事，是在一个短时间内交付出一个可运行的完整软件，伴随着一次一次的迭代，最终达到目的，交付一个高可用的软件产品。

常见敏捷实践方法

  • XP 编程
  • scrum
  • Crystal 水晶方法
  • FDD 特征驱动开发
  • ASD 自适应软件开发
  • DSDM 动态系统开发方法

Scrum

scrum 的创始人是 Jeff Sutherland 和 Ken Schwaber 。

Sutherland 在听取了两位日本管理教授竹内弘高和野中郁次郎介绍制造业里出现新的产品开发方法 Rugby （橄榄球）的文章后，结合自己多年的经验，和 easel 公司的 johJohn Scumniotales 和 Jeff McKennan 一起开发了一套方法，取名为 scrum （来源于橄榄球术语，意思是争球）。其中 rugby 方式的特点是整个流程都由一个高性能，跨功能的团队执行到底。

Schwaber 则从杜邦公司一个化工过程控制专家哪里取经，意识到项目分为两种：确定性项目，一切都已经确定，可以自动化生产流程；实验性项目，充满不确定性，哪怕一点微小的变化也会牵一发而动全身，因此只能用各种仪表不断监控，随时做出调整——这就是每日站会的由来。

两人合作，做了详细的研究，共同创造了 scrum。

Scrum 特性

Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。

在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（product backlog，我觉得翻译成“产品目标”更恰当）， 产品订单（产品目标）是指按照优先级排列的需要完成的工作的概要的需求（目标）。哪些订单项（目标项目）会被加入一次冲刺，由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。

Scrum 主要活动

  • 计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
  • 每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
  • 评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。
  • 反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。
  • 冲刺 Sprint 一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的一组订单项的开发。

Scrum 参与角色

  • 产品负责人 Product Owner： 负责维护产品订单的人，代表利益相关者的利益。
  • Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
  • 开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。

Scrum 工件

  • 产品列表 Product Backlog：根据用户价值进行优先级排序的高层需求。
  • 冲刺订单 Sprint Backlog：要在冲刺中完成的任务的清单。
  • 产品增量 Increment：最终交付给客户的内容

Scrum 基本流程

  1. 首先确认一个 产品列表 （Product Backlog，按照优先级排列），由 产品负责人 负责。
  2. 开发团队 根据产品列表，做工作量的预估和安排，即建立 用户故事。
  3. 有了产品列表，我们需要通过计划会来从中来挑选一个 用户故事 作为本次迭代完成的目标，这个目标的时间周期是1~4周（即一个冲刺），然后把这个用户故事细化，形成一个 冲刺订单。
  4. 冲刺订单 由 开发团队 完成，每个成员根据冲刺订单再细化成更小的任务（两天内完成，即一般来说任务要分解到8小时内）。
  5. 在冲刺过程中，每天要进行15分钟的每日立会，汇报内容为：我昨天完成了什么，今天要完成什么，遇到了什么困难。回答完成后并更新自己的燃尽图。
  6. 要做到每日集成，即每天都有一个可成功编译，可以演示的版本。
  7. 一个冲刺完成时，要进行评审会，演示完成的软件产品，并进行评审。
  8. 最后就是反思会/回顾会。

用户故事

用户故事是从用户角度来描述用户渴望的功能，一个好的用户故事包含三个要素

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

用户故事的 INVEST 特性

  1. 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
  2. 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
  3. 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
  4. 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
  5. 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
  6. 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

用户故事卡

用户故事卡要包含如下内容

  1. 优先级
  2. 价值
  3. 分数
  4. 时间
  5. 标题
  6. 描述
  7. 验收标准 (AC)

用户故事卡