拓冰网站定制 
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节奏。以前数据口径吵一个季度没结果后来把口径评审挂进GroomingPO牵头业务和数据的口径分歧在需求梳理阶段就解决不拖到报表上线再吵。第三指标交付跟着Review走。每个Sprint的Review上数据团队演示新增的指标和看板业务当场拍板对不对。两周一次的频率把以前半年的口径拉锯战切成了小步快跑。这么调完之后数据团队从敏捷的拖油瓶变成了受益者。因为敏捷最需要的燃料就是数据产能数据、质量数据、过程数据我们既是玩家又是裁判。6 写在最后两年Sprint跑下来我对敏捷的理解就一句话敏捷是节奏感不是仪式感。见过太多团队把敏捷做成仪式站会天天开开成向领导汇报。Reto期期做Action从来不落地。DoD贴墙上发布前照样特批放行。这种敏捷不如不做白花钱买心安。V企的转型能立住靠的不是那五个会的形式是三道门把质量拦住了固定窗口把任性治住了数据把透明做实了。形式人人学得会机制才是真功夫。给准备转型或者正在转型团队里的同行三个提醒。第一先把JIRA这类工具的数据录真实紧急活也要录数据假了一切白搭。第二Story颗粒度宁小勿大拆不动的Story不是需求太大就是没想清楚。第三数据团队要主动把活翻译成业务听得懂的Story别等着被边缘化。工具会换框架会换但一个组织按固定节奏交付、用数据说话的能力是能带走的能力。作者 凌波18年汽车行业数字化老兵CDGP数据治理专家。从DMS运维到数据中台架构干过甲方也干过乙方。 敏捷Scrum实战，一个传统车企的转型真实记录
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节奏。以前数据口径吵一个季度没结果后来把口径评审挂进GroomingPO牵头业务和数据的口径分歧在需求梳理阶段就解决不拖到报表上线再吵。第三指标交付跟着Review走。每个Sprint的Review上数据团队演示新增的指标和看板业务当场拍板对不对。两周一次的频率把以前半年的口径拉锯战切成了小步快跑。这么调完之后数据团队从敏捷的拖油瓶变成了受益者。因为敏捷最需要的燃料就是数据产能数据、质量数据、过程数据我们既是玩家又是裁判。6 写在最后两年Sprint跑下来我对敏捷的理解就一句话敏捷是节奏感不是仪式感。见过太多团队把敏捷做成仪式站会天天开开成向领导汇报。Reto期期做Action从来不落地。DoD贴墙上发布前照样特批放行。这种敏捷不如不做白花钱买心安。V企的转型能立住靠的不是那五个会的形式是三道门把质量拦住了固定窗口把任性治住了数据把透明做实了。形式人人学得会机制才是真功夫。给准备转型或者正在转型团队里的同行三个提醒。第一先把JIRA这类工具的数据录真实紧急活也要录数据假了一切白搭。第二Story颗粒度宁小勿大拆不动的Story不是需求太大就是没想清楚。第三数据团队要主动把活翻译成业务听得懂的Story别等着被边缘化。工具会换框架会换但一个组织按固定节奏交付、用数据说话的能力是能带走的能力。作者 凌波18年汽车行业数字化老兵CDGP数据治理专家。从DMS运维到数据中台架构干过甲方也干过乙方。