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

111

与团队默契协作,PO需要做到这六点

我与许多团队合作过,还与更多的人交谈过。大部分都理解和体会到作为产品负责人所面临的挑战。以下是团队告诉我他们想从您这位产品负责人获取的六件事物。

1. 您的时间

团队经常会面临巨大的快速交付压力。现在团队成员也普遍都视其为一种现实状态,这很好。

但是,在期望您团队快速交付同时,在团队成员存在业务问题时您也必须让他们能找到您。

对于一位产品负责人而言,不能既要团队快速交付却又不腾出时间为他们答疑解惑。

2. 您的信任

您的团队希望您能信任他们。当团队成员申请开展某些工作时,他们希望您相信他们这么做为了给产品带来好处。

他们不会介意您询问他们这么做的理由,但是您问的任何问题的出发点都应该是基于产品的利益。

举个例子,我记得我女儿16岁时曾询问她是否能去参加某个周末派对。她会这么问,是因为她这次外出会超过规定回家时间2小时。

我会询问派对在谁家开。她的朋友们都是好孩子,因此我不会否决她的请求。但我要知道是在谁家开派,对做到自己心安。

产品负责人针对团队申请开展的工作进行询问,也应该是基于类似的出发点。

例如,假设团队成员想清理一些旧代码。作为产品负责人的您,可能会问类似以下问题:
• 如果我们不清理哪些代码会怎发生什么?
• 如果我们把代码清理工作推迟两个冲刺会发生什么?

这些问题的答案可能会导致产品负责人告诉团队不要去清理代码。但更可能发生的是,产品负责人信任团队,并且只会对现在还是几周后再清理代码更好作出评估。

3. 理解您的愿景

优秀的产品负责人都有其产品愿景,并能让团队对愿景将创造的未来感到激动不已。

这并不需要是史蒂夫•乔布斯式的全新行业愿景。但是,对未来3到6个月怀有愿景是有用的。任何超越单个冲刺对未来的憧憬都是美好的。

愿景可以(也应该)随时间而改变。亚马逊的杰夫•贝佐斯无疑是一位富有远见的人,但即便是他也不可能预见到未来亚马逊的一切。如果能做到,他就肯定不会赋予亚马逊那最初的口号——“地球上最大的书店”。

4. 被您纳入干系人范畴

产品负责人非常清楚用户和客户是产品或者项目成功的干系人。另外,他们也善于识别组织内的业务干系人。

但是,有太多产品负责人没有认识到把开发团队成员们视为干系人的重要性。

您的开发团队成员们对产品的成功有着极大的既得利益。这就意味着,在您要考虑业务、用户和客户干系人的任何时候,应该把他们包括在内。

一个常见的疏忽是,产品负责人不会向开发团队征询产品待办项的优先级排序建议。向开发团队征询优先级排序意见,并不意味着他们的建议就能优于业务人员的建议而自动胜出。因此,您不需要完全按照团队成员的要求进行优先级排序,而是应该把其建议纳入到全体干系人的需求之列。

5. 被您允许从事高质量工作

没人会喜欢发布不能代表其最高水平的作品。我想没人会趴在梵高的肩膀上说:“画快点。现在已经够好了!”然而,团队却几乎每天都会听到类似的话。

有时,产品得带着已知缺陷发布;有时,团队得快速完成一个“足够好”的特性版本。
而且,相信我,您的开发团队也深知这么做的意义。
但每当这时,都得平衡考虑团队完成高质量工作所需要花费的时间。

6. 改进和学习的时间

技术技能会很快过时。新技术会被开发出来,旧技术也会不断被改进、加强或者以新的形式展示其用途。

您的团队成员们熟知这一切。因此他们需要时间来改进其现有技能和学习新的技能。许多团队成员也喜欢学习带来的挑战和兴奋感。

当然,学习新技能还有助于他们在就业市场上保持竞争力。也许他们会运用这些新技能来另攀高枝。
但是,值得冒这个险。

您难道不想拥有那种喜欢学习新东西并运用所学来构建可能最好产品的团队吗?这是一个双赢的局面:团队成员努力学习,而您能从他们的学习中获益。

您能成为出色的产品负责人

要成为一名出色的产品负责人是很难的。您必须花时间,对外审视客户、用户、竞争对手、行业发展趋势等等。但您也必须花时间,对内审视团队,与他们协作,回答他们的问题。

如果做到了这里列出的六件事,那么您在团队上花费的时间将帮助他们成为可能最适合于您的团队。

您怎么看?

您认为我的清单中少了什么吗?如果您是一位开发团队成员,您还想从您的产品负责人那里获得什么?如果您是一位产品负责人,我遗漏了什么您的团队想要从您那里得到的?请在下面的评论中分享您的看法。

 

作者: Mike Cohn
译者:李洁(Jerry Li)
原文链接:

https://www.mountaingoatsoftware.com/blog/six-things-your-team-wants-from-you-as-their-product-owner

111

避免把每日站会开成汇报会的四条建议

我常常在客户现场看到这样一种现象:在每日站会上,团队成员们围成一个圈或者站成一个排,依次向Scrum Master汇报工作,而其他与会人员则在开小会、考虑自己的事情,甚至还有人在玩手机。

每日站会不应该是这样的。

