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

任务分布

如何使用Leangoo看板统计中的任务分布?

之前已经为大家介绍了“如何使用Leangoo自动生成燃尽图

今天介绍,“如何使用Leangoo看板统计中的任务分布”

Scrum 团队是一个自组织的团队,团队每天的目标和工作安排由团队讨论决定。Leangoo 通过任务分布统计帮助团队快速直观的了解团队成员每个人负责的工作负荷及工作进展状态,帮助团队进行更高效的协作。

我们首先来创建一个新的看板,我们可以选择空白看板或者模版创建,该看板命名为:办公室改造项目,这样我们就创建好了一个看板。

默认的看板周期为2周(从当前日期开始)

办公室改造

接下来我们为此看板添加列表,泳道和卡片,添加好后的看板如下图:

屏幕快照 2018-06-14 上午10.55.35

一个完整的看板创建好了之后,我们需要自定义任务分布的各项设置

任务分布的统计方式有两种:卡片数和工作量

1.系统默认设置为根据“卡片数”进行成员工作分配统计(注:必须先为每一张卡片指定负责人,将成员拖拽至卡片上即可

也可以根据项目的实际情况修改为根据“工作量”进行统计(注:必须先为每一张卡片设置工作量,点开卡片,右边栏选择相应工作量即可

屏幕快照 2018-06-13 下午10.38.27

2.系统默认所有列都参与统计,您可以根据项目的实际情况勾选统计列。

屏幕快照 2018-06-13 下午10.38.48

3.系统默认设置成员都参与统计,您也可以根据成员的情况进行勾选。

屏幕快照 2018-06-13 下午10.39.01

现在我们就可以查看任务分布图了:

屏幕快照 2018-06-13 下午10.47.14

通过以上几步就可以轻松了解成员任务分布情况了,是不是非常方便呢?

 

 

 

 

产品经理VS产品负责人-leangoo

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

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

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

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

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

另外,像SAFe这样的一些方法,考虑到大规模的敏捷,采用了独立的产品经理和产品负责人角色。使用战略产品角色和战术产品角色是大规模敏捷的一个常用的实践。但在我看来,把产品负责人只作为一个战术角色是一个错误:因为在SAFe中的产品负责人并不等同于Scrum中的产品负责人。存在两种不同的产品负责人角色会让大家更加的混淆。

那么我们该怎么办呢?

那为什么Scrum 需要引入一个产品负责人的角色?为什么在Scrum不直接使用产品经理这个术语? 让我们回到Scrum 开始创建的上世纪九十年代, 那个时候产品的管理和当今是截然不同的。产品经理经常做的市场调研,产品的规划和需求的定义。大多数人把需求文档交由项目经理管理,因为项目经理和开发团队工作密切且负责最后上线的测试。 产品经理的职责只是修改需求或者帮助产品发布。

这与敏捷流程中的工作方式形成了鲜明对比,在敏捷环境下,产品人员需要和开发团队持续合作,同时也不能忽视市场和公司内部的相关干系人。

其次, Scrum 应用于产品开发和商业软件产品领域之外。 许多使用Scrum的组织如银行,零售企业和媒体公司,这些公司传统上没有产品管理,因此也没有产品经理。 但他们确实拥有数字化产品,用于帮助市场营销和销售产品(比如手机银行应用),或是他们开发实现业务流程自动化的软件,以提升生产效率和减少成本。

通过设立产品负责人的角色,这些组织可以以敏捷的方式开始工作,却不用立即建立产品管理团队或者在进行组织流程变革。相反,来自业务部门的人通过参加一些培训和指导可以担任产品负责人角色。但长远来看, 建立一个产品的管理职能是会带来更多好处的,就像我的文章: “Five Tips for Introducing Product Management to Your Company.” 中谈到的。

现在我们该怎么办?

那我们该何去何从呢。我的想法是我们不要纠结一直在产品经理和产品负责人里找不同点,我们不如统称他们产品人员 [2]
在短期内, 我们应当明确产品负责人是一个产品管理的职责, 只有具备相关产品技能的人才能胜任这个职位。 就像Mary Cagan和其它人曾经指出, 2天的培训是不足以培养一个有竞争力的产品负责人的,产品管理很复杂, 需要的知识面很广,需要较长的时间和精力才能掌握。

此外,我们建议不论设置产品经理或者产品负责人的角色,必要时要让他们具备相关资质。例如,可以聘用高级或者初级的产品经理/产品负责人,以及战略产品经理/产品负责人和战术产品经理/产品负责人。
其实,重要的不是工作角色和头衔,关注用户和我们的业务发展才更好。

参考资料:

[1] 这个引用来自于Scrum Guide 2016。1993年,Jeff Sutherland 最早将Scrum用于
Easel Corporation公司的“ design and analysis tool”开发项目上, 请参考 “Inventing and Reinventing SCRUM in Five Companies.”

世界上第一个Scrum产品负责人, Don Roedner, “ 必须要自己负责产品版本,商业计划,业绩,路线图 和发布计划, 还有…, 精心梳理和精确定义优先级的产品Backlog。
参考:“ Scrum敏捷产品管理”

[2] 非常感谢 Rich Mirnov向我介绍这个词

 

 

本文作者:罗曼 皮克勒
译者:Derek Ding,CSP/CSM/PMP, 英国爱丁堡大学计算机科学硕士,拥有十一年IT软件,信息产业,大数据和数字化产品经验,超过八年技术和产品团队管理经验。自2012年开始实践Scrum,担任过Scrum Master和Product Owner角色。
原文链接:https://www.romanpichler.com/blog/product-manager-vs-product-owner/

leangoo跨职能团队并不意味着每个人都具备所有技能

跨职能团队并不意味着每个人都具备所有技能

跨职能团队就是指在团队里面的每一个人都具备完成所有工作的所有技能,这或许是敏捷中最流行和持续存在的一个误区。

这显然是不正确的。跨职能团队的成员具有各种技能,但这并不意味着每个成员都具备所有技能。

敏捷团队拥有专家成员是可以接受的

敏捷团队拥有专家成员是完全可以接受的。(注:本文提到的专家成员是指在团队里面只擅长某个方面的单一技能的团队成员。)

而且我怀疑团队追求一些虚假的圣杯让每个团队成员都能够做到一切会失去很多生产力。

如果我的团队包括世界上最牛的数据库开发人员,我希望那个人为我们的数据库做出非常出色的成果。我不需要这个最牛的数据库开发人员来学习JavaScript。
Read more

敏捷估算-leangoo

敏捷估算, 请忘掉人天

在介绍敏捷估算的方法之前,我们先来回顾一下基于人天的传统估算的思路。传统的工作量估算是估计一个绝对值,单位是人天或者人时。

比如:

David喝完一小杯热咖啡花费1.2个小时(工作量 1.2人时)

David喝完一大杯热咖啡花费2.4个小时(工作量 2.4人时)

由于人的能力是有差异的,所以David的工作量对于Tom来讲可能就不适用,Tom喝完一小杯热咖啡可能需要1.5小时。这样一来,工作量、参与人以及完成这些工作的时间周期就是强相关的,因为强相关会带来如下挑战:

Read more

leangoo每日站会

每日站会要关注团队目标

在Scrum的标准定义中,团队在开每日站会的时候需要回答三个问题:

• 我昨天完成了什么?

• 我今天计划做什么?

• 我遇到了什么障碍?

 
在对很多团队做辅导的时候,我发现团队的确在回答这几个问题,看起来好像没有什么错。 但是,他们只关注自己做的事情,对伙伴们在做什么,我们这个迭代的目标是什么,差距还有多大?团队昨天的目标完成的如何?今天的目标是什么?似乎不怎么关心。

命令与控制式的传统式管理和自组织的主要区别在于,传统管理方式是命令驱动的,而自组织是团队目标驱动的,团队共享责任的。

自组织团队不是团队随意的想干什么都可以,也不是各自为政,做自己喜欢做的事情,而是围绕团队的共同目标,基于团队的决策和工作约定共同决定谁做什么,以达成团队目标。

因此,工作良好的自组织团队在进行每日站会的时候,我建议回答如下问题:
Read more

scrum团队会议太多了吗

Scrum团队的会议太多了吗?

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

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

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

一个实验

这里有一个实验,我希望你能试试,尤其是如果你认为Scrum会议太多。

从5-10中选择一个随机数。然后回想一下,你的团队是什么时候开始以敏捷方式开始工作的,或者他们是什么时候开始能较好地以敏捷方式工作的。

在你的工作日历(无论是在outlook、Google、苹果日历,或者其他什么程序)中,定位到这个月。现在,记得你在上一段中选择的随机数吗?再向前回滚随机数所对应的月数。
Read more

什么是用户故事(User Story)?

什么是用户故事?

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

1.     角色:谁要使用这个功能。

2.     活动:需要完成什么样的功能。

3.     商业价值:为什么需要这个功能,这个功能带来什么样的价值。

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

英文:

As a <Role>, I want to <Activity>, so that <Business Value>.

中文:

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例:

作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。

Ron Jeffries的3个C

关于用户故事,Ron Jeffries用3个C来描述它:

卡片(Card) – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述,工作量估算等。

交谈(Conversation)- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

确认(Confirmation)- 通过验收测试确认用户故事被正确完成。

用户故事的六个特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则。

独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性(Negotiable)— 一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。

有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。

可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。

短小(Small)— 一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。

可测试性(Testable)—一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子:软件应该是易于使用的。

 

 

scrum中文网scrum行业报告

Scrum行业报告 2017-2018摘要

《2018 State of Scrum》报告由美国Scrum Alliance发布。从实践者、教练、讲师等角度来探寻规模化敏捷转型中的问题,有助于理解、比较和思考敏捷方法在不同行业的效果。

本文摘取了部分精华数据,翻译成中文,供华语敏捷社区参考。鼓励大家在培训和教练辅导中引用这些关键点。

WechatIMG3

关于Scrum Alliance

Scrum Alliance是一个为Scrum和敏捷实践者提供教育、资源和支持的组织。深入一步,你会发现Scrum联盟是观念和变革运动的一部分。Scrum联盟提供主张、社区参与、研究、人际网络和关注组织变革,这些变革正在改变着全球的工作方式。Scrum是一个非盈利组织,由全球超过50万认证者组成,驱使我们的不是商业,也不是什么财务盈亏;我们的动力正是来自于全球社区的成员,以及寻求实现真正工作与生活平衡的每个人。

敏捷与Scrum

Read more

屏幕快照 2018-01-10 下午2.42.02

为什么Scrum Master不叫Scrum Manager?

leangoo为什么Scrum Master不叫Scrum Manager?

昨天, 去看最新上映的星战8
其中有一段剧情是这样的, 卢克·天行者担心自己没有能力教导下一代绝地武士, 尤达大师现身对他说了一段话, 大意是:

[“yes you can teach them, you can pass knowledge, pass experience, pass…, pass failure, yes, failure, is the most important thing… we are something they grow to beyond, that's the true meaning of masters.

你有能力教导她, 你可以传递知识, 传递经验, 传递…, 传递你曾经失败的经历, 是的, 失败的经历是最重要的, 在我们的帮助下, 他们将超越我们, 这就是一位Master真正的意义. "

*现场听记,可能与原文有出入 ]

leangoo-为什么Scrum Master不叫Scrum Manager?

这段话可算是“服务型”领导人绝佳的写照了, 也是Scrum Master的精髓所在.

Read more

leangoo敏捷实践编年史

敏捷实践编年史

敏捷实践编年史(敏捷联盟版)记录了上世纪六十年代至今敏捷相关实践的发展史,其英文原版材料来自于国际敏捷联盟网站(AgileAlliance.org) .

原文链接: https://www.agilealliance.org/agile101/practices-timeline

本文由国内知名敏捷教练李洁(Jerry Li)和廖靖斌(Eric Liao)翻译成中文版本。

1968年:“康威定律(Conway’s Law)”

“康威定律”被提出并概括为:“任何组织,在设计系统(不仅限于信息系统)时,产生的设计在结构上必然会复制自身组织的沟通结构。”长期以来,“康威定律”都只是被当成民间传说,而非得到充分论证的科研成果,尽管最近有些研究为其提供了一些学术支持。(直到90年代中期,软件开发的人际交互方面仍然在很大程度上为软件工程学术研究忽视。)
Read more