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

sad22

西瓜创客+Leangoo敏捷实践案例分享

333

西瓜创客是一家知名在线少儿编程教育公司,面向7-12岁的小朋友提供编程启蒙与思维训练,全面提升孩子的学习力与创造力。

西瓜创客的编程课自2017年4月在互联网上第一次亮相至今,已经获得了来自红杉和经纬等一线基金近亿元投资,成为全球六十多个国家十万个家庭和孩子的选择与热爱。西瓜创客80%的用户来自国内一线与新一线城市的高学历、高净值与高认知家庭,并且逐渐获得二、三线城市新中产家庭的追捧。

企业内部项目管理和团队协作遇到的问题、困境

时值2018年夏至初九,西瓜创客完成A轮融资不久,正由MVP阶段向高速增长阶段跃迁之际,聚各路开发、产品大佬于马尔代夫(实际上是间会议室名称)共商大事,讨论如何更加高效、规范的进行产品迭代。

从印度洋北上的风掀起卷帘挤入会场,会议开场后,众人皆道:当用敏捷开发。随即多位大佬打开MacBook,轮番将自己研习多年的敏捷开发Keynote投屏向大屏幕,台上口沫纷飞,台下肯瓜四溢,然而两小时后得出了一个可怕的结论:除了「应该两周一个迭代」,其它就没有什么共同点了,各自曾今所在团队癖好、奇技淫巧可谓八仙过海,听着很丰富,但总觉得缺了些什么,也并不足以确定西瓜团队的敏捷开发如何执行。

敏捷开发一定不是「两周做一个迭代」这么简单,也一定不是一些敏捷工具软件上看着就头晕的复杂界面;也不是一堆白板便利贴那样的混乱无序;敏捷开发也并没有一个绝对的规范手册,如果你读过多位敏捷大师的名著,甚至发现还划分不同的理念和流派。

最终我们明确到,产品迭代的目标是快速持续的交付用户需要的产品,而敏捷方法论的作用是调动团队的协调性,用更快的节奏贯穿产品需求收集、细化拆解、开发、测试、上线全流程,从而实现快速持续交付用户需要的产品的目标。

然而协调和调动不同部门的同事遵循敏捷方法不能光靠嘴,也没时间让每个同事都诵读《用户故事与敏捷方法》,如何简单快速让敏捷方法落地,成了一个难题。

为什么选择了Leangoo

简明,可以说是选择Leangoo的核心原因,因为只有足够简明,才能让不同团队成员快速上手,降低沟通成本,甚至能让一名新加入的伙伴在一个早晨站会的时间就能搞懂怎么用。

敏捷开发的条条框框很多,Leangoo显然抓住了其中最能解决问题的核心点,Leangoo产品的核心要素只有列表、卡片、泳道3个。

  • 列表用来表示卡片在进度上所处的状态,与大多数看板类工具类似,例如可将创建的任务卡片分配到待开发、待测试、已发布等不同列表中;
  • 卡片表示用户故事或者任务,而如果这个用户故事或者任务还拆成了一些子任务,多数工具是让你在卡片之内添加「检查项」,这其实很不直观,也难以评估子任务的进度状态,而Leangoo中,由于加入了泳道,子任务不再是卡片内的检查项,而是一张完整的卡片;
  • 泳道,正是Leangoo的一大创新点,一个故事卡片在一条泳道上横向移动,每一列列表,就是卡片移动的步伐,这种方式能清晰的看到一个用户故事从故事卡片,到拆解成若干个任务卡片,到任务评估开发点数,到任务分配到具体的工程师,到任务陆续进入到「待开发」、「开发中」、「待测试」、「已完成」、「已发布」等状态的全过程,非常直观。尽管任务可能很多,每个开发者只需要过滤出自己的任务,就非常清爽了。

123

 

当前用Leangoo进行协作的一些实际场景

