Nick 每周读读书 - 有关于“敏捷开发”

vlambda
2021-05-17

Nick 每周读读书 - 有关于“敏捷开发”

这算是半篇读书笔记，相关书籍：

《敏捷革命》- 杰夫·萨瑟兰
《精益创业实战》- 莫瑞亚

为什么会去阅读敏捷开发相关的图书呢？

最近所在的产品团队正在转换产品开发模式，从传统的“瀑布法“转换到”敏捷开发“，所以找到了这两本书。

在总结书中提到的方法论之前，想要先聊聊自己的一些想法：

虽然这两本书主要讲的都是在产品开发过程中如何使用敏捷方法，但仍然可以从中吸取到一些思想：

产品是一种求变的思维产物。产品所处的环境、所面对的用户都会产生变化，因此需要产品相关人员更加“柔性”，不断频繁地了解这些变化，并给出对应的解决方案。而面对这些变化，好的应对方法就是快速的将产品投入到市场中，接受检验，不断进步。

回顾互联网发展的这些年，无论是硬件还是软件，我们作为一些产品的消费者和使用者，也在不经意间产生着变化。身边的各种产品也在不断适应着我们。

例如我们熟悉的手机市场，从乔布斯时代的 3.5 英寸黄金尺寸，到如今百花齐放，甚至出现了接近 10 英寸的折叠屏手机。仔细回想，小米、OPPO、VIVO 等一众国产手机在过去的几年时间里，不断推出各种价位配置的机型，一方面是在抢占不同水平的市场，另一方面也在不断试错，想要找到人们最易接受的价格和配置的结合。这也是敏捷思维的一种体现。

另外，在接受变化的同时，也要理智的判断，究竟是用户“真实”的发生了转变，亦或是最初调研或者沟通中出现了障碍所致。敏捷 Scrum 方法，不断强调团队与用户、团队与团队的及时有效沟通，以此避免“脱靶”。

我个人认为产品就是传递双发想法的媒介，如何让产品变得有效，产品设计手段固然重要，但是从用户处得到真实需求才是最核心的要素。毕竟车技再高、车速再快，走在错误的路上也永远无法到达终点。因此每次沟通都要有明确目的，每次沟通都要真正了解用户这个目的情境下的真实想法，不断深挖。不要囫囵吞枣，也不要妄想一口吃掉一头大象，试图一次性获取用户面对的所有问题。另外沟通的频次尝试增多，以便于及时应对变化。

接下来是一些方法论：

分别介绍两种方法（本文敏捷主要指 Scrum 方法）的基础概念：

“瀑布法"：是一种比较传统的方法，其特点在于强调对流程顺序的把控。项目通常会分解成 5 个阶段：分析、设计、实现、测试、发布。每一个阶段的工作都建立在前一阶段的基础上，如果把每个阶段想象成纵向排列，就会像瀑布一样，所以得名“瀑布法”。

“敏捷开发”：是兴起于二十世纪九十年代的软件开发方法，它更加重视整个团队合作，与客户的沟通以及十分强调灵活性。敏捷开发就是将最终目标拆解成一个个小目标，并根据小目标快速迭代持续交付可以工作产品，通过反馈结果持续改进产品，提升客户满意度。

“瀑布法”更偏向一次性收集所有需求，因此前期与用户或者需求方进行大量的沟通，并根据沟通结果制定明确项目计划，一步一步前进，在这期间屏蔽掉外界的干扰，尽可能的减少需求变更，严格控制项目风险直至推出产品。

这就导致了一个十分严重的问题，一旦在测试环节发现问题，或者上线后市场不认可，无法满足用户需求，那么整个项目都要推翻重做，回到起点。并且一次性解决所有问题的方法也就意味着项目周期很长。因此造成的浪费也是十分严重的。

“敏捷开发”整个过程是由若干个短的迭代周期构成，每个迭代周期都会以解决优先级较高的”用户故事“为目标，通过需求讨论、拆解需求，评估工作量、开发上线。

其实每个迭代周期中都会经历类似“瀑布法”的工作流程：分析、设计、实现、测试、发布，只不过每次都是完成一个“小目标”，通过频繁的迭代以及跟踪对前一次迭代的反馈，最终得到接近完善的产品。这样即便是在某一阶段出现了失败，也只需要调整上一个迭代周期的内容，而不至于所有工作全部白费。变相的节约了资源。

