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

影响地图海报

如何使用Leangoo脑图实现影响地图

Leangoo 的5.8.12版本发布了Leangoo的脑图功能。Leangoo脑图是一个共享的思维导图,它具备了思维导图的所有属性,但它绝不仅仅是一个思维导图。那么Leangoo脑图有什么不一样呢?主要有如下三点:

  1. Leangoo脑图是项目团队实时同步、实时共享的。不需要再通过导出分享给项目中的其他人。
  2. Leangoo脑图可以支持多人在线编辑与协作。
  3. Leangoo脑图的节点和Leangoo看板上的卡片是一样的,支持富文本文档,可以添加附件,添加检查项,添加工作量以及评论等等。

所以,它可以用来代表需求、任务、测试或者一篇文档等等。而且每个节点都可以引用到看板上。

有了这些特性, Leangoo脑图就十分强大了。针对敏捷研发,Leangoo脑图有很多实用的场景,比如实现影响地图、用户故事地图、多级需求管理,知识管理、测试案例、迭代回顾等等。我们将通过一系列的文章来介绍这些实用场景。

本文,我们先从影响地图开始,介绍如何用Leangoo脑图来实现影响地图。

什么是影响地图?

Read more

Spotify-scrum中文网1

Spotify敏捷模式详解三部曲第三篇:工程文化

摘要

在本系列文章的第一篇和第二篇,我们分别介绍了Spotify的敏捷研发团队和研发过程。

在本篇,我们将介绍Spotify的敏捷工程文化。

引言

Spotify通过文化和价值观来进行管理,在本篇中,我们从如下八个方面来介绍Spotify的敏捷工程文化:

一、 如何管理小队的自主性

二、 如何管理标准化

三、 如果做到以人为本

四、 如何管理部署上线

五、 如何管理创新

六、 如何管理失败

七、 如何处理浪费

八、 如何管理文化

一、 如何管理小队的自主性

Spotify的小队,类似于一个高度自治的、迷你的“创业公司”。一方面,小队要保持自主性,同时也要兼顾公司在产品上的整体一致性。

如何看待自主性和一致性

通常认为:一致性和自主性就像是天平的两端,自主性高则一致性少。

scrum中文网Spotify1

Spotify认为:这是两个不同的维度:

1. 低一致性、低自主性:

管理者下指令,团队执行。

2. 高一致性、低自主性:

管理者告诉团队要做什么,以及怎么做。

3. 高一致性、高自主性:

管理者聚焦要解决什么问题,由团队自己去找出解决问题的方法。

4. 低一致性、高自主性:

团队各行其事,管理者很无助,产品是个怪胎。

理想情况:具备一致性的自主,只有具备一致性才令团队自主具备可能性,而一致性越高,管理层越能下放自主权。

scrum中文网Spotify2

Spotify的管理原则:

  • 独立自主,但不能局部优化
  • 小队可以自主,但不能追求局部优化。就像是一个大型乐队,每个乐队小队都在独立自主的演奏,但又必须彼此倾听其他小队的演奏,共同聚焦整首曲子的演出,这样才能演奏出好的音乐。
  •  目标——建立相互松耦合,但整体高度一致的小队。

scrum中文网Spotify3

打造独立自主、松耦合、整体高度一致的小队

1. 为什么小队的独立自主如此重要?

  • 这是一种激励方式,受激励的人们能够开发出更好的产品。
  • 独立自主能够让小队更快地做决策和行动,而不需要经过层层审批。
  • 独立自主,能够尽量避免交接和等待。

2. 独立自主:

  • 小型(人数少于8)、跨职能、自组织的团队。
  • 小队自行决定开发什么产品,如何开发,以及如何协作。
  • 坐在一起,共同对研发的端到端事物负责,例如:设计、交付、部署、维护、运营等。

3. 整体高度一致

  • 小队有长期的使命,例如:使Spotify成为探索音乐的最佳应用程序,或内部事物,例如执行A/B测试的基础架构。
  • 小队要与产品的整体策略保持一致,与公司的整体优先级和其他小队保持一致。Spotify的整体使命的重要性和优先级,高于小队的任务。
  • 小队们合作开发产品的整体策略,以及季度重新探索短期目标。

二、 如何管理标准化

一方面,小队的要保持技术灵活性,另一方面要兼顾公司的整体规范性。

自由胜过标准化

如果有人问:应该使用哪种编程工具,或是如何做计划?答案是:这要看是哪个小队。
有的会用Scrum,有的会用Kanban,有的会估算故事点并统计速率,有的则不会,实际情况因小队情况而已。