西瓜团队基于Leangoo官方推荐的看板模板,进行了一些小小的拓展,简单总结就是4种看板,3种角色,2种会议:

首先分为4大看板:

1. Backlog看板:

就是用户故事池,这里存放所有经过评审与设计的用户故事,通过列表将这些用户故事分为「以后的Sprint」「下一个Sprint」「SprintN」「SprintN-1」……;通过泳道将用户故事分为「学生端」「教学端」「运营后台」等大的板块。

2. Sprint看板:

Backlog中的一个「SprintN」列表,经过Sprint计划会讨论确定后,就单独创建成一个看板,即Sprint看板,用Leangoo的整个列表引用功能,可以轻松的将Backlog中一个Sprint列表里的故事,「引用」到Sprint看板的「故事」列表中,再给这个Sprint看板设好开始结束日期,就可以进行这个Sprint的冲刺啦。

3. 缺陷看板:

缺陷看板集中记录产品的bug,跟踪bug的状态

4. 产品计划看板:

产品计划看板用来管理待讨论、待评审的需求,也会记录一些非产品需求的临时任务,这里的每个卡片会设定一个截止日期,截止日期并不是说到期要做完,而是一个check point,每天产品站会会表述当天截止卡片的进展和下一步计划。所以当天截止的卡片会挪到「今日」列表,后续到期的卡片会挪到「已计划」列表,还没有任何计划的卡片先进入Inbox「待处理」列表。

当一个卡片从idea到讨论确定、完成需求评审后,就会挪到「已提需求」列表,同时将该卡片引用到「Backlog」看板;而临时任务如果完成了,就挪到「已完成」列表。

 

然后是3种角色:

  1. 产品经理扮演Scrum中的「Product Owner」负责管理「Backlog看板」、「产品计划看板」,主要是创建用户故事卡片,制定卡片优先级;
  2. 开发组长扮演Scrum中的「Scrum Master」负责管理每个「Sprint看板」,与产品经理核对每个用户故事卡片是否合理,是否需要进一步完善;然后Sprint计划会中负责为每个用户故事卡片分配开发人员,在每日站会中负责协调曝出的问题点或给出指导意见;
  3. 开发人员就是Scrum中的「Developer」负责关注「Sprint看板」,将分配给自己的用户故事拆解成一个个技术任务卡片,并为每个任务卡片评估开发时间。在西瓜团队,我们规定1个故事点表示0.5个无打扰人天,一个任务卡片原则上最多不能超过4个故事点,超过应该细化拆解成更小任务卡片;ScrumMaster会协助评估故事点数,确保点数分配合理。

 

最后是2种会议:

1. 每日站会:

在西瓜团队,每日站会是重要的惯例,每天早上一到上班时间,产品、开发成员就聚在一个大屏幕前,大屏幕投出当前的Sprint看板,然后每个开发对着Sprint看板讲述自己昨天完成的任务和今天计划做的任务,同时如果遇到任何困惑、任何的坑、发现任何的风险点都在站会中提出来,站会时间基本上控制在15分钟,站会上记录问题点,但不谈具体细节,细节在会后相关人员自行讨论。

这样整个团队每天一早都会获得信息同步,避免信息不对称造成的损失,同时又节约了大家的时间。这么好的事一定不能省。

除了早上的开发站会,每天晚上下班还有产品站会,所有产品经理聚在一个大屏幕前,大屏幕投出「产品计划看板」,然后每个产品经理对着看板讲述自己截止日是今天的卡片有什么进展,下一步计划,有需要头脑风暴或评审的需求,也一并在这里讨论。

2. 每两周进行一次的Sprint复盘/计划会:

在一个Sprint结束后,所有项目成员聚在一间较大的办公室中,回顾一下刚刚结束的Sprint完成情况,此时Leangoo的燃尽图提供了一个直观的展示;复盘一下遇到的坑,总结一下之后应该改进的点。

