我在哈啰的敏捷之旅

非常开心在空中和大家相聚，希望在接近一个小时的时间我们都能有所收获。首先感谢Bob老师和网易杭研的李岩同学，是因为他们的支持，我才能够在这里和大家分享。在开始之前，先简单自我介绍一下，我是陈文博，供职于哈啰出行PMO部门，一名成长中的敏捷教练，今天有很多敏捷社群的小伙伴来支持，谢谢大家！

言归正传，今天的分享将分为两部分：

• 第一部分是我在哈啰做的一些敏捷实践， 包括目前我是怎么操作Scrum的，如何利用透明拉通团队共识，如何利用内驱力模型来激励团队，以及我在兼顾多个Scrum团队时如何培养内部的Scrum Master。
• 第二部分将给大家分享我在内部敏捷社区的一些做法， 包括我是怎么发起内部敏捷社区Thor，以及社区是怎么运营的。

一、我的敏捷实践

首先给大家分享的是敏捷宣言的第一句话， “我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。”  分享这句话的原因是，我觉得敏捷实践是没有最佳实践这么一个说法，永远都是在不断地迭代，不断地找到更适合当前组织和团队上下文的一种做法，所以我在这里给大家分享的，也是基于我自己团队的上下文找到的目前最好的方法，后续还会继续迭代，以便做得更好。

Scrum的基本操作，包括五个关键活动和经验性框架的介绍。透明部分我会通过把整个研发过程可视化出来，通过Jira、Excel、白板等一些工具透明研发过程，后续我们还会使用团队工作日历，如手绘出一个迭代的工作日历贴出来，把团队的基本原则写在白板上。

比如，迭代工作开始后，团队成员不能接私活，如果需求变更了，必须由PO和Scrum Master一起决策，站会来迟了要发红包等团队共同的原则要透明出来。以及我们的DOD，需求评审规则，迭代开始后，子任务的完成标准是什么。检视和调整我们会通过回顾会议和专项过程改进来进行，后面会有详细的介绍。五个关键活动，主要介绍其中的四个，Sprint Review还没有找到合适的最佳实践，所以将聚焦在剩余的四个上。

1.1 Scrum的基本操作

五个关键活动的实践

今天的分享是基于大家对Scrum有一定的了解和实践。下面先从五个关键活动讲起，首先我们讲一下是怎么开展 需求梳理会 的？我们的迭代是两周为一个周期，梳理会有两个时间节点，第一周的周二，我会和产品以及业务方确定下一个迭代需求范围的初稿；周五将和产品及业务方确定下一个迭代需求是哪些，优先级如何。

具体来讲，我们会对Product Backlog中的所有需求进行梳理，找到当前优先级比较高的需求，需求的数量会根据团队的情况，估计一个到一个半迭代的需求数作为下个迭代的大致需求范围。后面有一张PPT将会讲到需求梳理会上，迭代之后的一些玩法。目前的这个主要是我当前团队上下文的一些实践，后面还将分享一些其他团队需求梳理会的开法。

需求计划会Planning ，我们是放在迭代第二周的周五，会上PO会对需求进行宣讲，宣讲后，团队将直接在现场拆分任务和估算工作量，估算是通过估算扑克进行的，拆分后的任务会告诉大家前端需要多少时间，后端需要多少时间，大家会一起去估算每个任务的工作量，并通过交叉估算去澄清需求，一般会让工作量估计最高的和最低的同事分享一下为什么是这样评估的。在保证大家对需求的理解对齐后，以最终的任务点数作为估算的最终结果。会上我们会逐个需求的去估算，直到团队告诉我这个迭代不能继续往下做了，我们就会停止，也就确定了这个迭代的范围。

两周一次迭代，根据团队的Velocity每个人能投入七个人天的工作量，我将会核算服务端会花费多少人天，安卓、IOS、桌面将会花多少人天，差不多每个人累计到7个人天的时候，我就知道这个迭代不能再加需求了，同时还要考虑一些请假的情况，这就是我们当时开需求计划会Planning的做法。