随着时间的积累,发展出了一些设计指引、代码规范等来减少工程上的摩擦,但唯有非常时期才会使用。在权威与自由的天平上,倾向于自由而非权威。

scrum中文网Spotify4

通过异花授粉而非标准化,来平衡灵活性和一致性

  • 异花授粉(Cross-pollination),而非标准化(Standardization)。
  • 当越来越多的小队都使用某种实践方法时,例如使用Git进行版本控制,其他小队也会跟进和开始使用,当小队间都使用这种工具协作时,就成为事实上的标准。
  • 通过采用这种非正式的方式,得以在一致性和灵活性间保持平衡。

scrum中文网Spotify5

解耦系统

1. 现状&问题:

  • 产品中包含100多个独立开发和部署的系统。
  • 在技术上,每个系统由某一个小队负责;大部分小队会同时负责好几个系统。
  • 系统间存在交互,而各小队又分别专注于自己的特性。例如播放清单的管理、搜索或监控。
  • 如何让小队在专注自己的特性和系统的同时,还能与公司整体以及其他小队保持一致?

2. 实践方法:

以清晰的接口和规范,力求实现需求之间以及系统之间的解耦。

内部开源机制

内部开源模式:谁都可以改代码+同舟共济的代码评审文化。

scrum中文网Spotify6

例如,上图中有两个小队:Squad1和Squad2

  • 小队1需要在B系统完成某项事情时,而小队2对B系统的程序编写比较在行。
  • 通常小队1会找小队2协助处理。
  • 如果小队2没有时间或者有更重要的任务,小队1也不会等待。组织鼓励小队1自行去编写系统B的代码,然后再请小队2评审修改。消除等待的同时,这样有助于提升质量和传播知识。

三、 如何做到以人为本

唯有以人为本,工作才能得以顺利进行。

以人为本的文化

1. 坚实的“互相尊重”文化:经常听到像是“我的队友真棒”的评论。

2. 人们常常把事情归功于其他人的杰出表现,而非自私的为自己争功。

3. Spotify确实有很多天才,但却很少有人狂妄自大。

4. “不干涉+同舟共济”的文化:

  • 你和你的队友会被期望自己去找答案,没人会告诉你该做什么。
  • 但当你需要协助的时候,你会很快获得许多援助。
  • 大家一致认同的真理是:我们在同一条船上,而且必须帮助其他人成功。

scrum中文网Spotify7

以激励为公司文化的重点

Spotify每年都会进行员工满意度调查。

scrum中文网Spotify8

四、 如何管理部署上线

对自主性最重要的一点是部署上线的难度。

追求小而频繁的发布:

1. 程序发布应该是例行的(Routine),而非戏剧性的(Drama)。

2. 拒绝恶性循环:发布困难-》发布得少-》发布规模大-》发布困难。

3. 追求良性循环:发布容易-》频繁发布-》发布规模小-》发布容易。

scrum中文网Spotify9

投资令发布更加容易

不是建立流程、规范来管理发布,而是通过投资测试自动化和持续交付的基础设施,例如:改变架构,让发布解耦。

——使用Chromium嵌入式架构,每个客户端就是一个伪装的网页浏览器。每个区块就像是网站的一个框架,小队可以直接发布他们的产品。

scrum中文网Spotify10

客户APP小队、基础设施小队和“自助服务”模式

scrum中文网Spotify11

利用发布火车和特性开关解决小队间的同步问题 

scrum中文网Spotify12

五、 如何管理失败

包容失败的文化

scrum中文网Spotify13

自下而上驱动,自上而下支持的持续改进文化。

  • 没有任何学习成果的失败就真的只是失败。
  • 当出问题的时候,通常要进行事后检视。不关注“这是谁的错”,只关注“怎么发生的?学到了什么”,以及“我们如何改变”。
  • 事后检视是事故管理流程的一部分,任何事故单,问题解决了还不算完,仅当有所学习和收获时才能关闭。不仅要改进产品,还要改进过程。
  •  所有小队,每隔几周就要召开一次回顾会议,讨论什么地方做得好,什么地方该改进

scrum中文网Spotify14

“改进清单”和“牛逼的定义” 

scrum中文网Spotify15

实例:某小队的改进看板

