每日站会怎么开才好?——你的站会姿势正确吗?

简介: 今天我们讲讲如何利用站会,更好地实现促进团队有效协作和聚焦,促进价值顺畅流动和交付,同时及时的暴露问题和风险。 站会的目标 说到站会,人们最熟悉的Scrum站会,典型的形式是团队围成一圈,依次回答三个问题:昨天做了什么?今天准备什么?有什么阻碍或问题?通过站会,Scrum团队成员了解其他成员的工作,从而更好地协作,达成迭代目标。

211

扫描上述二维码或点我直达 免费领!

今天我们讲讲如何利用站会,更好地实现促进团队有效协作和聚焦,促进价值顺畅流动和交付,同时及时的暴露问题和风险。

注:精益看板方法视频教程请前往:https://yq.aliyun.com/live/717

站会的目标

说到站会,人们最熟悉的Scrum站会,典型的形式是团队围成一圈,依次回答三个问题:昨天做了什么?今天准备什么?有什么阻碍或问题?通过站会,Scrum团队成员了解其他成员的工作,从而更好地协作,达成迭代目标。

看板方法应用得当,可视化价值流实践执行到位,以上三个问题完全可以清晰地展示在看板上,所以没有必要再回答这些问题了。那站会的目标是什么呢?

回到精益看板方法本身的目标:顺畅和高质量地持续交付有用的价值。相应的,看板站会要聚焦于价值的流动,而非个人工作。

站会的目标是:促进团队有效协作和聚焦,促进价值顺畅流动和交付,同时通过站会同步需求进展和暴露问题及风险,把可视化价值流实践落地到位。

站会的前提

在建立了如下图的精益看板系统的可视化价值流(以云效看板为例),明确流转规则和限制在制品数量的三个实践之后,还需要管理价值流动和建立效能反馈闭环并持续改进。管理价值的流动具体包含管理价值流动过程,价值的输入和价值的输出,关于管理价值流动过程的一个很重要的实践就是每日看板站会。
关于如何建立精益看板系统,后续云效会有专门的文章来详细讲解。

1

云效看板示例:入口

站会组织形式

1、频次:每天(每个工作日),时长不超过15分钟,一般在早上,具体时间团队可根据实际情况调整,建议9:45或10点开始;
2、三个相同:同一个团队在同一时间、同一地点在看板前进行日站会,形成固定的节奏后,会变成团队的习惯;
3、协调人:团队成员站在围在看板前,由一位协调人来带领团队从右往左(⬅️)逐列走读看板;协调人可以固定,也可以轮流进行;
4、电脑:为了让站会更加聚焦和高效,负责投屏和记录的同学可以带电脑,其他人不需要带电脑;

站会前:需求和任务的状态已更新

1、团队已按照统一优先级的规范更新需求的优先级,辅助优先级,状态、期望日期等
2

2、开发同学按照实际情况更新需求和任务的状态(任务向需求对齐)。

需求负责人负责协调把开发中的需求拆分成任务(如下图),并协调需求从开发完成,测试,直到发布完成为止;
已拆分好的任务需指派到个人,任务的颗粒度在1-2天的工作量,确保每天都有看得见的进展 ,及时暴露风险和问题;
任务责任人已更新好任务的状态和截止日期;
如有外包-接口人合作:外包同学也需要在站会前更新状态,接口人按照流转规则进行状态流转。

3

站会重点关注的信息

站会上不需要检视每一张卡片,本着“促进价值顺畅流动和交付” 的目的,我们要重点关注影响价值流动的问题和阻碍项,如下图所示,绝大部分问题会标记橙色或红色,可以很清晰地体现在云效看板上。

4

瓶颈和队列:某个环节不顺畅时,需求积压形成队列,这就是瓶颈所在,瓶颈是站会第一重点关注点,因为系统的流量往往是由瓶颈决定,只有解决了瓶颈问题,价值才能顺畅地流动。看板上的表现就是某一列的需求卡片数量特别多。