在这里需要澄清的是，我当时没有只是估算任务后让大家去认领，我们的团队有些特别，服务端2人，安卓1人，IOS端1人，桌面1人，所以估的安卓的任务只有一个人能去完成，不存在其他人会去认领和相互backup的情况。

需求计划会确定好了之后，我们就会开始 迭代 ，在开始迭代之前，我们会先在 项目管理工具JIRA 中启动迭代，同时发布迭代启动的邮件，通知相关干系人此次迭代要做哪些需求，时间范围是什么，站会是什么时间节点，团队有哪些人，分别是什么角色，以上是迭代启动的准备工作。

迭代启动之后，就进入到 Daily Scrum 的环节，每天我们都会开 站会 。开站会有几点特别重要，首先是维护站会的纪律，迟到的同学要发红包，这条纪律是贴在白板上的，作为团队透明出来的基本规则，后续在讲到团队透明的时候也会讲到这一部分。

我们的站会是有一个演变的过程的，最初是我和团队的Scrum Master带站会，这样进行了两个月之后，我会让团队以周为单位去轮流组织站会，页面上我放了一张图，是当时发在朋友圈的，内容是，我把站会的引导权还给了团队，展示了团队在开站会的一个场景。

在站会上除了标准的三个问题之外，我们还会做一件事情，就是一个Check in的动作，希望大家在开站会之前去画一下自己的 心情曲线 ，以便大家感受到每个人当前的状态怎么样。为什么要画心情曲线，后面会有一个团队驱动力的章节讲到。我们会在会上直接登录工作日志，相信很多使用Jira的小伙伴都知道， 燃尽图 就是根据每个子任务的工作日志生成的，这是我当时那个时间节点的做法，但是其实这个做法会随着团队成熟度不断提高后进行调整。有些团队会在会前登录工作日志，站会时主要过一些进度和风险。

后续会和大家讲一下在迭代过程中，这五个会议是怎么开的。其实也没有什么最佳实践，只不过是根据项目所处的不同阶段和团队的不同成熟度，做法会有些不同。

站会之后有一个Review的会议，这个会议没有整个团队一起参加，主要是我们的测试和PO会和业务方一起去做验收，然后把反馈带到团队中，没有特别好的去和团队做Demo和Review。

回顾会议 是在我带的团队中用得比较多和比较重的一个会议，在这个会议上承载了非常多的东西，团队所有的过程改进和朝着好的方向走，都是通过这个会议。

回顾会议的工具和技巧

下面向大家介绍一下在这个会议上我会用到的一些工具和技巧，我大概是在三年前接触到了引导，因此我会在回顾会议上用到引导的技巧，我还有很多引导的工具，如果大家感兴趣，会后我会给大家发一些相关的链接和书籍。

首先是 视觉化引导 ，我们会把回顾会议上的一些问题框架，通过视觉隐喻的方式贴到白板墙上，通过这个方式来引导整个回顾会的过程。

其次，我还会用到一个框架，叫做 鲜花与拳头 ，具体做法是在回顾会议上我们会针对每个人询问，给他的鲜花是什么？拳头是什么？也就是针对个人，他做的好的是什么？不好的是什么？这个框架需要整个团队的成熟度、亲和度都比较高的情况下才能使用，因为这是评价团队每个人的。

我们的团队会在每个迭代的回顾会之后拍一张照片，贴在我们的照片墙上；回顾会的结尾会有这个 迭代MVP的评选 ，有点儿类似“点赞达人”的玩法，就是每个人轮流分享在这个迭代过程中，他最想感谢的那个人是谁？为什么？被点赞最多的小伙伴，我们会发一个小礼物作为迭代MVP的证明。