1. 改进看板的内容:

  • 左上:现状,小队面临质量问题。
  • 左下:牛逼的定义,理想中不会有质量问题。
  • 右上:真正的目标。如果我们靠近牛逼一步是什么样子?
  • 右下:三个让我们达到目标的行动项,完成后会增加新的行动项。

2. 看板的内容,在回顾会议上跟进。

scrum中文网Spotify16

控制失败造成的损失

1. 失败必须是非致命的,否则我们无法存活到下次失败。

  • 通过架构解耦(Decoupled Architecture),控制爆炸范围(Limited Blast Radius)。
  • 当一个小队犯错时,只会影响到系统的少部分,而非搞垮整个系统。
  • 由于无需交接切换,小队通常能够快速修复问题。

2. 采用A/B测试

新功能发布时,先发布给少量用户体验并进行密切观察。仅当确定功能已经稳定后,才会逐步发布给全世界的用户。

因此,失败只会影响到系统的少量用户,并且影响时间很短暂。这种有限的损害范围,让小队勇于做更多的尝试,并加速学习的步伐,而不是把时间浪费在风险的预测和控制上。

六、 如何管理创新

通过降低可预测性,来促进创新

  • 100%可预测性=0%创新。
  • 如果必须做出交付时间承诺,通常会推迟承诺——直到产品特性已经被证实或者接近完成时,才给出承诺。
  • 通过降低预测性要求,使小队能聚焦于价值交付,而不是成为某人的武断计划的奴隶。
  • 有位PO说:我把我们的小队看做一群聚集起来从事自己狂热事业的志愿者。

scrum中文网Spotify17

鼓励人们玩耍和尝试,以促进创新

  • 惊艳的新产品,始于人的灵感,唯有允许人们玩耍与尝试,才能产生灵感。
  • 鼓励人们花10%的时间,执行“黑客日”或者“黑客周”。在这个时间里,人们可以根据自己的想法,尽情的去试验或者开发任何自己想要的产品。
  • 在Spotify,每年会举行两次黑客周。
  1. 头号标语:Make cool things real!Build everything you want, with whoever you want, in whatever you want!
  2. 好几百人整周都在闭门当黑客,并在周五时大型会展中展示成果。
  • 开发出来的产品真的有用吗?
  1. 这不重要。
  2. 关键是只要你尝试的点子够多,我们就能不断接近目标。
  3. 而且往往,做黑客时学到的知识,比黑客行为本身更有意义。
  4. 而且,也挺好玩的。

 

黑客创意产品——“拨打一首歌”

只需要拿起电话,拨打一首歌的号码,就能听歌。

scrum中文网Spotify18

“黑客周”活动 

scrum中文网Spotify19

鼓励试验的文化(Experiment-friendly Culture)

1. 例如:

  • 该用工具A还是工具B?不知道,让我们两个都试用一下然后做个比较。
  • 或我们是否真的需要Sprint计划会议?不知道,我们跳过一次会议,看看后面是否会怀念它。
  • 或我们该在歌手页放5首还是10首排行榜歌曲?不知道,让我们两种情况都尝试一下,然后评估效果。

2. 对于决策问题,以其争论半天,不如试着讨论下:

  • 有什么假设?
  • 我们学到了什么?
  • 接下来我们尝试什么?

3. 这让我们的决定多基于客观数据,而非来自某个人的想当然或者屈从于权威。

七、 如何处理浪费

排斥浪费的文化

  • 虽然我们乐于尝试,并且试着用不同的方式来做事情,但我们的文化非常排斥浪费。
  • 人们会快速停止做任何不能带来增值的事情。如果发现有效,就继续;反之,则抛弃。

a) 通过试验发现有用,需要继续的一些实例:回顾会议、每日站会、google文档、GIT、协会的研讨活动。

b) 通过试验发现没用,需要抛弃的一些实例:例行报告、交接、独立的测试团队或测试阶段,任务估算,无用的会议,企业官话。

大型项目

  • 大型项目是一种最常见的浪费。(大型项目,通常指需要多个小队一起合作好几个月来完成的项目。)
  • 大型项目,意味着巨大的风险。(Big Project = Big Risk)
  • 要尽量减少大项目,尽可能把大项目拆成一系列的小工作。
  • 有时候,大项目有其合理性,并且潜在收益远大于风险,这种情况下,需要采取一些措施:
  1. 用物理看板或者电子看板,通过各种组合方式,可视化项目进度。
  2. 进行每日同步会议:所有小队共同参与讨论,解决相互依赖。
  3. 每一到两周,进行一次演示:将产品各部分进行集成,召集干系人进行整体评估。
  4. 一个小而紧密的领导团队,来持续地掌控整个大局。通常有:一位技术主管,一位产品主管,有时候还有一位设计主管。三者通力合作。

