文章频道为您提供Leangoo实践，以及Scrum,敏捷,精益创业,产品创新等领域专业文章。
你想成为一个优秀的Scrum Master吗？
我想是的，除非你是一个产品负责人或者其他的角色。我作为一个Scrum Master已经有20多年了，这些年，我给出了很多很多的建议，也收到了很多建议。我甄选出了我认为最棒的十个建议给大家。
1. 如果没有和团队商议，请不要代表团队做任何承诺
作为一个Scrum Master，你没有任何权利代表团队接受需求变更，不管它有多小。即使你可以完全确定团队可以搞定它。你可以这么来回答：“我需要和团队沟通后再确认是否可以接受。”
当然也不能在没有和团队商议的情况下承诺任何交付日期，交付物，或其它的任何东西。当然，你也许不必每次都召开全员会议来和大家沟通，有些情况下，团队内的部分相关成员经过沟通后也是可以做出决定的。但是，这仍然是团队的决定，而非你的决定。
Read more →
当前版本主要进行了一些功能优化和bug修复。
敏捷团队有一个常用的度量指标——团队是否完成了迭代规划的全部工作。
评估团队多擅长完成其承诺，这并没有错。但不能要求团队每次迭代都完成全部工作。
这不现实，并且会导致团队为了安全交付所有工作而保守地承诺。
期望过高会导致运作失灵
我知道有这样一个团队：团队老板（就是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
春节期间，新型肺炎疫情肆虐全国，假期即将结束，但是疫情还不知道何时才能缓解，多数企业可能不得不选择在家远程办公。对于不需要大量团队协作的岗位，比如销售、客服等，准备好电脑、电话基本就可以开工了，但是针对研发型的一些团队，如何开展远程协作办公将会是一个巨大的挑战。笔者根据自己曾经辅导分布式敏捷团队的一些经验，给大家一些可参考的建议。
在家办公，由于家庭环境的影响，比如需要照看小孩，老人，时间节奏往往不是那么的规律。 因此，团队首先需要对每个人的作息时间进行统一的约定，比如每天的上班时间，中午的休息时间，晚上下班的时间，敏捷团队会议的时间安排等。
及时通讯讨论群就不说了，平时都在用。由于敏捷团队需要每天开站会，不定时还需要团队成员之间协作讨论，所有多方视频通话和屏幕共享是必须的，可以使用Zoom、Teamviewer，微信群视频，或者钉钉，飞书等工具。
代码仓库的建立通常有这几种可以参考的思路：
第一， 也是最快的方法，将你的代码托管在类似于Github私有代码仓库这样的代码托管平台上。
第二， 用Gitlab或其它工具，在阿里云，AWS等云平台上自己搭一个
第三， 使用VPN连到自己企业的企业内网
持续集成环境、集成开发和测试环境，如果您原来就在云上的，就比较简单，如果不是，有两个思路：
第一：在阿里云，AWS等云平台上搭建环境
第二：使用VPN连到自己企业的企业内网
1） 有很多敏捷团队管理需求直接使用的是物理的故事卡和故事墙，在远程工作环境下，这个会是一个大问题。推荐使用一些可视化的电子看板工具比如Leangoo，来代替故事卡和故事墙。
2） 针对需求的协作，还有一个比较突出的问题是，如何进行远程的需求梳理活动，需求梳理活动通常需要团队一起共创完成需求细化、编写用户故事的验收条件等。 那么远程环境下怎么来开展需求梳理呢？我们推荐的方式是使用视频会议+Leangoo协作式脑图来进行。Leangoo提供了一个多人实时协作的脑图，通过这个脑图我们可以实现从Epic到Feature、Story、AC（验收条件）的四层结构可视化，并且团队成员可以共同远程实时编写故事和验收条件。
3） 需求确认和设计效果的确认
很多时候，我们无法在梳理会上完全确认所有的需求，相关的设计效果，在进入迭代后也会根据需要进行调整，笔者的一个实践是，设计师可以将设计的效果进行视频录屏，及时的发到开发群进行讨论和确认。
1）物理的任务看板，在这个时候，可以通过实时的可视化电子看板替代，电子看板一定要便于操作，能够达到接近物理看板的易用性。Leangoo工具提供了实时同步，实时协作的看板，非常易用，可以实现可视化和透明化的管理。 
2） 远程Sprint计划会议
计划会议通常做两件事情：第一，明确迭代目标；第二，讨论设计，确定如何实现目标，并拆分任务。
计划会议期间，肯定会涉及到方案的讨论，写写画画是必须的，我们的实践是使用Surface 的手写笔+OneNote 画布，通过Teamviewer共享屏幕来进行方案的讨论。
任务分解我们使用Leangoo实时协作看板，多个人同步进行任务拆分。
3） 远程的每日站会
每日站会是一个15分钟的面对面的站立会议，远程的情况下，我们可以采用视频会议加上实时同步的看板结合的方式进行。
4） 远程迭代评审
迭代评审，可以通过Teamviewer/Zoom共享屏幕，视频会议的方式开展。
5） 远程的迭代回顾
远程的迭代，我们的实践是通过Leangoo共享的实时协作脑图+视频会议来进行，脑图可以是头脑风暴的方式，海星图的方式或者根因分析图的方式，有很多种思路。
6）缺陷和问题的跟踪
缺陷和问题的跟踪，如果是当前迭代的缺陷，直接放到迭代看板上处理就可以了，如果涉及到遗留的缺陷，可以使用leangoo的缺陷看板来来进行实时跟踪。
7） 迭代过程的Showcase
开发团队开发好的功能，及时的将做好的功能录视频发到开发群跟PO确认，不要让PO等到迭代结束才看到。
8） 开发过程中的讨论
有时候你会发现，团队会在聊天群针对一个问题，无休止的发信息讨论，当有多次信息往复的时候，团队就要有意识的终止群讨论，通过电话或视频进行沟通，遇到这种情况Scrum Master可以提醒团队。
在这段艰难的时期，期望上面的这些小小的建议能够帮助到您和您的团队，大家共度难关。以上提到的这些Leangoo工具中的功能，所有团队都可以免费使用。
祝愿所有的朋友们新年快乐、身体健康、阖家幸福！
上篇介绍了如何使用Leangoo思维导图实现影响地图。本文，将介绍如何用Leangoo脑图来做多级需求管理。
什么是Epic？
Epic是史诗故事，通常需要花费多个Sprint来开发和测试，才能完成最终的交付。它通常范围比较大而细节描述较少，Epic的粒度比较大，在团队开发前通常需要拆分成多个更小的用户故事。
假如构造月度销售报表科目时，可能有这样的史诗故事：“作为销售经理，我希望能分区域看销售数据”。
什么是Theme？
Theme是指主题故事，是一组相关的用户故事的集合。Epic通常比较大，会分解出很多个小的用户故事，我们可以根据这些故事的相关性，通过Theme主题故事对其进行分组。
什么是Story？
Story是User Story的简称，用户故事是从用户的角度来描述用户渴望得到的功能。
用户故事通常按照如下的格式来表达：
Read more →
影响地图是一个工具，它建立了业务价值到产品功能的映射。本文将介绍如何通过Leangoo脑图创建影响地图，并且基于影响地图进行需求规划。
Leangoo 的5.8.12版本发布了Leangoo的脑图功能。Leangoo脑图是一个共享的思维导图，它具备了思维导图的所有属性，但它绝不仅仅是一个思维导图。那么Leangoo脑图有什么不一样呢？主要有如下三点：
所以，它可以用来代表需求、任务、测试或者一篇文档等等。而且每个节点都可以引用到看板上。
有了这些特性， Leangoo脑图就十分强大了。针对敏捷研发，Leangoo脑图有很多实用的场景，比如实现影响地图、用户故事地图、多级需求管理，知识管理、测试案例、迭代回顾等等。我们将通过一系列的文章来介绍这些实用场景。
本文，我们先从影响地图开始，介绍如用Leangoo脑图来实现影响地图。
在本系列文章的第一篇和第二篇，我们分别介绍了Spotify的敏捷研发团队和研发过程。
在本篇，我们将介绍Spotify的敏捷工程文化。
Spotify通过文化和价值观来进行管理，在本篇中，我们从如下八个方面来介绍Spotify的敏捷工程文化：
一、 如何管理小队的自主性
二、 如何管理标准化
三、 如果做到以人为本
四、 如何管理部署上线
五、 如何管理创新
六、 如何管理失败
七、 如何处理浪费
八、 如何管理文化
在本系列文章的第一篇，我们介绍了Spotify的敏捷研发团队，以及它独特的组织架构。在本篇，我们将介绍Spotify基于敏捷开发和精益创业思维的产品研发过程。
在本系列文章的第一篇，我们介绍了Spotify的敏捷研发团队，以及它独特的组织架构。Spotify的研发团队采用的是一种非常独特的组织架构，如下图所示：
2018年4月，来自北欧瑞典的音乐流媒体公司、百亿美元独角兽Spotify创造了历史，它成为了当代上市公司当中，第一家通过“直接上市”的方式在美国纽交所成功挂牌的公司。这家公司改变的可能不仅是人们听音乐的习惯，而且还有企业进入资本市场的方式。截至2018年初，Spotify拥有1.59亿的全球活跃用户数量、7000万的付费用户数和46%的付费用户增长率。Spotify是当之无愧的音乐流媒体领域的霸主，排名第二的苹果音乐，无论是付费用户还是活跃用户，都只有Spotify的一半。
是什么成就了Spotify？他们是如何打造出这么一款深受用户喜爱的产品的？幸运的是有Henrik Kniberg的存在。Henrik Kniberg是全球知名的敏捷和精益教练，也是一位多产的作家，他参与了Spotify公司的这一过程，并写下了多篇文章，向外界揭开了Spotify公司的神秘面纱。
笔者通过自己的收集和整理，梳理出了Spotify敏捷模式的整个过程，并通过一系列的文章呈现给大家。在本期的文章中，笔者将首先介绍Spotify的研发团队。 Read more →
敏捷开发团队（Scrum团队）在每天开每日站会的时候会领取当天的任务，这个实践在敏捷开发中叫做sign-up-for-tasks即领任务。这个实践源自极限编程，在1998年，极限编程最早期的介绍中提到了，“指派任务”和“领任务”是传统方式和极限方式的一个显著区别。
领任务是指，团队成员在任务卡上写上自己的名字，或者贴上自己的照片，表明这个任务，由这个成员来负责。领任务的活动通常在开展每日站会的时候进行。领任务的方式体现了团队自组织的工作方式，传统模式下的经理指派任务是命令和控制的工作方式。
领任务的实践看似简单，但是在实践中往往很难做好，通常存在如下几个方面的误区：
Read more →