回顾会议上，我们还会 评选下一个迭代内部的Scrum Master 是谁，会有一个交接的仪式，由当前迭代Scrum Master推荐下一个迭代的Scrum Master由谁担当，这样就会把团队Scrum Master的接力棒传递下去。

以上就是我们在回顾会上做的一些事情。回顾会议的基本框架，大家可以参考《敏捷回顾》这本书，里面讲得非常详细，如预设会议基调、收集数据、头脑风暴、怎么开展下一步行动等非常多好的实践。在这里我主要介绍的是在这本书之外我尝试使用的一些方法。

回顾会议的技巧篇，尤其想和大家分享一下，我的团队过程改进都是从回顾会议开始的，我的思路是一开始我不会告诉团队我们怎么做是最好的，而是会通过每次迭代后的回顾会议上，根据团队的反馈找到这次迭代最大的问题在哪个地方，然后去做改进，我们的站会通过一轮一轮的迭代演变越来越好，团队的共识也通过回顾会议慢慢变得越来越好，回顾会议是五个会议中最重要的一个会议，我也特别看重这个会议对团队的帮助。

在回顾会议中，除了几个基本的用法之外，再给大家2个进阶的用法，就是教练技术和引导技术如何在回顾会议中使用。

第一个是 教练技术 ，举个例子来说，一般在回顾会议开始的时候，我通常会开展一个 Check in的环节 ，问问大家如果用一种颜色或一个心情来形容你当下的感受，你会怎么说？大家就会轮流分享作为回顾会开始的Check in。有时我也会用图片，让大家选择列出的图片哪张能代表你当下的状态或者感受，为什么？这样往往就能让大家快速进入到回顾会议的场域下面，以便开始回顾会议中正文部分的内容。

还有教练技术中的 打分框架 ，我通常会问团队，如果你给当前这个迭代打分的话，0-10分你会打几分，大家打完分后，我会让团队成员分享得分的地方在哪里？失分的地方又在哪里？这就对应到典型的回顾框架当中，哪些地方做得不够好，哪些地方是需要保持的，可以用这个打分的框架来做一下转换。

同时还会用到教练技术的 积极聆听 的部分，我会鼓励团队多去发言，多去提开放性的问题。积极聆听是一个技术，大家如果感兴趣的话，可以去专门搜索一些资料，看看回顾会议的时候怎么去应用积极聆听，我也可以做一些分享。

引导技术 会用到一些常用的技巧是，团队里面怎么能够让大家都发言而又不尴尬，这样我们就可以 设立一个发言规则 ，比如这一轮我们从谁开始轮流来一圈，没有想要说的可以允许跳过。通过这些引导的技巧使每个人都有发言的机会。

在回顾会上，还会有一个 me/we/us的引导框架 ，如果分小组的话，你可以让每个人先思考，个人思考后可以让每个小组去思考，最后再让每个小组去分享他们的答案或者经验，这也是一个非常好的分组引导的框架。

另外，如果你懂一些 视觉的技巧 的话，你还可以画一些视觉的图来结合你的框架，就能非常好的来帮助团队更好地投入到回顾会议过程中，右下角的这张图就是我当时在用视觉引导的方式给团队开回顾会。

引导技术中还有一种常用的方法叫 停车场，发散与收敛的框架 。比如在回顾会上讨论到一些与当前情况无关的问题，我们会先记录下来放在停车场，我们在这个部分的主题讨论之后，再一起看停车场的内容是否需要继续讨论。发散收敛框架其实也会有非常多的应用，比如说用投票来进行收敛。

上面就是我们开回顾会议的图集，请大家特别关注一下右下角的这张大家一起抱大西瓜的照片，这是团队在进行第10个迭代的时候，有一件特别的事件发生了，之前回顾会议上的一些小零食都是我去准备的，但是在第10个迭代的时候，这个团队的Team leader主动说，这次回顾会上的小零食由他来买，从那一刻起，我就觉得团队里面已经发生了一些变化，并且在那次会后，Team leader告诉我，我是他见过最好的项目经理，也证明了我在团队开展的回顾会议已经是有些收获了。

