文章频道为您提供Leangoo实践,以及Scrum,敏捷,精益创业,产品创新等领域专业文章。

Scrum_TP

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

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

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

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

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

当然也不能在没有和团队商议的情况下承诺任何交付日期,交付物,或其它的任何东西。当然,你也许不必每次都召开全员会议来和大家沟通,有些情况下,团队内的部分相关成员经过沟通后也是可以做出决定的。但是,这仍然是团队的决定,而非你的决定。

2. 记住,你的目标是让团队看起来很棒

作为一个Scrum Master并不是要让自己看起来很棒。当团队看起来很棒的时候,你自然也看起来很棒。 当团队做得很好的时候,他们才看起来很棒。

当团队外的人开始怀疑是否还需要你的时候,你知道你干的不错。是的,如果你的老板怀疑是否还需要你的时候,那就太可怕了。但是,一个好老板会知道你的技能和专业知识会使你显得不必要,而事实上你是不可或缺的。

相信您的经理会明白显得不必要和实际上不需要之间的区别。

3. 不要用敏捷规则手册来怼团队

Scrum和敏捷都没有附带规则手册(尽管有些人试图创建规则手册)。

如果您的产品有用户,请考虑编写用户故事。但故事并非敏捷必需。如果有人需要知道你什么时候交付:请估算,如果没人想知道,也许你可以不做估算。如果您认为Sprint结束时做Sprint评审,收到反馈太晚,请在开发完每个功能时评审。

保持敏捷是指尊重创造敏捷性的原则和价值观。如果你只是生搬硬套这些规则,你可能不会走得太远。

4. 没有什么是永恒的,所以请验证你的过程

尊重敏捷性原则的其中一个方面是验证您的过程。鼓励团队尝试新事物。

你的团队是否喜欢为期两周的Sprint,并认为他们运行的完美无缺? 如果是的,那非常棒。现在让他们尝试一周或三周的冲刺并观察结果。实验可能并不总是受欢迎,但它们是确保您继续发现新的,更好的工作方式的最佳途径。

5. 确保团队成员和利益干系人视彼此为同行

团队成员和业务方利益干系人各自为产品开发计划带来了重要的视角。因此,每个人都需要得到平等的对待。

如果双方出现隔阂,整个组织都会受到损害。开发团队需要了解利益干系人带来的独特视角,利益干系人需要尊重开发团队,包括倾听开发人员说:“这个截止日期是不现实的”。

6. 保护团队,用比你想象的更多的方式

Scrum Master需要保护团队避免受到过于苛刻的产品负责人或利益干系人的影响,这是我们经常听到的对Scum Master的建议,这是个好建议。有时候,产品负责人很强势,只是简单地要求更快、更多。这会迫使团队牺牲质量,到头来困扰着项目。因此,一个优秀的Scrum Master可以保护团队不受此影响。

但是,你可能不知道,一个优秀的Scrum Master也应该防范团队陷入自满。优秀的Scrum团队会不断寻求改进。有些团队,可能不自觉的认为自己已经足够好了,他们的确有可能比敏捷之前有了显著的进步。但即使是最棒的团队,也经常有机会变得更好。卓越的Scrum Master保护团队,不会让他们感到没有任何东西需要学习。

7. 把失败从你的词汇表中移除

我偶尔会碰到一些团队,如果他们在Sprint结束时未能交付他们计划的所有内容,他们会将这个Sprint称为“失败的Sprint”。我不认为这是失败,特别是如果团队完成了大部分计划的条目,或者他们巧妙地处理了紧急情况。

当篮球运动员将球投向篮筐并得分时,它被称为进球得分(Field Goals)。如果球员没投中,这就是所谓的投篮尝试(Field Goals Attempt)。不是失败,而是一次尝试。

优秀的Scrum Master帮助团队调整他们的思维,以便他们认识到未能达到预期的Sprint和功能特性不是失败而是尝试。

8. 经常赞美,但永远诚挚

有一天,我告诉我十几岁的女儿,我为她感到骄傲,她立刻兴高采烈。这不应该让我感到惊讶。谁不想知道某人为他们感到骄傲?

但她的反应让我意识到我不能经常告诉她这一点。我认为这相当于我告诉她一些明显的事情,比如“你很高”。但我知道事实并非如此。

永远不要提供虚假的赞美。没有人想听到这个。但是,当你发现你的团队成员的工作做的很好的时候,请告诉他们。他们很可能不会经常听到。

