Mike Cohn专栏

Scrum

ScrumMaster指南:Scrum Master的情景领导力模型

作者:Mike Cohn

译者:李洁(Jerry Li)

审校:廖靖斌(Eric Liao)

本文由Mike Cohn授权翻译,未经许可请勿转载

 

几年前,我把几个高尔夫球打到湖里了,一起打球的朋友给了我一些建议。现在那位朋友打高尔夫球已经不比我强了,但他仍在没完没了地建议。他说:“问题是,你得把球打得更远。” 他这样说还不如告诉我,“问题是,你打了很多次才把球打进球洞。”  我当然需要打得更远。但怎么做到呢?

类似的,你们可能也被告诫过——ScrumMaster、敏捷教练或敏捷项目经理都可能告诫你——敏捷项目管理是要领导团队而非管理团队。

Read more

Scrum_tp

团队需要Scrum Master做这六件事

我一直在和你的团队交流,好吧,可能不是你正在带的团队,而是很多和他们类似的团队。这些团队跟我分享了他们期待Scrum Master做的六件事情。

1. 帮助他们理解职责边界

敏捷团队被告知他们是自组织的。但是,这并不意味着每个企业的自组织都完全一样。比如说:

  • 团队是否有权将团队的技术需求添加到Sprint中?
  • 团队是否可以决定谁在这个团队中?
  • 团队是否可以在不询问Scrum Master的情况下改变他们的Sprint长度?
  • 在未经许可的情况下,团队可以在工具、团建活动或任何其它事情上花多少钱?

等等等等,这个列表可以无限长。
Read more

Scrum_TP

给Scrum Master的十个建议,你值得拥有

你想成为一个优秀的Scrum Master吗?

我想是的,除非你是一个产品负责人或者其他的角色。我作为一个Scrum Master已经有20多年了,这些年,我给出了很多很多的建议,也收到了很多建议。我甄选出了我认为最棒的十个建议给大家。

1. 如果没有和团队商议,请不要代表团队做任何承诺。

作为一个Scrum Master,你没有任何权利代表团队接受需求变更,不管它有多小。即使你可以完全确定团队可以搞定它。你可以这么来回答:“我需要和团队沟通后再确认是否可以接受。”
Read more

scrum会议

Scrum团队的会议太多了吗?

在进行CSM(认证Scrum Master)授课时,我听到的最常批评之一是“Scrum团队有太多的会议了”。

由于Scrum具有每日Scrum站会、Sprint计划会议、Sprint评审会议、Sprint回顾会议,甚至可能还有产品待办列表精化会议,也就不难理解为什么人们会这样评论。

但是让我们看看这是不是真的。
Read more

Scrummaster

Scrum Master角色可能消失吗?

当一个团队逐步成长的时候,Scrum Master投入的时间越来越少,但是一个团队可以完全没有Scrum Master吗?

Scrum Master通过教练、指导、引导团队,使得他们的团队开发出伟大的产品。对一个初次接触Scrum的组织中的一个新的团队而言,这是一个具有挑战性而且耗时的工作。
Read more

scrumcn_userstory

用户故事,史诗故事和主题故事

敏捷团队喜欢以一种刚刚好的方式处理需求。我们采用最低限度地、逐渐细化并保存在产品待办项(Product Backlog)中的特性描述文字,来替代传统长篇大论的需求文档。

我们发现用户故事是最好的描述方式,这种形式能够捕获到特性足够多的信息,并促进产品负责人和团队在后续进一步交流。用户故事是从人(通常是系统的用户或者客户)渴望新功能的视角来对特性进行描述。

用户故事一般会采用以下这种简单格式进行描述:“作为【某类用户】我【想要/能/需要…】以便【满足什么用户价值】”。尽管这种描述格式有其优越性,但只要能围绕着故事进行交流,用户故事可以以任何形式进行描述。
Read more

Scrum中文网

反对迭代0:停止拖延,开始迭代

很多项目都不会一开始就完全就绪——例如,需要分配人员和准备工作。为了处理这些项目开始前的任务,很多团队使用了“迭代0”的做法。虽然理解其由来,但我仍然感到担心。以下是我的理由。

停止“迭代0”的三个理由:

首先,尽管很难相信,但绝大多数的项目都是可以立刻启动的。我所听过的所有声称需要在Scrum项目启动前完成的事项有:需要组建团队,包括调配人员到项目上或雇佣新人;需要获取或者设置硬件设备;需要写一个初始的产品待办列表(即使只是高度概要的)。然而现实情况是:诸如技术环境、初始产品待办列表之类的事项都可以在第一个迭代中完成(一个完全是正常的和传统模式的迭代一),同时至少还可以交付了某些潜在可发布产品增量。
Read more

Scrum中文网

故事点数是对工时的度量

尽管我尽了最大努力来澄清,但是仍然流传这样一种说法:故事点数是对复杂度的度量。这种说法是完全错误的。真相是,除非复杂度已经对完成用户故事的工作量造成影响,否则其复杂度并不重要。

让我举个例子。假设你和我一起观察离一栋建筑物的距离。你认为需要走5分钟,而我因为正拄着拐杖所以需要走10分钟。

你和我不能在花费时间上达成一致。对你来说走5分钟是对的,而对我来说走10分钟也是对的。如果采用分钟、小时、天等时间单位进行估算,问题就会比较棘手——由于我们处于不同的生产率水平,这会导致我们无法在估算上达成一致。
Read more

Scrum_tp

放弃在每日站会上按成员逐个发言

很少有Scrum文献会说每日站会需要按团队成员逐个发言。然而大多数团队恰恰都是这样做的,但这可能不是最好的方式。

当每日站会是逐个团队成员进行的时候,团队成员会很容易丢掉所讨论的待办事项的上下文。例如,可能第一位团队成员正在处理前两个产品待办事项,第二位团队成员正在处理第二个和第五个产品待办事项,第三位团队成员也在处理其中这些待办事项中的一个,同时花费少量精力处理另一个无人的待办事项。
Read more