凤凰沙盘回顾

简介: 凤凰沙盘回顾

640.jpg

写在最前面

       最近在读《凤凰项目》的姐妹篇《独角兽项目》,就随手翻看了下上一次玩凤凰项目沙盘的记录,感觉收获还是不少的。给我印象最深的有两点:

       第一是顺畅的沟通。不管在什么样的团队中,如果沟通不顺畅,那必然会导致很多不必要的浪费和冲突,如何让团队保持一份良好的沟通环境,让成员能够没有负担的说出自己的想法,愿意去表达自己的想法。因为玩沙盘的时候,人员是临时聚集在一起的,彼此都不熟悉,顺畅的沟通显的更加重要。

       第二是无责的文化。大家都是第一次玩这个游戏,对游戏规则的理解各不相同。在第一轮结束后,成绩不理想的情况下,如何安抚队员的情绪,审视过程中的问题,包容队队员所犯的错误,成为能继续玩下去的关键。在现实的团队中也一样,构建心理安全的环境尤为重要,只有在这种环境下,才会产生更多的创新和意外,相信团队的创造力,允许犯错,管理者会收获不一样的回报。

   

凤凰项目简介

        凤凰项目DevOps沙盘是由欧洲著名沙盘游戏研发机构Gaming Works的创始人Jan Schilt先生联手《凤凰项目》一书的作者Gene Kim 先生联手开发的同名沙盘演练课程。凤凰项目沙盘演练覆盖了业务场景中所有的职员角色,尤其是那些从事IT开发、IT测试以及IT运维工作并希望通过精益(LEAN),敏捷(AGILE)和IT服务管理流程如(ITIL)等最佳实践来提高IT服务表现或通过IT解决方案为业务创造价值的IT专业人士。该沙盘同时也是为那些通过创建更好的协作氛围并最终实现更高效以及更精确的IT解决方案部署的企

体会1:明确需求的验收标准

现象:第一轮由于不明确游戏规划,不清楚验收标准,导致很多需求都没有及时的完成,所以看似完成了很多需求,但是都没有到对应的分数。

收获:不管是在游戏还在实际的工作中,敏捷强调在迭代计划会期间,就需要全员一起制定DOD(Definition of Done),以明确什么是“完成”。但是我们经常都以自己的经验主题自认为清楚什么是“完成”,结果自己的信息和别人的信息不对称,导致冲突产生。可以在看板的泳道下方明确列出每个泳道的“完成”要求,统一信息,让大家对齐目标要求,以便更好的合作。


体会2:了解游戏规则,提升效率

现象:在第二轮的游戏中,由于我们知道了验收标准就是测试手中的那份每个节点的数字总和。于是我们就把手中所有的卡牌按序排列,然后就不管卡片上的具体内容了。找到需求对应的点数,然后放卡牌,很少关注卡片本身的内容 。(没玩过的同学看不懂也没关系,简单点说就是通过了解规则,然后只对结果负责,走了一些偏路)

收获:游戏中的规则其实就是现实场景中的客户需求,只要清楚的认识到客户的需求是什么,就可以快速交付,产生价值。过程是否“合规”,其实并不是很重要(不合规并不是指是偷工减料,而是真实沟通和理解用户的使用场景和目标,而不是根据自己的经验认为用户“应该”会这么用、“可能”需要这个功能)。不要迷恋“最佳实践”,可以借鉴但不能照搬。


体会3:明确各环节工作量,提升整体效率

现象:在游戏中,每个环节(不管是产品、研发还是运维)都有工时的限制,所有卡片完成都有对应的工时,不能超出,否则会被随机抽掉一张卡片而导致需求交付不完整,无法获得分数。

收获:敏捷的理念中有WIP(限制在制品,就是个节点最大允许的工作容量)的概念,现实工作中,团队成员的工作时间也是固定的。为了团队的良性发展,保持稳定的速度(衡量团队DevOps实践是否成功的三个标准之一,其它两个是对应变化和交付高质量的产品增量),我们不提倡加班,可以通过培训、学习的方式来提高每个成员的产出,而不是通过堆人或者加班来解决,因为那是不可持续的。(道理总是对的,但是实现还是需要妥协,适当加班吧。。。。。。)


体会4:学会信任,勇于担当,主动接任务

现象:在游戏过程中,负责测试的同学对验收结果不明确、部分同学卡片要求看错,也有拿错卡片的,产生了各种的错误。但是团队成员并没有对因此产生的结果产生抱怨(前两轮的成绩不是很理想)。在后面2轮中,大家有了明显的改善,很多工作量相对较轻的同学主动负责起检查的工作,并提出了一些创新性的办法来提升速度和质量。

收获:不管是在游戏还是工作中,成员难免会犯错,我们不应该过份针对某个人或者现象。在敏捷中也提倡免责文化,我们应该帮助每个人解决问题,提升团队整体的效率,学会信任。同时在遇到问题时,要勇于担当,主动接任务,我们是一个团队,是一个整体,一般情况下会共事比较长的一段时间,更需要紧密的合作。同时,免责不等于无责,在经过几次的沟通后,如果成员不做出改变,可以考虑调整出团队。我们希望每个成员都是具有自主成长的意识,免责不是挡箭牌。


