【敏捷那些事儿05期】敏捷实践中如何提高团队敏捷性？

╰半夏微凉° 2023-10-02 21:58 57阅读 0赞

#### 目录 ####

*  开好四会
 *   *  一、每日站会
 *  二、计划会
 *   *  三、评审会
     *  四、回顾会
 *  用户故事的故事
 *   *  用户故事
     *  验收标准
     *  外部质量和内部质量
     *  故事和任务

--------------------

熟悉完Scrum的全景，我们来重点分享一下Scrum中的四会和相关用户故事，从实际出发，看看究竟如何用这些工具提高团队的敏捷性！

## 开好四会 ##

### 一、每日站会 ###

每日站会，无论是否实践敏捷、是否实践Scrum，这个会团队都在开，但是会议最终是否达到效果了呢？

每日站会会让团队成员讲三件事情，分别是：

*  昨天做了哪些事
 *  今天准备做什么
 *  有没有什么困难或者问题

按照敏捷价值观，这三件事其实是不必要的，因为所做事情都是可以由团队成员自行去决定。

但如果整个团队敏捷程度并不是很高，那么不妨在每日站会上从这三件事入手来进行这方面的实践。

要开好每日站会，就需要做好以下几点：

**1. 养成习惯**

如果以前我们的团队并没有开站会的习惯，项目经理或产品经理则需要进行提醒。

在初期和团队成员还不熟的情况下，我们可以在企微的日历里设置会议提醒。整个团队经过一两个迭代之后，这个习惯其实很快就可以养成。

到了后期，会议几点钟开可以由团队自行决定，只要正常推进即可。

**2. 时间管理**

每日站会对时间的把控非常严格，**建议在15分钟内完成站会**，大家千万不要把每日站会开成了讨论会。

当成员在讲遇到什么困难、该怎么解决的时候，如果是一听就知道该怎么办、几句话可以说完的，在站会上就可以及时沟通。

如果是陷入到一些技术细节，比如某个具体的技术方案，需要花很多时间进行讨论，这个时候，会议的主持人最好打断讨论，仅保留相关人员在原地参与讨论。

比如一个七人团队，该技术方案的讨论可能需要其中的三个人参与，那么15分钟的站会结束后，就让这三个人留下来做详细的讨论，不再占用大家共同的时间。

**3. 任务管理**

任务管理比较好的做法就是主持人把自己的电脑接到大屏上，在大屏上展示出每项任务的进度。

此外，如果本来就有白板、贴纸，也做了泳道图，则可以在会议过程中一边开会一边更新相对应的泳道图。  
![在这里插入图片描述][17566285fc8b45dfaa3236d5b17c2855.png]

--------------------

## 二、计划会 ##

**计划会开在每个迭代启动之前，最好是迭代的第一天**。比如眼下是两周的一个迭代，那么可以在第一周的星期一上午启动计划会。

在计划会中必须要有需求的提供方出席这一次会议，比如产品经理或者BA。

计划会的目的其实就是**让需求的提出方给整个团队成员提供足够多的信息**，包括每个需求的点该怎么样进行细化。

这样一来，在整个迭代过程中，所有的团队成员就可以十分清楚知道自己在这个Sprint当中需要做的事情。  
![在这里插入图片描述][0822e8bd9f1140b8bd7f10d0176ee0a3.png]

此外，如果能说清楚需求，产品经理也可以放心大胆地让整个团队成员在迭代过程中去冲刺。

计划会上最重要的事情，就是**对产品列表里的待办事项进行优先级排序**，把能够最快实现客户价值、可以交付客户价值的事项提取到Sprint的代办列表里面的前列。

要开好计划会，就需要做好以下这点：

**范围、进度**

计划会的任务就是对本次Sprint的范围以及工作进度、工作时间进行确定 。

如果整个Sprint的团队已经定义好了是以两周为周期的迭代，那么每两周就要开一次计划会。

### 三、评审会 ###

在一个迭代结束的时候就需要去开评审会。

**相关方**

评审会最重要的就是让尽可能多的相关方参与进来，特别是提出需求的业务方，甚至是客户。

在迭代结尾的时候，我们就去demo该迭代的产出物，让相关方进行一个评审。

如果有需要改动的地方，及时建立相应的故事或者任务，并把它加到下一个迭代里， 立马做出相对应的改进。

### 四、回顾会 ###

回顾会是现实场景当中不太好开的一个会，可能因为技术同学普遍比较内敛吧~不大喜欢表达，所以需要项目经理或产品经理需要花一定的时间去引导。

此前在我所带的项目里面，一开始大家确实都不大愿意说话，我就给每个人发了一个便签，让大家**在便签上把他所认为的整个团队在这次迭代当中做的好的写三点，做的不好的再写三点。**

随后在会上我们把这些便签进行收集，贴到白板上，由会议的主持人，或者Scrum Master，对整个团队提出的这些好的和不好进行归类。

**不好的点需要大家集体进行一个讨论，最后达成一致的解决方案。**

比如在我们此前的迭代回顾会里，我们发现团队当中因为要培养应届生，所以代码质量不太好，那么在回顾会里边提议我们需要加强代码质量。

团队随后就达成一致，在下周会启动一个周期性的代码审查。比如周四下午，确定了一个时间，那么整个团队就会follow我们一致达成的解决方案。

**下面我们来了解一下与Scrum相关的用户故事！**

--------------------

## 用户故事的故事 ##

### 用户故事 ###

用户故事是一种描述需求的技术，所有的可以给用户创造价值的工作我们都可以把它写成用户故事。  
![在这里插入图片描述][5a4cfd2078f44a65b63dec9885c6ea73.png]

