一次,为了缩短上市时间,我们设法尝试并实施了各种敏捷实践。不出所料,其中最可行的是SCRUM。
在2020年初,我们开始扩展SCRUM,研究了LeSS框架并建立了脱机交互过程,但这一大流行进行了自己的调整:3月,我们转移到了远程工作格式。我不得不紧急重建一切。
削减后,我们将向您介绍我们必须解决的任务,SCRUM和LeSS工具如何帮助我们以及其结果。
线下销售减少
当然,大流行影响了业务绩效。客户来信用购买汽车的经销店关闭,我们的销量下降。
但是没有时间担心:为了建立业务并帮助合作伙伴,我们在线上与客户进行了互动交流。
一天上网?
刚开始时(这次我们称之为“大流行之前”),整个团队坐在一起,一个挂着任务的实物板挂在墙上,而计划和回顾则是在办公室“关门之后”进行的。我们只是尝试遵循AGILE宣言和SCRUM指南。
但是随着时间的流逝,团队开始成长。来自萨马拉的家伙加入了我们的莫斯科开发团队。这对现有世界进行了一些调整,并推动了解决方法的发明。因此,我们开始更频繁地使用视频会议和Skype for Business,并且每天我们都在实体板上放置网络摄像头。但是,尽管事实上该团队分布在莫斯科和萨马拉之间,但实际上仍然处于离线状态。
我们有机会挂断了可见的交互规则,这些规则对我们的工作有所帮助(例如,计划规则,日常规则,修饰规则,复古规则)。每个人都可以注意他们。
网上情况并非如此,我们必须寻找其他使用最佳做法/工具的方法。
IT根本不是Flex
事实证明,这并不是一个微不足道的过程。该银行长期以来一直在积极地过渡到Flex-office,这使得大多数人可以轻松上网。但是,IT是一个独立的世界:我们很难拿一本薄的13英寸超薄笔记本电脑去咖啡馆里工作,我们需要功能强大的生产型计算机,大型对角线显示器,并且最好至少有两块。
关于远程连接服务器的能力,我们能说些什么-任何银行中的信息安全都非常重要,但这需要额外的批准,设置,使用密码术等。
并且,当然,不能忽略人为因素。是的,IT专业人员喜欢安静地坐着,他们中的大多数人都很高兴能够在舒适的环境中坐在家里工作,但是个人沟通却非常缺乏。以前通过与同事通过Skype交流的形式交换几个单词就可以轻松解决的问题,Slack变得更加难以解决。
例如,如何传播和发言,如何主持与这么多参与者的对话?在离线状态下,这是有机发生的,因为每个人都看到对方,而在网上,我们立即失去了所有非语言性的内容。
为了解决节制问题,我们提出以下建议:每个员工轮流(两天)成为日常工作的负责人。因此,每个人都可以感觉到“从另一端”进行交流的复杂性,并了解如何更好地进行在线讨论,以使所有参与者都感到舒服。
此外,我们还解决了“沉默”的问题:尚不清楚应由谁回答整个团队提出的问题(团队中50%以上的新员工肯定会在这种情况下感到不适)。在这种情况下,主持人通过名字向其中一位参与者讲话,并征求他的意见。因此,“老人”在做决定时并没有掩盖自己,新员工可以以一种舒适的方式说话。
反之亦然:我们提出了一个“停用词”,以停止长时间的讨论,而讨论已经脱离了话题。当有人说“沙拉三明治”时,每个人都应闭嘴,提出需要进一步单独讨论的问题,然后返回会议主题。
顺利过渡到“全面在线”
过渡到“完全在线”的过程非常顺利:首先,我们将所有与会议保持在线面对面的会议-计划,日常,梳理,冲刺审查,回顾。所有通信都是通过Skype for Business进行的(幸运的是,很早以前它已在银行中引入)。
下一个问题是如何处理物理板。我们很快就决定JIRA允许我们轻松制作具有类似可视化效果的在线白板。因为我们长期使用JIRA来维护Product Backlog和Sprint Backlog,所以该解决方案浮出水面。为了方便起见,演示者接手了将贴纸从WIP转移到DONE的过程,后者在Skype for Business中广播了董事会。
回顾性
可能最困难的事情可能被翻译成在线回顾。在大流行前的世界里,举行回顾展是一个完整的仪式-准备练习,画图翻转,购买甜甜圈/比萨饼/糖果-有很大的想象空间。我们试图利用一切来保持团队的健康和友好。因此,事实证明,当切换到在线状态时,没有太多用于这种SCRUM事件的工具。我们尝试了许多工具:IdeaBoardz,Miro,Mural,FunRetro等。
最后,我们选择了TeamRetro。这是一个方便的平台,能够将回溯结果发送到Slack中的邮件或所需的通道,以及其他芯片和“好东西”。该功能确实与许多其他平台相似,但是重点在于可以大大简化工作的细微差别:进行投票,准备卡片,自动分组机制。总的来说,我们喜欢它。
与合作伙伴沟通
顺便说一下,关于Slack:随着向“完整在线”的过渡,这个沟通渠道为我们找到了第二生命。我们将合作伙伴与它联系起来,以讨论和及时解决问题,以及与其他团队合作在LeSS中使用一种产品的我们,并修改了渠道结构,以免将业务问题与开发问题或环境混淆。
我还必须寻找与合作伙伴的交互工具:Trello-分析合作伙伴方面的错误和改进,Slack-进行业务交互并回答24/7,ZOOM,Skype的问题以进行会议。
合作伙伴/承包商方面的所有改进和错误均已添加到Trello,以监视其状态。我们有8列:“新建”,“进行中”,“完成”,“测试”,“等待生产”,“生产”,“已完成(不需要删除)”,“保留”。这些状态使您可以跟踪任务现在所在的位置,并及时通知新事件。我们和合作伙伴都可以访问Trello,如果状态发生更改,则会向邮件发送通知。
随着转向在线,业务分析师收集信息变得更加困难。安排Skype会议并不总是那么容易,而通过邮件进行通信的时间过长。结果,与离线相比,获取数据的过程效率降低,并且开始花费更多时间。
我必须与最终用户以及我们的客户(在这种情况下,是汽车经销商)一起介绍定期的Zoom和Skype会议。他们在计算机屏幕上摸索着,清楚地说明了问题所在。根据收到的解释,业务分析师得出结论并建立业务流程。
在线开发和分组
上线时,有必要在产品待办事项列表和Sprint待办事项列表中清楚地区分故事。因此,我们决定将具有历史的作品分为“发现”,“交付”,“生产中”两个阶段。
这是在sprint中执行的发现阶段的示例。根据此阶段的结果,决定是否要进行“交付”还是将想法变为现实。
可伸缩SCRUM(LeSS)要求多个团队在一个产品上协调工作,即汽车贷款服务。在一个团队的努力下,检验假设,开发和优化众多功能根本是不可能的。在大流行期间,实际上有四个Scrum团队在线形成,但这也是另一个故事。
所有团队都在研究汽车贷款产品。在线申请是其功能之一。这些团队致力于开发API,以便与软件/ CRM合作伙伴集成,以接收应用程序和处理信贷交易,为客户开发和实施新服务和新服务(例如,“ CASCO在线延长”,“在线借贷利率降低”),与外部系统集成以优化客户端(例如,通过ESIA服务)填充数据的过程。所有任务旨在增加应用程序渠道并将应用程序转换为贷款。这些团队拥有共同的商业KPI,因此每个人都对做能带来结果的事情感兴趣。
团队不仅致力于新功能和流程改进,而且还在不断对已实施的改进进行更改,从而修复了“销售”和“测试”中的错误。
3个月以上的在线结果
测验
在测试团队中,由于在线服务开发步伐的加快,优先级转移到了任务上。在这方面,在大流行开始时,发生了一次小小的抢劫,但随后负载趋于平稳。
通常,在大流行期间,任务数量没有明显变化,但是有可能全天分配负载。例如,长时间休息会延长工作时间。
发展
对于我们来说,评估我们的表现非常困难。最初,我们的开发团队只有五个人。更准确地说,甚至是四个半月,因为一个参与者部分地承受了管理问题。
在三个月的时间里,我们又招募了五名员工-因此,在比较“之前”和“之后”结果时,应考虑到团队成员数量的增加以及他们在新条件下训练,适应和沉浸的时间。
但是我们有一个很好的指标,即达到冲刺目标。以前(6月之前的某个时候),我们仅成功地完成了三个计划目标中的一个,到了7月,我们达到了90%。
另一个重要指标是解决与涵盖技术债务有关的问题:重构,修复次优实现等。如果团队超负荷,则没有时间为此分配资源,并且一切都放在了后面。
在过去的一个半月到两个月的时间里,我们设法解决了许多此类问题:我们已经在许多地方放弃了遗产,甚至能够使用新技术(例如React)完全重写某些内容。
在大流行发生前的5个月中,我们制作了146个故事/任务/错误。在孤立的3个月中,我们制作了198个故事/任务/错误。随着转向在线,团队不仅没有失去效率,而且变得更加专注和富有成效。