在混乱与官僚主义之间取得平衡

  • 当我们成长时,面临者陷入混乱的风险。当如果增加太多的结构和流程,又会陷入官僚化的风险。
  • 关键问题:什么是最小可行官僚系统?可以让我们以最少的结构和流程来避免陷入完全混乱。
  • 排斥浪费的文化和敏捷思维能帮助我们在混乱和官僚主义之间保持平衡。

scrum中文网Spotify20

八、 如何管理文化

为何Spotify如此重视文化?

在企业成长的过程中,会面临各种问题,以及采取各种解决方案,包括改造产品架构、流程和组织等。

但是企业面临的情况也是一直在变化的,今天看似聪明的解决方案,可能会在明天造成一个难缠的新问题。而健康的文化能够修复有问题的流程。

scrum中文网Spotify21

关注文化的角色(Culture-focused Role)

  • 人力资源运作团队
  • 30+位敏捷教练

scrum中文网Spotify22

新员工训练营(Boot Camp)

  • 时间:为期一周
  • 人员:由新招募的人员组成临时的小队
  •  内容:
  1. 解决实际问题。
  2. 同时学习技术栈和工作过程。
  3. 以及学习如何作为一个团队协同工作。
  4. 这种紧张而有趣的训练,能让你真正融入到文化中。

scrum中文网Spotify23

通过讲故事来传播文化

在博客、午餐以及各种场合分享自己的成功以及失败学到的经验教训。

scrum中文网Spotify24

每个人都是组织文化的一份子。

  • 组织文化,是组织中每个人的态度和行为的总和。
  • 每个人都是组织文化的一份子。
  • 每个人都在塑造组织的文化。

scrum中文网Spotify25

相关阅读:

Spotify敏捷模式详解三部曲第一篇:研发团队

Spotify敏捷模式详解三部曲第二篇:研发过程

参考资料:

本文部分内容及引用的图片主要来自于Henrik Kniberg和Anders Ivarsson的文章《Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds》。

本文作者:

Jerry Li(李洁), Eric Liao(廖靖斌)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Spotify-scrum中文网1

Spotify敏捷模式详解三部曲第二篇:研发过程

摘要

在本系列文章的第一篇,我们介绍了Spotify的敏捷研发团队,以及它独特的组织架构。在本篇,我们将介绍Spotify基于敏捷开发和精益创业思维的产品研发过程。

引言

在本系列文章的第一篇,我们介绍了Spotify的敏捷研发团队,以及它独特的组织架构。Spotify的研发团队采用的是一种非常独特的组织架构,如下图所示:

1

整个研发组织有多个称为“Tribe部落”的单元组成,每个部落中包括多个“Squad小队”,从横向的维度,把拥有类似技能的人放在一起形成“Chapter分会”和“Guild协会”。

本篇是Spotify敏捷模式详解三部曲第二篇,将继续为大家介绍Spotify基于敏捷开发和精益创业思维的产品研发过程。

Spotify产品开发的核心理念

  • 创造革命性的产品,通过早期低成本的原型设计来控制产品风险。
  • 品质不过关决不发布产品,即便是落后于既定的发布日期。
  • 通过产品发布后持续地调整优化,来确保产品从发布时就表现优异,直至最后得到惊艳的产品。

从产品创意——>形成产品4个阶段

2

产品风险控制

  • 产品开发最大的风险——构建一个错误的产品。
  • 思考阶段:以较低的成本,大幅度降低产品风险。
  • 构建阶段:运作成本高,几乎无法降低产品风险,所以要尽量缩短。
  • 发布阶段:随着产品的发布和客户使用,产品风险持续降低。
  • 调整阶段:随着时间的推移,产品逐渐完善,运作成本持续下降,小队们可以开始逐渐去做其他事情。

3

一、Think it 阶段

工作流程

4

过程说明

  • 目标:拿出一个足够吸引人的故事性描述和能够传达它的可运行原型。
  • 输入:产品创意
  • 过程:

1. 组建Think it 小队。
2.写故事描述,定义指标(要达到的效果)。
3.构建原型。
4.确认是否值得构建MVP。

  • 完成的定义:

1.管理者和Think it 小队都认同这个产品值得构建(或者这个产品永远都不值得构建,应该被舍弃)。
2.说明:这是一个主观上的决定,它并没有过硬的数据作支撑。直到Ship It阶段才会产生坚实的数据,所以我们希望尽可能快地到达Ship It阶段。

  • 故事描述(narrative)

故事描述,是一个简短的文档,用来回答如下问题:

1. 为什么我们要开发这个产品?谁能从中受益?如何受益?

2. 我们期望可以从这个产品提升哪些关键指标?诸如:会增加多少音乐播放量,增加多少下载量,增加多少登录量等等。

3. 我们的预期是怎样的?我们如何判断这个产品是否成功?

4. 是否会令产品“再上一个台阶”(Step Change)吗?(指的是,我们预期这个产品在既定指标上会带来至少双倍的提升。如果只是在度量指标上略有提升,最好有个更强有力的理由,例如战略方面的原因)

关于故事描述的说明:

1. 故事描述不是所谓的产品愿景规划。它不包括特性清单、预算、资源计划。更像是一个用数据说话(数据驱动)的意愿陈述。

2. 最重要的部分就是故事,要讲一个生动的、能吸引人的故事。

举例:“Discover”标签产品的故事描述——介绍一种发现音乐的更好方式。看!你最喜爱的艺术家刚刚分享了一首歌给你。我们让艺术家们和粉丝们从未如此靠近过。喜欢一个艺术家?那就去follow(关注)他,并与朋友们分享你的新发现吧。

  • 构建原型

1. “Think It”小队会构建许多不同的原型来传递产品的感官上的体验。

2.“低保真”的纸面原型。

3.“高保真”的可运行的原型(上面跑伪数据源之类)。

4.几个内部焦点小组会用来辨别哪一个原型能最好地传达了它的产品精神(那个故事性描述)。

5.直到我们不断缩小范围,最后只剩下几个胜出的原型。

5

  • Think it 阶段何时可以结束

1. 这是一个没有截止日期的迭代过程,我们无法决定这个产品前期会花去多少时间。

2. 只有当我们可以拿出一个足够吸引人的故事性描述和能够传达出它的可运行的原型,才值得去构建产品。

二、Build it 阶段

工作流程

6

7

过程说明

  • 目标:构建出能够向真实用户充分传达产品理念的MVP(最小可行产品)。
  •  过程:

1. 扩建小队。
2. 构建和内部发布。
3. 确认MVP是否足够好。

  • 注意事项:

1.尽量快:不希望在发布产品前构建一个十分完备的产品,因为这个过程会延迟我们获取客户使用数据的时间。

2.不希望产出无用的或令人沮丧的产品。要写产品级的代码并且保障质量。

3.(MVP也可以称为:最早令人喜爱产品。)

  • 完成的定义:

管理者和小队共同认为:

1.目前这个MVP已经实现了基本的故事描述。

2.已经足够好,可以开始向真实用户发布。

三、Ship it 阶段

工作流程 

 8

过程说明

  • 目标:逐渐将产品扩散到所有用户,同时进行度量和分析,确保产品在真实环境下,也能够达成它的设计初衷。
  • 过程:

1. 小范围发布。
2. A/B测试。
3. 度量和分析、学习、迭代提升。
4. 逐步扩散到所有用户,或者抛弃。

  • 完成的定义:

1. 产品扩散到所有用户。

2. 注意点:

1)这时并不意味着产品已经“功能齐全(feature complete)”,完成了Ship It阶段只是意味着产品(MVP+必要的改进)已经被100%铺开而已。

2)不存在“功能齐全”的说法,因为产品即使在Ship It阶段之后还会继续优化。

四、Tweak It 阶段

工作流程

9

过程说明:

1. 在这个阶段,小队持续优化、A/B测试、度量和分析。

2. 直到有一天,所有重要的改进都已经完成,新的改进已经无法带来吸引人的收益,指标数据已经很难有进一步的提升,产品已经趋近于“极致”。

3. 这时候,小队会逐渐转向新的工作或者重构下一代产品(回到Think it 阶段)

五、总结

产品开发全景图如下图所示,它包括了四个阶段:

  • Think it阶段:拿出一个足够吸引人的故事性描述和能够传达它的可运行原型
  • Build it阶段:构建出能够向真实用户充分传达产品理念的MVP(最小可行产品)。
  • Ship it阶段:逐渐将产品扩散到所有用户,同时进行度量和分析,确保产品在真实环境下,也能够达成它的设计初衷。
  • Tweak it阶段:在这个阶段,小队持续优化、A/B测试、度量和分析。

10

