敏捷.概念辨析

908486905

已于 2023-05-17 09:44:21 修改

阅读量1k

点赞数

分类专栏：敏捷开发ACP 文章标签：敏捷

于 2023-01-14 10:00:22 首次发布

本文链接：https://blog.csdn.net/u010025781/article/details/128682447

版权

敏捷开发ACP 专栏收录该内容

22 篇文章 9 订阅

订阅专栏

第一部分

1. 最小可行产品MVP（Minimum Viable Product）

在很多同学的脑海里，MVP就是你想传达给用户的功能的最小集合。

错，完全错。

问题不在于“你觉得应该……”，关键是“用户目前感觉……”。我们预设了立场，认为我们已经知道所有的用户需求。而当我们的产品被用户使用了多年，必须要用新产品或者功能推倒重来的时候，我们才知道，对于用户，当时我们不是无所不知。而MVP，就是彻底颠覆这种产品观，解决预设立场带来的问题。

MVP就是边验证边学习，它应该完全以用户问题为中心，而不是以解决方案为中心。因为用户不关心你的解决方案，就算你的方案有趣又好玩，与他也不直接相关。所以首先我们要明确“MVP”的定义。

这个概念是由Eric Ries在《精益创业》的理论中提出的，这本书囊括了他对精益产品开发思路的完整阐述。而MVP是整本书最核心的概念，书中给出的定义是：“所谓最小化可用产品，是让开发团队用最小的代价实现一个产品，以此最大程度上了解和验证对用户问题的解决程度。”

假设你现在创业，你的产品目标是——有史以来最好的甜甜圈！

产品团队用最快的速度干了一张原型图，程序工程师快速吐出一团代码，编译工程师把原型图和代码揉成面团扔进锅里炸熟，开发出了一套味道普通的甜甜圈——这就是你们第一个最小化可用产品。能吃，能用（谜之作用），但可能还不是有史以来最好的甜甜圈。这时候，你的产品团队就要抓紧时间，问用户一些问题。比如说：

你们觉得这款甜甜圈哪最好？

如果你可以选择加配料，你会加哪些？

你喜欢什么甜甜圈造型？切开的还是一体的？金黄炸透的还是脆嫩相间的？

……

有了这些通过种子用户得到的验证结果，产品团队精神大振，立马操刀做了一套更好的甜甜圈。根据用户的反馈，产品团队总结出了不少实施细节：

在一些特定情况下，用户会喜欢加一些七彩糖珠；

一些特定的市场和特定的用户更喜欢巧克力甜甜圈；

如果是海外用户，他们可能更喜欢草莓甜甜圈。

如你所见，“开发MVP-通过用户验证”是创造好产品的第一步。接下来就是用“构建-测量-学习”的方式，在限量测试或者正式运营中，对产品进行循环迭代。

作为产品的创造者，你可以是骄傲的、品位非凡的、目光长远的，但请不要忘记，在产品的成长旅程中，你的用户始终是旅程的重要部分。

那么，怎样才能确定“最小可用产品”的“最小”呢？

如果只仅仅考虑“最小化”，就会像上图左边那样陷入没人需要，不能解决问题的困境。而加上了“可用”这个考量，我们就可以设计出一款对于种子用户刚刚好的产品。当然，我们的最终目标当然是实现可用性的最大化，达到产品的理想形态。

实操过程中，如果我们矫枉过正，开发了“最小”但“不可用”的产品，这就需要我们做好用户访谈，多多测试产品，多多去用户的社区了解他们的痛点。尽量把方向转移到“可用”上来。

从某些方面来说，开发MVP增加了很多额外的工作，进行产品迭代、验证需求都要耗费大量的时间和精力。因此，在测试MVP时一定要避免不必要的细节，根据不同的产品选择不同的方法。最终，你需要将验证过的MVP转变成真正的产品，接受市场的考验。

第二部分 scrum过程

