作者：黄隽（Charlie）

八月的最后一天中国DevOps社区在大连举办了第二届Meetup。关于本次Meetup将从社区活动介绍、活动内容和流程、分享的主题、心得等几个方面来小结一下。

先分享活动后对专业人士的采访吧…

社区活动简介

中国DevOps社区大连Meetup是一年一度的大连本地DevOps社区聚会，旨在传播DevOps文化，落地DevOps实践，帮助大连本地的IT从业人员共同学习和进步，也是帮助有需求的企业培养更多的DevOps人才。到今年已经举办了两届，这次由DevOps社区主办，敏捷江湖桃花岛社区协办，邀请了大连本地著名公司的DevOps和敏捷专家为大家分享和现场答疑。

中国DevOps社区

中国DevOps社区由一群拥有相同价值观和理念的志愿者们共同发起，并于2018年7月正式成立。社区的目标是推动DevOps在中国的蓬勃发展。社区设有理事会和专职运营人员。

社区使命：传播DevOps文化，落地DevOps实践

社区愿景：成为中国DevOps运动的领航人与催化者

社区核心价值观：开放、专业、使命感

敏捷江湖桃花岛社区

敏捷江湖桃花岛社区是19年1月成立于美丽的浪漫之都大连。由最初单纯的敏捷分享交流演变而来，《华山论剑》是社区的金牌活动。由开始的华为云DevCloud敏捷专家组和运营组以及邀请的圈内几个好朋友一共十几个人组成，现在已经发展到二百多人。主要成员为敏捷教练、DevOps工程师、企业家、高级项目管理人员、出版社的朋友们。社区努力打造高价值的技术和人脉分享平台，共建敏捷生态圈。

内容和流程

本次活动上、下午共计一百人左右，从上午10：00持续到下午6：20。主要进行了DevOps和敏捷相关实践、主题分享。上午DevOps动手操作，下午DevOps和敏捷主题分享和最后的Open Space互动。

第一部分：上午进行了DevOps实战工作坊。

来自IBM的明星DevOps团队，为大家带来为期2小时的DevOps实战工作坊！你有机会在专家的指导下，模拟项目实景，亲自上手体验DevOps的工具链操作，用最短的时间，最快的路径，获取DevOps的知识和实操经验！

该工作坊是国内首次由经验丰富的一线DevOps专家设计的，基于项目实景环境，帮助参与者直接获取实操经验的工作坊，机会难得。

第二部分，下午上半场进行了DevOps&敏捷大咖心法分享。

本次Meetup活动汇集了来自IBM,、埃森哲、东软、华为云DevCloud的资深实践专家，为大家分享DevOps&敏捷在实施过程中的宝贵经历。参与者可以获取一手经验，了解到DevOps&敏捷在团队层面的操作，以及在部门和公司等更高层级上的应用和影响。同时一窥大连本地的各主流公司对DevOps的应用情况，及各公司内部的DevOps生态环境。

第三部分，下午下半场进行了“开放空间”活动。

由各位主讲嘉宾带队，每位参与者都有机会提出或选取自己最感兴趣的关于DevOps&敏捷的问题，获得大咖的深度解答，同时可以和参会的其他同行进行深入讨论，互相学习。

主题分别为：

如何进行CI\CD？---埃森哲架构师 刘玉森

如何保证DevOps的安全性？---IBM DevOps应用安全架构师 于湍(Nick)

敏捷团队如何做绩效管理？---IBM 敏捷教练管 婷婷(Lisa)

如何快速落地敏捷？---东软敏捷教练 巩敏杰

敏捷站会你开对了吗？---华为云 DevCloud敏捷专家 黄隽(Charlie)

分享的主题

在最后2个小时左右的Open Space环节，对大家感兴趣的几个话题中选出了“如何正确开站立会议”进行了引导、分享，同时介绍了我们DevCloud敏捷专家组日常站会。

会上大家关于站会的问题集中在：    

总结的18Key如下，得到了很好的验证，具体关于18Key内容可以参考【DevCloud专家智库】中的“何如玩转每日站会”：

Key 1: 主持人

会议主持人（比如Scrum Master，也可以团队成员轮班，轮流感受下站会的节奏）确保会议的举行，并控制会议时间，团队成员进行简短有效的沟通。

