中兴网管UEP项目告警团队敏捷转型之路 张莹 ZTE 敏捷教练

我们的历程 2012 2013 2014 2015 全项目转型 多团队的尝试 单团队的转型变革 团队技术实践探索

说说我们团队成长的故事 传纸条的故事 回顾会的故事 阶段1:基础期 测试休假故事 阶段3:磨砺期 防火墙的故事 阶段1:引导期 先从哪里开讲呢？

UST UST 公共测试团队 项目背景 网管平台 2008启动 至2011年 100多人 300万行自研代码 …… 2-3 …… …… …… 网管平台 2008启动 至2011年 100多人 300万行自研代码 项目经理 研发科长 研发科长 …… 测试科长 2-3 开发经理 测试 开发 UST 开发经理 测试 开发 UST …… 公共测试团队 …… ……

团队情况 研发科长 开发经理 测试 开发 开发 我是救火队员。 哪里有难哪里有我，但这火怎么越救越旺？！ 我负责需求。 会给大家安排周任务 我关注质量。 谁能告诉我，为什么他们所做的和需求系统中描述的总是不同？ 我是 老鸟 我做的活绝对靠谱的，至于那些新人嘛…... 开发 我们是新人 开发 别人的事我不懂，我负责的模块基本还是清楚的

改变的萌芽：可视化团队工作－－传纸条的故事 改变要从何处开始？怎么开始？

太简单了，查询API增加设置特殊属性的函数即可 改变的萌芽：传纸条的故事－－问题起因 本周任务： 需求一：告警查询条件API中需要增加W专业网特殊的属性条件。开发1来做 需求二：T专业网要求用查询接口打开的告警表格界面上增加条件重设功能。开发2来做 研发科长 需求一：查询API该怎么验？开发没给工具，等外部测试验。 需求二：重设条件，操作验证后没有问题。 太简单了，界面加条件重设按钮即可 两个需求实现有冲突，为什么没人发现呢？ 我做需求一 太简单了，查询API增加设置特殊属性的函数即可 我做需求二 测试 开发经理 开发1 开发2

改变的萌芽：传纸条的故事－－应对办法 WIKI知识库存放内容详情 这有用吗？ 编码完 ？ 检查完 测试 研发科长 概设完 开发 开发经理

改变的萌芽：可视化的价值 队员之间的协作流程清晰化 物理卡片增强了办事成就感 团队感加强以及周边影响力 得领导认可，赢获更多支持 暴露新问题，引出下步改进 研发科长 开发经理 开发 测试

改变的基石：持续团队共建－－坚持回顾的故事 团队应定期反思如何能提高成效，并依此调整自身的举止表现 －－－敏捷原则第十二条

都是外面没做好！版本计划不合理，需求老变，分支策略不当，缺少好用工具…… 改变的基石：坚持回顾的故事－－坚持与变化 传达会 牢骚会 茶话会 一周一试 …... 开发 这么忙的时候，又多了一个会，值得么？ 开发 他在说些啥？不明觉厉！ 我们一起来回顾下近期的工作吧 测试 可以讲我的委屈了么？ 开发 都忙死了，还要再增加新的改进任务么？ 都是外面没做好！版本计划不合理，需求老变，分支策略不当，缺少好用工具…… 开发经理 开发

改变的基石：坚持回顾的故事－－心情场域 …... 一周一试 能量调节 回顾会一定要安排改进行动么？ 开发经理 测试 开发 开发 开发

改变的基石：坚持回顾的价值 是改进措施的孕育地 可形成改进的封闭环 能创造安全试错机会 是团队共建的好场所 长期坚持会更有效果 研发科长 开发经理 开发 测试

改变的方式：先跟后带、小步促变－－防火墙的故事 团队看到的问题： 1.技术壁垒严重，团队人力调配受限制 解决办法：要求开展培训！ 2.队员不写必要的文档，工作交接麻烦 解决办法：规定必须写文档！ 为什么这些解决办法最后总流于形式？