9. 鼓励团队接管你的工作

对敏捷不熟悉的团队将重度依赖他们的Scrum Master或教练。团队可能不知道如何让每日站会在十五分钟内完成。或者他们可能不了解如何交错式地工作,以及建立跨职能团队的重要性。

一个没有经验的球队也是如此。学习踢球的小孩的教练需要教会他们一切。当我的女儿们6岁的时候,他们的教练会在边线跑动,整场比赛大喊“踢,跑!”如果他不这么做,那么年轻球员就会忘记。即使他大喊大叫,偶尔也会有一些孩子坐在草地上发呆。

将年幼孩子的教练与世界杯队的教练进行对比。在世界杯球队中,球员们已经学会了做什么。如果训练的时候,教练迟到了,球员知道用什么样的演练或练习开始一天的训练。世界杯教练不需要提醒球员踢球和跑动。但是世界杯球队永远不会告诉你他们根本不需要教练。

无论敏捷团队有多好,我认为他们仍然可以从Scrum Master或者教练的辅导中受益。但是,优秀的敏捷团队会更加主动地去学习,以精通产品开发所需的技能。

10. 闭嘴听

很多时候,聆听、保持沉默是最好的辅导,让团队自己找到答案。

这可能很难。当你看到你的团队正在努力弄清楚要做什么时,很自然地想要插话并提供建议。但是如果你解决了问题,或者轻易地提供了建议,团队成员就会等着你为他们解决每一个问题。

我不想暗示你不能提供任何建议。你是个聪明人,否则你就不会担任现在的角色了。但作为一名优秀的Scrum Master,要帮助团队学习如何自己解决问题。如果你解决了团队成员面临的每一个问题,他们就没有机会知道他们自己行不行,可否自己搞定这些问题了。

以上,就是我给到大家的十个建议,您觉得这个建议列表还缺少些什么吗?我敢肯定我一定错过了一些不错的点子。您作为Scrum Master收到或给出的最好的建议是什么?请在下面的评论中分享您的想法。

 

本文作者:Mike Cohn

英文原文链接:https://www.mountaingoatsoftware.com/blog/ten-sentences-with-all-the-scrum-master-advice-youll-ever-need#comments

本文译者:Eric Liao 廖靖斌,资深敏捷教练,Scrum顾问和培训师

19ad9ebd5ba29e36bcae22bd99b42c549e23681f

Leangoo 6.4.1 版发布

当前版本主要进行了一些功能优化和bug修复。

修复和优化

  • 【优化】新建项目流程优化;
  • 【优化】注册流程优化
  • 【优化】登录页优化
  • 【修复】修复某些情况下拖拽添加卡片成员会同时添加到多张卡片上的问题
  • 【修复】修复团队版绑定新手机号报错问题
  • 【修复】修复在个人中心页创建项目时,没有可选的部门问题
  • 【修复】修复移动端快捷方式无法打开Leangoo问题

Read more

leangoo看板工具

你知道敏捷团队的迭代目标达成率该是多少吗?

敏捷团队有一个常用的度量指标——团队是否完成了迭代规划的全部工作。

评估团队多擅长完成其承诺,这并没有错。但不能要求团队每次迭代都完成全部工作。

这不现实,并且会导致团队为了安全交付所有工作而保守地承诺。

期望过高会导致运作失灵

我知道有这样一个团队:团队老板(就是CEO)警告他们,如果不能完成所有工作,他就会“采取纠正措施,甚至可能会解雇团队”。你们设想一下,会发生什么。

团队绝不会积极主动地在迭代中承诺更多工作。他们只会竭力去寻找工作量上的平衡点,使其既不会表现懒惰而惹上麻烦,也不会承诺太多而可能完不成。

适当的目标是多少?

我发现对团队来说,比较合适的目标是:80%情况下,团队能完成承诺的每项工作。这对业务来说,能提供较好的可预见性;对团队来说,也不会达不成。

说得更清楚点,一个好的敏捷团队应该能在10次迭代中8次完成其规划工作的100%,而非团队每次迭代都完成其规划工作的80%。这两者是很不一样的。

如果认为做不到,就请您不要规划

当尝试80%情况下能完成100%工作时,团队的感觉应该是:自己应该能达成目标,但实际上又做不到每次都达成。