Key 2: 两个比萨大小的团队

在《Scrum敏捷软件开发》一书中，作者麦克.科思提出了一个简单的方法用来辨别什么是合适的团队规模，那就是，如果两个比萨够整个团队成员吃的话，那么这个团队的规模比较适合。

因为两个比萨大小的团队跟家庭的规模相似，站立会的目标可以轻松达成。当团队是家庭规模大小时，人们头脑中就很容易追踪到团队中发生的事情。人们可以很容易地记住每个人每天的承诺，以及每个人对于其他成员或团队成果的责任。Scrum中也建议团队规模不要太大，一般为7-9人左右。

最后再强调一点，并不是要求团队一定要按以上15key进行开站会，15key只是在很多实践中总结出来的一些经验，曾经解决过很多问题。对于每个具体团队需要结合实际情况进行选择应用15key,没有绝对的对与错，只有适合和不适合。

Key 3: 限制发言

团队外成员也可以参与，但没有发言权。Scrum中曾经使用过术语“猪”和“鸡”来区别在每日站会中哪些人应该参与发言，哪些人就站在旁边看就行了，不过这两个术语现在已经不用了。这两个农场动物术语来自一个老笑话：“在早餐吃的火腿鸡蛋中，鸡是参与者，猪是全部投入了。”显然，Scrum使用这些术语是为了区分参与者（鸡）和为了实现冲刺目标面全力投入的人（猪）。在每日站会中，只有猪应该发言，如果有鸡参加例会的话，应该作为旁观者。

Key 4: 预留缓冲时间

建议开发团队在上班时间后的半小时或者1小时后开每日站会。这样可以给堵车、喝咖啡、查看邮件、去卫生间或其他每天上班后的例行工作提供一些缓冲时间。晚点开会还可以给开发团队一点时间来检查前一天的工作（比如，前一天晚上开始运行的自动化测试工具所生成的缺陷报告）。

Key 5: 同时同地

每日站立会议应尽可能在同一时间、同一地点召开，最好的方式是在团队的可视化的任务板前面召开。同一时间和地点也可以有效帮助团队成员形成固有的节奏，不用在找地点和确认当天的开会时间浪费时间。

Key 6: 准时开始

所有的团队成员需自觉按时到场，会议主持人要按照预定的时间按时开始会议，而不管是否有人还没到。对于迟到的人员要有一些惩罚措施，比如缴纳罚金或做俯卧撑等。惩罚措施和数量由团队成员事先共同商定，如果是罚金，如何支配也由团队共同决定。如果团队成员就是不自觉按时到场怎么办？关于更多这方面的解决方案请参见下面的了解更多中的“成员迟到的解决方案”。

Key 7: 站立开会

团队成员一定要站着开会，这也是会议的名字叫站立会议的原因。站着开会确实比坐着开会简明扼要，让人更想快一点结束会议，开始一天的工作。坐下容易使人放松，精神不集中，不易控制时间（相信很多人有体会）。

Key 8: 强调站会目的

经常强调站会目的，特别适合刚刚启用站会的团队。可以由Scrum Master来强调，如果没有Scrum Master也可以由其它Leader（轮职的主持人也可以）来强调。然后询问团队成员“站会对你们来说怎么样？你们得到了什么成果？”几次以后，团队成员可能选择目标声明作为每天的度量，在每次站会之后，团队成员对自己的表现做出相应的评价，是一种强有力的自我管理工具。

Key 9: 聚焦三个问题

站会期间，团队成员就说那典型的三个问题（昨天…今天…障碍是…），其它事情不说。只讨论已完工和即将开始的工作，或者在这些工作中碰到的问题和障碍。目的不是向领导汇报工作，而是团队成员之间相互交流，以共同了解项目情况和共同解决问题。

Key 10: 眼神支持

这是一个好玩的游戏：当一个人站在前面发言时，要求其他团队成员都直视发言人，并进行眼神交流。别让发言人抓到你在看别处。这个游戏帮助发言人的发言简洁，同时可以加强成员对发言人所讲内容的理解。这样可以帮助团队加速完善每日计划。

Key 11：严格时间盒

站会是开发团队的一个时间盒限定为 15 分钟的事件。 时间建议不要太久，对于5-9人的团队来讲15分钟的会议时间足够。