我觉得可能要3故事点，但这是G妹子的模块，我说了不算 改变的方式：防火墙的故事－－计划估算遇到的事 本迭代需要做这个MML需求 这不是G妹子的工作么？ 我觉得可能要3故事点，但这是G妹子的模块，我说了不算 研发科长 开发 开发经理 大家一起来估算下这个任务的工作量吧？ 开发 又是“慢慢来” 的活，下迭代我的事好多！ G妹子做事我是放心的，看她怎么估 这不是我的事。看G妹子说多少就是多少 G妹子 测试 开发

想学啊，但现维护模块支持工作量好大，根本无力学其他的 改变的方式：防火墙的故事－－聆听队员心声 想学啊，但现维护模块支持工作量好大，根本无力学其他的 你想学习其他模块么？ 开发经理 G妹子

改变的方式：防火墙的故事－－回顾会抛出问题 是啊，干扰太严重，简直没法做需求 外部支持随时都可能发生，根本没法控制 我注意到大家专注工作时经常因外部支持被打断，是不是啊？ 开发 开发 要是有人能把支持工作担起来就好了 我们想改变现状！ 开发经理 G妹子 想帮大家，但很多功能实现我也搞不清楚 要不安排一人专门对外支持，让其他人能安心做需求？ 测试 开发

改变的方式：防火墙的故事－－群众决议 开发 开发经理 开发 G妹子 测试 开发 各开发按月轮流担当对外防火墙，负责全团队对外支持工作 开发经理默认是第二支持，负责和防火墙一起解决疑难问题 防火墙尽量直接搞定外部支持，若搞不定先查WIKI知识库中有无相关记录，还找不到，则找该功能以前的维护队员，该队员必须无条件支持防火墙工作 决议签名：林XX，张XX，龚XX，熊XX，郝XX，李XX 开发 开发经理 开发 G妹子 测试 开发

改变的方式：防火墙的故事－－新机制引发更多改变 在知识库中多写点有用内容，这样防火墙才会少打扰我 这个模块代码确实写得好，排查问题方便，那个模块就太差了，支持真麻烦 原来外面这样用系统的 防火墙 我把支持内容写个FAQ，下次就方便了 好忙！ 开发 下月轮到我当防火墙，别人讨论问题时我尽量多听听吧 头几个月的防火墙轮替真难熬啊！ 开发们好像更理解我的工作了 代码得尽量写好点，不然就我模块问题多，太丢人 开发经理 开发 测试 开发

改变的方式：防火墙的故事－－一段时间后 开发 研发科长 开发 开发经理 G妹子 测试 开发 3点 5点 2点 2点 本迭代又有个MML需求要做 5点 开发 研发科长 大家一起来估算下这个任务的工作量吧？ 开发 进步很大啊！ 开发经理 2点 G妹子 3点。我也能估个大概了！ 2点 测试 开发

改变的方式：先跟后带、小步促变的步骤和价值 步骤： 解决集体问题，先跟个人痛点 缓解个人痛点，带动行为改变 连续小步改变，导向集体目标 价值： 解决团队改进的内部动力问题 研发科长 开发经理 开发 测试

改变的深化：危机时刻－－测试休假的故事 当保护自己的安全网消失后会发生什么？ 随着Scrum引入，固定回顾开始 开始尝试让队友头脑风暴收集信息 收集的信息解决办法都是让别人去改 自己设法改，但一下要改的很多，最后还是没效果，即使让大家自己来领任务也是这样 一次聚焦一个改进 短回顾间隔的好处 回顾不一定就要安排改进任务，是一种团队能量场调节器 心情故事案例

改变的深化：测试休假的故事－－危机来了 开发经理 测试 研发科长 开发 这下麻烦大了，团队质量会不会失控？ 我怀宝宝了，它太不安份，只好休长假！ 这下麻烦大了，团队质量会不会失控？ 开发经理 项目没多余人力给团队安排新测试。我会请其他UST测试帮忙盯着点，但主要只能靠你们自己 没守门员了，现在要是我们一开始不做好点，出泄露故障全是我们自己扛 测试 研发科长 开发