再给大家分享一下这些图片背后的故事，最上方的那张桌上有一些卡片的照片，在我们的回顾会上，我们除了会遵循传统的框架，还会给大家做一些分享和workshop，帮助大家在回顾会上了解，在敏捷实践中，我们的需求管理会怎样去做等等，通过游戏化的方式帮助团队更好地去理解和应用。

刚刚讲了那么多回顾会议的技巧，回顾会议是为了帮助团队变得更好，那 如何落实回顾会产生的改进项呢？ 我有两个方面的策略，第一个是共识问题，第二个是复杂问题。

• 共识类的问题，我们通常会在回顾会上确定下来我们要怎么做。 比如“站会”经常有人迟到怎么办？我们就定下来迟到的人要发红包。得出的结论要与参会的团队所有人对齐并达成共识，大家都没问题后就要按照规则来，并且把规则放在我们的文档库里，同时也可以在白板墙上写下来。包括之前讲过的不接私活儿、需求进入评审的DOR是什么样子？都是在回顾会上通过共识类的问题定下来的。

这里面有个 小技巧 ，当有人违反了规则，千万不要私下和他聊，就在团队的群里面@他，或者直接把这件事抛出来，比如“这是我们共同讨论的规则，你违反了规则，应该怎么办？”并直接在公开的群里讨论，往往这种方式能让大家更好的守护规则。共识类的问题我是这样做的。

• 对于复杂问题， 我不会在回顾会上对需要很多分析和交流的问题去讨论，我会在会上把这些问题通过投票选出来后，作为Scrum Master将 在下个迭代开始后作为专项的工作去推动改进， 将会和不同的干系人讨论和分析，并在下个迭代的站会上同步改进事项的进展。

这里有个过程改进分析的模型，大概是我们当前发生了什么问题？问题发生的场景是什么？问题的影响有哪些？根因分析用5个为什么去分析，下一步的行动计划是什么？

回顾会的改进项就是通过以上两种方法去推动落地。

五个关键活动的改进

团队的实践其实没有所谓的最佳实践，只有基于上下文的持续改进。 那我做了哪些改进呢？

1）Daily Scrum

• 全职的Scrum Master组织站会到团队轮流组织站会；
• 从关注Task的流动到关注Story的流动；
• 在团队不同的成长阶段做调整。

2）Refinement 

• 最早我们会将需求的Refinement和Planning放在一起，在后期则将其区分开，Refinement更多是和大家澄清需求，Planning则是确定迭代我们要做哪些事情；
• 梳理会我们最初是让大家说要多长时间，没有一个估算的过程，演变为大家利用竖手指扑克估算的方式帮助对齐需求；
• 开始是当前迭代梳理下一个迭代的需求，后续也会做一些改进，当有大项目进来时，对需求进行一次性梳理，延长梳理会的时间，分迭代进行排期。
• 确定梳理的目的是为了Planning做准备。梳理会也有很多不同的演进方法。

3）Planning

• 最早我们是在Planning会议上做了需求的梳理和Planning，带来的问题是梳理完、Planning之后需求还是会有问题，有些依赖项或各种问题没有澄清清楚，带着问题就进入了迭代，这样就会给团队带来很多困扰和返工。所以后续我们将需求的梳理单独的放在Refinement会议上去做，同时在Refinement和Planning中留一些时间去解决依赖项。
• 最终我们将Planning拆分为两部分：第一部分是在Planning时决定哪些需求要进入迭代；第二部分进行技术方案的评审和拆分子任务。
• 排期也会有一些演进，最初是根据团队成员的本能，拍脑袋进行排期，后续则是基于团队的Velocity来排期。
• 将迭代启动、看板初始化作为Planning的一部分。

4）Retrospective