复盘大概进行20分钟,然后就是下个Sprint计划会,Sprint计划会需要由产品经理依次讲述每个用户故事的需求详情,然后当场分配开发,评估故事点数,这注定是一个持久战,咖啡、果汁、零食是标配,这很重要,因为长时间精神集中又饥饿的话,容易引发身体不适。Sprint计划会虽然长,但毕竟2周一次,减少了平时的会议,可谓集中时间办大事。

 

 

456

 

 

通过使用Leangoo工具,为团队带来哪些变化

 

“真正的竞争对手并不是其他竞品,而是不断变化的「客户需求」。而生意萧条的原因只有一个,即现在的工作方法已经无法满足时代和消费者的需求变化。”
————日本Seven-Eleven创始人铃木敏文

 

市场与用户需求瞬息万变,借助Leangoo工具,西瓜团队短时间内搭建起了敏捷开发流程,实现了快速持续交付用户需要的产品。

上文说到Leangoo的简单易用对团队上手起到了重要作用,使用Leangoo一段时间后发现,尽管任务越来越多,按照整个流程执行,整体结构依然保持着清晰,对相应的角色保持着相应的确定性;上手简明和数据量多了之后能持续保持简明,保障了西瓜团队持续的产品迭代。

随着每个Sprint中一个个用户故事持续上线,就像是打怪升级一样,每个团队成员都充满成就感,脸上洋溢着喜悦。

关于西瓜创客 

222bg

西瓜创客,致力以教育的初心、科技的力量与创客的精神,释放每一个孩子的创造力,成为他们未来梦想的燃料与火焰。

课程特点

西瓜创客的课程以内容有趣,服务用心和结果有效而著称。

【内容有趣】课程基于儿童心理学与认知学设计,特别能激发孩子们的学习兴趣和自我驱动力,让孩子们具备既勇于探索和创造,又细致坚韧耐挫折的品质。

【服务有心】无论是在线辅导还是作业批改,也无论是问题回复还是家长访谈,我们都坚持人性化地引导和激励,保护孩子们的好奇心,鼓励他们去迭代和创造,跟家长们持续同步最先进的教育理念与方法

【结果有效】基于海量学习行为大数据分析与用户反馈,西瓜坚持快速迭代自身的课程体系和内容,保障孩子们学习的有效性,过程让家长省心,成果让家长放心。

课程体系

西瓜创客编程课分为基础、进阶和应用三个阶段。

【西瓜创客编程基础课】每个月开两期,以游戏化的方式教授孩子们 Scratch 编程语法和计算机基础知识,培养孩子们的计算思维和基础编码能力;

【西瓜创客编程进阶课】分为未来世界与人工智能两个大的方向,基于Scratch 和 Python 语言完成无人车、密码破解、人脸门禁、智能环保箱等等独立项目,来全面提升孩子们的创意、认知、表达、沟通和协作方面的能力;

【西瓜创客编程进阶课】深度掌握 Python 语言,学习其他编程语言(C++、HTML、CSS、Javascript等等)的基础语法以及不同场景下的典型应用。比如:数据分析、网站制作、

App 与小程序开发,通过可编程器件控制飞行器和机器人等。学习后可以独立开发自己的软件,成为一名具备创造性解决问题的小创客。

创始人

肖恩 / Shawn

德国科隆商学院BWL硕士,西南交大电子信息工程硕士,苹果与三星官方推荐音乐类 App 创作者,儿童心理学与认知学专家。个人爱好非常广泛,包括摇滚、DJ、徒步、滑雪、潜水、摄影等。

钟鸣 / ET

美国纽约大学硕士,图像识别与增强现实以及无人驾驶汽车方向专家,热爱编程,也热爱历史人文和音乐,曾经为不少团队制作过音乐音效,也擅长即兴钢琴、吉他、音乐创作编曲等。

了解更多

网站:www.xiguacity.cn

微信:西瓜创客(公众号)

xiguachuangke1

