Scrum敏捷实践集

用户故事

用户故事是否可以不写 “So that” ?

1. 背景

最近在微信群里,有一些关于用户故事书写的讨论,其中有一些观点

观点1:用户故事的格式不用完全按照标准格式那样,拘泥于形式。

关于格式这一点,不在这里讨论。

观点2:用户故事的 “So that” 必要性不大。

必要性不大的几个理由:
a) 企业已经运作很多年, 赚了很多钱了. (So that 强调的价值, 不大。)
b) 百人级别的产品总监,焦点在哪? (So that提不起他们的兴趣?)
Read more

Scrum_tp5

华为LeSS大规模敏捷案例分享

作者:吕毅,中国首位CST,LeSS认证导师
原文链接:https://yihuode.io/articles/324?from=timeline
原文主题:LeSS在华为 – 没有Scrum的LeSS

“没有Scrum的LeSS”描述了我们在大规模敏捷导入中从应用LeSS的组织设计元素切入 – 而非直接引入Scrum团队 – 的一次经历。自下而上的团队先行的方式虽然更常见,但是在大规模领域的导入中采用多少显得有些天真。相比之下这里呈现的组织先行的方式更接近在《LeSS:大规模Scrum》书中描述的LeSS导入指南“三个导入原则”之一:自上而下和自下而上并重来导入。为什么需要并重?因为合适的组织设计为后续辅导提供了坚实的基础,从而能放大辅导的有效性。我们在同一公司的两个不同产品开发部门都采用了这种方式。两个部门的规模不同,分别代表了LeSS和LeSS巨型的案例。

1. 背景

这个报告描述的是发生在2015-2016年期间华为杭州的两个产品开发部门的经历。我的工作是作为一个咨询师帮助他们的大规模敏捷导入。公司规模巨大,在产品开发上就有几万人。他们组织成业务线和开发部门,每个通常都有几百到几千人。之前也尝试过敏捷导入,只是多少有些偏差,比如他们实现的“迭代”事实上更象小瀑布,经常把测试和缺陷遗留到下个迭代;而“持续集成”更多只是每日构建和测试自动化,而非开发人员真正持续地集成他们的代码。
Read more

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

Spotify-scrum中文网1

Spotify敏捷模式详解三部曲第三篇:工程文化

摘要

在本系列文章的第一篇和第二篇,我们分别介绍了Spotify的敏捷研发团队和研发过程。

在本篇,我们将介绍Spotify的敏捷工程文化。

引言

Spotify通过文化和价值观来进行管理,在本篇中,我们从如下八个方面来介绍Spotify的敏捷工程文化:

一、 如何管理小队的自主性

二、 如何管理标准化

三、 如果做到以人为本

四、 如何管理部署上线

五、 如何管理创新

六、 如何管理失败

七、 如何处理浪费

八、 如何管理文化

一、 如何管理小队的自主性

Read more

Spotify-scrum中文网

Spotify敏捷模式详解三部曲第二篇:研发过程

摘要

在本系列文章的第一篇,我们介绍了Spotify的敏捷研发团队,以及它独特的组织架构。在本篇,我们将介绍Spotify基于敏捷开发和精益创业思维的产品研发过程。

引言

在本系列文章的第一篇,我们介绍了Spotify的敏捷研发团队,以及它独特的组织架构。Spotify的研发团队采用的是一种非常独特的组织架构,如下图所示:

屏幕快照 2019-01-02 上午10.26.32

整个研发组织有多个称为“Tribe部落”的单元组成,每个部落中包括多个“Squad小队”,从横向的维度,把拥有类似技能的人放在一起形成“Chapter分会”和“Guild协会”。 Read more

Spotify-scrum中文网

Spotify敏捷模式详解三部曲第一篇:研发团队

引言

2018年4月,来自北欧瑞典的音乐流媒体公司、百亿美元独角兽Spotify创造了历史,它成为了当代上市公司当中,第一家通过“直接上市”的方式在美国纽交所成功挂牌的公司。这家公司改变的可能不仅是人们听音乐的习惯,而且还有企业进入资本市场的方式。截至2018年初,Spotify拥有1.59亿的全球活跃用户数量、7000万的付费用户数和46%的付费用户增长率。Spotify是当之无愧的音乐流媒体领域的霸主,排名第二的苹果音乐,无论是付费用户还是活跃用户,都只有Spotify的一半。

是什么成就了Spotify?他们是如何打造出这么一款深受用户喜爱的产品的?幸运的是有Henrik Kniberg的存在。Henrik Kniberg是全球知名的敏捷和精益教练,也是一位多产的作家,他参与了Spotify公司的这一过程,并写下了多篇文章,向外界揭开了Spotify公司的神秘面纱。

笔者通过自己的收集和整理,梳理出了Spotify敏捷模式的整个过程,并通过一系列的文章呈现给大家。在本期的文章中,笔者将首先介绍Spotify的研发团队。

组织架构

Read more

影响地图海报

如何使用Leangoo脑图实现影响地图

影响地图是一个工具,它建立了业务价值到产品功能的映射。本文将介绍如何通过Leangoo脑图创建影响地图,并且基于影响地图进行需求规划。

Leangoo 的5.8.12版本发布了Leangoo的脑图功能。Leangoo脑图是一个共享的思维导图,它具备了思维导图的所有属性,但它绝不仅仅是一个思维导图,那么Leangoo脑图有什么不一样呢?主要有如下三点:

1, Leangoo脑图是项目团队实时共享的,不需要再通过导出分享给项目中的其他人。

2, Leangoo脑图是可以支持多人协作。

3, Leangoo脑图的节点和Leangoo看板上的卡片是一样的,支持富文本文档,可以添加附件,可以添加检查项,进行评论。所以,它可以用来代表需求、任务、测试或者一篇文档等等。而且每个节点都可以引用到看板上,支持批量引用。

有了这些特性, Leangoo脑图就十分强大了,针对敏捷研发,Leangoo脑图有很多实用的场景,比如实现影响地图、用户故事地图、知识管理、测试案例的管理、迭代回顾等等。我们将通过一系列的文章来介绍这些实用场景。本文,我们先从影响地图开始,介绍如何实用Leangoo脑图来实现影响地图。

什么是影响地图?

Read more

timg-(1)

产品经理 VS.产品负责人(Product Owner)

很多年了,人们一直在讨论产品经理和产品负责人角色之间的区别。这两个角色是否可以共存,以及应该使用哪一个角色。本文谈谈我对这个问题的一些想法,以及对产品负责人起源的一些思考。

大家都遇到什么问题了呢?

您可能知道,产品负责人源自Scrum,其最大的职责是“最大化产品的价值”。[1]对我来说,这听起来像是教科书上产品管理的职责范畴。尽管如此,产品负责人经常被认为是一个战术角色,负责管理产品Backlog,细化产品需求、以及和开发团队进行协作,那这样的职责定义到底是怎么来的呢?

这些困惑至少部分是自于Scrum 本身,Scrum是一个关注在帮助团队开发软件的简单框架。 整个过程并不包含大家所熟悉的产品管理实践,例如产品战略,产品规划、路线图,以及成本预测,并且只介绍了唯一的一个产品管理工具—产品Backlog。
Read more