什么大多敏捷实践从站会开始

现在我们一起来聊一下为什么大多敏捷实践从站会开始。

我之前在服务团队的时候经常会用下面这个例子作类比：公司里面推敏捷，就像我们国家一直坚持不懈的发展高铁一样。回到北京夏季奥运会开始前，咱们国家第一条真正具有划时代意义的高铁线路（时速350km）是在2008年的8月1日，是从北京到天津的这条线路。经过大量的测试实践掌握了前期的经验，再有了后来各个的条新线路的发展，在这个发展过程中遇到了好多的问题，也经历了媒体等的不信任报道，但是国家没有放弃，切实的把问题一个一个的解决掉。那么到现在为止，我们的高铁已经成为了我们国家飞速发展，造福民生的基础设施，被世界各国人民所艳羡。咱们国家地大物博，一开始就坚信发展这个领域对未来快速腾飞、实现中国梦具有极高的战略意义。现在看来中国高铁已经领先世界，除了已经成为中国人民习以为常的基础设施，在这个过程中也带动了材料、信号、轨道、人工智能等等领域的突破，开始对外输出；成果为世界人民共享。

敏捷在一个组织里面的发展也一样。刚开始可能会遇到不少实施上的问题，牢记敏捷价值观坚信能为公司或者团队带来收益。赋能给每位成员，用实践创造价值，慢慢的你会发现，咱们的敏捷实践也会成为组织飞速发展的基础设施。为公司竞争力提升建立良好的组织基础。现在你只需要在你的组织里面找到一条北京到天津的高铁开始试点就可以了。

回到今天的主题，为什么大多敏捷实践从站会开始？我们的目标是希望能把众安在站会实践过程当中积累的经验，还有一些还有一些正在实施新的实践持续不断的分享出来。在前几年，会听到好多人说敏捷其实就是站会+看板。因为站会+看板是公司里面敏捷事件的外在表现，大家最先感知到的就是站会或者看板这两个实践。

站会这个实践门槛比较低，站会只需要每天花5~10分钟的时间、效率比较高。花费比较少的资源做好信息同步，极大的降低延期交付的风险。对于站会组织实施者来讲，压力比较小，负担也不是很重。在刚开始其他的敏捷实践相对比较重不利于前期切入。也能够让你的团队成员对于目标更清晰，促进团队成员之间的熟悉程度，鼓励多沟通，便于阶段性目标的对齐。降低未来因为沟通不充分、信息不对称带来的风险。在研发过程当中，每个人看到需求都可能有不同的理解。当出现一些会阻碍我们当前的研发进度的情况的时候，那我们也可以根据组织资源利用率最大化这个准则做资源调配。研发的同学都是最金贵的。

那么如何能够把站会开好呢？我们在众安里面是这么做的：

刚开始到组织里面进行敏捷服务的时候，不会开始就进行敏捷的一些基础知识的培训，或者敏捷主流框架的宣导。会先和团队里面的核心干系人进行沟通，发现问题。这些问题大多都可以通过站会来解决。不能通过站会来解决的作为接下来敏捷实践的backlog.在站会开始之前，我们需要做些准备。我曾经服务过一个之前就有站会，我参加过之后发现：大家站一个圈儿，逐个向leader进行汇报，没有发挥出展会的主要作用。信息不是很透明，向某一个人汇报，其他人基本上对于对于当前汇报的同学来讲的这个信息基本不感兴趣；汇报完之后leader又能记住多少呢？所以我们需要准备一块看板。团队初始的时候建议用物理看板。看板上的内容有哪些？

比较简单一点的看板上，有团队的任务，任务怎么来？任务来自于需求，那么按照敏捷实践来讲的话，就是用户故事，那么用户故事是怎么来的呢？是产品同学经过需求分析提炼得来的。所以我们第一步需要把我们的这个看板上的内容你要提前准备好。团队所有任务方向、价值都由咱们的产品同学提供。为了看板上的内容，咱们需要赋能产品同学具备把需求按用户故事的形式展现给团队的能力。这样能够更好的让我们的研发同学顺滑的开展下一步的研发工作。如何让产品同学参与进来，用户故事是个帮助他进行信息传递的好工具，产品同学所负责的产品所掌握的知识在他的脑海中非常的清晰，非常透彻。如何把他的掌握这些透彻或者清晰产品图展示出来呢？做一个需求分析，写一个比较详细的文档，然后再做需求评审。说实话这种方式，不能给我们研发同学很好的进行信息的传达，出现因需求理解不一致导致的风险的情况几率较高。

