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

Scrum_11

获得和改进快速反馈的七种方法

在高中和大学里我作为游泳运动员时学到了快速反馈的重要性。像绝大多数人一样,我在游泳池开启了我的游泳生涯。如果你在游泳池偏离了方向,很快就会碰到泳道线并得到反馈。

最终,我厌倦了在游泳池里一圈一圈地游,转而到开放水域里。与在游泳池里每25米折返一次不同,游泳运动员在开放水域里通常在两个或者多个点之间要游数英里,比如游跨海湾。

在海里游泳的时候并没有泳道线帮你保持在航道上,而是你自己要设定一条路径,如果你偏移太多,你最终会比你预期的游得更长。
游泳运动员保持航道的主要策略是时不时地抬头以确认路径。

他们获得反馈的频率越高偏离航道的可能性就越低,于是多久抬一次头就很关键,太频繁很容易累,次数不足就会容易偏航。
这与敏捷团队如出一辙,在Scrum中短的反馈循环为团队提供了多种检查和调整的机会以确保产品朝着正确的方向发展。

增加和改进反馈

让我们看看做哪些可以改善反馈的时机和它的用处。

首先,如果你还没在每个迭代结束的时候举行评审会,那是时候开始了。一些团队认为他们是在通过降低冲刺评审频率来节约时间,但这会因为一次迭代中的小误解可能在几个迭代后变得更严重而产生问题。

在员工分布在全球各地的时候,你还需要考虑给那些没办法参加现场评审的员工分享一下会议记录。在某些情况下你可以实录评审会,不过在大多数情况下,为新功能演示创建一个讲解视频对你更有帮助。

如果在每个迭代你都创建这样的屏幕录制,这件事儿就会变得很快,毕竟通常不会有太多的新增功能。屏幕录制的链接可以所有人共享,也可以仅仅给那些没能参加的人。你可以要求人们直接发给你反馈或者让人在视频的页面下面留下反馈。

在迭代评审会之外,你也许会考虑开展一系列一次一个的特性评审。在实现每个特性时,只给少数提需求的干系人和用户展示以征求他们即时反馈。

并不是每个参与迭代结束评审的人都需要对每个特性提供反馈。和对应的干系人进行一次一个的评审通常可以尽早产生更高质量的反馈。

微信图片_20220805110128

在征求反馈的时候需要问多样化的问题。在很多评审会上,唯一被问到的问题是“你觉得怎么样?”,而通常也仅仅会得到像“我喜欢”这类很难对其有任何行动的评论。

我喜欢很多东西,但是很多东西都有变得更好一些的可能。我喜欢来自附近玉米卷卡车的玉米卷,但如果能更辣就更好了。
问“你觉得怎样”通常得不到我们需要的更确切的反馈。取而代之要问更多具有目的性的问题,诸如:

• 我们是否忽视了一些用户可能想在这做的事儿?
• 是否我们的某类用户会对此感到困惑?
• 你认为这里有什么是我们可以省去的吗?

进一步深入:当问这些问题的时候,考虑向特定的人发问,而不是问所有人。当然,要对任何人的评论都保持开放的态度。但是向特定的参与者直接提问可以减少尴尬的沉默,并且有时可以带来更好的对话。

评审的时机也很关键,请尝试在这些特性100%完工之前就演示和获得反馈。假想你在开发一个仅能在10个产品待办列表的条目完成以后才可以交付的新功能。别等到第10个,也就是最后一个待办项完成以后才征求反馈。

只要可行,尽量直接从用户而不是代表用户发评论的干系人那里获取反馈。对于内部使用的产品,尽可能简单直接地邀请用户一起参与评审。对于商业化的产品,你可能需要为用户能分享反馈而创建一个公共论坛。

最后,确定团队在做计划的时候为这些反馈所需采取的行动规划了时间。对干系人和用户来说没有什么比自己提的反馈被忽视更令人沮丧的了。

要点回顾

下面是七个可以帮你提升反馈的质量和实效性的要点:

