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

未标题-2

Leangoo看板Jenkins配置指南

介绍:

Jenkins 是一个独立的开源软件项目,是基于 Java 开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。它可以用于自动化运行各种任务,如构建,测试和部署软件。

使用 Leangoo 集成 Jenkins 是在 Leangoo 中驱动 Jenkins Job 的构建,并实时显示 Job 的构建结果。在 Leangoo 中将卡片拖到配置好的构建列中,会向 Jenkins 服务器发送请求。Jenkins 接收到 Leangoo 的请求后,进行构建,并通过 Notification 插件将构建结果发送到 Leangoo。

操作步骤:

Read more

Scrum Leangoo跟项目干系人说不的六大准则

跟项目干系人说“不”的六大准则

说“不”是件难事。我们大部分人都喜欢取悦别人,可是当我们向别人说“不”时,我们会让请求者失望。

但向干系人说“不”,却是产品负责人最重要的工作之一。产品负责人应以优化产品交付价值为己任,而不是每个客户需求都答应。

产品负责人每接受一个干系人的需求,就意味着可能要拒绝将来的一些客户需求。团队的时间总是有限的,接受今天的一个需求,就意味着可能要被迫丢掉明天的一个机会。

因此,学会向干系人说“不”是每个产品负责人都必须掌握的技巧。我想分享六条准则,以便大家能礼貌而坚定地做到这一点。

向干系人清楚说明:是“不”,还是暂时“不”?

当产品负责人需要告诉干系人,他们不会优先处理某个需求时,他们应该说明清楚“不”的含义。

如果你要表达的是你将永远不会让团队开发这个需求,不要给干系人留有任何幻想,这会鼓励他们在未来继续地提出类似的需求。这会浪费他们的时间,也会给心里清楚这个需求绝不会被实现的你,带来持续说“不”而引发的挫败感。

另一方面,对于你后续可能会实现的需求,你要清楚地告诉客户——只是暂时“不”。

例如,你可以说:

“非常抱歉,我们不能立刻实现这个需求。相信我,我非常希望现在就开发它,但我们已经承诺要在8月之前交付[任何可能的需求名称]。我必须让团队先集中精力开发那个需求,否则我们就可能会违反那个承诺。但是如果你在8月份提醒我,我保证会在那之后认真考虑。”

注意这个例子中的回复方式,我并建议你不要承诺稍后就做,而只是说你会考虑这一点。

还要注意的是,你要把责任转回到干系人或客户身上。让他们在合适时重新提需求或提醒你。我这样做的目的,是为了确保这个功能那个时候对他们来说仍然很重要。如果干系人不愿意为这个需求,再稍微费点事提醒你,我会质疑这个需求是否真的那么重要或紧急。

最重要的是,如果你真的从未打算接受这个需求,不要让干系人离开,认为他们应该在一个月内再次提出需求。

向客户表达感激和理解

每当被提出一个需求时,产品负责人们应当总是向干系人表达谢意,并指出他们理解为何对干系人来说这个需求是如此得重要。

某人花时间向你们团队要求了某事。那就意味着他们对你的产品感兴趣。要告诉客户你感激他们花时间提需求。

你需要说诸如此类的话:

“谢谢您!感谢您考虑我们产品该如何改进!”

除了感激,产品负责人还应该表现出对干系人状况的理解。你即将说“不”的这个需求,可能对他们来说是非常重要的。至少在干系人的头脑中,这个需求可能是需要完成老板指派的目标,甚至可能会对他们造成的财务影响。

在表达你的理解之前,你要确保已经了解这个需求为什么对这个客户很重要。如果这时候仍不了解,那么在对这个需求说“不”前,你必须做到这一点。

在表达对客户状况的理解时,你可以采用类似这样的说法:

我能理解这个需求对于您完成[任何可能的事情]有多么重要!

要确信你对此是真诚的。谁都会被错误的理解感到失望。

只提供一个说“不”的理由

当说“不”时,产品负责人最好能提供一个令人信服的理由,而不是提供一堆理由。当提供一堆理由时,人们会倾向于挑选出最薄弱的理由并进行反驳。

设想一下,我是你的客户,我要求你们团队把手头的工作先放在一边,优先满足我想要的需求。你告诉我:
对不起,我不能那样做,我们已经规划好了这次冲刺。否则,我需要团队再开一次计划会议他们不喜欢这样。我相信我们现在正在做更高优先级的工作。

你认为我会攻击你论点的哪一部分?需要再开一次计划会议,还是当前的工作优先级更高?