本篇是Spotify敏捷模式详解三部曲第二篇:研发过程,本系列文章的下一篇将继续介绍Spotify的工程文化,敬请期待。

相关阅读:

Spotify敏捷模式详解三部曲第一篇:研发团队

Spotify敏捷模式详解三部曲第三篇:工程文化

参考资料:

本文部分内容及引用的图片主要来自于Henrik Kniberg和Anders Ivarsson的文章《Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds》。

本文作者:

Jerry Li(李洁), Eric Liao(廖靖斌)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Spotify-scrum中文网1

Spotify敏捷模式详解三部曲第一篇:研发团队

引言

2018年4月,来自北欧瑞典的音乐流媒体公司、百亿美元独角兽Spotify创造了历史,它成为了当代上市公司当中,第一家通过“直接上市”的方式在美国纽交所成功挂牌的公司。这家公司改变的可能不仅是人们听音乐的习惯,而且还有企业进入资本市场的方式。截至2018年初,Spotify拥有1.59亿的全球活跃用户数量、7000万的付费用户数和46%的付费用户增长率。Spotify是当之无愧的音乐流媒体领域的霸主,排名第二的苹果音乐,无论是付费用户还是活跃用户,都只有Spotify的一半。

是什么成就了Spotify?他们是如何打造出这么一款深受用户喜爱的产品的?幸运的是有Henrik Kniberg的存在。Henrik Kniberg是全球知名的敏捷和精益教练,也是一位多产的作家,他参与了Spotify公司的这一过程,并写下了多篇文章,向外界揭开了Spotify公司的神秘面纱。

笔者通过自己的收集和整理,梳理出了Spotify敏捷模式的整个过程,并通过一系列的文章呈现给大家。在本期的文章中,笔者将首先介绍Spotify的研发团队。

组织架构

Spotify采用的是一种非常独特的组织架构,如下图所示:

Spotify scrum中文网1

整个研发组织有多个称为“Tribe部落”的单元组成,每个部落中包括多个“Squad小队”,从横向的维度把拥有类似技能的人放在一起形成“Chapter分会”和“Guild协会”。

Squad(小队)

组织定位:

• 类似于一个高度自治的、迷你的“创业公司”。

• 肩负一个长期的使命,长期从事某一类任务或者开发产品的某一个部分。例如:

1)功能特性小队:专注于某块功能特性,例如搜索功能。

2)客户端APP小队:专注于使特定的客户端平台更容易发布,例如:iOS、Android.(注意:他们不进行业务特性开发)。

3)基础设施小队,专注于让其他小队更有效率,提供工具和例行事物,例如:持续交付、A/B测试,监控和运维。

团队成员:

• 不存在官方任命的团队领导。

• 有一位产品负责人(Product Owner)。

1) 各小队的产品负责人紧密合作,共同维护一个宏观的产品路线图(Roadmap),指引整个 Spotify 公司的产品发展方向。

2) 每个产品负责人也分别维护一个自己所在小队的产品待办列表(Product Backlog)。

• 可能会有一位敏捷教练(Agile Coach),帮助团队改进工作方式。

• 具备开发产品需要的所有知识和技能,例如设计、开发、测试、发布等。

• 通常少于8个人。

工作方式:

• 坐在一起工作。

• 自组织管理自己的工作。

• 定义和改进自己的工作流程。

办公环境

Spotify scrum中文网2

Tribe(部落)

组织定位:

• 在相关领域工作的多个小队的集合,例如音乐播放器、后台基础架构等等。

• 可以看成是迷你创业小队的“孵化器”。

团队成员:

• 每个部落有一名酋长,他负责为部落内的各小队提供最好的栖息地(Habitat)。

• 部落规模大小基于“邓巴数(Dunbar Number)理论”而定(小于100人)。

工作方式:

• 一个部落中的所有小队在同一个办公地点工作,通常各小队的办公区是彼此相邻的,办公区附近的休息区能促进了小队间的交流与合作。

• 会定期在部落内开展非正式的聚会,在聚会上相互展示自己正在做什么、已交付了什么、其他人能从自己正在进行的事项中得到什么经验教训。展示内容包括能工作的软件、新工具与新技术、非常酷的黑客日/黑客周项目……

“邓巴数理论”:即150定律,由英国牛津大学的人类学家Robin Dunbar在1990s年代提出。

