Tags敏捷开发 Scrum 数据团队 项目管理 Sprint JIRA 敏捷转型 传统车企 数字化转型 数据治理
第二季第一篇。2022年我进V企做数据中台，落地就赶上敏捷转型。两年Sprint跑下来，我把传统车企怎么把Scrum跑起来的真实过程讲一遍，包括跑崩的时候。
目录
1 开头 2 Scrum的骨架，先跑起来再说 3 真正管用的三招 4 数据说话，也包括跑崩的时候 5 数据团队在敏捷里怎么活 6 写在最后
1 开头
2022年年中我进V企，做营销数据中台。入职第一周就发现不对劲，早上九点半，全办公室的人都站起来开站会，一开就是一圈人，一个接一个说昨天干了啥今天要干啥。
后来才知道，我赶上了V企敏捷转型最猛的那一波。业务线九条，会员、商城、社区、销售、售后、充电、客服、直售，加上基础平台，全部切成敏捷团队跑Sprint。
为什么要转。转之前的老毛病，做过传统车企IT的都熟。业务提个需求，三个月后排期，半年后上线，上线一看业务早变了。需求变更随便提，今天加一个明天改一个，没人说不行。项目进度是个黑盒，业务问IT做到哪了，IT说在开发，问开发到哪了，说快了。文档基本没有，人一走项目就瘫痪。
V企当时的问题一模一样，还多一条，大量开发是供应商做的，供应商能力怎么样，没人说得清。
于是高层拍板，全面转Scrum。我是数据团队的人，被卷进这场转型，一站就是两年。今天把真实的过程讲一遍，包括跑得好的部分，和跑崩的部分。
2 Scrum的骨架，先跑起来再说
V企的Scrum骨架是这样的。
两周一个Sprint，这是所有节奏的母版。五个Sprint加一个缓冲迭代，组成一个PI，相当于季度规划。每天早上九点半站会，十五分钟，雷打不动。
一个Sprint里的五个会，各有各的用处。
Grooming，需求梳理会。PO把下个Sprint候选的需求拿出来讲，团队评估工作量，拆Story。这个会的产出是让需求在进Sprint之前就基本想清楚，而不是进了Sprint再吵。
Sprint Planning，迭代计划会。团队按自己的产能认领Story，做出承诺。注意是团队自己认，不是Leader派活，这一点很重要，派活和认活，出来的责任感完全两样。
每日站会。三个人人回答三个问题，昨天做了什么，今天做什么，有什么阻碍。站会不是汇报会，是同步信息、暴露障碍的地方，后面讲坑的时候细说。
Sprint Review，迭代评审。做出来的东西演示给业务看，业务当场提意见。这个会最大的价值是把「验收」从三个月后提前到了两周后。
Sprint Retro，回顾会。团队自己复盘，哪些做得好，哪些要改，改的东西落成Action进下个Sprint。
团队规模七到九人一条线，九条业务线，配APP、小程序、中台三条职能线，每个交叉点上配齐PO、Scrum Master、架构师三个角色。跨团队靠Scrum of Scrums横向对齐，季度靠PI Planning把所有线拉到一张图上。
这套骨架跑起来之后，最先变的是透明度。JIRA上每个Story什么状态，谁在做，卡在哪，业务自己打开就能看。Confluence上需求矩阵、架构文档、流程说明，短时间堆起来一大堆。业务问进度，不用再打电话问IT，自己看板。
3 真正管用的三招
骨架是标准的，但让V企真正尝到甜头的，是三个土办法。
第一招，三道门。
需求进门出门都要过检，DoC、DoR、DoD，三个缩写，三道门。
DoC管进门，业务提的BRD，业务目标、用户画像、用户旅程、影响评估，缺一样不让进评审会。以前业务一句话就提需求，「帮我加个报表」，现在不行，你得说清楚这报表给谁看、看了做什么决策。
DoR管开工，PRD要过需求矩阵、业务流程、交互稿、发布计划这一串检查，才允许进Sprint。需求没想清楚就开发，是返工的最大来源，这道门把返工拦在门外。
DoD管出门，Story要过测试用例评审、单测通过率、功能测试通过率。整个Sprint还有团队级DoD，最高级缺陷必须是零，高中低级缺陷合计不能超过六个，代码扫描要达标。达不到，这个Sprint就不算完成，别想蒙混过关。
这三道门看着繁琐，实际是把「差不多得了」这个词从研发流程里抠掉了。
第二招，固定发布窗口。
以前需求变更是随意的，业务想什么时候改就什么时候改。转型后，发布窗口是固定的，要插队，走变更评审，跟PO和团队协商，用优先级置换，把哪个需求往后挪。
这一招治的是需求方的任性。不是不让变，是变要有代价、有协商。业务慢慢学会了在规划期把话说清楚，而不是开发到一半再改。
第三招，用数据管交付。
每个Sprint结束，JIRA数据拉出来，九条业务线各自的计划点数、完成点数、人均产能、完成率，全部公开。供应商的能力也用这个衡量，单位时间产能、质量数据、过程数据，摆到桌面上。
以前评估供应商靠感觉，现在靠数据。哪个团队产能虚标，哪个团队质量差，两个Sprint就现形。
4 数据说话，也包括跑崩的时候
敏捷最容易吹牛，只讲好的不讲坏的。我把V企真实的数据摆出来。
Sprint2的时候，出现了一个好笑的现象，好几条线的完成率超过100%。会员线161%，商城线163%，社区线248%。完成率超100%说明什么，说明计划定保守了，也说明团队在超负荷接活。数字好看，隐患在里面，人的产能被透支了。
Sprint3调了计划口径，完成率回落到80%到100%之间，这是健康区间，说明计划能力和实际产能对上了。
Sprint4，跑崩了。商城线完成率6%，社区线29%，充电线35%，售后线44%。会员线也只有60%。
为什么崩。复盘出来的原因很具体。UAT环境宕了一天，测试开发全部堵死。预生产环境的搭建不顺，预估投入严重不足。紧急生产问题占用大量工时，比如会员线的GIT仓库拆分、接入监控，这些活没录入Sprint，等于计划外消耗。还有充电线的部分需求Story颗粒度太大，一个Story吃掉整个Sprint的产能，做不完就是做不完。
这次跑崩教会团队两件事。一是环境也是交付的一部分，环境和基建的问题会以最粗暴的方式砸进完成率。二是没有录入的活不等于不存在的活，紧急任务不进JIRA，数据就是假的，基于假数据做的下个Sprint计划必然失真。
从Sprint5开始，紧急任务强制录入，环境类工作也排进Backlog，数据才重新变得可信。
这个过程我是深度参与者，因为我做的就是数据。用数据管交付，本身就是一个数据项目。
5 数据团队在敏捷里怎么活
聊点和我同行相关的，数据团队在敏捷转型里特别容易掉队，V企也踩过这个坑。
掉队的原因很典型。业务线的Story是功能，看得见摸得着，一个Sprint能演示。数据团队的活是分层建模、口径统一、管道搭建，一个Sprint演示什么，演示ER图吗。
早期数据团队的Sprint过得很难受，Story拆不出业务价值，Review上没东西可讲，慢慢就被边缘化，变成业务线的附属。
后来调整了打法，三条。
第一，把数据资产当产品排Story。比如客户宽表这个事，拆成「支撑会员线的客户标签宽表」「支撑商城线的消费行为宽表」，每个Story挂到具体业务线的需求上，业务在Review上能看到和自己有关的东西。
第二，口径对齐借用Sprint节奏。以前数据口径吵一个季度没结果，后来把口径评审挂进Grooming，PO牵头，业务和数据的口径分歧在需求梳理阶段就解决，不拖到报表上线再吵。
第三，指标交付跟着Review走。每个Sprint的Review上，数据团队演示新增的指标和看板，业务当场拍板对不对。两周一次的频率，把以前半年的口径拉锯战切成了小步快跑。
这么调完之后，数据团队从敏捷的拖油瓶变成了受益者。因为敏捷最需要的燃料就是数据，产能数据、质量数据、过程数据，我们既是玩家又是裁判。
6 写在最后
两年Sprint跑下来，我对敏捷的理解就一句话，敏捷是节奏感，不是仪式感。
见过太多团队把敏捷做成仪式，站会天天开，开成向领导汇报。Reto期期做，Action从来不落地。DoD贴墙上，发布前照样特批放行。这种敏捷不如不做，白花钱买心安。
V企的转型能立住，靠的不是那五个会的形式，是三道门把质量拦住了，固定窗口把任性治住了，数据把透明做实了。形式人人学得会，机制才是真功夫。
给准备转型或者正在转型团队里的同行三个提醒。第一，先把JIRA这类工具的数据录真实，紧急活也要录，数据假了一切白搭。第二，Story颗粒度宁小勿大，拆不动的Story不是需求太大就是没想清楚。第三，数据团队要主动把活翻译成业务听得懂的Story，别等着被边缘化。
工具会换，框架会换，但一个组织按固定节奏交付、用数据说话的能力，是能带走的能力。
作者 凌波，18年汽车行业数字化老兵，CDGP数据治理专家。从DMS运维到数据中台架构，干过甲方也干过乙方。