在每次迭代的第一天，召开迭代计划会(Sprint Planning Meeting)。产品负责人会逐一挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和。一旦迭代开始，这些任务将不会发生大的变化。
在迭代期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的站立会议即每日立会 Daily Stand-up Meeting，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一张“燃烧图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，以观察和预测所有任务是否会按期完成。
在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。
当天还会召开反思会(Retrospective Meeting)，对本次迭代中的成功与失败之处做出总结，并在以后迭代中进行改进。

两个清单

Product Backlog

产品待开发项 Product Backlog是从客户价值角度理解的产品功能列表。

功能、缺陷、增强等都可以是待开发项。
一般以条目化的方式描述。
客户和用户必须能够理解。
整体上从客户价值优先级排序。
工作量一般需要0.5～10人天。
高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。

Sprint Backlog 冲刺待开发项，是从开发技术角度理解的迭代开发任务。

在简单的纯软件环境中，可以直接把产品待开发项当作冲刺待开发项分配到迭代中。
在复杂的开发环境中，可以把一个产品待开发项分解为Web/后台……软件/硬件……程序/美术……等开发任务。

三个角色

Product Owner 产品负责人，负责产品需求的提炼、条目化、优先级排序。
现实世界的产品负责人

部门经理、产品经理、策划人员等都可能做产品负责人。
产品负责人是产品的指路人，必须对产品有长远的规划和深入了解，因此不能简单地选择销售人员甚至客户作为产品负责人。
大型产品如嵌入式产品和网络游戏，常常使用有层级的产品负责人团队，来解决广度与深度的矛盾，如产品总监-产品经理 / 主策划-策划团队。

Scrum Master Scrum“大师”，负责维护Scrum方法的秩序，并协助解决非技术问题。
现实世界的Scrum Master

Scrum Master的工作方式是靠领导力(leadership)而非权力工作，因此首先应服务于团队。
一种人选是原来的项目经理转型，保留原有的管理和技术职能，但弱化指派任务、下达时间点指令等内容，而增强其组织协调能力。
另一种人选是企业原有的过程改进人员，协助不太了解Scrum的项目经理按照Scrum的方法工作，可以每人负责多个项目，接近全职的Scrum Master。

The Team （团队）以“自组织”的相对扁平方式进行管理，负责完成开发工作。
现实世界的开发团队

实际团队常常不是“扁平的”，而是仍有项目经理、小组长等职位。
工作中他们以“共同估算”“跨职能工作”“共同跟进”等方式自组织工作，而不是完全依赖层层指令。
项目经理、小组长的领导、指导、协同职能大于其指令职能。

四个仪式 + 产品待办列表梳理会

计划会：Sprint Planning Meeting
迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
产品负责人逐条讲解最重要的产品功能。
开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。
产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。
每日立会：Standup Meeting
队员认领任务（或由组长协商分发），独立或与别人一起完成任务。
团队内部利用每日立会来沟通进度。
开发团队利用燃尽图来展示整体进度。
如无特殊原因，迭代期内无变更。
评审会：Review Meeting
小组向产品负责人展示迭代工作结果。
产品负责人给出评价和反馈。
以用户故事是否能成功交付来评价任务完成情况。
反思会：Retrospective Meeting
在每个迭代后召开简短的反思会。
总结哪些事情做的好，哪些事情做的不好。
制定改进计划。

1.3 敏捷日常跟进

看板
看板又叫任务版，对于Sprint进度的沟通，看板是一种简单而强大的方式。从形式上看，看板显示的是Sprint冲刺待开发项随时间的进展状态。
故事板简单说就是把所有正在工作的内容，张贴到一个板状空间中。
看板（Kanban）一词来自日语，指的是制造业中的一种可视化方法，有相当复杂的思想和流程。由于两者看上去很类似，两个词汇经常混用。
燃尽图
在Sprint执行的每一天，团队成员都要更新未完成任务的剩余工作量估算。我们可以创建一个表来是使数据可视化，就是燃尽图
根据整个团队的剩余工作总量，每天进行更新，就可以得到燃尽图。

