作者:foruok

Scrum 是当前最流行的敏捷软件开发 实施框架。

Scrum 起源于软件开发项目,但它适用于任何复杂的或是创新性的项目

可能有的小伙伴并不熟悉 Scrum ,我们先看下 Scrum 中文网的描述:

Scrum 是一个用于 开发和维护复杂产品的框架 ,是一个**增量的、迭代的 开发过程。在这个框架中,整个开发过程由若干个短的迭代周期 **组成,一个短的迭代周期称为一个 Sprint(迭代),每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。

Scrum 使用产品 Backlog(一个按照 商业价值排序 的 需求列表) 来管理产品的需求,列表条目的体现形式通常为用户故事Scrum 团队总是先开发对客户具有较高价值的需求。

为了挑选出 最高优先级的需求进行开发,Scrum 团队在Sprint 计划会议经过讨论、分析和估算,得到相应的任务列表,我们称它为 Sprint Backlog。在每个Sprint(迭代)结束时,Scrum 团队将递交潜在可交付的产品增量。

Scrum 流程如下图:

图0:我的每日站会是怎么演变成鸡肋的

每日站会 是 Scrum 实践中最具代表性的一个形式,也是我们今天讨论的话题。

每日站会的目的

Scrum 的团队是一个 **自组织 **的团队。每日站会,是团队面对面沟通,和团队自组织的体现,是 Scrum 过程,进行 **每天的检查和调整 **的环节。以期达到:

  1. 团队商量决定谁做什么(不能有领导人物指派),为当天做出一个计划
  2. 团队沟通状态,了解现状,发现障碍
  3. 团队回顾昨天的工作,做调整,持续改进

基本规则

相信所有践行过每日站会的人,都对如下规则印象深刻:

  1. 会议最好在 **15分钟内 **完成(或者每个人的时间不超过一分钟)
  2. 每个人回答三个问题:
    • 我昨天完成了什么任务
    • 我今天打算做什么任务
    • 我遇到了哪些障碍或困难
  3. 同一时间只能有一个人发言,任何跑题的讨论,需要被 Scrum Master 阻止

健康站会的效果

据说,一个有效执行 Scrum 的团队是这样的:

早上 scrum 站会前,团队是安静的。站会结束后,团队很活跃,中午饭前慢慢沉寂下来。午饭后,团队再度开始活跃,直到下午下班前又慢慢安静下来。

我的实践是怎么演变成鸡肋的

单看以上对健康站会的描述,我会以为,我曾经经历过的 Scrum 实践是非常有效的——完全符合上文的描述。但实际情况并非如此。

第一天站会

领导没有说话,大家也都很沉默,低头看地板或者盯着白板,面无表情。

领导说:“那就从小A开始吧!”

小A:“我昨天做的事情是:1,2,3;今天计划做:4,5,6。但是我昨天下班前发现了一个 bug,这个 bug 会导致我的 4,5,6 都没有办法开始。这个 bug 所在的部分之前是由小B 负责的,小B 今天把 bug 改好了,我的工作才能开始。”

小B:“怎么可能呢?这部分之前都测过的,如果有这个 bug,测试根本不可能通过,我最近也没动这部分代码,怎么可能会有 bug 呢? 再说我今天计划好了三件事情,时间排的满满的,根本没时间解 bug。小C 这两天在做某某功能,和这部分相关,是不是小C 做的新功能引起的?”

小C 马上很警觉:“什么bug?抱歉刚才没听仔细。”

小A 把 bug 现象又重新描述了一遍。

小C:“怎么可能会抛出这个错误呢?你用的是什么数据?哪个浏览器,什么版本?”

小A一一回答。

小C 做沉思状:“你说的这个情况有点奇怪,我的代码应该不会引起这个问题。你有没有 debug?Log 上怎么说?”

小A 刚要回答,领导抬手看了下表:“是这样啊,我们 scrum 的目标是平均每人控制在1分钟左右,现在光讨论小A 的问题已经用了6分钟。接下来每个人只说:昨天做了什么,今天计划做什么,遇到了什么问题。不过多谈论细节,好吧!”

小A 作罢,领导说:“小B,该你了!”

小B 按照领导的要求,快速做了更新,包括自己遇到的困难。但是鉴于小A 的经验,没有人对小B 的困难做任何回应。

然后是 小C,小D,小E……

所有人更新完,领导又看了下表,“很好,我们今天的时间控制在了15分钟,虽然比一人一分钟多了点儿,总体还是不错的。大家还有什么问题吗?”

小A:“那我刚才说的那个 bug 怎么办?那个问题不解决,我今天的工作没法开展。”

领导:“你找小B,小C 讨论一下吧。发挥下大家的主观能动性。”

小A喊:“小B,小C,你们能过来看一下吗?”

小B:“等会儿,手头有个急事儿处理一下。”

小C:“我去接个水噢。”

十分钟后,小B 站在了小A 的电脑后,说:“到底是什么问题,再重现下?”,小C 抱了个大水杯也站过来。

两人在小A 身后,一会儿要求打开这个文件,一会儿要点下那个按钮……,大概一个小时后,俩人都摇着头,表示这个问题很奇怪,跟自己那部分代码都没关系。最后语重心长地对小A 说:“你自己再看看吧,实在不行,找大牛帮你看看。”

小A 绝望地扭头,正要喊大牛,却看到他头带着耳机正和国外的同事开会,只好作罢……

第二天站会

仍然沉默,过了半分钟,领导说:“还是从小A 开始吧。”

小A:“我昨天看了下那个 bug,找小B,小C讨论了,可是没有头绪,现在还在debug,任务4,5,6也没办法做。”

领导:“这样下去,我们这个 Sprint 安排的工作风险很高啊。老D(大牛),你帮小A 看看吧。”

老D:“今天跟美国的架构师约了个会,昨天的问题还没讨论完,今天还得继续。这个不讨论完,我们下个 Sprint 的任务没办法安排啊。我尽量挤时间帮小A 看看吧。”

领导:“好的,辛苦你了老D。小A,你今天再花两个小时 debug 问题,还找不出原因,就先去帮小B 或者小C 的忙吧。”

小A 低下头:“好吧”。

一个星期后,Sprint 结束。

领导:“今天是 Sprint 最后一天,我刚看了下我们这个 Sprint 的进度,落后了很多。是什么原因呢?大家分别说说,自己的任务完成情况。小A,还是你先说。”

小A……

你的破法

你参与过 Scrum 实践吗?

对每日站会有什么想法?

如何破解上面的这种鸡肋实践?

欢迎在本文后留言,说出你的看法。

余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

电子邮件地址不会被公开。 必填项已用*标注