我会去争论,尽管团队不喜欢,但我们仍需要再开一次计划会议。我可以提出,可通过在午餐时召集会议来减少大家对开会的不满,并且我会买披萨。

尽管你仍然不喜欢我的方案,但我现在已经改变了对话内容:我们正在争论是否需要再举行一次会议,而不是哪个需求的优先级更高。而这更难说服对方。

并且,这是一个错误的做决策的基础。

说“不”,要坚定地提出最令人信服的理由。如果干系人在这一点上成功地说服你改变自己的观点,那么就有必要考虑你的第二点拒绝理由是否足够充分。如果不够充分,你可能需要接受这个需求。

表示你们有着共同的目标

如果产品负责人和干系人共享一个相同的整体目标,当产品负责人带来不受欢迎的消息时,应该借助于这个共同的目标。

产品负责人和干系人们通常有各自不同的目标。然而,有时候它们之间是矛盾的。但是通常会共享一个更高的、产品级目标,你可以参考这一点。

如果你们身处同一家公司,这会变得特别简单。在这种情况下,可以这样说:

我和你一样,很想让团队为你开发这个,但我们需要专注于[更大的,共同的目标]。
我相信你们还记得,我们都被赋予了[更大的,共同的目标]的目标。

提醒客户,你们共享着一个共同目标,这会帮助他们理解为什么你需要说“不”,即使他们仍然并不完全认同你的答案。

向干系人解释清楚接受需求会造成的后果

当拒绝一个干系人的需求时,产品负责人应当解释清楚接受需求会造成的后果。

这能有助于让干系人明白你为何不得不拒绝他。例如,你可能可以这样说:

如果我们接受了您的需求,我们就无法按时交付了。
团队工作压力已经很大了,如果需要加上这条需求,我们就必须拿掉已经承诺的其它需求。

解释后果有助于让干系人明白,或许能理解你拒绝的理由。

为客户提供替代方案

产品负责人或许可以提供一个替代方案,而不是毫不客气地直接向客户说“不”。

你或许可以说这样的话:
我们可能无法做到你所说的一切,但是如果我们做到部分怎么样呢?
我无法让团队现在就开始做这个,但是如果我们在三个星期后开始做怎么样?

注意:只有你真的想接受这个需求时,才提供替代方案。

说“不”未必是一件难事

产品负责人经常害怕说“不”,不敢让干系人或客户失望。但是说“不”并不那么困难。

我发现,只要我们能够清楚地提供一个而不是多个理由,做到感激和理解,阐述我们的共同目标,解释清楚接受需求会造成的后果,以及提供一个替代方案,说“不”就会简单很多。

如果做得够好,说“不”能提升而不是损害产品负责人与干系人之间的关系。

作者:Mike Cohn

译者:李洁(Jerry Li) ,CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

原文链接:

https://www.mountaingoatsoftware.com/blog/six-guidelines-for-saying-no-to-a-stakeholder

leangoo企业版海报

Leangoo企业版,助力企业规模化敏捷

大变革时代,很多企业不仅难以跟上不断变化的客户需求和技术进步,而且还要面临颠覆式商业模式的威胁。在这种形势下,通过敏捷来实现以用户为中心,扁平化,快速应变的组织已经迫在眉睫。

Leangoo自2015年发布以来,一直秉承免费策略,目前已拥有百万级企业用户。借助Leangoo工具,众多团队实现了Scrum和敏捷落地。如今,企业规模化敏捷势不可挡,为此我们推出了Leangoo企业版,助力企业实现企业规模化敏捷。

通过Leangoo企业版,实现企业管理透明化和可视化

在Leangoo的企业版中,企业可以:

  • 集中管理所有项目和组织成员;
  • 通过企业仪表盘直观的了解所有项目的运行状况;
  • 通过项目状态统计了解所有项目的状态,对问题项目进行预警;
  • 通过吞吐量统计了解整个组织的产能,吞吐量统计了每个月团队处理的需求和缺陷数量;
  • 通过需求趋势和缺陷趋势了解整个组织每个月的需求和缺陷变化趋势,包括新增、累积和已经处理完成的需求和缺陷的情况;

leangoo企业仪表盘

Leangoo企业管理员视图

Read more

任务分布

如何使用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

scrum中文网scrum行业报告

Scrum行业报告 2017-2018摘要

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

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

WechatIMG3

关于Scrum Alliance

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

敏捷与Scrum

Read more