• A-csm
  • 2018-new-csp-path
  • Csp-4
  • Arne-201911
  • Scrum@scale201908
  • Shine-scrum-02
  • Cal
  • Inner-training
  • Jens-heart-of-scrum
ShineScrum首次开设的【凤凰项目沙盘&DevOps Professional认证培训课程】圆满落幕!

ShineScrum捷行首次主办的2019329凤凰项目沙盘工作坊&30-31日的DevOps Professional认证培训课程获得学员一致好评圆满结束。


先听听学员的反馈吧~

☻ As an agile coach finding problems form globe prospective to build a better world for happily working.

提到转型,创新总是想到艰辛,阻碍,业绩压力......

其实痛点难处正是最好的切入点。如何运用智慧创新和价值观指引,改变习惯和思维定势营造开心融洽的合作氛围,才是建立信任持续改进从而提升效率实现价值的关键。

Btw,见到志同道合的的小伙伴,一直激动居然直接给跪了。

☻ 周日的午后,借着温暖的阳光,我想是时候把周五那段难忘的经历用键盘来回忆下…

怀着猎奇的心我和同组的几个小伙伴参加了 ShineScrum 的凤凰项目沙盘工作坊培训,说是培训,但亲历后感觉更像是一场紧张的 Scrum 实战。

来自不同公司的同学加入无极限汽车零件公司,为挽救下滑的公司业绩而全力奋斗。这里有掌管业务决策的业务负责人、CFO、HR 和 CISO,有领导技术团队的 VP,注重细节的测试、关注流程的变更管理、勤勤恳恳的开发、未雨绸缪的 IT支持和技术运营,还有幕后默默的技术专家。

整个公司运作活动被划分为了 4 轮迭代,每次迭代 15 分钟准备,花 30 分钟完成。

在业务层面,业务负责人、CFO 和 HR 需要从公司营业收入和股价两个方面进行权衡,确定每轮迭代公司需要完成哪些任务,任务的优先级是什么。看似简单,实则非常困难,譬如修复 bug 解决问题的任务卡可能并无法创造收入,但却可以避免客诉等造成的损失,提升公司的商誉进而拉高股价。

在技术层面,各技术同学负责完成业务确定的任务卡片。其中每项任务都需要开发/变更、IT 支持/运营、测试等几位同学协作完成,占用各位同学的工作容量。好比第一项 POS Wireless Scaning,就需要 52 个单位的开发/变更,10 个单位的 IT 支持/运营,以及 1 个单位的业务容量。一方面要保证每项任务能有正确的开发/变更、IT 支持/运营等工作卡片对应,另一方面也要考虑每项任务所占有每个同学的工作容量,避免超过。

在迭代一,由于团队刚刚建立,彼此的陌生及对实战规则的不理解,导致勉强完成既定目标,在此基础上我们总结经验教训,强调工作流程与协作分工职责,并安排计时提醒。

迭代二,团队建立业务及技术两块看板,将工作内容可视化,大大提升了项目整体的可控性,并且方便沟通与记录。迭代三,代价进一步深化之前的优秀实践,超出预期完成计划。迭代四,团队创新引入业务与技术中间过度看板,将任务优先级进行梳理,先完成确定任务卡,再尝试并决策待定工作,最终取得了收入$254808,股价$53 的好成绩…

短短一天的培训却留下了很多值得回味的启发与思考。周五的时候我还在想这是一次太过完美的策划,所有的任务需求被提前安排确定,所有的工时占比被清晰的划分,大家有着共同的目标并且与企业的发展高度的一致……在现实工作中,我们又是不是如此这般的幸运呢?后来我想到了,我觉得有些我们是可以沉淀下来的,是可以在工作中被继承和使用的:比如看板可视化整个项目过程,比如分阶段的集中回顾之前工作的得失,从确定任务的提前开始到模糊任务的尝试与待定,测试可以前置开发甚至是需求,业务也可以深入技术倾听实现难点,团队间我们需要容许试错,检验交付时我们更要严谨与较真…凤凰沙盘,一次公司涅槃重生的有趣体验,如有机会,我期待尝试更多这样