Key 12: 会后讨论

某位团队成员在发言期间，其他人员应认真倾听，如有疑问可简短确认，但不应做过多讨论。如果对某位成员的报告内容感兴趣或需要其他成员的帮助，任何人都可以在每日站立会议结束后即刻召集相关感兴趣的人员进行进一步的讨论。

Key 13: 问题风险跟踪

将站会成员遇到的问题和风险做概要的记录（不必详细，只要说明重点即可，不需要在记录上花费更多的时间），然后保留到wiki，或者方便大家跟踪的地方。此目的是确保这些问题和风险得到了闭环（例如，问题和风险可以会后按排专题讨论、跟踪，直到关闭）。

Key 14: 回顾改善

本身每日站会就是最小化的戴明环（PDCA），另外团队在回顾会议上时也可以对站会开的效果进行回顾，哪些地方做得好，哪些地方做得不好，有哪些改善点可以在下一轮迭代中改善等。（站会只是回顾会议中一个回顾点，如果没有问题不用做专题回顾）

Key 15: 发言棒

站会时可以利用一些小道具来保证会议不会超时。团队可以找一只笔或者一个娃娃（女生多的团队）作为发言棒仍给一位成员，让他拿着发言棒陈述完“三个问题”，然后将其交给下一位。没有拿发言棒的成员不允许发言。如果有人用时过长，建议把发言棒换成一个水桶（当然是盛满水的）让他托起，直到托不动为止。如果他想说就让他说，要么会议很快结束，要么我们的开发人员练成强大的臂力，按经验，一般都会挑重点说，会议按时结束。

Key 16: 冲刺待办列表

站会中，成员在发言时可以利用冲刺待办列表来检视当前工作项的完成状态。冲刺待办列表记录了团队成员工作的进展，需要每天更新并跟踪。电子化的冲刺待办列表更能很好的解决异地团队开站会思路不聚集的问题。发言人在讲那“三个问题”时，同步可以展示冲刺待办列表给团队。

Key17: 任务看板

在站会期间，通过任务板，团队中每一个人都可以知道哪些工作正在进行，哪些工作已经完成。团队关注事情的完成，一直处于进行中的任务为被发现，成为当前的焦点，这样团队就可以尽快把这些焦点问题解决掉。

Key 18: 燃尽图

燃尽图是将进展和剩余工作情况可视化的有力工具。一般竖轴表示剩余工作量（小时、故事点或工作项个数），横轴表示冲刺时间（一般单位为天）。

开站会时，发言人可以利用燃尽图来做进展讲解。燃尽图让所有团队成员一眼就可以看出冲刺的状态，进展情况非常清楚，看出工作是否在按计划进行，状态是否良好。这些信息可以帮助团队确定是否可以完成预定数量的工作项，并在冲刺早期做出明知的决定。使用燃图易达成如下效果：

高可视性，直观展示进度情况和剩余工作；

快速识别风险；

帮助团队建立信心，了解自己的能力；

了解团队成员工作步调；

了解团队冲刺计划；

和任务墙能非常高效地匹配使用。

关于18key，这里想强调一下，并不是站立会议时要把所有18key都要执行一遍，这里的18key只是提供了一些参考实践和关键点，18key来源于大量的实践，也解决过团队站会的问题，所以大家在站会遇到了问题时，可以先想到这个18key，然后选择适合自己团队的key。没有绝对的对与错，只有适合和不适合。举一个例子，这里有四个key是关于工具的，这些工具我们都要使用吗？当然不一定。敏捷宣言里提到“个体和互动高于流程和工具”，工具是为团队服务的，不是团队的负担，更不能被工具所绑架。所以团队一起选择适合的，才是正确的做法。

心得

1.促进人才交流，更多的小伙伴们有着共同的爱好走到了一起。助力DevOps和敏捷人才的培养，更多的人才加入到DevOps和敏捷的队伍中，为需要的企业做人才储备。

2.了解最新行业动态，一窥大连本地的各主流公司对DevOps的应用情况，及各公司内部的DevOps生态环境，良性促进行业发展。

3.高校志愿者学生提前感受IT前沿管理和技术内容，明确日后学习和发展方向。