我们用用户故事+故事地图这个实践能很好的解决这个问题。我们在服务EAST这个业务比较复杂依赖方比较多的项目时候就用了这个实践。该项目涉及的团队和模块儿比较多。不单单和组织内部的五六个产品模块的沟通，还涉及到部门之外的协调。主导这个项目产品同学对需求涉及到的模块儿非常清晰，但是依赖方模块儿的产品同学对于如何配合不是很清晰。本项目设置了里程碑，时间在一天天消耗，在这种情况下这个项目的用户故事地图就起到了很好的作用。用故事地图帮助产品的主要负责人把产品思路同步出来。并且把这故事地图展现的信息很好的同步给依赖以及支持的产品。识别出目前需求的状态，哪些待确认的需求？哪些依赖需求？用不同颜色的贴纸展现出来。并把这些信息落地在公司自研的功能非常强大的项目管理工具----TM上形成任务跟进起来。这是一个典型的实践。落在工具上以后就有了一个逐步完善的product backlog list。

有了product backlog list与之配套的梳理、拆解等相关实践就可以准备了。在做需求评审的时候，每一次需求评审大概一个小时左右，合理的需求拆解和颗粒度一次评审5~6个需求（用户故事）。每个需求我们会引入故事点估算，这个实践能够量化大家对于这个需求的认知统一度，需求拿到故事点了说明团队理解达成统一，故事点点数也可以成为团队吞吐量的重要指标。

需求拿到故事点之后，每个需求设置一个Owner。Owner起什么样的作用呢？他可以是我们的前端同学，也可以是我们的后端同学，也可以是我们的测试同学。那么这位Owner负责这个需求能够正常交付过程中遇到的所有技术相关的一些问题的处理、沟通和协调，包括与其他团队的一些接口依赖和功能上的依赖。需求没有问题之后，拆解出对应研发同学具体的任务，那么我们识别出前置依赖，后置依赖和对应的一些技术人员和技术的依赖方。出了排期，有了任务，把这些任务和排期都落地在TM这个工具上。另外，拆任务的时候我们鼓励大家所有的任务是小于等于八小时的，就是力争在一天内完成。一些研发团队的同学觉得我拆这么小的一个颗粒度是比较难的一个事情，鼓励大家朝这个方向走，这样方面有什么好处呢？

第一，敏捷轻文档了，研发同学拆的越细，拆的过程中拆的越细思考的越充分，思考越充分，由于你思考不充分带来的技术风险就会降低。

第二，站会上的我们看板上每个人的任务是小于等于八小时的，我们每天都会开站会。这样颗粒度的任务状态都理论上每天都应该是有更新的。如果没有更新，就是风险。

第三，降低项目经理管理项目的复杂度和难度。由原来跟进项目的进度的过程转变每天站会问题自发暴露的过程。站会时如果某个同学的任务没有没有完成，表现为该任务的状态没有变化的话，这就需要关注，可能潜在的一些风险。发现问题，会有象征风险或者问题的这样红色的纸条，或者是在任务上标志出来这个风险。owner在下次站会之前，需要给大家来同步一下这个问题目前的状态。

这样按照任务在研发过程中的不同状态把看板建立起来了。

初期建议大家适用物理看板，跑两三个迭代之后，基本操作相对固化了，把它移到TM工具上。TM是一个功能强大而又非常灵活的系统工具，不单单能够展示像其他工具上面的看板的功能，我们还可以实时的在我们的任务上进行添加标注。标识出这个任务是不是延期？我可以实时添加这样的标注来提醒我们的团队成员，并改变该任务的颜色，从看板整体来区分出来那些是有风险的。

这是我们建立看板的一个过程。

建立机制非常重要。