• 从Scrum Master去推动整个回顾会的改进事项落地，到团队内部的Scrum Master去推动，到团队主动Owner这件事情，会有一个逐渐的过渡；
• 探索更多更好的方式去帮助团队，比如说视觉引导，教练的方式等很多不同的实践。

以上讲到的仅仅是针对我的当前上下文场景的实践，根据不同的组织，也会有更好的实践可以去尝试。

1.2 透明拉通团队共识

拉通大家的共识，就是透明的用法。 我当时的做法是给团队画一张团队日历，每两周一个迭代的话，关键的时间节点会被写下来，比如需求冻结日，需求发版日等，这样团队就会知道工作节奏是怎么样的。团队的共识、DOD的相关内容都会呈现在白板上面。

1.3 内驱力模型激励团队

接下来分享一下我在做团队Scrum Master时用到的内驱力模型激励团队，它来源于 《管理3.0实战手册》 ，这是一本非常好的书，大家可以参考。书里提到了激励团队的8个要素，团队的驱动力可以从这8个方面做一下尝试，包括让团队成员在过程中更好的推进，让他们觉得在团队中工作非常有意义和价值，我用的比较多的是好奇、荣誉、认可、能力和关系这五个驱动力元素，接下来就和大家分享一下我是怎么做的。

1）关系：你与工作中的其他人有良好的社会关系，让你觉得有意思并能驱动你。 我通常是在站会和回顾会上帮助大家建立关系。

回顾会上，团队成立初期时，每个新成员我都会安排新人介绍的环节，包括童年？家乡？孩子？个人爱好？第一份工作？帮助团队成员之间拉近关系。这里面有一件特别有意思的事情，年后我带了一个新的团队，回顾会时我问了团队一个问题，“大家觉得一个好的团队会是什么样子？”很多人说，团队成员应该像朋友一样，这就说明了社会关系在团队中的重要性，所以我会用查户口这一招。

另外一个会用到关系模型的就是，在每天站会上和团队分享情绪，在站会Check in的时候谈谈心情怎么样，结束的时候也说说当前的心情，其实都是在帮助大家关注每个人的状态，拉近彼此之间的关系。

第三个招数是投名状，每个新团队成员进入时，我都会邀请他来立投名状，内容主要就是，你作为一个新加入的成员，你能为团队贡献什么呢？除了工作之外的，比如你的兴趣爱好、特长。我们会把每个人的投名状记录下来。

2）荣誉：因为工作体现了你的价值而感到自豪；认可：同事认可你所做的以及你本人。

我们在回顾会上做了点赞达人和迭代MVP的评选，在团队的微信群里公开表扬团队的某些成员，认可他的价值，作为一个Scrum Master你应该及时去认可你的团队，同时投资团队成长是回报率很高的一件事情。在我的团队中，我会经常去买一些小礼物，小零食以及奖牌等送给团队的成员，虽然这些都是我自己花钱去买的，好像是本职工作之外的事，但是往往收获更多的也是你自己。Scrum Master的成绩也是体现在团队身上的，所以Scrum Master也应该多想想，能主动为团队投资一些。

3）能力：工作对你的能力有挑战但在可控范围之内。

我把它应用在内部Scrum Master的培养上，对他们有一个成长路线的规划，这个规划既在每个阶段都有挑战，又在可控范围之内。

• 一阶段：在第一个迭代的时候，只需要组织好站会就可以了；
• 二阶段：第二个迭代，需要支持团队做一些统一流程标准、规范的落实；比如Jira工具上的规范，哈啰内部的一些工作规范需要进行推动，这些都需要一些额外的工作去监督；
• 三阶段：进行迭代的沟通计划，比如迭代启动邮件，迭代的周报和一些其他的沟通计划；
• 四阶段：和内部的Scrum Master去做效能提升，比如如何通过度量体系去看团队当前的状态，并开展过程改进。

1.4 培养内部Scrum Master