每日站会应该是,团队成员之间同步信息以及共同管理迭代工作的会议。但是,初创的Scrum团队非常容易延续以往的工作习惯——把每日站会开成团队成员向Scrum Master进行工作汇报的会议,而团队成员之间却缺乏必要的沟通和协作。

该如何改变团队成员的汇报习惯

那么,如何才能改变团队成员的这种汇报习惯呢?

以下是我给出的四条建议:

1、不要在计划会议上就分配完所有工作

许多团队在召开计划会议时,会把所有的工作都分配到个人。

这并非是一种好的做法。因为,如果在计划会议上就分配完所有工作,那么就很容易导致在迭代中每个团队成员只关注自己而不关注他人。

更好的做法是,不要在计划会议上就分配完所有工作,而是要改为在每日站会上确定工作分工。只有这样做,才能让整个团队始终保持对整体迭代目标和进展的关注。

2、每日站会上,不要过人,而要过故事

许多团队在召开每日站会时,会让团队成员依次进行工作陈述。

这种做法并不妥当。因为,如果在每日站会上让团队成员依次进行工作陈述,就会很容易把每日站会开成是针对每位团队成员的工作汇报和纠偏会议。

更好的做法是,按照优先级依次回顾每个故事的完成情况、讨论遇到的问题和规划当天的安排。只有这样做,才能把会议焦点从关注人转向关注迭代工作。

3、Scrum Master尽量只引导,尽量少发表意见

我看到,许多Scrum Master在很积极地参与到每日站会的工作讨论,例如:代替团队成员陈述昨天的工作完成情况,对工作进行点评和给出工作建议,直接向团队成员进行工作任务分配,等等。

在每日站会上,谁发言最多,谁就会自然而然地成为会议上所有人员瞩目的焦点。如果Scrum Master的管理行为过于积极,往往就会打击团队成员参与工作讨论的积极性,而自然而然地把每日站会开成工作汇报会。

更好的做法是,Scrum Master尽量只做会议引导,引导团队成员们进行协作和思考,而非开成以自身为主的管理会议。

需要强调的是,如果Scrum Master发现团队成员的迭代工作安排中出现了严重问题,还是应当给出必要的反馈,但最好在团队成员已经充分交流后再给出,而不要一开始就把问题抛出来。

4、让团队成员轮流主持每日站会

如果Scrum Master想要减少自己在每日站会上的发言,以更大程度上促进团队成员间的交流,可以考虑让团队成员轮流主持每日站会。

需要强调的是,如果要让团队成员来主持每日站会,必须先进行必要的每日站会主持方法和技巧培训,否则可能会把每日站会开得很糟糕。

您怎么看?

您的团队在每日站会上的交流情况怎么样?有把每日站会开成了工作汇报会了吗?您是否赞同以上建议?欢迎在评论区分享您的观点和看法。

 

作者:李洁(Jerry Li),SPC,CSP,CSM,Scrum中文网咨询总监,组织敏捷及精益转型教练,敏捷管理及技术教练

 

2

创建敏捷产品路线图的十大建议

产品路线图是一个强有力的工具,可用于描述产品可能会如何成长,以便与干系人达成一致,和获得开发产品所需的预算。但是要创建有效的产品路线图并不容易,尤其是在敏捷环境下还会频繁且意外地发生变更。本文分享了十个建议,能帮助您创建可行的敏捷产品路线图。

1 、聚焦意图和收益

当您面对敏捷、动态变化的环境时,无论产品尚不成熟,或者产品正在经历重大变化,或者市场正随着某些全新竞争对手的进入或全新技术的引入而变化,您都应该使用面向意图的产品路线图(a goal-oriented product roadmap),有时也称为基于主题(theme-based)的产品路线图。面向意图的产品路线图着聚焦于意图、目标和类似于赢得客户、增加参与度和消除技术债的结果。在路线图上仍然存在特性,但它们源于意图,并且应当被谨慎使用。一般来说,每个意图对应的特性仅限于三到五个。
Read more

srchttp___img3.doubanio.com_view_note_l_public_p53477936.jpgreferhttp___img3

如何避免产品Backlog的这七个常见错误

本文译者:廖靖斌Eric Liao,资深敏捷教练,Scrum培训师,SAFe培训师
原文作者:Roman Pichler
原文链接:https://www.romanpichler.com/blog/product-backlog-mistakes/

产品Backlog是一个简单而强大的工具,用来捕获产品创意和调整产品决策,并且为开发工作的方向提供指引。不幸的是,想要用好产品Backlog这个工具并不容易。本文讨论了七个常见的产品Backlog错误,以帮助您识别和规避这些错误。

产品Backlog太大

几年前,一家医疗保健公司期望我能够在敏捷转型上提供一些帮助,特别是敏捷转型后对产品管理的影响。这个公司的敏捷转型团队所关心的一个关键挑战是如何选择正确的产品Backlog工具。一开始,这让我觉得很诧异。但是,当我知道他们的Backlog的条目有超过4万条时,我知道这才是问题所在。 毋庸置疑,这是我迄今为止见到的最大产品Backlog。但我发现,我经常会遇到几百到几千个条目的Backlog。但这样的产品Backlog是难以理解的,更不用说调整优先级和更新了。这是有问题的,特别是对于新产品和那些需要进行重大调整的产品,比如延长产品的生命周期,这些情况下,产品Backlog往往是不稳定的,需要频繁的调整,有时候调整会很大。 Read more

Scrum_TP

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

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

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

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

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

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

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