体会5:检查反馈

现象:在后面的几轮游戏中,大家慢慢适应了游戏规则,从而更快的完成自己的任务,同时会相互帮助其它成员check卡片是否选择正确。

收获:在明确了DOD后,及时检查结果并沟通反馈是非常重要的,团队并不依赖测试人员对每个环节进行检查,而是自发的进行检查并帮助其它成员。质量内建是现在团队提升产品质量的重要手段,只有在每个环节都对质量负责,最终的交付才会是高质量的。及时反馈有助于团队的沟通,及早发现问题,修复成本也会降低。


体会6:唯一不变的就是变化

现象:在最后一轮游戏中,CEO给我们增加了很多的政治任务,必须优先完成,导致我们的工时都浪费在这上面,游戏的最后几分钟,这些任务又都被取消了(说是CEO换人了,哈哈)导致工时出现了空缺。

收获:在这个快速变化的世界,唯一不变的就是拥抱变化了。如何增加团队的适应性成为了重要的课题,不管是Po,还是Sm,都要为之做出更多的努力。


成功的团队需要的基本文化

1. 顺畅的沟通:通过沟通使问题被更早的发现并放置到看板上,透明化的信息有助于团队更好的识别和解决问题。

2. 明确的分工:各司其职,掌握完善的技能,努力提升自己。

3. 高效的学习:大家都是第一次玩这个游戏,谁能高效学习游戏规则,就可以尽早建立优势并扩大优势。

4. 无责的文化:共勉,做分析具体的事而不是针对人。5why方法要注意使用场景。

5. 1+1>2的创新



相关文章
|
监控 Linux 开发者
Docker服务systemd配置文件详解
Docker服务systemd配置文件详解
525 0
|
开发工具 git
Git使用不当导致代码丢失的N种场景
背景git作为目前使用最广泛的分布式版本控制软件,集团内基本上所有开发同学都使用它来做代码管理。一个最典型的使用场景,是一个git仓库存在一个master主干分支,多个需求基于master拉自己的开发分支,然后在发布日时,新建一个release分支,然后原先并行的几个开发分支merge到release分支上,最后基于该分支发布上线,上线后release再merge到master主干上,一次发布完成
3400 1
Git使用不当导致代码丢失的N种场景
|
jenkins 持续交付 开发者
自动化部署:使用Jenkins和Docker实现持续集成与交付
【8月更文挑战第31天】本文旨在为读者揭示如何通过Jenkins和Docker实现自动化部署,从而加速软件开发流程。我们将从基础概念讲起,逐步深入到实际操作,确保即使是初学者也能跟上步伐。文章将提供详细的步骤说明和代码示例,帮助读者理解并应用这些工具来优化他们的工作流程。
|
存储 安全 Linux
在Linux中,如何进行系统镜像管理?
在Linux中,如何进行系统镜像管理?
|
Ubuntu 网络安全 数据安全/隐私保护
Ubuntu 普通用户修改sudoers导致无法使用sudo的解决办法
Ubuntu 普通用户修改sudoers导致无法使用sudo的解决办法
492 2
|
算法 Linux 调度
Docker的资源限制实战篇
本文详细介绍了如何利用Docker对容器的资源进行限制,包括内存和CPU的使用。文章首先概述了资源限制的重要性及其在Linux系统中的实现原理,并强调了不当设置可能导致的风险。接着,通过一系列实战案例展示了如何具体设置容器的内存限制,包括硬性限制、动态调整以及软限制等。最后,文章还提供了限制容器CPU访问的具体方法和示例,如指定容器使用的CPU核心数和基于`--cpu-shares`参数对CPU资源进行分配。通过这些实践,读者可以更好地理解和掌握Docker资源管理技巧。
765 14
Docker的资源限制实战篇
|
JSON Kubernetes 数据格式
k8s集群yaml文件方式迁移
k8s集群yaml文件方式迁移
探索Linux命令:`dirname`
`dirname`是Linux中的命令,用于从文件或目录路径中提取目录部分。基本语法是`dirname PATH`。示例包括:基本用法(如`dirname /home/user/documents/file.txt`返回`/home/user/documents`)、处理相对路径和末尾斜杠,以及在脚本中使用(如获取脚本所在目录)。注意事项包括`dirname`仅做字符串操作,不检查路径实际存在性。它是处理路径的便捷工具,适用于命令行和脚本编写。
|
开发工具
如何修改Vscode查看源代码管理版本变动文件的查看方式
这篇文章介绍了如何在VSCode中通过源代码管理插件修改查看源代码版本变动文件的方式,提供了树形视图和列表视图两种查看方法,并说明了如何通过设置选项来切换查看方式,帮助用户根据自己的喜好更高效地查看和管理代码变动。
如何修改Vscode查看源代码管理版本变动文件的查看方式
|
开发工具 git 开发者