关键的缺陷:缺陷会阻碍需求的流动,而且缺陷多容易出现需求积压,从而阻碍其他需求的流动。阻塞需求流动的缺陷需要及时解决,期待做到缺陷日清(缺陷发现后24小时内解决,甚至当天就解决),在Fixed状态(指缺陷已修复,待提出缺陷者验证)的缺陷需要及时验证和关闭。保持缺陷及时发现即时解决和关闭,保持存量缺陷保持低水位。站会时需要抽1-2分钟过一下整体缺陷的状况。

重点关注的需求:指涉及重点商业利益或风险的重点需求,看板上会用红色的标签来凸显。

阻碍和问题:指因外部(如依赖)或内部(如设计缺陷)原因无法正常流动的需求。团队需关注被阻碍的需求,跟踪和推动问题解决,及时恢复它们的流动。看板上会红色的阻碍项来标记。

到期或即将到期的需求:部分需求有明确的完成时间要求,例如存在对外承诺的需求。如果它们即将到期或已经到期,就需要特别关注,以确保承诺的达成。看板上快到期的需求会用橙色凸显时间,已到期的需求会用红色凸显时间。

中断:指某个步骤供给不足,价值流出现中断,如上图中,就绪(待开发)这列没有需求,此时上游队列需要尽快供给到该列。

未反应在看板上的问题:走读完看板,还需要添加一个问题:“是否有为反映在看板上的问题需求沟通”。团队当然需要关注没有反映到看板上的问题,同时,团队和站会的协调人需要有意识地思考,这类问题是否可以和应该反映在看板上,以提高可视化和执行的效果。

站会中:促进价值顺畅流动

站会上,团队按照"站会重点关注信息6+1"从右向左检视各列,促进价值顺畅流动,同时要避免在一个问题上花费过长时间,耗时长的讨论要放在会后小范围进行。

15人以内的团队,站会要能在15分钟内完成,在现实中,效果不好的站会,往往耗时会比较长。

站会中讨论带来的变化,需即时更新到看板上,如有问题,也需求及时记录。

下图给出了站会中应该做到和应避免的问题:

5

还需要明确的是,站会只是团队沟通的一个场景,更多的沟通要在平时和更小范围内发生,而不是过度依赖于站会。

站会后:信息透明,风险和问题跟进

站会需要达成的成果:

看板已处于最新的状态,反映站会讨论的结果
识别阻碍需求流动的问题,并现场解决或则安排会后跟踪的Action
团队成员了解项目的整体进展和状态
团队成员清楚工作的优先级

会后小范围讨论需求较长时间才能解决的问题。

总结:

站会的目标是:促进团队有效协作和聚焦,促进价值顺畅流动和交付

站会要以价值交付为线索,从右向左检视需求的状态,聚焦于发现和处理价值流动中的问题

不应该依赖站会检查每个人的工作,价值交付的状态和问题应该已清晰的体现在看板上,良好设计和应用的看板是高效站会的基础

更多的协作应该即时发生,不应该完全依赖站会来进行团队协作

一个好的站会,帮助团队了解整体的价值流动状况,促进有效的协作,并即使处理价值流动的问题,保障价值顺畅流动。

附1:站会Checklist:

需求和任务的状态在站会前已更新;
提醒带电脑同学合上电脑,只有投屏的同学使用电脑;
从右往左检视各列,按照6+1类关注点进行;
开发中的需求数量是否已超过卡片数量的限制;
开发中任务是否向需求对齐;
需求是否按照既定的流转规则进行流转;
单独快速过一下缺陷的总体状况,保持缺陷库存低水位;
记录要跟踪的问题和依赖项;
会后小范围讨论遗留要解决的问题;

附2:站会中会碰到的问题:

Q:在Scrum站会中,典型的形式是团队围成一圈,依次回答三个问题:昨天做了什么?今天准备什么?有什么阻碍或问题?为啥看板上不需要回答这三个问题了呢?

A:看板方法应用得当,可视化价值流实践执行到位,以上三个问题完全可以清晰地展示在看板上,所以没有必要再回答这些问题了,同时我们需要按照需求来组织站会,关注价值流动,而不是按人来组织站会。

Q:开发同学站会上讲了很多,可产品经理同学却听不懂,同时对需求的进展也不太清晰

A:按照Scrum的方式,回答三个问题,开发同学往往说的是技术实现和细节,产品经理自然会听不懂。需求作为价值是产品经理的输入,看板关注的是价值流动,不是任务的完成情况,需求的状态和问题可以很清晰地在看板上体现出来,同时在开发中的需求也会拆分成各端或各模块的任务,拉通技术各角色之间的协同。这样既可以看到价值的流动,也可以看到任务的进展和对齐,产品和开发同学都可以一目了然知道目前的进展与问题。

Q:为啥看板要从右到左检视各列,而不是从左到右检视呢?

A:从右往左,一方面体现价值拉动的方向,另一方面是为了更好地贯彻“暂缓开始,聚焦完成”的原则,让接近完成的需求尽快的完成,而不是开始更多的需求开发。譬如测试中发现的Bug,从右到左更方便优先解决Bug。

Q:站会时间到了,但还有个别同学没有到,是等他还是不等?
A:团队需要共识此类事情发生的机制,避免这样的事情发生。当确实有个别成员迟到了,一般建议站会还要在固定的时间和地点进行,当然团队对于迟到可以有团队处理的办法,譬如邀请迟到的同学给大家买水果吃等等。

Q:团队处于两地,甚至多地,站会如何开?

A:云效电子看板的好处就是便于异地开发,各地成员都打开看板页面,同时用电话会议的方式接入,进行异地站会。目前云效看板已可以做到需求卡片移动后瞬间同步。

Q:两个需求都进行了近一半却都不能提测?如下图

A:图中用红框圈起来的两个需求,一个是前端任务已完成,后端任务在处理中,另一个是前端任务在处理中,后端任务已完成,这总情况需要避免,团队需要聚焦其中一个需求,让其快速完成,而不是启动两个,让两个都只是完成一半或90%。

6

附3:团队开站会的照片:

云效协作域团队
7

信息平台诉讼团队
8

阿里云飞天一部工业大脑
9

CEM客户运营平台的物理看板的站会
10

站会上很多人都带电脑,效率就会相对低,不建议出现这种情况。
11

作者介绍:

洪永潮(花名:舍卫),现就职于阿里巴巴研发效能事业部阿拉丁团队,先后负责手猫、手淘、天猫新零售等阿里内部多个部门的效能提升,曾担任MPD、GIAC、RSG、 DOIS等大会的讲师。

关于云效:

云效,一站式企业协同研发云,源于阿里巴巴多年先进的管理理念和工程实践,提供从“需求->开发->测试->发布->运维->运营”端到端的协同服务和研发工具支撑。支持公有云、专有云和混合云的协同研发,助力企业产品快速创新迭代和研发效能升级。

云效产品:

项目协作 https://www.aliyun.com/product/yunxiao-project

代码托管 https://promotion.aliyun.com/ntms/act/code.html

Maven公共仓库 https://m.aliyun.com/markets/aliyun/ali-repo

制品仓库 https://m.aliyun.com/markets/aliyun/repo-manage

持续交付 https://www.aliyun.com/product/yunxiao-cd

测试平台 https://www.aliyun.com/product/yunxiao-testing

_

