中兴敏捷转型的2个核心3个阶段和4个故事
2019-12-24
来源：壹佰案例 张莹
导读：在缺少外部指导，对敏捷认识也极其有限的情况下，团队如何从自己遇到的问题出发，通过反复摸索，找出新路？敏捷团队的成长究竟需要经历什么样的阶段和辅助条件？敏捷真正的核心究竟是什么？当转型之路从团队往更大一级组织扩展时，我们又能从以前的经验教训中获得什么样的帮助？
本案例通过再现一些真实的故事，讲述一支传统团队如何通过不断尝试探索自己的工作流程，实现集体职责共享，提升质量及学习意识，从而成功实现敏捷转型。
案例简述
三年前，中兴网管UEP项目告警团队在懵懂中开始了自己的敏捷转型之旅。在缺少外部指导，对敏捷认识也极其有限的情况下，团队如何从自己遇到的问题出发，通过反复摸索，找出新路？
本案例讲述了转型过程中，团队发生的一些故事，包括：传纸条的故事、回顾会的故事、防火墙的故事、测试休假故事。通过这些，我们可以了解到一支传统团队是如何通过不断尝试，探索自己的工作流程，实现集体职责共享，提升质量及学习意识，从而不断成长的。
今天，再次审视这些故事时，我们也在思考，敏捷团队的成长究竟需要经历什么样的阶段和辅助条件？敏捷真正的核心究竟是什么？当转型之路从团队往更大一级组织扩展时，我们又能从以前的经验教训中获得什么样的帮助？
案例背景
中兴网管UEP项目是从2008年末启动的平台项目，历经2009年试商用，2010至2012年逐渐全面铺开，项目总人数达到百人规模，自研代码超过300万行。
2011年底，整个项目进行了组织结构调整，除少数公共测试外，大部分测试进入研发团队，形成全职能的UST（统一服务团队）。每个UST少则4人，多不超过9人，每2-3个UST归属一个科室，由一位重点关注需求计划和周任务安排的研发科长管理。我们的转型故事就发生在这样一个UST中。
当时这个UST有6人，包括1位开发经理，1位测试，4位开发人员中，1人是参与项目2年半的资深员工，3人则是进入项目不到1年的新员工。
早几年前，该UST的现任开发经理（在UST成立前是科室的研发骨干）更多聚集于技术实践，所以该团队的持续集成系统，单元测试工具及技能储备、WIKI知识库建设等都已经有一定基础，但这些工具并不能解决团队当前遇到的问题。
随着11年大量新员工加入，团队成员的平均代码水平有所下降、而且，项目大规模商用铺开后，外场支持压力和更多专业网的新需求开发任务都在激增，整个团队不知不觉间已跌入焦油坑。不断增加的救火任务不停消耗着团队有限的精力，由于精力分散再加上队员能力和配合上的问题使得新需求开发效率和质量情况极不令人乐观，而这又进一步导致更多救火任务出现。难以突破的怪圈，使得团队士气不断下降，下一步，团队将何去何从，这是个严重问题！
故事再现
●传纸条的故事
团队迈出怪圈的第一步从传纸条开始。
一次周任务研发过程中，两名队员领取了两个看上去独立，实现上却存在严重相关性的任务。但在整个编码及测试过程中竟然一直没人发现问题。这件事刺激了团队，经过讨论，他们采用了一种把任务记在便利贴上，并把贴纸在队员之间来回传递的方式来规范相互间协作。
这是团队可视化协作改进的起点，它极其简单，甚至连白板都没有使用。但正是这微不足道的改进，团队惊奇的发现，小小纸条的价值绝不可小看，它直接影响并导致了后来团队的一系列改变。
通过纸条变革，团队总结出了可视化的五大价值：
队员之间的协作流程
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