一个团队真正开始站会之前我们也需要建立建立一些机制，这些这些机制是起什么作用呢？比如说我们要让团队成员自己商量站会的开始时间。众安有相对比较灵活的上班时间。团队成员达到达成一致之后，比如说我们现在9:50开始，那么希望大家就都在这个时间能到。那么如果你没有到的话，那我们也需要让大家一起来商量出迟到的应对措施或者是负激励方案。建议大家男生五个俯卧撑，女生五个深蹲。还需要把你做深蹲或者俯卧撑的过程拍成小视频发到群里面，增加趣味性和影响性。另外分享一下，建立这个机制的过程可以不单单应用在站会上，还可以建立迭代的测试覆盖率，提交代码的一些规则机制建设上。任何违反规则的行为都可以把它兑换成俯卧撑或者深蹲这样的一些小技巧。所以大家建立这样一些机制之后，我们很多的一些实践就可以持续不断的坚持下去。这是我们站会前需要准备的。

作为敏捷推进者，鼓励和团队里面所有成员沟通，会发现好多的一些问题，用解决问题的思路来驱动我们的这些实践。

站会准备好了，就开始站会吧。按书上说的每个成员面对着大家介绍一下昨天做了什么？有没有遇到问题，计划今天做什么。我们还建议会上同步下与你相关的依赖方的任务状态。

面对站会成为向领导汇报的短会的问题，我们也有比较丰富的实践经验。会鼓励和leader沟通，让他相信你的团队，他们都很强的。尽量不要在团队成员同步状态时干预太多。Leader想参加站会的话我会给他主备一叠便签纸和一支笔。当发现问题的时候，不要当面指出来，在纸条上写下来。写下来之后来，轮到你说的时候，把记录这些问题同步给大家。并设置一个对应owner，让他在站会之后来解决掉。

建立小团队的信息中枢。

在我目前服务的团队的过程当中，研发同学相对来讲是比较内敛的。遇到问题的时候喜欢研究一定要把它解决掉。其实有的时候，你花了花了半天时间来钻研这个问题，可能对你来讲是一个学习的过程，但是对于项目进度来说可能是一个风险，我们的目标是真正的是要交付这需求。所以当你研究了一两个小时之后发现还没有很好的解决这个问题的时候，建议你把这问题抛出来。因为公司整个组织里面有太多经验比较丰富能力比较强的同学，你把抛出来之后问题能够很好得到解决，也能够给大家营造一个良好的学习氛围。作为敏捷推进者来讲，我也会鼓励敏捷推进者、master或者产品经理或者是leader更多的去和团队成员进行去沟通。了解到每个团队成员擅长的技术是什么，了解他的性格，了解到他不擅长什么。这个时候，你能在这个组织里面起到一个技术和信息中枢的作用。当有出现问题的时候，他你可能不能给他解决，但是你可能知道谁能帮他解决，在技术比较强的这样的公司里面，这样的信息资源中枢还是非常有必要的。作为敏捷的新人，为了更好的服务团队掌握更多的信息，能够很好的帮大家解决这个问题，也能够提高影响力。促进资源能够更更好的合理利用，为迭代正常交付保驾护航。

站会的时候，如果你跟你的团队的成员每个人都非常熟悉了之后，某个成员之前在站会的时候他的声音非常的洪亮，同步信息也很清晰，突然间有一天他的声音比较低了，这可能存在风险。有的时候一个眼神也可能看出他内心的一些活动。鼓励大家更多的去是去跟你的团队进行沟通，同时也能物色出这个团队里面未来的敏捷维护者。

TM有很强的数据搜集功能，是团队度量的好工具。

各个组织里面都会牵扯到项目过程、资源利用数据上的一些搜集，或者对于团队的一些度量指标的设定。TM工具具有强大的数据搜集、报表生成功能。

在众安我们能够实时的看到团队的数据，通过数据能够识别我们团队目前出现的问题。针对这些问题实施一些改进的实践。站会前后的数据更新也可以成为团队日常的机制，如果某些同学没有及时更新，俯卧撑和深蹲就起作用了。

如此下来相信团队的站会会高效持久的坚持下去。

通过站会的实践你会发现很多能够用敏捷实践解决的问题，运营下这些问题，并帮团队解决。通过两三个迭代形成适合这个团队的敏捷框架。

以上但不限于这些实践都会在众安精心打造的敏捷实战训练营中手把手的拆解给入营者。