欲速则不达!Scrum团队如何做好UX设计?

本文探讨了如何在Scrum框架中有效整合UX设计,避免仅追求速度而忽视产品质量的问题。作者分享了将UX设计融入Scrum流程的实践经验,强调了全职设计师在团队中的关键作用,并提出了一个初步的融合框架。

在他人眼中,我是Scrum专家:合著了一本关于Scrum的书,还拿了奖;有近10年的授课、培训经验。尽管如此,我还是会遇到许多问题,主要来自产品经理、行政主管、技术经理。这些问题都可以归结为:怎样将Scrum和UX设计完美融合?这是许多公司面临的难题。这些公司采用Scrum的本意,是为了“速度”,而不是“质量”。渐渐地,公司员工琢磨的,都是如何更快地打代码,而不是打造更缜密的、以用户为中心的产品。

经过亲身实践,以及向优秀的团队讨教经验,我把我的发现写成书,在课堂中教给学员们。最近,我和我的合作者Josh Seiden,以及敏捷(Agile)Scrum领域的前沿专家合作,正在努力构建一个框架,逐步说明Scrum和UX设计如何融为一体

我们做了一个练习:在Scrum流程图中,标注相关的UX和设计工作。我的总结如下图所示。

附加说明:

这不是最全面的示意图。相关的设计工作有很多,一张图难以做到面面俱到。

  • “设计”一词是一个总称,包含了设计师参与的所有工作。

  • “设计”、“UX”等词包罗万象,因此,我不会对定义作过多解读。

我对UX工作做了分组、编号。每一组的简要说明和分组理由如下:

  1. 产品需求列表包含了更高层面上的产品愿景。一次迭代只能实现其中的一部分。此时,前期假设也会被提出来。为了让产品需求列表更充实,Scrum团队会开展设计迭代、用户研究(不仅仅是定性的,包括各种类型),同时列出假设,认清现实,保证产品设计以用户为中心。

  2. 迭代计划会每天都会举行。许多问题在会议中得到解决,比如:产品外观如何设计?用户旅程如何设计?有没有被忽略的地方?Scrum团队可以一起画草图(这个环节又称为“设计工作室”、“专家研讨会”等),开展头脑风暴会,让UX设计师各抒己见,解决问题。

  3. 具体的设计工作(包括产品设计的各个方面)针对具体的用户需求,有相应的迭代需求列表,主要由设计师完成,也会和Scrum团队的其他成员合作。设计工作的关键是分清主次,分工明确,让团队成员各司其职。

  4. 对Scrum团队来说,全职设计师“缺位”的后果很严重。把UX设计整合到Scrum流程中,离不开全职设计师这一角色。全职设计师是团队的“粘合剂”,与开发人员、产品经理和项目负责人(Scrum Master)通力合作,完成第3点中的设计工作。

  5. 迭代评审会是一个评估团队工作成果、个人学习成果的良机。通过开展设计评审会、研究成果总结、定量分析讨论等活动,Scrum团队对工作情况有了更好的了解,同时确定了下一次迭代中,产品/迭代需求列表的侧重点。

需要重点提醒的是,如果Scrum团队没有专门的设计师,设计工作的展开将会困难重重。设计师会在对的时间,作出相应的工作安排,同时分清主次,推动工作的执行。

如果把设计工作外包给团队以外的设计师(包括公司内部和外部的),那么,Scrum团队难免会重回“瀑布式开发”的老路,团队成员之间的合作、理解和信任也所剩无几。


原作者:Jeff Gothelf

原文链接:https://medium.com/swlh/here-is-how-ux-design-integrates-with-agile-and-scrum-4f3cf8c10e24

翻译:『即能』团队

公众号:『即能学习』