• 如果还没有开展迭代评审会,请即刻开始。
• 给那些没能参加评审的人发送一份录屏。
• 给那些提特性要求的人做一次一个的特性评审。
• 针对特定的个人问更多有目的性的问题。
• 对部分解决方案征求反馈,而不是等所有的产品待办项都完成以后。
• 向用户寻求反馈,而不是那些代替用户评论的干系人。
• 为团队根据反馈而需要采取的行动预留时间。

快速且频繁地获取反馈让团队可以打造满足用户需求的产品。一个团队如果很少收到反馈,那么在发现偏航时就不应该感到惊讶,好比一个游泳运动员对是否接近尼亚加拉瀑布失察一样。

你怎么看?

你如何确保你能尽早获得有价值的反馈?请在下面的评论区分享你的想法。

注:部分图片来源于网络

原文地址:

https://www.mountaingoatsoftware.com/blog/7-ways-to-get-and-improve-fast-feedback

关于作者 & 译者

【作者】Mike Cohn

Mike是敏捷联盟及Scrum联盟创始人之一,是帮助企业适应和改进敏捷过程及技术,以建立极致高效团队的专家。著有《用户故事与敏捷方法》,《敏捷估算与规划》,《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。

【译者】Scrum中文网翻译组

Scrum中文网是全球第一个Scrum中文网站,中国最早的Scrum和敏捷教育及推广机构,也是国际Scrum联盟(ScrumAlliance)官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。
Scrum中文网是国内领先的敏捷培训及教练咨询机构,作为中国敏捷教练的摇篮,启蒙和培养了数万名敏捷专业人士,帮助数百家知名企业成功转型敏捷。

 

Scrum_tp

三个方法帮助敏捷团队与不确定性共舞

不确定性无处不在。当我写这篇文章的时候,我正在等水管工人,他已经迟到了一小时。他今天还来吗?什么时候来?

天气预报APP告诉我,今天应该是个晴天,而我却看见窗外正在下雨。

今天早些时候,我向开发人员提了一些需求变更。我大致知道我想要什么,但并没有考虑好所有细节。由于我思维里的不确定性,我也将不确定性带进了他们的世界。 Read more

4

如何进行多团队故事点估算

当组织实施规模化敏捷时,企业往往面临着管理多团队的挑战。而如果有多个团队在一个项目中工作,协作就变得更加复杂,尤其是在做估算时。

团队需要进行估算和计划,并根据计划跟踪进展,以便产品负责人对工作进行优先级调整,并与干系人沟通出最后交付产出物的时间。

但多团队工作带来了一些额外的挑战,包括: Read more

封面

在Sprint中可以更改Sprint Backlog吗?

Scrum里不真实的二十件谣言之二:在Sprint当中是不可以更改Sprint Backlog的

1

很多人都说Developers承诺了交付在Sprint Backlog里的所有的内容,所以不可以增加减少或者修改任何Sprint Backlog,这样团队才有必要的专注力完成他们的承诺。

这是一个听上去多么有道理的说辞啊,但是它是正确的吗? Read more

Scrum_tp

Scrum团队初建的十一件事

越来越多的公司(IT/非IT)正在做或者计划做Scrum转型。很多的团队往往对于转型无从下手,且转型开始后实际效果往往并不如人意。在这里我们系统性的去讲一讲怎么把一个新的Scrum小组从0做到1,怎么让大家快速热身起来

1. 要有充分的准备期

很多的公司可能拍脑袋说我们下周开始做Scrum吧,然后Scrum就开始了。还有一部分公司请Scrum Coach来给大家做一个两天的培训,然后就期望Scrum团队就完美了。

希望是美好的,现实是残忍的。如果我可以选择Scrum 培训热身的时间,我觉得1-2周会是一个比较合适的时间,给团队足够的时间去消化理解,因为在Scrum Guide里清楚的写明了Scrum is easy to use, but hard to handle。不过我并不赞同完全设置培训Sprint,在开始的Sprint我们还是要交付增量的,但是我们可以交付的少一点。
Read more