该定律认为:人类智力允许人类拥有稳定社交网络的人数是148人(四舍五入为150)。Spotify认为在超过 100 人的组织中,大部分人很难维持稳固的社会关系。当一个组织变得过大后,我们就会开始看到限制性的规定、官僚主义、政治斗争、冗余的管理层级,以及其他各种浪费。

组织对小队的支持

每个季度,组织会对每个小队做一次调查,以确定小队需要在哪些方面改善以及需要在组织层面提供哪些支持。
Spotify scrum中文网3

各个调查项的评判参考标准:

1. 产品负责人(Product Owner)——小队内是否有专职的产品负责人对任务的优先级进行排序?排序时,产品负责人是否能够综合考虑商业价值和技术因素?

2. 敏捷教练(Agile Coach)——小队是否有敏捷教练帮助团队识别障碍、指导团队进行持续地过程改进。

3. 支配自己的工作(Influencing Work)——小队内的每个成员都可以支配自己的工作?可以积极参与制定工作计划?可以选择自己做什么任务?每个成员是否都可以把自己 10%的工作时间投入到黑客时间?

4. 容易发布(Easy to Release)——小队是否可以(并且确实做到)轻松发布产品,而不需要很多的争论和同步?

5. 合适的流程(Process that fits the team)——小队拥有自己的工作流程并且持续对其进行改进?

6. 使命(Mission)——小队是否有一个小队所有人都知晓并关注的使命?产品待办项中的故事是否都与此使命息息相关?

7. 组织级支持(Organizational Support)——小队是否知晓该从何处寻求解决问题所需的支持,无论是技术问题,还是“软”问题(“soft” issues)?

管理小队间依赖

核心思想:

• 依赖就意味着堵塞和等待。

• 要尽量减少小队间的依赖项。

实践方法:

1. 经常对小队进行依赖调查:你们的工作依赖于哪些小队?这些依赖是否阻塞或拖慢了你们的工作?严重到了什么程度?

2. 基于调查结果,讨论如何消除有问题的依赖,特别是引起了工作阻塞的以及跨部落的依赖关系。为了消除这些有问题的依赖,经常会调整任务优先级、团队组成、架构或技术方案。

3. 必要时,召开SoS(Scrum of Scrums)协调会议。

4. 开发小队自行发布成果,运营小队只负责“铺路”。

Spotify scrum中文网4

Spotify scrum中文网5

Chapter(分会)

组织定位:

• 负责传播知识和开发工具。

• 类似于传统的职能部门。

团队成员:

• 同一个部落、相同技能领域、拥有相似技能的一些人。(技能领域,例如:例如敏捷教练,或Web开发。)

• 分会有一个领导,就是分会成员的直线经理,是一个服务式的领导,负责教导和指导分会成员的工作,执行员工发展、定薪等。

• 分会的领导,同时也是某个小队的成员,参与小队日常工作。

工作方式:

• 每个分会定期聚会,讨论专业知识及遇到的挑战。

Guild(协会)

组织定位:

• 分享知识、工具、代码和实践。

• 轻量级的“兴趣爱好社区”。

团队成员:

• 囊括整个公司的成员,聚集和分享特定领域的知识,例如领导力,Web开发或持续交付。

• 每个协会都有一个“协会协调人”,负责组织和协调协会的活动。

• 任何人都可以随时加入或离开协会。

工作方式:

• 每个协会定期组织一些研讨会。

如何解决系统的整体一致性?

1. 现状&问题:

1) Spotify 的技术是高度面向服务的。

2) 一共有 100 多个独立的系统,每个系统都可以单独地维护和部署。

3) 通常小队需要更新多个系统来完成新特性的开发。

4) 如果没人关注系统整体一致性的话,那么系统架构就会变得一团糟。

2. 解决方案:

• 系统负责人(System Owner):每个系统都有一个或一对系统负责人(鼓励结对)。对某些关键的运营系统,系统负责人由开发和运营结对组成(Dev-Ops Pair)—— 一个人拥有开发视角,另一个人拥有运营视角。

• 系统负责人负责协调和指导开发人员,以避免开发人员之间的冲突。

• 系统负责人关注于:质量、文档、技术债、稳定性、可扩展性和发布流程。

• 系统负责人并非专职,通常也是小队成员或分会领导,还有其他的日常工作。

• 系统负责人会不时地执行一次“系统负责人日”,以整理一下系统。(系统负责人要在“系统负责人日”上投入的时间,不同的系统差异较大,但是通常不少于10%。)

• 一个首席架构师,负责协调跨越多个系统的、较高层面的架构问题。