我喜欢把它比喻成篮球运动员投篮。除非球员感觉能投进球,否则就不应该投篮。但即使是最伟大的球员也非常清楚,并不是每次都能投进球。

伟大的篮球运动员只能投进40%至50%的球。而这个数值对大多数敏捷团队来说,意味着可预见性不足,这就是为什么我建议把80%作为目标的原因。

您的经验是什么?

您的团队在完成承诺工作方面表现得如何?请在下面的评论中分享您的想法。

 

作者:Mike Cohn

译者:李洁(Jerry Li)

原文链接:

https://www.mountaingoatsoftware.com/blog/an-agile-team-shouldnt-finish-everything-every-iteration

 

 

leangoo看板工具

疫情来袭,远程办公,敏捷怎么玩?

春节期间,新型肺炎疫情肆虐全国,假期即将结束,但是疫情还不知道何时才能缓解,多数企业可能不得不选择在家远程办公。对于不需要大量团队协作的岗位,比如销售、客服等,准备好电脑、电话基本就可以开工了,但是针对研发型的一些团队,如何开展远程协作办公将会是一个巨大的挑战。笔者根据自己曾经辅导分布式敏捷团队的一些经验,给大家一些可参考的建议。

1. 工作时间节奏的同步和约定

在家办公,由于家庭环境的影响,比如需要照看小孩,老人,时间节奏往往不是那么的规律。 因此,团队首先需要对每个人的作息时间进行统一的约定,比如每天的上班时间,中午的休息时间,晚上下班的时间,敏捷团队会议的时间安排等。

2. 统一沟通工具

及时通讯讨论群就不说了,平时都在用。由于敏捷团队需要每天开站会,不定时还需要团队成员之间协作讨论,所有多方视频通话和屏幕共享是必须的,可以使用Zoom、Teamviewer,微信群视频,或者钉钉,飞书等工具。

3. 远程集成开发环境的建立

代码仓库的建立通常有这几种可以参考的思路:

第一, 也是最快的方法,将你的代码托管在类似于Github私有代码仓库这样的代码托管平台上。

第二, 用Gitlab或其它工具,在阿里云,AWS等云平台上自己搭一个

第三, 使用VPN连到自己企业的企业内网

持续集成环境、集成开发和测试环境,如果您原来就在云上的,就比较简单,如果不是,有两个思路:

第一:在阿里云,AWS等云平台上搭建环境

第二:使用VPN连到自己企业的企业内网

4. 需求的协作

1) 有很多敏捷团队管理需求直接使用的是物理的故事卡和故事墙,在远程工作环境下,这个会是一个大问题。推荐使用一些可视化的电子看板工具比如Leangoo,来代替故事卡和故事墙。

leangoo2

2) 针对需求的协作,还有一个比较突出的问题是,如何进行远程的需求梳理活动,需求梳理活动通常需要团队一起共创完成需求细化、编写用户故事的验收条件等。 那么远程环境下怎么来开展需求梳理呢?我们推荐的方式是使用视频会议+Leangoo协作式脑图来进行。Leangoo提供了一个多人实时协作的脑图,通过这个脑图我们可以实现从Epic到Feature、Story、AC(验收条件)的四层结构可视化,并且团队成员可以共同远程实时编写故事和验收条件。

Leangoo脑图

3) 需求确认和设计效果的确认

很多时候,我们无法在梳理会上完全确认所有的需求,相关的设计效果,在进入迭代后也会根据需要进行调整,笔者的一个实践是,设计师可以将设计的效果进行视频录屏,及时的发到开发群进行讨论和确认。

5. 迭代开发过程的协作

1)物理的任务看板,在这个时候,可以通过实时的可视化电子看板替代,电子看板一定要便于操作,能够达到接近物理看板的易用性。Leangoo工具提供了实时同步,实时协作的看板,非常易用,可以实现可视化和透明化的管理。 leangoo迭代管理

2) 远程Sprint计划会议

计划会议通常做两件事情:第一,明确迭代目标;第二,讨论设计,确定如何实现目标,并拆分任务。

计划会议期间,肯定会涉及到方案的讨论,写写画画是必须的,我们的实践是使用Surface 的手写笔+OneNote 画布,通过Teamviewer共享屏幕来进行方案的讨论。

任务分解我们使用Leangoo实时协作看板,多个人同步进行任务拆分。

3) 远程的每日站会