整个敏捷开发过程中最为关键点就是“用户故事”

用户故事是从用户角度出发来描述他们想要获取的功能。

一般来说用户故事包含 3 个要素：

角色(role)：谁来使用这个功
活动(activity)：需要完成什么样的功能
商业价值(business value)：为什么需要这个功能？这个功能能够带来什么价值。

将三要素串联起来就是故事的结构：

作为一个<角色>，我想要<活动>，以便于<商业价值>

用户故事具有 6 个特性：

独立性：尽可能让每个用户故事可以独立于其他用户故事而存在。减少用户故事之间的相互依赖性有助于确定优先级和估算工作量。
可协商性：用户故事只是一个概括，具体的细节是在沟通阶段产出。
有价值：每个故事对于用户来说都是有价值的，也就是能够帮助用户解决问题的。
可估算性：敏捷开发中开发人员需要根据用户故事评估工作量，因此用户故事的大小必须是适当的，如果太大了，就需要将其拆分多个更小的故事。
短小的：短小并不是指越小越好，因为过于小的故事可能会导致开发人员用来评估的时间比实施还要长。所以，尽量保证在一个迭代周期内大家都可以有充足的事情可以做。
可测试的：测试的目的是为了确认它是可以完成的。如果不能测试，那么就无法知道它什么时候可以完成。

用户故事是不承载任何功能细节的，它更像是一个灯塔，告诉团队成员产品最终去往的方向，不要偏航。说的再远一点它是希望团队成员知道自己工作产生的价值，从而转为内驱力，潜移默化的改变团队。

有了“用户故事”之后，团队之间、团队与用户之间的沟通则是决定着产品细节的设计，“用户故事”频繁的迭代也就意味可以与用户多次的进行沟通，时刻了解用户最新的想法。相比于”瀑布法“更加的灵活。

介绍完“用户故事”，就该说说 Scrum 的构成元素了。

包括 3 个角色：

产品负责人(product owner)：主要回答产品 why & what 的问题。
开发团队：主要解决产品 how 的问题。
Scrum master：类似于教练，帮助团队成员转换为敏捷思维。

3 个工件：

产品待办列表：

产品负责人是产品代办列表的唯一负责人。
应当涵盖产品已知所需设想内容的有序列表，是需求变动的唯一来源。通常采用“用户故事”进行描述
会随着产品和环境的变化不断的演进。
列表中的内容有描述、估算、动态和次序的 4 个属性。也可以称为 DEEP 原值

detailed appropriate
estimated
emergent
prioritised

迭代待办列表:

是从产品待办列表中筛选出来的前迭代要实现的“用户故事”。
是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测

产品增量：

是完成一个迭代的所有待办列表的综合，以及之前所有 sprint 所产生的增量的价值综合。
增量必须是完成的且可用的。

5 个事件：

迭代（sprint)：是 scrum 的核心，整个开发期间，sprint 的长度保持一致。在这段时间内构建一个“完成”的、可用的和潜在可发布的产品增量。
迭代计划会议(sprint planning meeting)：计划在迭代中要做的事情。主要回答以下几个问题：

what：接下来的迭代交付产品增量中要包含什么内容
how：如何完成交付增量所需要的工作

每日站会(daily scrum meeting)：

为每日制定工作计划，汇报上一日工作进度汇报紧张过程中的障碍并据此预估当日工作量。

迭代评审会(sprint review meeting)：

用来检视交付成果并按需调整产品待办列表。将产品增量演示给产品负责人和业务方。根据产品负责人和业务方的反馈调整产品代办列表。并且团队成员总结项目过程中的进展与问题。会议的结果是一份修订后的产品代办列表。

迭代回顾会(sprint retrospective meeting)：

主要是检视团队自身的目的：
检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；
找出并加以排序做得好的和潜在需要改进的主要方面；
制定改进 Scrum 团队工作方式的计划。

5 个价值：

承诺：愿意对目标做出承诺
专注：把心思和能力都用到工作中去
开放：把项目中的一切都开放给团队每个人看
尊重：每个人都有独特的背景和经验
勇气：有勇气做出承诺，履行承诺，接受别人的尊重

以上就是敏捷中 Scrum 的核心要素，如果你对更多相关内容感兴趣可以去

Scrum 中文网浏览相关内容，或者阅读相关书籍。

vlambda博客
学习文章列表