改变的深化：测试休假的故事－－意想不到的结果（几月后） ？ ？ 研发科长 开发经理

改变的深化：测试休假的故事－－危机引发的改变（前事） 个人思考会有盲区，交叉集成自测也是必要的 故障复盘和代码走查也需要加强 测试不在，需求完成后我必须得仔细验下 开发 开发 开发 需更多集体学习，提升能力！ 危机时候，大家好像更愿意接受变化！ 突然觉得，我们以前对测试工作的定位是否有误？ 开发 开发经理

改变的深化：危机的价值 危机给团队提供了引入变化的契机 危机能极大增强团队成员责任意识 把握或者制造可控危机为团队所用 危机结束后要及时和团队庆祝胜利 研发科长 开发经理 开发 测试

还有…... 开发 开发 开发经理 研发科长 测试 开发 故事终于讲完，可以喘口气了！ 没有！好多事还没讲！！另外，我们做的这些就是敏捷么？ 不管是不是敏捷，现在团队氛围挺好，大家配合度，学习意愿都比原来强。每周回顾会也时不时引出新花样，有意思 还有…... 故事终于讲完，可以喘口气了！ 开发 开发 开发经理 感觉这团队做事挺规范，知识库积累也丰富，就是压力有点大 我要成为真正的质量专家，不再满足于纯当个守门员 为什么我让其他UST照你们的方法做事，却没能做起来？ 我们是新新人 开发 研发科长 测试

这算是成功么？ 在实战而不是特殊照顾下打造了一只有战斗力的团队，有强烈示范作用。 经历过转型的队员得到成长，逐渐走出团队在更大范围内发挥作用。 从这里开始，两三年内，更多团队直至整个项目都逐渐被卷入转型大潮中 随着Scrum引入，固定回顾开始 开始尝试让队友头脑风暴收集信息 收集的信息解决办法都是让别人去改 自己设法改，但一下要改的很多，最后还是没效果，即使让大家自己来领任务也是这样 一次聚焦一个改进 短回顾间隔的好处 回顾不一定就要安排改进任务，是一种团队能量场调节器 心情故事案例

再回首－－团队成长三阶段 运用危机 制造危机 阶段3:磨砺期 先跟后带 小步促变 阶段2:引导期 可视化 回顾环 阶段1:基础期

敏 捷 的 核 心 启示录一：敏捷的核心 敏捷性的基本含义 敏捷性的现实承载 达成敏捷性 的辅助工具 各种敏捷参考实践，框架，方法 从当下开始，持续保持对自身状态的审视，朝着目标方向，快速试错并不断调整 敏捷性的基本含义 用微观和宏观手段引导组织不断往更适应变化方向进化 敏捷性的现实承载 各种敏捷参考实践，框架，方法 达成敏捷性 的辅助工具

多试多思 立敏捷之心，不惧多走弯路 重敏捷之形，警惕知识诅咒 人艰不拆 启示录二：经验及警示 几年前，当团队蹒跚踏上改变之路时，严重缺乏敏捷工具及实践方法支持，大家只能从解决问题开始，不断摸索尝试。这样确实走过不少弯路，但整个探索过程既不受既有条框的限制，也始终在推动大家思考总结，这使得整个团队始终行走在敏捷改进的道路上。 今天，各种敏捷工具和方法已极大丰富，各地转型实践也提供了大量现成经验。但是，我们在组织中推广敏捷时，是否会因对敏捷形式的强调，而导致新的僵化产生？是否会因为现成经验指导，让受众缺少不断试错调整而引发的思考过程？对此需要保持足够警惕！ 所以，在此重新整理当年团队转型的历史，既提醒自己，也是和大家交流对敏捷初心的认识。