1. Scrum(1) | Scrum 计划会

计划会准备的内容
1. 每个人准备做（测试）哪几个需求？
  1. 手工
  2. 自动化测试UI
  3. APP测试
2. 自动化测试（验收、回归、批量）方案？
3. APP测试
  1. Android模拟器
  2. Android真机（adb） iphone真机（手工）

计划会的步骤
PO 产品负责人产品经理
1. 业务背景介绍
  - 整体的介绍产品的业务
  - 产品可以做什么事情
  - 产品有多少种平台：
    - Web (B/S)
    - PC (C/S)
    - Android
    - iOS
  - 产品有什么样的版本：
    - 免费版
    - PRO版（付费）
  - 有多少种竞争的产品
    - Worktile
    - 明道
    - Leangoo
    - teambition
    - trello
2. 准备 product backlog （更新产品待开发项）
  - 产品经理登录禅道
  - 创建产品
  - 提需求，构成产品待开发项
3. 挑选 sprint backlog （选择该迭代要做的冲刺待开发项）
  - 项目经理登录禅道
  - 创建迭代（项目）
  - 关联产品
  - 关联需求（从第二步创建的需求中，选择一部分，构成冲刺待开发项）
  - 团队设定
4. 讲解 sprint backlog 的具体需求（用户故事）
  - 产品经理讲解每一个被关联的需求
  - 确定验收标准
PM 项目经理 Scrum Master 敏捷教练
1. 确定 sprint 周期长度 1 week？ 2 weeks？
  - 2周/Sprint
2. 认领 sprint backlog，预估时间
  需求（开发，xxx，多少时间；测试，xxx，多少时间）
  - 项目经理登录禅道
  - 选择本次迭代
  - 打开需求
  - 依次选定每一个需求 | 编辑
  - 编辑备注：
    1. 开发：XXX，2h
    2. 测试：YYY，3h
3. 确定评审会的日期
  - 开几次？
  - 每次评审什么需求？
  - 确定演示会的次数
  - 确定每次评审会的需要评审的需求
  - 确定每次评审会的时间
4. 每日立会开会时间
  - 09:05每天
计划会输出文档
- sprint 开始日期，结束日期
- sprint 周期
- 表格（sprint backlog表格）
  1. sprint backlog 列表
  2. 任务认领 + 估算
  编号需求名称 [所属模块] 认领开发开发时间认领测试测试时间
  105 登录/数据提交[手工自动化安全抓包] xxx
  106
  109
  - APP Monkey测试
- 每日站会时间
- 评审会表格
  1. 日期
  2. 评审需求

3. 每日立会

汇报内容
1. 我昨天做了什么事情（完成什么需求的测试？开发？）
2. 我今天准备做什么事情
3. 我目前有什么用的困难（挑战）
  1. 缺乏数据库权限
  2. 缺乏服务器系统用户权限
  3. 技术问题
  4. 业务问题
  5. 时间问题
燃尽图

统计需求：产品本身的需求（或者需求分解的任务总数） + 产品级对应的测试任务数
每日站会中，每个团队成员需要回答3个问题。通过这3个问题，我们可以得到两个层面的信息：
- 团队内信息的透明度，整个团队的进度以及距离Sprint目标还有多远；
- 同时是否存在障碍
每天团队都会得到反馈，并可以根据得到的反馈做出调整。