scrum中问网&leangoo想知道敏捷为什么叫敏捷吗?

想知道敏捷为什么叫敏捷吗?

原文作者:Jim Highsmith

译者:大卫张33

译者按

本文译自:http://www.agilemanifesto.org/history.html

要想了解敏捷软件开发,这篇文章是必读,对学习敏捷中的不少疑惑都给出了解释。感谢@AgileCoach和@徐毅-Kaveri的审校。

leangoo敏捷宣言

 

2001年2月11日至13日,在美国犹他州瓦萨奇山雪鸟滑雪胜地,17个人聚到一起,交谈、滑雪、休闲,当然还有聚餐。他们试图找到共识,最终的成果就是《敏捷软件开发宣言》(Manifesto for Agile Software Development)。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

由全体参会者签署的《敏捷软件开发宣言》(Manifesto for Agile Software Development)成为了重要标志,因为这么大一帮无政府主义者能聚到一起实在是太不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心,他认为多数美国人都不知道“敏捷”这个词如何发音。

Alistair Cockburn和很多参会者一样,最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后,他再次分享了自己的感受。“对我来说,很开心宣言能够最终定稿。而让我感到惊讶的是其他人也同样开心,因此我们的确达成了某种实质性共识。”

这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站(http://www.agilemanifesto.org/)首页的《敏捷软件开发宣言》,他们称自己为“敏捷联盟”。
但多数人(如果不是所有的话)成为联盟成员的动力不仅仅是因为宣言上列出的那些理由,他们还有着更深层次的考虑。在长达两天的会议临近结束的时候,Bob Martin半开玩笑地说他打算谈点“虚的”,讲讲“空话”。Bob这话虽然有玩笑成分,却得到了几乎所有人的响应。因为我们都会非常乐于与一群拥有相似价值观的人一起共事,这些人会相互信任与尊重,会促成以人和协作为本的组织模式,能构建大家都愿意为之贡献的组织社区。本质上讲,我相信敏捷方法学家们确实要玩这些“虚的”东西。为了交付好产品给客户,他们会切实去做,不止是口头上说“人是我们最重要的资产”,还要从实际中体现出人本身就是最重要的,去掉“资产”这个提法。因此在最后的讨论过程中,敏捷方法学家们对价值观和文化这些“虚的”东西表现出了极大的兴趣,有时甚至会进行激烈的争论。

例如,我认为,极限编程呈现出强劲的发展势头,其根源不在于结对编程或重构等实践本身,而是从整体上看,极限编程能让开发人员们摆脱“呆伯特”组织中那些腐朽观念的束缚。Kent Beck分享了他早年的一次亲身工作经历。当时他估算的开发工作量是2个人做6个星期。结果在项目开始的时候,经理临时换了另一个人和他一起工作,最后他们花了12个星期才完成项目。他的感觉很糟,因为在后面6个星期中间,经理一直喋喋不休,嫌他太慢。Kent有点沮丧,觉得自己作为一个程序员实在是太失败。到最后,他终于意识到最初2个人做6个星期的估计其实是相当准确的。这不是他的失败,是管理者的失败(指临时换人这件事),实际上是那些持续祸害着我们这个行业的,所谓标准化、流程化的“僵化”头脑的失败。

同样的事情每天都在重复发生。市场人员、经理、外部客户、内部客户,当然,也包括开发人员,谁都不想难为自己,去做出那些艰难的、需要折衷的决定。于是他们利用组织的权责划分将难题转嫁给他人,甚至提出荒谬的要求。这不仅仅是软件开发的问题,在“呆伯特”组织中它无处不在。

想要在新经济环境下成功,并引领电子商务和网络时代,那么公司一定要去除“呆伯特”式的行为表现,不要没事找事做,不要搞出那些没人能搞懂的规章制度。敏捷是一种解放,让人不再虚度时光。这吸引了敏捷方法论的支持者们,却把传统主义者吓得屁滚尿流(抱歉,在专业文章中说脏话了)。坦率来讲,敏捷方法吓到了组织中的官僚们,尤其是那些乐于为过程而过程,却不全力为客户着想,不想履行承诺按时交付可见成果的官僚们,因为这(敏捷)会让他们无处藏身。

敏捷运动并不是反方法论的,事实上,我们中的大多数人正在试图恢复方法论的名声。我们希望能重归平衡。我们乐于建模,但目的不是给无人问津的企业资源库增加几篇图表存档。我们要写文档,但那些从不维护、并很少用到的长篇大论不算在内。我们得做计划,但同时也要认识到在剧烈变化的环境中计划的局限。有些人给XP、Scrum或任何一种敏捷方法论的支持者们打上“黑客”的标签,这只表示了他们对方法论和黑客本意的无知。

2000年春,Kent Beck组织了一次会议,地点在俄勒冈州的罗格里夫酒店,参会者包括极限编程的支持者们和一些“圈外人”,正是这次会议导致了后来在雪鸟的聚会。在罗格里夫会议上,参会者们宣称了对一系列“轻量”方法论的支持,但没有发表什么正式声明。2000年期间一系列论文都被归类到“轻”或“轻量”流程,其中很多都提到“轻量级方法论,如极限编程、适应性软件开发、水晶系列和Scrum”。大家交流后发现,没人真正喜欢“轻”这个名号,但这似乎是当时约定俗成的称呼。

2000年9月,来自芝加哥Object Mentor公司的Bob Martin用一封电子邮件吹响了下次会议的集合哨。“我想召集一个为期2天的小型会议,时间是2001年1月或2月,地点在芝加哥,目的是让所有轻量级方法论的领袖们汇聚一堂。您们都被邀请了。如果您们觉得还有谁该来,请告诉我。”Bob建立了一个Wiki网站,由此开始了热烈的讨论。

很快,Alistair Cockburn就用一封书信加入了讨论,他表达了对“轻”这种提法的不满:“我不介意用‘轻’来描述方法论的轻重程度,但我并不愿意因参加一个轻量级方法学家会议而被看作是轻量级的。这听起来有点像一群干瘦、低能、并无足轻重的人在试图回忆起某个特定的日子。”

关于会议地点的争论最为激烈。芝加哥让人不爽,既冷又无趣;犹他州的雪鸟,虽然也冷,但至少对那些想滑雪的人来说还挺有意思,像Martin Fowler在第一天滑雪就滑个头朝地;加勒比的安圭拉岛,暖和又好玩,但路途太远。最后还是可以滑雪的雪鸟胜出,不过有些人(例如Ron Jeffries)还是希望下次能去个暖和点的地方。

我们希望,一起组成的敏捷联盟能够帮助到其他同行,帮他们用新的更“敏捷”的方式去思考软件开发、方法论和组织。做到这一点,我们就得偿所愿了。

Jim Highsmith,来自敏捷联盟©2001 Jim Highsmith

 

参考:

极限编程:敏捷软件开发方法的一种,缩写XP,英文全称Extreme Programming。

Scrum:敏捷软件开发方法的一种。

DSDM:敏捷软件开发方法的一种,英文全称Dynamic Systems Development Method。

自适应软件开发:敏捷软件开发方法的一种,缩写ASD,英文全称Adaptive Software Development。

水晶系列:敏捷软件开发方法的一个方法系列,都用Crystal开头。

特征驱动开发:敏捷软件开发方法的一种,缩写FDD,英文全称Feature-Driven Development

实效编程:不是一个方法论,是一个流派,英文全称Pragmatic Programming,

呆伯特(又名迪尔伯特):Dilbert,美国 Scott Adams 的有名职场卡通人物。呆伯特法则:http://zh.wikipedia.org/wiki/%E5%91%86%E4%BC%AF%E7%89%B9%E6%B3%95%E5%89%87

未标题-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