有趣、烧脑、费力的挑战。谢谢 ShineScrum,谢谢 Wand 老师,我们玩得很开心:)


人们会有一个公平的机会,来体验新的工作方式。他们中的某些人,对于新的工作方式,可能有着与其他人截然不同的看法。通过新的方式,他们能够更好的理解这到底是什么。

]

我和这个团队运行一个沙盘模拟。在关键时刻,其中一个参与者说:

这压根就不可行!

我询问团队,是否有更多的人也有同样的感觉。其他有几个人也有同感。

是什么因素,让你们认为这是不可行的?我问。

有几个答案冒了出来:

我们的管理层,绝对不会同意购买一个工具!

不像游戏中做的那样,我们没有一个专职的流程经理

这是一个理想的设定,在游戏中客户清楚知道工作的优先顺序

我把这些意见写了下来,然后问团队,这些事项是否是他们在日常工作中实际经历到的?然后,我问了如下的问题:

假如这些事项都能够得以解决,你们是否相信新的工作方式是可行的?

在沙盘模拟中,这些事项是成功要素。大部分的团队成员还是积极的。

我接着更往前进了一步,问道:

这些事项里面,你们想要先解决哪个?

团队达成了一致意见,先搞定流程经理的角色。

接下来我们开始讨论,我们需要做什么,以便说服管理层来在团队中设立这些角色。板子上列出了很长的一个行动事项列表,同时也有一些来自于不相信这事可行的人们的反应。在沙盘的最后,我们有了一个行动计划,然后我问,谁愿意跟我一块,参加与IT经理的总结会议。

团队中有2个人加入到了总结会议,他们向经理解释了在沙盘模拟中发生的事情、以及他们如何体验新的工作方式。

过了几个星期,当我再跟这个IT经理交谈时,他告诉我,他已经在团队中指定了一个事件经理,他也看到员工正在做一些改进的实验。

 

这个例子展现了,当您在一次沙盘模拟中让人们体验新的工作方式时,改进的一小步是如何被采取的,以及它如何引发了从象限1到象限4的转变 。持续的尝试,如果你采纳其他的一些新的行为方式,它真的有助于创造认同感、赋能团队进行变革,也有助于解决抗拒,从而增加转型成功的机会。

 

今天,DevOps已经成为一套广为熟知的实践方法集和文化价值观,它可以帮助任何规模的组织缩短软件发布周期,提升软件质量、安全以及快速获取产品开发反馈的能力。据《2017全球DevOps现状调查报告》,成功应用DevOps的高效能组织,在生产力和稳定性方面有明显的优势,包括:高出46倍的部署频率、快出440倍的前置时间、快出96倍的故障恢复时间、低出5倍的变更故障率。


DevOps Professional课程的核心内容围绕DevOps实践的“三步工作法”。这三种方式包括:流Flow、反馈Feedback、学持续学习和实验Continuous Learning and Experimentation。第一步是从开发到运维再到客户,实现从左到右快速流动;第二步是从所有利益干系人到价值流,实现从右到左快速反馈;第三步是通过创建高度信任的实验和风险承担文化,促进学习。此外,还涵盖了各个阶段至关重要的安全问题及在变更期间保持合规性。


本次课程,Wand老师以DevOps三步法知识体系为主线,穿插2个游戏沙盘,并包括10+个详实的DevOps企业实战案例分享,案例涵盖国Google/Facebook/Amazon/Netflix/Etsy/eBay、国内B/A/T/Ping'an等顶尖企业;


Wand老师是国内少有的一线职业经历横跨IT产品、研发、测试、运维部门的专家讲师,精通业界主流的多种精益/敏捷/DevOps方法论与实践,曾在大型金融集团多年主持8000+人规模的企业级敏捷与DevOps转型工作,并具有大型IT部门的管理经验;

三天的授课是面向软件研发团队的培训和实践相结合的课程,旨在帮助学员深入、全面的理解敏捷及Scrum,课程互动、游戏练习非常丰富,贴近实战,实践性很强,真正帮助学员解决在Scrum及敏捷实施过程中面临的实际问题

课程结束后学员依旧进行了激烈的探讨,拍照,有感而发,除了学习知识,放松的课堂和笑声也余音绕梁。