如果不是每天开站会，那么就可能：
1. 团队内有些信息会隐藏。有的团队反映说团队小（比如4-5人）并且大家都坐在一起，随时都会沟通，没必要每日站会。而实际上团队内的沟通在多数情况下只有相关2-3人一起，而不是整个团队一起。因此每日站会还是非常有必要的（同步、透明化信息）；
2. 团队错过最佳的调整机会。每日站会中，团队可以得知距离Sprint目标有多远，是否存在障碍或者问题。尤其存在障碍时，需要整个团队共同努力，来想办法解决。这不是说发现问题了只有在每日站会才说出来，而是发现问题马上暴露，但每日站会需要正式得让整个团队得知情况（一般这类信息容易在2-3人之间讨论）；
3. 团队没有仪式感。每日站会可以让团队形成规律，每天固定时间、固定地点所有团队成员凑在一起同步信息和进度，很容易团队成员可以形成仪式感，这是一个非常重要的事情。

2. Scrum(2) | 敏捷任务迭代

敏捷 Scrum 流程② | 任务迭代 - 简书

1. 迭代开始

每个小组：

按照计划会的文档画燃尽图
开站会（每天）
1. 昨天做了什么
2. 今天准备做什么（开始测试哪个需求？）
3. 对目前的工作有无困难（阻碍）
组长更新燃尽图
组长在禅道中新建项目（迭代），关联产品，关联开计划会的需求。
1. 登录禅道，组长新建项目（迭代），并且关联产品，设置团队成员。
2. 根据计划会的内容（计划会挑选的需求），关联需求
  
  以接下来的一条需求为例，操作第五步

根据计划会认领的需求（需求141，如上图），对指定的需求，创建测试任务，指派给相关人员

编辑

根据计划会认领的测试任务，由组长或者测试人员自己添加任务

以下图的 APP压力测试和WEB UI自动化验收测试为例，讲解此步骤

编号	需求名称	所属模块	测试人员	测试时间
105	普通用户注册	注册	XXX	1
106	普通用户密码登录	登录		2
120	新建项目	项目列表		1
134	任务编辑
109	邀请新成员	团队		1
111	成员列表
-	APP压力测试（monkey）
-	WebUI自动化测试（验收）
汇总	14个			14

以上列表中，有编号的是需求，直接按照第五步，对需求，创建测试任务，指派给测试人员。

无编号的，是针对产品的任务，直接在项目（迭代） | 任务中创建任务。

3. Scrum(3) | 敏捷流程项目评审会，项目组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈。

1. 评审会

小组向产品负责人展示迭代工作结果。
产品负责人给出评价和反馈。
以用户故事是否能成功交付来评价任务完成情况。

评审会开展

评审标准：整个用户故事是否已经达到交付标准。

评审的标准是整个故事是否已经达到交付标准，而不是从其中分解出来的任务完成了多少，因此若一个故事“差一点就完成了”也算没有完成。
评审标准在迭代计划会上设定。

一般在迭代计划会上设定每个故事的完成标准，如是否需要测试，是否需要考虑性能，是否需要说明文档等等。这些标准一般由项目组提前列好，每个故事只需要选中是否需要即可。
单个用户故事评审

尽管有正式的评审会，但很多团队习惯在单个故事完成时，就让产品负责人进行单个故事评审，以确保交付时不会有“惊喜”。
发现的问题被累积到产品待开发项

评审会上发现的问题或改进将被累积到产品待开发项，也不会马上或在下一个迭代中开发，而是由优先级排序决定何时开发。

这个活动的关键是 检视与调整 sprint过程中产出的产品增量。

第一步是回顾sprint目标和承诺的特性集，并和实际完成的情况进行对比。
第二步是演示和讨论完成的特性，并对产品backlog或者发布计划做出必要的调整，以反应讨论中新的认知，然后重复这个步骤。这个循环直到讨论完所有完成的特性之后才结束。

在这个方法中，演示只是sprint评审会议中的一个活动，它不是sprint评审的目的。

sprint评审会议的目标是 检视与调整 构建的产品。成功的评审结果是双向的信息流动。不属于Scrum团队的人也可以得知开发的成果并帮忙指出方向。

同时，Scrum团队成员通过频繁的反馈而加深了对产品的业务和市场认识。所以，sprint评审会议是一个 检视和调整 产品的预定机会。

2. 评审会问题和改进