在Scrum里面，用户故事一般都是固定的三段式的写法：**我作为什么样的角色，我想达到什么样的目标，以便得到什么样的价值或有什么样的收益。**

这有点像八股文。

关于用户故事，按我个人的习惯，我会坚持用户故事的这种三段式的写法，建议大家尽可能也尝试以这种三段式的方式来写。

因为在写的过程中，首先会很明确的知道这个功能是由哪个用户角色来使用的。此外，**我们还可以通过这样的三段式明确需求的价值。**

这样就方便我们在Sprint的计划会上对相应的用户故事的优先级进行排序，**用户价值最高的我们就最先把它完成，最先交付给客户。**

### 验收标准 ###

用户故事里，很重要的就是需要去定义好验收标准。

**完成的定义（DoD）**

\*\*验收标准里面非常重要的组成部分就是DoD，也就是对完成的定义。\*\*同时，这会因团队而异，每个团队可能对完成的定义不一样。

一个用户故事到底怎么样叫完成呢？是开发人员把代码写完，能够编译通过交到代码库算完成？还是说需要测试通过没有bug算完成？或者是客户觉得没问题了，这个故事就算完成 ？

虽然完成的定义是不一样的，**只要团队内部达成一致就可以。**

以我自身的经验，绝大多数情况下我们会把测试通过作为完成的定义。比如登录这个功能进行测试，测试完，没问题了，这个时候就认为这个故事是完成了。

**由此提出一个问题：**

既然测试没问题了，用户故事已经完成，就需要关闭。\*\*那是应该由测试来进行关闭，还是应该由产品经理来进行关闭？\*\*这个问题大家也可以思考一下。

### 外部质量和内部质量 ###

项目质量里面还有个很重要的概念，就是外部质量和内部质量。

**\# 外部质量：**

就是提供给用户的系统本身的质量，比如说这个系统是不是很慢？是不是很容易出错？

**\# 内部质量：**

这是用户看不到的，但是会影响系统的一些问题。

比如这个系统的设计是不是本来就有缺陷？它的测试覆盖率是不是不够？代码稳定性是不是不强？这些用户其实是看不到的。

**在验收标准里，为什么要明确的把内部质量定义好呢？**

内部质量很高的情况下，外部质量也有可能很差。

也就是说我的设计很好，测试覆盖率很高 ，代码稳定性很强，但是我的系统功能有问题，客户不满意， 这就是外部质量可能会不好。

但是**如果内部质量很差，那外部质量肯定会很差**，所以我们需要把内部质量写进验收标准。

团队里边的所有人都是内部质量的负责人，他们所做的每一步工作，**他们提交的每一行代码都需要去保证内部质量**。但并不是说外部质量是不需要保证的。

在敏捷里面有这样一个思路，我们为了去赶开发进度，有时候实际上是可以牺牲一定的外部质量的。

怎么去理解这一点呢？

一般一个列表页面会有一堆搜索框，这种搜索框在一些复杂的搜索情况下，可能有十几个搜索条件。

如果要去交付，在第一个交付的版本当中，我可能只去**定义最简单的搜索框**，甚至在比较简单的列表页面里面连搜索都不做，就**先把列表做完**。

把这个页面做完后，用户其实是可以使用的，进而可以看是不是需要搜索框（列表里的数据是否正确其实是可以通过翻页的方式去浏览）。

这其实就是一种牺牲外部质量去赶发布速度的例子。当然**在后面的迭代当中还是会把一个完整的搜索查询条件做完**。

### 故事和任务 ###

Jira里所建的类型都叫issue, 也就是问题。而issue还可以分为不同的类型，比如故事类型、任务类型。

**所有可以给用户创造价值的工作，都可以用用户故事的方式编写出来。**

但在我们日常的开发过程当中，有很多的事情是用户看不到的，比如说架构设计、代码审查，甚至是PM要做的汇报、一些比较重要的会议的会议纪要等。

这些具体的事情并不产生用户价值，所以在我们的产品待办列表和Sprint的代办列表里, 除了要写满足用户需求的用户故事，很可能还要去\*\*添加一些技术故事。\*\*这些技术故事就包括一些技术调研、架构设计、代码审查等等。

而像一些像做ppt汇报、写会议纪要这样具体的工作， 我们就**以任务的方式把它写出来。**

所以我们会看到一个完整的产品待办事项列表和一个Sprint的待办事项列表，里面不只有用户故事，还会有团队要做的其他工作，我们都会把他们放到这个待办列表里面去。  
![在这里插入图片描述][e4e53fa8d3d341a5a193c954e0433359.png]

以上就是从迭代、Scrum里边的会议以及用户故事这几个点，具体讲了一些敏捷的实践。

这里并没有完整的去讲整个Scrum框架，目的也只是想把里面一些常用的实践分享给大家！

**大家可以在还没有开始实践这种Scrum的情况下，就把这些技术和方法先开始用起来呀~**

[17566285fc8b45dfaa3236d5b17c2855.png]: https://img-blog.csdnimg.cn/17566285fc8b45dfaa3236d5b17c2855.png
[0822e8bd9f1140b8bd7f10d0176ee0a3.png]: https://img-blog.csdnimg.cn/0822e8bd9f1140b8bd7f10d0176ee0a3.png
[5a4cfd2078f44a65b63dec9885c6ea73.png]: https://img-blog.csdnimg.cn/5a4cfd2078f44a65b63dec9885c6ea73.png
[e4e53fa8d3d341a5a193c954e0433359.png]: https://img-blog.csdnimg.cn/e4e53fa8d3d341a5a193c954e0433359.png