<think> 嗯,用户这次明确询问Kanban与Scrum混合模式的设计方法,看来ta正在为团队寻找更灵活的敏捷实施方案。之前我详细解析过Kanban的系统知识,但用户现在更关注两种方法的融合——这很常见,因为纯粹的方法往往需要本土化调整。 从对话历史看,用户似乎有技术背景(能理解WIP限制等术语),但没透露具体角色。可能是Scrum Master或项目经理?毕竟ta在调研混合模式这种偏落地方案的内容。引用中提到的PingCode案例[^1]和Scrumban概念[^2]很有参考价值,需要融入回答。 混合模式设计的关键在于平衡。Scrum提供框架纪律,Kanban增加流动柔性,直接列举"如何结合"可能太生硬。应该分层说明:先从目标切入(为什么混合),再讲具体操作(怎么做),最后给场景案例——这样用户能根据团队现状裁剪方案。特别要注意强调XP实践的融合可能性[^3],这点容易被忽略。 用户没提团队痛点,但混合模式通常为了解决两类问题:要么Scrum迭代太僵化(比如紧急需求频发),要么Kanban缺乏节奏导致目标模糊。回答里需要包含这两类场景的解法,比如用Kanban泳道隔离突发工单,或保留Scrum计划会确保目标聚焦。 数学表达要谨慎使用,WIP限制公式$WIP_{limit}=n+1$这类基础计算可以保留,但避免复杂推导。重点突出可视化工具配置(如看板列分割)、会议精简技巧这些实操细节。最后生成的三个问题要覆盖实施难点(角色冲突)、指标监控(混合模式怎么算速率)和工具落地(Jira配置),形成递进关系。 </think>以下是Kanban与Scrum混合模式(Scrumban)的系统化设计方法,结合核心原则与落地实践: --- ### 一、混合模式设计框架 #### 1. **核心目标** - 保留Scrum的**迭代目标驱动**与**角色分工** - 融入Kanban的**流动效率优化**与**可视化控制**[^1][^2] - 公式化价值: $$ \text{Scrumban价值} = \text{Scrum目标聚焦} \times \text{Kanban流动效率} $$ #### 2. **四层融合结构** | 层级 | Scrum元素保留 | Kanban元素引入 | |------------|----------------------------|-----------------------------| | **节奏层** | 固定长度Sprint(2-4周) | 持续交付流(无迭代内冻结) | | **可视化** | Product Backlog | 看板板+WIP限制 | | **会议机制**| Sprint计划会/评审会/回顾会 | 每日站会聚焦阻塞项 | | **过程控制**| 燃尽图监控进度 | 累积流图(CFD)分析瓶颈[^4] | --- ### 二、关键实施步骤 #### 1. **工作流可视化改造** - 在Scrum任务板基础上增加Kanban流程列: ```mermaid graph LR A[产品Backlog] --> B[Sprint待办] --> C{开发泳道} C -->|WIP≤4| D[开发中] --> E[测试中] --> F[完成] C -->|紧急通道| G[生产问题修复] ``` - **WIP限制规则**: - 开发列 $WIP_{limit}=$ 团队成员数(如6人团队设$WIP_{limit}=6$) - 紧急通道独立限流(如$WIP_{limit}=2$) #### 2. **迭代与流动的平衡** | 场景 | 解决方案 | |-----------------------|------------------------------| | **Sprint内需求变更** | 通过Kanban紧急通道插入高优先级任务,占用独立WIP配额 | | **跨迭代持续交付** | 已完成开发的任务可不待Sprint结束直接发布[^2] | | **进度监控** | 燃尽图(目标跟踪)+ CFD图(流程效率分析)双维度监控 | #### 3. **角色职责调整** - **PO(产品负责人)**: - 维护Backlog + **监控看板流动效率**(如测试列阻塞超24小时需介入) - **Scrum Master**: - 扩展为**流程工程师**,负责优化WIP限值及看板规则[^1] - **开发团队**: - 自主拉取任务(Kanban原则),但需**承诺Sprint目标**(Scrum原则) --- ### 三、典型场景配置示例 #### 案例:电商团队Scrumban实践 | 组件 | 配置方案 | |--------------------|-------------------------------------------| | **迭代周期** | 2周Sprint,但生产问题修复按小时交付 | | **看板设计** | 开发/测试列$WIP_{limit}=4$,紧急通道$WIP_{limit}=1$ | | **会议机制** | - 保留Sprint计划会与评审会<br>- **每日站会**:70%时间讨论看板阻塞(如测试积压) | | **度量指标** | - Sprint目标完成率(Scrum)<br>- 平均周期时间$T_{cycle}$(Kanban) | > **效果**:迭代目标达成率提升至85%,紧急需求交付时间从3天缩短至8小时[^2] --- ### 四、避坑指南 | 常见陷阱 | 修正方案 | |---------------------------|-------------------------------------------| | **角色冲突** | 明确PO对Backlog与看板流的双重决策权 | | **WIP限值僵化** | 每Sprint回顾会调整限值:<br>$WIP_{new} = WIP_{old} \times \frac{实际吞吐量}{目标吞吐量}$ | | **可视化板过载** | 分层设计:战略层(Epic看板)→ 执行层(Sprint看板) | --- ### 五、工具落地建议 1. **电子看板配置**(以Jira为例): - 创建**Scrum项目**但启用**Kanban视图** - 自动化规则: ```python # 当测试列任务>3时触发警报 if column_count("测试中") > 3: send_alert("测试瓶颈!当前WIP="+str(column_count("测试中"))) ``` 2. **混合指标看板**: - 并排展示**燃尽图**(迭代进度)与**累积流图**(阶段堵塞点)[^4] > 如PingCode实践所示:**Scrumban的本质是“框架兼容”而非“规则叠加”**,需根据团队上下文定制[^1]。 --- ### 总结 成功实施Scrumban的关键: 1. **目标锚定**:Sprint目标为北极星指标,Kanban服务于目标流动效率 2. **渐进融合**:先固化Scrum基础,再逐步引入WIP限制与CFD分析[^3] 3. **数据驱动**:通过$$ \text{吞吐量} \times \text{周期时间} $$量化混合模式收益 > 引用[2]强调:**混合模式追求“足够好的流程”而非“完美方法论”**。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值