赋能团队，我是如何兼顾多个Scrum团队的？具体的做法就是培养内部的Scrum Master。

培养的方法在我现在负责的三个团队中不太一样，有一个团队是选择了固定的Scrum Master，另外两个团队是轮流承担Scrum Master。在培养的过程中，我做得更多的是给他们作辅导，比如开完站会之后，我会告诉他做得好的部分和不好的部分，基本上通过一个迭代的引导之后，Scrum Master就能非常好的组织站会以及一些基本的操作；第二个迭代的时候我再给他一些反馈，他就能做得更多；通常三、四个迭代之后，内部的Scrum Master就能完成基本的五个会议的Scrum运转。

上图右侧定义了，作为Scrum Master的DOD是什么，比如Sprint中，需求要及时的流转，站会组织的DOD是什么，周报的DOD，启动迭代关闭迭代等。

敏捷教练需要具备的多个方面的能力。不仅是要在敏捷精益上有了解，要让一个团队能很顺利的成长，在教练、引导、指导和教学等方面都会有所涉及。这些是我的看法，我也在朝这个方向努力，所以也将这个敏捷教练的框架分享给大家。

1.5 资料分享

接下来，给大家 分享一些我学习过程中比较好的资料。

• 《硝烟中的Scrum和XP》：是一本非常好的实践指南，我的很多实践操作都使用了里面的方法，包括迭代启动的邮件就是参考这里面的，Scrum的任务板怎么去设计、燃尽图的呈现等。
• 《你的Scrum检查列表》：告诉我们每个Scrum的会议应该怎么开？输入输出是什么？有哪些关键要素？
• 《Scrum简章》：告诉我们Refinement和Planning怎么开更好，基于大的发布计划我们怎么去开Refinement，以及产品从0~1的阶段和从1~无限大的阶段我们怎么去开梳理会，里面有非常多的介绍。
• 《用户故事与敏捷方法》、《Scrum精髓》、《敏捷估计与规划》：在在需求和估算方面提供了很多实践指南，其中《Scrum精髓》是Bob老师翻译的，是一本非常好的书，我最近还在读。

下面的这些主要是 教练、引导等方面的软技能的培养。 相关方面的书非常多，大家可以参考。

• 《团队协作的五大障碍》：是我上一家公司的老板推荐给我的，是一本非常好的书。前段时间我在回顾会上做了一个调研，能知道团队当前的主要障碍是什么？包括互相不信任或者不愿意承诺等问题，我会根据调研的结果去确定后面团队的改进方向。
• 《幸福领导力》和《管理3.0》：与内驱力相关可以做的事情，里面有非常详细的介绍。
• 《引导工具箱》、《结构化引导》：告诉了我们非常多引导的技巧，包括怎么按顺序发言等很多非常好的技巧。
• 《敏捷教练》：刚刚讲到的敏捷教练的能力体系来自于这本书。
• 《敏捷回顾》：回顾会的基本框架可以从这本书参考。
• 《Scrum Master做好迭代回顾会的Facilitator》：Ethan Huang分享的Scrum回顾会的很多招数，团队成长的不同阶段回顾会的不同招数。

二、内部敏捷社区

2.1 Thor的故事

Thor是我们社群的名字，它的故事是怎么样呢？背景是当我经历了在哈啰几次组织机构调整后，我从一个团队的Scrum Master变成要负责七八十人的研发团队，这时我发现PMO只有我一个人的时候会有很多问题，包括团队快速扩充、项目太多没人管，流程规范没人推进等，这时我们发起了一个专项叫做虚拟PMO的项目，从每个团队抽取1~2个人加入虚拟PMO，我作为虚拟PMO团队的发起人教大家一些项目管理的经验和技巧，教的形式就是通过Scrum的形式教大家Scrum。

