Download presentation
Presentation is loading. Please wait.
1
中兴网管UEP项目告警团队敏捷转型之路 张莹 ZTE 敏捷教练
2
我们的历程 2012 2013 2014 2015 全项目转型 多团队的尝试 单团队的转型变革 团队技术实践探索
3
说说我们团队成长的故事 传纸条的故事 回顾会的故事 阶段1:基础期 测试休假故事 阶段3:磨砺期 防火墙的故事 阶段1:引导期
先从哪里开讲呢?
4
UST UST 公共测试团队 项目背景 网管平台 2008启动 至2011年 100多人 300万行自研代码 …… 2-3 …… …… ……
网管平台 2008启动 至2011年 100多人 300万行自研代码 项目经理 研发科长 研发科长 …… 测试科长 2-3 开发经理 测试 开发 UST 开发经理 测试 开发 UST …… 公共测试团队 …… ……
5
团队情况 研发科长 开发经理 测试 开发 开发 我是救火队员。 哪里有难哪里有我,但这火怎么越救越旺?! 我负责需求。 会给大家安排周任务
我关注质量。 谁能告诉我,为什么他们所做的和需求系统中描述的总是不同? 我是 老鸟 我做的活绝对靠谱的,至于那些新人嘛…... 开发 我们是新人 开发 别人的事我不懂,我负责的模块基本还是清楚的
6
改变的萌芽:可视化团队工作--传纸条的故事
改变要从何处开始?怎么开始?
7
太简单了,查询API增加设置特殊属性的函数即可
改变的萌芽:传纸条的故事--问题起因 本周任务: 需求一:告警查询条件API中需要增加W专业网特殊的属性条件。开发1来做 需求二:T专业网要求用查询接口打开的告警表格界面上增加条件重设功能。开发2来做 研发科长 需求一:查询API该怎么验?开发没给工具,等外部测试验。 需求二:重设条件,操作验证后没有问题。 太简单了,界面加条件重设按钮即可 两个需求实现有冲突,为什么没人发现呢? 我做需求一 太简单了,查询API增加设置特殊属性的函数即可 我做需求二 测试 开发经理 开发1 开发2
8
改变的萌芽:传纸条的故事--应对办法 WIKI知识库存放内容详情 这有用吗? 编码完 ? 检查完 测试 研发科长 概设完 开发 开发经理
9
改变的萌芽:可视化的价值 队员之间的协作流程清晰化 物理卡片增强了办事成就感 团队感加强以及周边影响力 得领导认可,赢获更多支持
暴露新问题,引出下步改进 研发科长 开发经理 开发 测试
10
改变的基石:持续团队共建--坚持回顾的故事
团队应定期反思如何能提高成效,并依此调整自身的举止表现 ---敏捷原则第十二条
11
都是外面没做好!版本计划不合理,需求老变,分支策略不当,缺少好用工具……
改变的基石:坚持回顾的故事--坚持与变化 传达会 牢骚会 茶话会 一周一试 …... 开发 这么忙的时候,又多了一个会,值得么? 开发 他在说些啥?不明觉厉! 我们一起来回顾下近期的工作吧 测试 可以讲我的委屈了么? 开发 都忙死了,还要再增加新的改进任务么? 都是外面没做好!版本计划不合理,需求老变,分支策略不当,缺少好用工具…… 开发经理 开发
12
改变的基石:坚持回顾的故事--心情场域 …... 一周一试 能量调节 回顾会一定要安排改进行动么? 开发经理 测试 开发 开发 开发
13
改变的基石:坚持回顾的价值 是改进措施的孕育地 可形成改进的封闭环 能创造安全试错机会 是团队共建的好场所 长期坚持会更有效果 研发科长
开发经理 开发 测试
14
改变的方式:先跟后带、小步促变--防火墙的故事
团队看到的问题: 1.技术壁垒严重,团队人力调配受限制 解决办法:要求开展培训! 2.队员不写必要的文档,工作交接麻烦 解决办法:规定必须写文档! 为什么这些解决办法最后总流于形式?
15
我觉得可能要3故事点,但这是G妹子的模块,我说了不算
改变的方式:防火墙的故事--计划估算遇到的事 本迭代需要做这个MML需求 这不是G妹子的工作么? 我觉得可能要3故事点,但这是G妹子的模块,我说了不算 研发科长 开发 开发经理 大家一起来估算下这个任务的工作量吧? 开发 又是“慢慢来” 的活,下迭代我的事好多! G妹子做事我是放心的,看她怎么估 这不是我的事。看G妹子说多少就是多少 G妹子 测试 开发
16
想学啊,但现维护模块支持工作量好大,根本无力学其他的
改变的方式:防火墙的故事--聆听队员心声 想学啊,但现维护模块支持工作量好大,根本无力学其他的 你想学习其他模块么? 开发经理 G妹子
17
改变的方式:防火墙的故事--回顾会抛出问题
是啊,干扰太严重,简直没法做需求 外部支持随时都可能发生,根本没法控制 我注意到大家专注工作时经常因外部支持被打断,是不是啊? 开发 开发 要是有人能把支持工作担起来就好了 我们想改变现状! 开发经理 G妹子 想帮大家,但很多功能实现我也搞不清楚 要不安排一人专门对外支持,让其他人能安心做需求? 测试 开发
18
改变的方式:防火墙的故事--群众决议 开发 开发经理 开发 G妹子 测试 开发 各开发按月轮流担当对外防火墙,负责全团队对外支持工作
开发经理默认是第二支持,负责和防火墙一起解决疑难问题 防火墙尽量直接搞定外部支持,若搞不定先查WIKI知识库中有无相关记录,还找不到,则找该功能以前的维护队员,该队员必须无条件支持防火墙工作 决议签名:林XX,张XX,龚XX,熊XX,郝XX,李XX 开发 开发经理 开发 G妹子 测试 开发
19
改变的方式:防火墙的故事--新机制引发更多改变
在知识库中多写点有用内容,这样防火墙才会少打扰我 这个模块代码确实写得好,排查问题方便,那个模块就太差了,支持真麻烦 原来外面这样用系统的 防火墙 我把支持内容写个FAQ,下次就方便了 好忙! 开发 下月轮到我当防火墙,别人讨论问题时我尽量多听听吧 头几个月的防火墙轮替真难熬啊! 开发们好像更理解我的工作了 代码得尽量写好点,不然就我模块问题多,太丢人 开发经理 开发 测试 开发
20
改变的方式:防火墙的故事--一段时间后 开发 研发科长 开发 开发经理 G妹子 测试 开发 3点 5点 2点 2点
本迭代又有个MML需求要做 5点 开发 研发科长 大家一起来估算下这个任务的工作量吧? 开发 进步很大啊! 开发经理 2点 G妹子 3点。我也能估个大概了! 2点 测试 开发
21
改变的方式:先跟后带、小步促变的步骤和价值
步骤: 解决集体问题,先跟个人痛点 缓解个人痛点,带动行为改变 连续小步改变,导向集体目标 价值: 解决团队改进的内部动力问题 研发科长 开发经理 开发 测试
22
改变的深化:危机时刻--测试休假的故事 当保护自己的安全网消失后会发生什么? 随着Scrum引入,固定回顾开始
开始尝试让队友头脑风暴收集信息 收集的信息解决办法都是让别人去改 自己设法改,但一下要改的很多,最后还是没效果,即使让大家自己来领任务也是这样 一次聚焦一个改进 短回顾间隔的好处 回顾不一定就要安排改进任务,是一种团队能量场调节器 心情故事案例
23
改变的深化:测试休假的故事--危机来了 开发经理 测试 研发科长 开发 这下麻烦大了,团队质量会不会失控?
我怀宝宝了,它太不安份,只好休长假! 这下麻烦大了,团队质量会不会失控? 开发经理 项目没多余人力给团队安排新测试。我会请其他UST测试帮忙盯着点,但主要只能靠你们自己 没守门员了,现在要是我们一开始不做好点,出泄露故障全是我们自己扛 测试 研发科长 开发
24
改变的深化:测试休假的故事--意想不到的结果(几月后)
? ? 研发科长 开发经理
25
改变的深化:测试休假的故事--危机引发的改变(前事)
个人思考会有盲区,交叉集成自测也是必要的 故障复盘和代码走查也需要加强 测试不在,需求完成后我必须得仔细验下 开发 开发 开发 需更多集体学习,提升能力! 危机时候,大家好像更愿意接受变化! 突然觉得,我们以前对测试工作的定位是否有误? 开发 开发经理
26
改变的深化:危机的价值 危机给团队提供了引入变化的契机 危机能极大增强团队成员责任意识 把握或者制造可控危机为团队所用
危机结束后要及时和团队庆祝胜利 研发科长 开发经理 开发 测试
27
还有…... 开发 开发 开发经理 研发科长 测试 开发 故事终于讲完,可以喘口气了! 没有!好多事还没讲!!另外,我们做的这些就是敏捷么?
不管是不是敏捷,现在团队氛围挺好,大家配合度,学习意愿都比原来强。每周回顾会也时不时引出新花样,有意思 还有…... 故事终于讲完,可以喘口气了! 开发 开发 开发经理 感觉这团队做事挺规范,知识库积累也丰富,就是压力有点大 我要成为真正的质量专家,不再满足于纯当个守门员 为什么我让其他UST照你们的方法做事,却没能做起来? 我们是新新人 开发 研发科长 测试
28
这算是成功么? 在实战而不是特殊照顾下打造了一只有战斗力的团队,有强烈示范作用。
经历过转型的队员得到成长,逐渐走出团队在更大范围内发挥作用。 从这里开始,两三年内,更多团队直至整个项目都逐渐被卷入转型大潮中 随着Scrum引入,固定回顾开始 开始尝试让队友头脑风暴收集信息 收集的信息解决办法都是让别人去改 自己设法改,但一下要改的很多,最后还是没效果,即使让大家自己来领任务也是这样 一次聚焦一个改进 短回顾间隔的好处 回顾不一定就要安排改进任务,是一种团队能量场调节器 心情故事案例
29
再回首--团队成长三阶段 运用危机 制造危机 阶段3:磨砺期 先跟后带 小步促变 阶段2:引导期 可视化 回顾环 阶段1:基础期
30
敏 捷 的 核 心 启示录一:敏捷的核心 敏捷性的基本含义 敏捷性的现实承载 达成敏捷性 的辅助工具 各种敏捷参考实践,框架,方法
从当下开始,持续保持对自身状态的审视,朝着目标方向,快速试错并不断调整 敏捷性的基本含义 用微观和宏观手段引导组织不断往更适应变化方向进化 敏捷性的现实承载 各种敏捷参考实践,框架,方法 达成敏捷性 的辅助工具
31
多试多思 立敏捷之心,不惧多走弯路 重敏捷之形,警惕知识诅咒 人艰不拆 启示录二:经验及警示
几年前,当团队蹒跚踏上改变之路时,严重缺乏敏捷工具及实践方法支持,大家只能从解决问题开始,不断摸索尝试。这样确实走过不少弯路,但整个探索过程既不受既有条框的限制,也始终在推动大家思考总结,这使得整个团队始终行走在敏捷改进的道路上。 今天,各种敏捷工具和方法已极大丰富,各地转型实践也提供了大量现成经验。但是,我们在组织中推广敏捷时,是否会因对敏捷形式的强调,而导致新的僵化产生?是否会因为现成经验指导,让受众缺少不断试错调整而引发的思考过程?对此需要保持足够警惕! 所以,在此重新整理当年团队转型的历史,既提醒自己,也是和大家交流对敏捷初心的认识。
Similar presentations