问题反馈
改进积累到Product Backlog

3. 评审会示例

计划会认领的需求（任务）：讲解和最初估计时间。
展示一页纸测试计划，简单描述测试方案
- 关于Tower 日历的测试场景：
  1. 日历表中，高亮今天的日期
  2. 创建多个日历簿，每个日历簿上创建日程
  3. 在项目日历簿，创建日程
  4. 在项目中添加任务，到当前日历中查看
  5. 日历中的任务，点击跳转
  6. 在项目中创建日常，到日历中查看
  7. 日历的重复功能
  8. 日历的提醒功能
  9. iCalendar订阅
打开禅道，找到指定的迭代和需求。展示需求的测试任务。
在测试模块，找到用例，简单讲解用例
在Tower中演示测试过程
如果有测出缺陷，描述缺陷。

4. 评审会总结：

经验的积累：分析需求需要更加细致，不可以放过页面上的任何一个元素
测试要注意关联：模块之间的关联容易寻找，但是模块内部的关联也是很重要的
用例的编写：需要留意用例的标题，标题不可以有是否这样的寻求答案的字眼出现，而是应该以预期结果为导向的出现。
- 例如
  1. 注册用户时，输入过长的团队名称，可以注册成功。（错误用例）
  2. 注册用户时，输入过长的团队名称，是否可以注册成功。（错误用例）
  3. 注册用户时，输入过长的团队名称，不可以注册成功，提示用户名称过长。（正确用例）
Bug提交：Bug的描述，Bug的重现步骤，截图等需要认真描述。另外在禅道中学会使用用例的转Bug功能。

4. Scrum(4) | 敏捷流程回顾反思会

Retrospective Meeting，开展回顾反思会是Scrum中最难以实施的活动之一。

反思会讨论三个问题：我们上个Sprint迭代有哪些事情做得好希望继续，哪些事情做得不好希望改进，有何改进计划。

1. 开展反思会

在每个迭代后召开简短的反思会。
总结哪些事情做的好，哪些事情做的不好。
制定改进计划。

1.1 如何开展反思会

反思会是Scrum中最难以实施的活动之一。

反思会上讨论三个问题：

做得好的希望继续
做得不好的希望改进
改进计划

经常出现一些问题多次被提到，但却始终没有解决。这是很不合理的实践，应该每次仅就1～3个关键问题做出可行的解决方案，在下一个迭代执行改进。“可行”的概念包括两个含义：

第一是方法简单，影响面小，见效快
第二个是目标不要激进，而要现实可行，积少成多。

领导回避制度

示例：

1. 明确项目（Sprint）目标、验收标准；
2. 将Code Review作为任务固化，排入Sprint计划，Codereview进行的形式和输出将由XXX和XXX确定；
3. 提高自测质量，开发人员先写一份关于自测的test case，由测试负责人Review和补充，在开发过程中开发人员可参考这份Case进行自测；
4. 下一个Sprint中，由开发工程师自己分解任务，并进行评估，最后进行团队Review；
5. 新模块在开发前一定要经过设计。
6. UI方面的改进只是增加三人小组协调而已，有些涉及企业特有的做法，我就不展开了。

1.2 传统项目和敏捷项目的差别

	传统项目	敏捷项目
项目压力	相对较小	相对较大
项目周期	一段时间（半年、一年等）	持续，一次次SPRINT（冲刺）累积
测试人员	工作单一	工作复杂，角色模糊
文档	文档复杂，详尽、但是往往文档与代码不符	文档少、精炼，指导工作
需求	比较固定，需求变化不被容忍	变化大，随时可以调整
仪式	会议过多，评审过于复杂，效率低	会议短，高校

Scrum 敏捷的100个障碍

在 Scrum 实践中，敏捷教练(Scrum Master)需要帮助团队移除障碍。「移除障碍」诚然是一种挑战，「识别障碍」同样也是一种挑战。鉴于此，如下有一些潜在的障碍需要你小心提防:

组织结构
1. 僵化的矩阵式管理结构
2. QA、Analysis、DBA、 CM...等职能型组织
3. 缺乏合作

外部障碍
4. 团队与团队之间的冲突
5. 无法融入团队的事物
6. 导致分心与中断的因素

资源
7. 合同性的风险
8. 无法改变的时间、价格与需求范围
9. 不切实际的计划
10. 不切实际的预算
11. 不切实际的估计
12. 外部强加的干预(对于用户故事估算或项目估算) 13. 缺乏配置管理
14. 硬件设备/系统/网络性能不足

政治
15. 奖惩制度有悖团队合作
16. 强制性但无效的流程
17. 强制性但无用的工具

流程
18. 无效的流程
19. 不确定的流程
20. 不兼容的流程
21. 事先过度分析
22. 分析不足
23. 过早决策
24. 没有产品待办清单
25. 敏捷教练没有干活儿
26. 团队没有好好分解事项
27. 缺乏跟进(燃尽图等)
28. 团队无法演示产品

冲刺
29. 变化的冲刺长度
30. 冲刺被延展(而不是按时间盒)
31. 冲刺轻易改变

管理
32. 管理风格与敏捷相冲突(如命令型与控制型)
33. 在推行敏捷时传递混乱的管理理念
34. 缺乏管理层的支持
35. 不断的干扰
36. 并行项目太多
37. 产品不具备商业价值
38. 自上而下的决策(如强制性会议)

技术风险
39. 性能
40. 过分镀金
41. 非潜在可部署的
42. 没有系统集成
43. 团队在设计决策上意见不一
44. 少得可怜的测试
45. 缺乏重构
46. 测试导致的延期
47. 无法实现的需求
48. 勉强能实现的要求

团队共识
49. 没有定义何谓“完成”
50. “完成”的定义中未涉及测试
51. PO 或团队其他成员不召开计划会
52. 当计划出现延迟时，团队未考虑做出调整
53. 无法持续回顾和改进(没有改进就放弃了回顾)
54. 没有跟踪障碍
55. 没有处理障碍
56. 没有冲刺待办事项清单(或者任务清单)
57. 团队不拥有冲刺待办事项清单

质量
58. 单元测试不充分
59. 少到可怜的重构
60. 测试导致延期
61. 代码质量差
62. 交付质量极差
63. 自动化测试不足或过于低效

产品风险
64. 无PO
65. PO 没发挥作用
66. 多个(且意见不同)的PO
67. 不向客户开放的产品设计
68. 产品经理未把大的用户故事进行拆分
69. 错误的特性设计
70. 拙劣的交互界面
71. 需求摇摆不定无法达成共识
72. 不够明确的需求
73. 市场风险
74. 产品愿景模糊
75. 缺少干系人参与/过于主观
76. 为极端情况而纳入的需求
77. 产品待办列表过早明细
78. 产品待办列表未定义优先级

人
79. 错误的技能配置
80. 过度专业化的组员
81. 人数不符合敏捷框架要求
82. 瓶颈
83. 新加入成员无法快速融入团队
84. 团队成员缺乏归属感
85. 团队成员间有冲突
86. 团队成员缺乏互信

技能
87. 团队协作
88. 分析
89. 设计
90. 实施
91. 测试
92. 重构
93. 沟通
94. 不熟悉团队选择的技术

环境/工具
95. 产品经理、测试或开发

使用无效的工具
96. 构建缓慢或不可靠
97. 第三方组件
98. 开发语言

99. 硬件/软件的领先度

还有呢?
100. 待你补充

你可能注意到列表中不是真的100个障碍(其实是99+?个)，这是因为没有一个确定的清单可以涵盖所有我们对障碍的定义。不管怎样，有这样一个现成的或者你自己维护的清单之后，你可以随时保持一种敏感性，去察觉是什么正在阻碍你的团队走上敏捷之路。