传统的培训方式就是给大家做一次培训就完了，但是我在想为什么不把它发展成为一个长期的敏捷社群，形式上为什么不能通过Scrum的形式来教大家Scrum呢？也就是在当下有这么一个灵感就开始了。下面就是内部社区Thor的成员加入的内部信里的一段话，分享给大家我们的愿景。

下面是团队的基本信息，包括迭代的基本节奏、DOD、团队的投名状等。

• Thor名字的由来： 其实这个团队的组建还是挺不容易的，所以用Thor来隐喻我们的团队会披荆斩棘，最终获得丰盛的果实。
• 团队投名状： 我列出了不开心的时候给大家表演Beatbox，如果熟悉我的话就会知道我是一个会Beatbox的敏捷教练。（Beatbox彩蛋）

2.2 社群的成长路径

通过Scrum教Scrum，产品的Backlog是什么呢？ 产品演进的路线图是Thor中的每个人第一步要学会成为敏捷团队里的好的队员，第二步是要学会成为团队的Scrum Master，这就是一个成长路径图。

每一步我们都有一些要做的事情，比如怎么利用Jira将工作线上化和高效协作、迭代Scrum中参加哪些会议、如何更好的参加会议；当加入一个跨团队的项目时，将要做哪些事情...这些是成为好的队员要学习的一些东西。

当作为Scrum Master的时候，视角就会不一样了，比如怎么用Jira去管理一个迭代？怎么去组织各类会议？怎么去管理一个大的项目？如何去打造一个高效能的团队？以及卓越个人的成长计划是什么样的？怎样做好个人的时间管理、知识管理等等。这些就是社群中团队成员的成长路径。下图就是我们Backlog的story。

以下是具体实践工作中工具的一些截图，有一些重点事项想和大家说，在教你的团队的时候，要刻意的给他们留坑，这个方式能更加让团队感受到哪些事情是重要的。比如需求要不要写验收条件，我在第一个迭代的时候并没有要求写验收条件，等验收会的时候我告诉大家这不是我想要的，通过这种方式就能告诉大家验收条件是重要的。估算这件事情为什么一定要做，比如交叉估算等等，有很多的实践技巧都是在一个一个坑中给大家传递的。 在社群中，我们还有一个成长体系，由社群的能力成长委员会进行评估。

• 第一个阶段，如果你达到了基本的能力要求，就会发一个结业证书，标志你已经完成了基本技能和知识的学习。
• 第二个阶段我们会有一个领导力的排行，如果你在每个迭代中owner的需求足够多的话，等你集齐七颗龙珠时，就会获得领导力的认证，也会发一个认证的信物。

在社群中，我们还进行很多实践，比如针对需求梳理会进行了实践，当我给大家讲解完需求后，大家在群里估算，挑出最高和最低的分别澄清他的理解。

2.3 内部社区 — 社群运营

社群的运营其实有一个框架，也可以理解为个人品牌的框架。最早我在Bob老师的社群分享过一次个人品牌，当时也是按照“引流-促活-转化-拉新“来帮助社群做得更好。

1）引流 & 拉新

我首先会组织一个爱好者社群，可以理解为一个流量池或者其他说法，把感兴趣的人都拉到一个群里面，然后我会在公司内部去做一些事情，包括：

• 积极社交、内部分享；
• 口碑营销、话题营销；
• 朋友圈、内部论坛持续更新进展；
• 收集大家在社区的成长故事。

让大家知道我们这个社群在做哪些事情，进展怎么样。在这里给大家分享一下团队成长故事，这也是在社群里拉新的一种方法。我会在团队成长到一个阶段，也就是完成Leve1的认证，我会让他去分享经验和收获，这样会把我们社群的影响力往外传播，而且我要求他们要把邮件抄送给他们的Leader。

2）促进活跃度

我会在爱好者社群里做专题的分享，也会去发起一些讨论，与大家进行互动。如果被我们打动了，就会加入我们的团队，核心团队成员会开展迎新活动，有专门的迎新邮件，也就是之前给大家看过的，介绍Thor的邮件。