每日站会是一个15分钟的面对面的站立会议,远程的情况下,我们可以采用视频会议加上实时同步的看板结合的方式进行。
4) 远程迭代评审

迭代评审,可以通过Teamviewer/Zoom共享屏幕,视频会议的方式开展。

5) 远程的迭代回顾

远程的迭代,我们的实践是通过Leangoo共享的实时协作脑图+视频会议来进行,脑图可以是头脑风暴的方式,海星图的方式或者根因分析图的方式,有很多种思路。

6)缺陷和问题的跟踪

缺陷和问题的跟踪,如果是当前迭代的缺陷,直接放到迭代看板上处理就可以了,如果涉及到遗留的缺陷,可以使用leangoo的缺陷看板来来进行实时跟踪。

leangoo缺陷问题跟踪

7) 迭代过程的Showcase

开发团队开发好的功能,及时的将做好的功能录视频发到开发群跟PO确认,不要让PO等到迭代结束才看到。

8) 开发过程中的讨论

有时候你会发现,团队会在聊天群针对一个问题,无休止的发信息讨论,当有多次信息往复的时候,团队就要有意识的终止群讨论,通过电话或视频进行沟通,遇到这种情况Scrum Master可以提醒团队。

在这段艰难的时期,期望上面的这些小小的建议能够帮助到您和您的团队,大家共度难关。以上提到的这些Leangoo工具中的功能,所有团队都可以免费使用。

祝愿所有的朋友们新年快乐、身体健康、阖家幸福!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

使用Leangoo脑图做Epic/ Theme /Story 管理

使用Leangoo脑图做多级需求管理

上篇介绍了如何使用Leangoo思维导图实现影响地图。本文,将介绍如何用Leangoo脑图来做多级需求管理。

什么是Epic?

Epic是史诗故事,通常需要花费多个Sprint来开发和测试,才能完成最终的交付。它通常范围比较大而细节描述较少,Epic的粒度比较大,在团队开发前通常需要拆分成多个更小的用户故事。

假如构造月度销售报表科目时,可能有这样的史诗故事:“作为销售经理,我希望能分区域看销售数据”。

什么是Theme?

Theme是指主题故事,是一组相关的用户故事的集合。Epic通常比较大,会分解出很多个小的用户故事,我们可以根据这些故事的相关性,通过Theme主题故事对其进行分组。

什么是Story?

Story是User Story的简称,用户故事是从用户的角度来描述用户渴望得到的功能。

用户故事通常按照如下的格式来表达:
Read more

影响地图海报

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

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

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

  1. Leangoo脑图是项目团队实时同步、实时共享的。不需要再通过导出分享给项目中的其他人。
  2. Leangoo脑图可以支持多人在线编辑与协作。
  3. Leangoo脑图的节点和Leangoo看板上的卡片是一样的,支持富文本文档,可以添加附件,添加检查项,添加工作量以及评论等等。

所以,它可以用来代表需求、任务、测试或者一篇文档等等。而且每个节点都可以引用到看板上。

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

本文,我们先从影响地图开始,介绍如用Leangoo脑图来实现影响地图。

什么是影响地图?

Read more

Spotify-scrum中文网1

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

摘要

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

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

引言

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

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

二、 如何管理标准化

三、 如果做到以人为本

四、 如何管理部署上线

五、 如何管理创新

六、 如何管理失败

七、 如何处理浪费

八、 如何管理文化

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

Read more

Spotify-scrum中文网1

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

摘要

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

引言

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

1
Read more

Spotify-scrum中文网1

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

引言

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

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

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

Scrum中文网敏捷团队领任务的误区

关于敏捷团队领任务的几个误区

敏捷开发团队(Scrum团队)在每天开每日站会的时候会领取当天的任务,这个实践在敏捷开发中叫做sign-up-for-tasks即领任务。这个实践源自极限编程,在1998年,极限编程最早期的介绍中提到了,“指派任务”和“领任务”是传统方式和极限方式的一个显著区别。

领任务是指,团队成员在任务卡上写上自己的名字,或者贴上自己的照片,表明这个任务,由这个成员来负责。领任务的活动通常在开展每日站会的时候进行。领任务的方式体现了团队自组织的工作方式,传统模式下的经理指派任务是命令和控制的工作方式。

领任务的实践看似简单,但是在实践中往往很难做好,通常存在如下几个方面的误区:
Read more