相关文章
|
新零售 测试技术 持续交付
阿里如何定义团队的研发效能?
作者:何勉,阿里巴巴研发效能部资深技术专家 相关阅读:都996了,研发效能还是提不起来,关键在这里 因为身处研发效能部,我接触了公司很多产品技术团队。他们几乎都把研发效能提升列为了本财年的重要目标,大部分还为此成立专项。
18991 3
阿里如何定义团队的研发效能?
|
人工智能 安全 Devops
让研发规范管得住,在流水线之上做研发流程
研发规范的目标,是为了解决或降低出现软件危机的风险。但传统流水线受限于工具的定位,无法解决研发规范的落地问题,需要在更高的层面来解决。阿里云云效团队经过内部启发后推出的新产品:云效应用交付平台 AppStack 给出了解决方案,快来使用体验吧!
79685 7
|
人工智能 运维 Kubernetes
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
研发效能提升不知从何下手、一头雾水?阿里资深技术专家一文为你揭秘研发效能提升的系统方法
4828 1
深度 | 从DevOps到BizDevOps, 研发效能提升的系统方法
|
Devops 测试技术 持续交付
阿里巴巴DevOps实践指南(五)| 业务驱动的协作
明确需求层次以及每个层次承载的价值之后,接下来要做的是定义每个层次的协作过程,最终服务于“顺畅高质量地交付业务需求”这一目标。如何组织各个层次的协作,来达成这一最终目标?
阿里巴巴DevOps实践指南(五)| 业务驱动的协作
|
运维 Cloud Native 数据可视化
2018-2021,60+篇阿里研发效能提升干货,都在这里了
今天,正值2021的最后1天,我们精心盘点了2018-2021连续3年来,云效团队在研发效能提升方面输出的所有干货,希望对大家有所帮助。
5289 3
2018-2021,60+篇阿里研发效能提升干货,都在这里了
|
缓存 监控 架构师
开发流程规范
这是近期在公司做的一次分享,这几年的互联网开发,算比较幸运,团队一直践行完善这套规范,没有太多的阻碍,得益于公司整体氛围,以及团队对规范和写文档的不排斥,形成了良好的开发习惯 在这次分享后,发现好些大V也在谈规范,写文档,估计是前段时间阿里又发布了开发手册(华山版),借鉴于一下,对一些细节做些补充,整理出来
2698 0
开发流程规范
|
敏捷开发 移动开发 前端开发
如何开一场高效的迭代排期会 | 敏捷开发落地指南
如何开一场高效的迭代排期会,高效落地敏捷开发,先从这3个关键活动着手,通过本文你将了解到什么是敏捷开发、什么是双周迭代、如何高效地开展排期会,以及如何在云效项目协作·Projex 中落地排期会相关事宜。
2365 0
如何开一场高效的迭代排期会 | 敏捷开发落地指南
|
敏捷开发 前端开发 BI
好的每日站会,应该这么开 | 敏捷开发落地指南
高效落地敏捷开发,先从这3个关键活动着手。在敏捷迭代中,虽然迭代周期比较短,但依然需要对迭代过程进行有效跟进。如果在输入、过程、输出环节,没有要求,每日站会(迭代跟进)将会非常低效。好的每日站会,应该这么开!
1391 0
好的每日站会,应该这么开 | 敏捷开发落地指南
|
机器学习/深度学习 人工智能 达摩院
“洛犀” 端云协同AI平台,来了
在 “中国工程院院刊:信息领域青年学术前沿论坛上”,阿里巴巴达摩院、浙江大学上海高等研究院、上海人工智能实验室联合发布“洛犀”端云协同平台。
2031 0
“洛犀” 端云协同AI平台,来了
|
监控 测试技术 持续交付
通过度量把发版过程的不确定变成确定-构建闲鱼版本持续交付管道及度量 | 实践案例三
2018 财年初为了应对闲鱼业务和技术快速发展。闲鱼技术团队在云效中心敏捷教练的指导下闲鱼客户端的泳道研发支撑项目 kickoff。
1130 0
通过度量把发版过程的不确定变成确定-构建闲鱼版本持续交付管道及度量 | 实践案例三