内部社群其实还有很多玩法去探索，目前核心团队已经有了十几个人，我发现一个团队已经cover不住了，后续可能会尝试拆分团队，借此机会，我也可以进行大规模敏捷的尝试，例如我们可以去做一些文化渗透，定制一些Thor周边的产品，例如发表我们团队在项目管理方面的周刊，招募一些社群的志愿者等等非常多的玩法可以去探索。

Thor这个社群成长的过程，也是很好的帮我践行敏捷的一个过程，我的很多技能都是在组织这个社群的过程中学会的，所以我觉得还是很有意义的一件事情。

三、Q & A

Q：在 Planing 会上是怎么做技术方案评审的？

A：如果是迭代优化类需求，我们更多是团队自己拆分子任务；如果是近期的大项目，我们的架构师会带着大家一起做技术方案评审。

Q：公司内部SM实践中具体要做哪些工作呢？有时候都轮流做了

A：Scrum Master 要做的内部 SM 都要做，应该会有一个逐步成长的过程，例如从组织站会先开始。

Q：如果是近期的大项目，我们的架构师会带着大家一起做技术方案评审 ，这时候需要有技术文档吗？而且这个技术方案评审是在单独的其他会议进行，应该不是在 planning 上吧？ 

A：会有其他会议，应该是团队 Refinement 的一部分。我理解 Refinement 的灵活性其实在这里。

Q：请教一个关于Thor 社区的问题，最开始是凭着大家兴趣发起的，还是按照专题项目推广的？对这个团队的激励是如何考虑的？

A：最初是凭大家兴趣发起的，完全是凭借口碑宣传、扩大。——@ 尔东陈

Thor的运行模式特别适用，感觉是即学即用的那种，愿意放弃休息时间来学习成长。——@ Jerry.Jiang

主要是个人身处团队的特殊性，需要有人去做出改变，刚好Thor符合这样的需求，解决团队需求的同时，自身也能得到成长。——@ 晚来凤急

我觉得是thor本身运行模式就能让我们亲身体验敏捷迭代的运作方式，然后在每次迭代里面还会系统的学习敏捷知识。而且团队很nice，大家互帮互助，互相分享趣事，积极帮忙解决困难。——@ 焦鹏飞

加入Thor团队，初衷是扩充对SM知识点，解决当前遇到开发遇到的困境，提升研发效能。加Thor入团队快两个月，吸引我的好多，学习氛围好，教练人帅……太值了。——@ 王清妹

Q：开发团队这边有前端、客户端等不同模块，目前有鼓励大家做跨模块的扩展吗？如果有大概是怎样发生的？

A：全栈工程师可遇不可求，我目前团队没有遇到全栈的苗子。不过我会鼓励大家更多理解端到端、交付价值，多去尝试内部 SM 的角色。鼓励内部 SM 的方法：找到 SM 对他成长的意义，和他目标保持一致、和他老板拉齐目标。最后鼓励在绩效上写上这部分的成长目标。

Q：我现在的困境是，公司对敏捷不了解，也没打算做敏捷。同时团队有很强的原有瀑布项目管理文化，我感觉实在拥抱一颗仙人球，无处下手，同时管理层的认知也是 推式的，而我想要做拉式的，被认为是想要偷懒。

A：我其实现在的策略偏向于先不提敏捷，先从一两个敏捷实践开始帮助团队。我们的项目经常出现救火情况，那我们开始开个站会吧。我们的会议总是很难凑齐人员，尝试固定会议时间吧。

Q：推荐的那么些书，有优先级顺序么，从入门到精通模式的去看，一下子这么多，有点儿无从下手了。

A：如果是敏捷实践相关的建议从硝烟中的Scrum和XP 开始。

内容来源：敏捷+社区线上直播005期，《我在哈啰的敏捷之旅》分享实录

分享者：哈啰出行陈文博