• 评审新系统的开发工作,以避免一些常见错误,并确保新系统和现有的架构设计是一致的。架构师的反馈只是建议和输入——系统设计的最终决策取决于小队。

与传统矩阵式组织的区别

传统矩阵式组织形式

1) 项目立项时,“职员”由“职能经理”从职能部门“分配”到“项目”。

2) 在项目中,“职员”由项目的“项目经理”分配任务。

3) “职员”要例行向“职能经理”进行工作的“汇报”。

4) 项目结项后,“职员”从“项目”释放,回到“职能部门”,等待分配到下一个“项目”。

• Spotify的组织形式:

1) “职员”在“小队”中“持续”工作,与小队中其他人员共同“打造”一款优秀的“产品”。

2) “分会”和“协会”为“职员”提供“服务”,分享知识、工作、代码和实践,解决如何小队成员“如何做得更好”的问题。

• Spotify的组织设计思想:

1) 采用社区(Community)来替代传统的层级式组织(Hierarchical Structure)。

2) “教授和企业家”模型

3) 产品负责人(PO)就是“企业家”,关注于交付优秀的产品,

4) 分会领导是“教授”,关注于技术卓越。

本文是Spotify敏捷模式详解三部曲第一篇:研发团队。

相关阅读:

Spotify敏捷模式详解三部曲第二篇:研发过程

Spotify敏捷模式详解三部曲第三篇:工程文化

参考资料:

本文部分内容及引用的图片主要来自于Henrik Kniberg和Anders Ivarsson的文章《Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds》。

本文作者:

Jerry Li(李洁), Eric Liao(廖靖斌)

 

 

 

 

 

 

 

 

 

 

 

Scrum中文网敏捷团队领任务的误区

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

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

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

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

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

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

有人可能认为,经理决策不是很好吗,又快又好,因为经理知道谁的能力怎么样。但是,这种决策机制带来的问题是,第一,对经理依赖比较大,经理的能力决定项目的成败;第二,团队比较被动,参与感比较差;第三,责任在经理肩上,团队只负责完成被安排的任务。

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

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

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

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

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

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

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

 

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

leangoo巴久灵

巴久灵 x Leangoo敏捷实践案例分享

首次了解到Leangoo,大概是2年前。之前已经有过比较多的Scrum实践,当时在前司开发了一个看板的系统,离开后在新团队没有类似的工具,有点不便,就想找找有没有这样的工具!

Google一下后就找到了Leangoo,用了一下,和之前自己开发的工具功能基本一致,非常方便实用,上手很快,所以就成了忠实用户

在半年前来到吴晓波老师的公司巴久灵担任CTO。公司的IT团队组建不久,不到一年。担负着好几个产品的开发任务,整个项目管理比较混乱。

我第一件着手要做的事儿,就是按产品线划分团队,然后采用Scrum开发过程,来提高团队交付能力,并使团队聚焦在有价值的产品上。在给大家培训了基本的Scrum知识后,就需要有工具来辅助落地。
Read more

sad22

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

333

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

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

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

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

遵循Scrum的一些规则来使你的产品开发取得成功leangoo

遵循Scrum的一些规则来使你的产品开发取得成功

1. 需要有全职的有威信,有能力的产品负责人(PO-Product Owner).

2. PO要和Scrum Team、其他的利益相关者(stakeholder)一起工作

3. 有PO来创建和管理产品backlog

4. Scrum每日站会必须的3个问题(完成了什么,准备做什么,有什么障碍)

5. Scrum每日站会要在固定的地方时间不要超过15分钟

6. 有规律的Sprint长度(不超过30天)

7. 在Sprint计划会议上创建Sprint Backlog和经过详细估算的任务列表

8. 一定要有Sprint的燃尽图

9. Team必须的设备及相关的供应要齐全

10. 使用回顾会议确保过程在不断提升

11. 有明确的对于“任务完成”的定义

12. 按照合理的速率给出承诺(根据Sprint的工作量估计)

13. 团队大小在7 +/- 2,最多不能超过12人

14. 跨职能的团队包括ScrumMaster和PO

15. 自组织的团队 – 团队成员志愿挑选任务

16. Scrum master要跟踪进度,并且为团队扫清障碍

17. 确保Team不被外界干扰

18. Sprint之间不能间断

19. 合理的节奏 – 根据固定时间段来确定任务量, 不只是一个进度表

20. 质量是第一,不需要在质量上讨价还价 – 代码缺陷永远位于Backlog的最上层

 

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