Scrum_tp

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

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

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

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

误区一:我们的团队不是很主动,如果不给他们分派任务,他们就无法开展工作。

敏捷团队的工作方式和传统的经理领导的团队的工作方式的一个最主要的差别在于决策机制。经理领导的团队,由经理来决定谁做什么,团队成员听经理的安排就可以了。敏捷团队,由团队来决策谁做什么,是团队商量着办。

有人可能认为,经理决策不是很好吗,又快又好,因为经理知道谁的能力怎么样。

但是,这种决策机制带来的问题是:

第一,对经理依赖比较大,经理的能力决定项目的成败;

第二,团队比较被动,参与感比较差;

第三,责任在经理肩上,团队只负责完成被安排的任务。

领任务,背后的核心逻辑是团队负责和团队决策。所以,如果要让团队能够很好的开展领任务的工作方式,第一件要做的事情是让团队学会协作和集体决策。

团队的Scrum Master可以引导团队制定他们的工作协议(自组织团队的工作约定,这个在后续的实践文章中介绍),包括如何决定团队每天的目标,如何决定每个人如何对每天的团队目标进行贡献,以及如何分工合作等约定。在每天开站会的时候,大家按照约定来商量着办。

误区二:如果大家都领简单的任务怎么办?

如上面误区一中介绍的那样,团队领任务,核心逻辑是团队决策,而不是个体自我决策,不是我想领什么任务都可以。团队决策的时候,需要基于迭代的目标来分析每天的目标,基于团队每天的目标来决定团队成员每个人的目标。

误区三:如果能力比较差的人,领取了比较难的任务,他完不成怎么办?

自组织团队的团队决策机制,让每个团队成员有了更多的参与机会。然而,自组织团队的目标是迭代成功、项目成功。

自组织鼓励团队的参与,和挑战更高的目标,让团队成员能够不断成长。所以,能力差的人,领取到比较难的任务,这种情况是可能发生的。但是,自组织团队要根据任务的进展情况,及时的发现可能产生的风险和障碍,必要的时候让其他队员进行协助,以确保迭代的目标不受影响。

 

本文作者:廖靖斌 Eric Liao, Scrum中文网资深敏捷教练、顾问和培训师,CSP

 

WechatIMG80

如何使用Leangoo做测试管理?

“软件测试是指在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。”

在敏捷需求开发中,测试伙伴无法通过看板将测试用例和Sprint的故事进行绑定,每个Sprint的测试用例过多,无法对所有的测试用例进行统一管理和统计,造成了测试流程混乱等,无法保证功能回归测试的完善性。在多个Sprint同时开展时,也无法直观地看到不同Sprint内测试用例覆盖情况等等,以上这些问题导致Sprint中测试用例使用很繁琐、麻烦。

那怎么利用Leangoo解决上述问题,怎么用Leangoo做测试管理呢?
Read more

leangoo微信微信公众号

迭代中干扰不断,该如何应对?

理想情况下,Scrum团队能完全不受干扰地实施Sprint工作。产品负责人永远不会引入变更,客户永远不会提出紧急需求,用户也永远不会发现任何缺陷。

尽管团队都渴望能有一个不受干扰的Sprint环境,但大多数团队都无法独善其身。绝大多数Scrum团队确实得在Sprint中处理各类干扰。

如果只需将团队迭代的5-10%用于处理干扰,并不会给团队带来太大问题。
Read more

Scrum_tp2

是否需要在Sprint计划会上分完所有任务?

小时候,妈妈教我系鞋带。我已经记不清具体每个步骤了,但应该是采用了兔耳朵系鞋带法。

那以后,我了解到有很多种不同的鞋带系法,其中多数方法都更好用。大多数方法会更适用于某些特定环境:宽脚、窄脚、高足弓等等。
从首次系鞋带至今,我已学到了很多。同样,从在首个敏捷团队工作至今,我也已学到了很多。
Read more

111

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

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

1. 您的时间

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

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