进阶必看！大厂设计超爱用的敏捷开发指南

谈互联必谈敏捷，可你真的了解敏捷吗？你们公司的是么开发模式？一个健康的敏捷开发流程又什么样的？设师如何介入敏捷？如果到厂班，那么必须了解这些；如果职场晋升，那么利用敏捷帮团队提效就很好的机会。本次我将团队内部的敏捷分享，一深挖，建议伙小笔记记起。

什么是敏捷开发

1. 敏捷开发的定义

敏捷开发就是将项目拆为多个项目，独立开发、别实现，尽快的产出交付给用户，收集用户反馈后立即调整优化，一直迭代用户，最后集成为一个完整的极用户价值的产品，且在此过程中产品一直于可用状。

2. 敏捷的核心思想

小步快跑、快速迭代、拥抱变化：不追求一开始就尽善尽美，而是把最核心的东西先付 MVP，根据场反馈来对需求进行验证和矫正，灵敏捷的改变调整适应变，在一次次持续迭代中达到最终目标。

附识补给：MVP为最小行产品

3. 敏捷开发的由来

“敏捷”一词来源 2001 年年初美国犹他州雪鸟滑雪圣地的一次的聚，由 17 名软件开人一同的“敏捷软件开宣言”。它原是一种价值观，用指导我们高效地完成产品开，随着它改变整个行业模式，大家便用它来统一命名其指导下的新型开模式。

传统的开发模式，像瀑布模型、喷模型、螺旋模型等等，虽然有不断的进化创新，但始终没有一款能快速、灵活地适应市变化。进而发展了多轻量化的软件开发方法，比如 Scrum、水晶清透法、极限编程法等等，它都起源于敏捷开发宣言之前，但都统称为敏捷软件开发法，因为都是迭代和增量式的开发。

各敏捷开发法异在于理念、过程、术语不，相较于“敏捷”，它们都更强调团队紧密协作、沟、频繁交付新版本、紧凑而自我组织型团队、能够很好地适应需求变化代码编写和团队组织法，也更注软件开发过程作用。

知识补

• 迭代：不断用变量的旧值递推新值，说人就是改进优化。比微信一开始只能纯粹的编辑消息，甚至无法复粘贴，在来的迭代中陆续支持复粘贴、转、撤回等功能。
• 增量式开发：多个项目逐步增加、集成，也就是丰维度。比如一开始的通方式只有发送文字、图片，在后面的迭代中新增了语音消息、语音通话、视频通话、语音输入等多种形式。

4. 敏捷宣言

需要注意的是敏捷 4 大值观中，我们更重视左侧的值，这并代表可忽略右侧的值。

体互动高于流程作：

产品持续出确的决策很困难的，我们需跨部门面对面的沟通交流，获取多的价信息。同时，让团队所员熟悉掌握项目本身、展况，帮员清晰了解全局，不一层一层隔断信息却求员们具全局观，良好透明的沟通能保证项目的高效运转。

当务线众多、项目复杂、周期跨较大，这一点尤为重要。为了帮助成员更快速直观地掌握全，一些企甚至会在办公区置一显示屏，上面投放项目进、代办清单、参与成员及情况、里程碑任务、燃尽图等等，将项目信息可视，助成员们的决策分析与执行控制。

工作的软件于详尽的档：

软件相对于档更灵轻量，毕竟档无论是撰写还是维护，都需要大量的时间精，于是各种效有序的项目管工具在协作中更受。但软件于档并代表着要抛弃档或草草记录，而是在快速迭代的周期里软件协作为，档尽可的精简，可在复盘顾时进行维护修补。

相比软件，文档流传、追溯更强，规范的文档能帮助我们低成的跨部门沟通；面对团成的更新换代，文档也能更的帮助新人清晰地产品历程及貌。

客户合高合同谈判：

软件开初期，需求无法完收集（我不道想什么样的，你先做几版看看），且客户需求一直在生变化，所以要和客户持紧密频繁的沟通，果条件允许最与客户面对面沟通，甚至是在客户现场办。样以一时间获取反馈和详尽的信息细节，以减少理偏差和决策误判，证开效率和质量。

响应变化高遵循计划：

敏捷开身就是为快速地响应市场变化，随时关注变化，以际付质量、的反馈去做衡量、决策，而不是遵循计划。我们需要做的就是研要有够的深度，方案要考虑期的拓展，尽量避免变化成为瓶颈甚至危机。果你想晋升，更要关注学习整个程中领导何协资源、决困难、指导部署。

除了 4 大价值观，敏捷开发还有 12 条则，兴趣的朋友可以进一步了解。

为什么要用敏捷开发

1. 传统模式危机

对外：不业务发展，错失市场机遇

20 世 50 ，算机刚投入实际使用时，软件发多了特的应用指的算机编制设，供小范围使用，简单、规模小且文档资料，不用谈系统化发。随技发展（70 -90 ），算机应用范围的扩展，出了数据、复杂程度高、软件稳可靠的需求，催了一些系统化的发方法，其中以瀑布模型表（后面会）。

系统解决了过的分问题，但面对互联时代（90 年代-2007 年）更大、更复杂、陌生领域的项目，会产生更大且难预测的问题。随着移互联时代兴起（2007 年-现在），这些问题愈发凸显，面对日益激烈的场竞争，企的反应成为键商因素。

显然，传统模式适合中小规模、简单的产，无法兼容需求升级；面对断变的场需求，开发周期长，研发时跟上务发展节奏，导致客户/户满意低，甚至有可错失场机遇。

对：团队耗、成本大、紧密低

传统模式往往是线性流程，强调结构、标准，若有发生需求变更或问题现，则涉及多个模的调整，需要投入大量的时间、精与金钱；团队成员只和上游互，缺乏信息共享意识，容易导致透明、信任，最直观的表现就是明明有沟通协配，但很难形成团队共识；在规模较大的企，人员众多、门复杂、分工细，跨门协作经现信息一致、沟通成本、反馈及时、紧密程低等问题。

2. 瀑布模型弊端

传统瀑布模是一种线性顺序生命周期模，将产研发各阶按照固定顺序展开工作：需求定义→产品设计→研发实→测试验证→发布维护，瀑布流水般自下。一阶段功完后，会移至下一阶段，相邻的两阶段互唯一的输入/输出，其他各阶段之间缺乏业务交流，这可能导致细节疏漏、理解偏差，发展项目延或失败。

瀑布模型的优势于的需求分析产品设阶段，投入了的时间精力，较全面深入洞察问题，越早发问题，一程度降低了后维护本。但它也结构化，败也结构化，很多时候甚至可以称之僵化。

每一阶都依赖于上一阶的正确、整，一旦某个阶现问题，需要到上一阶推到重来，如果是需求变或者需求误判，那么有已成的工作都要付诸东流，越到后期险成本越大。各阶的信息断层，又会使得队员们在“可是……”的反复改改改中丧失信心与创。

瀑模型还是一种理想化模型：需求要够稳定甚至不变、设计者要有超强的前瞻、现者要有极强的业务能力及适应。而存在着大量的不控风险：市场/客户需求每天在随着业展、技术展在变化，我们无法完预料到未来生的所有问题，研也无法百分之百精准还原、完美集成。

（没有在针对开发哥，没有！不是！）。

介于瀑布模型及其传统模式研发周期长、反应较慢、容易错失机会、队耗能高、成本大等问题，需要敏捷这灵活、轻、低耗能、反应迅速的新型开发模式。

Scrum 敏捷开发流程

众多敏捷开发方法中，有的专注于实践，如极限编程、敏捷建模；有的专注于管理工作流程，如 Scrum；有的支持需求规范和开发（如 FDD）的活动；而另一些则图涵盖整个开发生命周期，如动系统开发。这简介绍一下较为流行的 Scrum 开发流程。

Scrum 原意指是英橄榄球运动，要犯规时在犯规地阵争球，两队各以个体，队员紧密相拥、协作争球。1995 年美国计算协会 OOPSLA’95 会议上，在 Jeff Sutherlan 和 Ken Schwaber 联合发表论文首提出 Scrum 概念：以跨职能团队形，像橄榄球队般紧密协作，围绕随着统目标前进，以此提高工作与交付效率。

在介绍 Scrum 流程前，咱们先来看看相关概念与相关色。

1. 相关基础概念

冲刺（Sprint）：

在Scrum框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，官方建议每个Sprint的长度是24周（互网产品研发可以使用1周的Sprint），前一个 Sprint 结束后，新的下一个 Sprint 紧着立即开始。Sprint由 Sprint计划会议、每日Scrum站会、开发工作、 Sprint评审会议和 Sprint回顾会议构成。

产品列表（Product Backlog）：

即产品需求列表，更喜欢称之为需求池。其表现形式通常为用户故事（仙指路本文5.2），颗粒度较粗。

冲刺列表（Sprint Backlog）：

即本次Sprint迭代包含的任列表，颗粒度较细。

产品增量（Product Increment）：

本次Sprint+过去Sprint所产生的价值总和，说人话就是新版产品，要求足验收标准。

2. 相关角色

敏捷团：

即负责软件开的跨职能团，包含产品经理、设计师、程序、架构师、运等角，一个产品以由个敏捷团分模块共同创建。为证沟通质量，一个敏捷团一般控在4-9人，人数太少则生产力受，人数太则容易增加沟通成。

敏捷练（Scrum Master）：

管和带领团队的领导者，他并管人（因为团队是自我组织的）而是管Scrum，负责帮助团队扫除实施中的障碍，屏蔽外界对团队的干扰，确保Scrum过程被按照初衷使；指导团队快速推进Scrum、促进团队达成共识。

利益相者：

户、客户、股东及管层等等，他们会受到产交付成果的影响，同时他们影响着产决策。

产负责人（PO）：

负责敏捷团队和利益相者的连接，梳、拆解、估算需求，确保产列表对有人可见、透明、清晰，帮助团队成员清晰解需求和目标。中小企多产经（PM）负责，一些大To B企则是由务分析师（BA）负责，具体情况视产属性及体量规模而定（在本统一使“PO”这一称谓）。

细谈PO、敏捷团队、敏捷练：

利益相者总是希望我们在产研发上，做到又快又好又对（想义），而忽略复杂且混沌的现实情况，论结果如何，整个过程都是会较地消耗团队信心、热情、信任与创的。

果我们耗费大量的时间精力在以正确的方式做正确的（完美主义），么很有能错市场机遇；果我们沉浸在快速搭建漂亮的架构模式（形式主义），么很大几率是在自嗨，浪费时间在用户根不需要的功能上；果我们致力快速产出有用的产品（快餐主义），没有深研究正确的投方式，么在未来付出巨大的修复成。

所以需要通过 PO、敏捷队、敏捷教练三者相互协作，PO 关注于构建哪些正确的事，敏捷队关注于如何正确构建，敏捷教练关注于如何推动 Scrum 快速进行，在一次次迭代循环中收集反馈、加速学习，在实践中逐步找三者衡。

3. Scrum 流程

需求规划

PO 会将利益相者们的需求及自身想法转为具体的户故事，接着进行需求规划：与利益相者了解需求值，放弃伪需求和无值需求，将值需求放入 Product Backlog（需求池）；和敏捷团队沟通需求规模（实现难与时长），需求的值和规模作为判断依据，对需求池容进行优先级序；必要时，还会将需求拆解为多个子需求，单个子需求具备在一次 sprint 迭代中实现的可性。

通项目早期，或者并非卓越超群的团队，对于需求的判断多是准确的，更多的是在需求池相对的较择，快速产投入场，在反馈中得到验证与矫正，并在此过程中升团队，这正是敏捷的值在。

 Sprint划会议（Sprint Planning Meeting）

每次迭一般都从划会议始，确保发质与效率，我们通常会根据团队的发速度，将需求池内制到迭划中，一次迭概解决 4~6 需求（视具体况）。划会议针对本次迭范围，行需求审，并将一需求拆解多任务，明确每任务的目标验收标准，以及任务估算排，产出一份 Sprint Backlog（任务列表）。

这里值得一的是需求规划和需求评审的区别，前者由 PO 导，涉及商、场、营，更像是范围层“我们做么，做么”；后者由 PM 导，涉及务逻辑、产架构、产设计、功实现、户体验设计，更像是结构层“如何构建，如何连接”。

比 PO 提出一个用户故，孩子的个家长以时收到孩子的学习情况，需求规划对该需求价值、规模进行评判：其投资回报率及产品当前阶段，我们现在是否要现个需求。

PM 根据这个需求细化，是通过 Push 通知、短通知、弹窗通知还是息提示？包含学习长、测成绩、能力析模型、老评价等哪些功能?需求评审会对这些实现需求基于用户体验、术层面进行评判：其实现方式、可行性、疑难点、潜在风险，如何去落地实现这些需求或者部需求。

每日站会（Daily Scrum Meeting）

项目进入开发阶段，计、开发、测按照计划展开工作。每早上展开一个 15 钟的站会来跟进项目进度，每个人都说说昨的任及完成度、今的待任，确保迭代计划的正常进行；遇了什问题及背后因，是否会响其关任或其成员，以及是否需要帮助，确保及规避风险。

日 Scrum 站会增进团队交流沟、发现开发过程需要移除障碍、促进快速决策、提高团队认知程度，这是个进检视与适应关键会议。

需求变更

需求变更是在所难免，我们要“响应变化高于遵循计划”。若发生紧急变更，我们从开发成本进考量，是在本完成是将部分任务延后到下迭代，以确保本迭代能如期交付；若发生大变更，我们需要进团队会议讨论解决案。随着时变化，问题发现、需求新解、任务完成，我们会 Sprint Backlog 进不断地调改。

测试验收

已完成开发功能进可用性、易用性、体验度、原度等系列测试验收，发布过测试部分、复未过部分。注意敏捷开发测试并完成本迭代所有开发任务才测试，而是完成个测试个，及时地发现问题解决问题。

Sprint评审会议（Sprint Review Meeting）

在迭代快结束时举 Sprint 评审会议 ，敏捷团队演示这迭代完成工作（Demo 演示），讨论前 Sprint Backlog 情况、做好地、遇到什么问题及如何解决，并解答相关问题。然后 PO、利益相关者、敏捷团队起探讨接下来可能要做事情，评审市场变化或竞品新动将会我们造成什么影响。这并不是个单纯进度汇报会议，目是为了获取反馈并促进及时调。

Sprint回顾会议（Sprint Retrospective Meeting）

迭代结束后需要进回顾会议，复盘所遇问题、成本偏、协作过程，提炼做好和需要改进地，并制定改进计划；这个时候 PO 会根据收到用户反馈、上线数据，大家起探讨优化案，大致规划下个 Sprint，以便成员们提前准备。我们个需要做是将本迭代经验结，积极地成员们分享你所学到知识及法技巧，沉淀为团队知识库、法论，复用到日后迭代去。

注：Sprint 审会议对项目本身行检视调整， Sprint 回顾会议则对团队的作方式行调整优化。

4. Scrum 流程小结

利益相关者提出需求，由 PO 转化具体的用户故事，需求规划后，梳理出 Product Backlog（产品列表）； Sprint 划会议选取并拆解需求、规划优先级，得到相应的 Sprint Backlog（任务列表）；产品入发阶段，每日召 Scrum 站会项目度、及时发问题并解决；迭结束时举行 Sprint 审会议 ，对项目检视调整；迭结束后行 Sprint 回顾会议，改团队作方式，此时还会根据产品增的反馈，致规划下一 Sprint。

瀑布模型与敏捷适用范围

1. 瀑布 scrum

当以一个产品生命视角来，瀑布模型呈线性沿着初始方向推进，Scrum 呈螺旋状在一次次迭代中矫正方向前行。假用瀑布模型开发，要想在 2011 就开始着造一款涵盖社交、娱、支付、出行、理财等完整生圈的产品，可能要花 2-3 年的间进行需求定义、型计，然后花 5-6 年进行研发，再花 2 年多测验证，最后花 1 年发布推广。这听起来是不是不切实际？且不说 2011 年的队是否有如此超前的思想，有哪家企业可以在长达 9 年没有营收的研发中存活下来？有哪款产品能一投入市就拥有十亿的用户量？

如我们用 Scrum 来开发微信呢？先从熟讯工具入手，用户可以添加讯录/QQ 好友，并免费发信息；接着新增“查看附近”功能，开启陌生交友；然后更新“朋友圈”功能，升级为社交平台；再接着过“微信支付、公众号”转型为互联网枢纽；最后过“小程序”打造移动商业圈。在品不断迭代，随着市场需求变化、用户量积累、企业持续盈利，这是不是比瀑布模合理畅多？

如是要做个单纯讯工具，按照瀑布模型：定义信息类型、使用场景，再进原型设计、研发、测试、发布维护，是不是很合乎逻辑？若按照 Scrum 来开发：先做个可以发信息品，接着迭代为可语音话，再升级为可视频话，迭代都要召开 Sprint 计划会议、日站会、Sprint 评审会议、Sprint 回顾会议，这并不复杂、前技术难度不大品，用 Scrum 是不是有些浪费资呢？

可见瀑布模型并非毫无价，敏捷也并非万能神方。瀑布模型合需求明确、稳、简单、易于理解的小型产品/项目，敏捷合需求（一始）不明确、新型、复杂的型产品/项目。我们多的把瀑布揉入到敏捷的单迭中，例如需求理流程用的都瀑布模式：产品理→设→研发→测试→发布→维护。

2. B 端品是否适合使用敏捷开发

综上所述，瀑布适合简单明确品，敏捷适合复杂多变品，那么复杂而较为稳定 B 端品适合使用敏捷吗？C 端品用户广、市场多变未知、竞争激烈，需要尽早入局、速战速决，在场场战役不断提升品价值，C 端品在基里和敏捷高度匹配。

 B 端产品相对用户面较小，若非政策业务模式变动，通常都较稳。B 端一般分服务于客户的普性产品服务于少客户的性化制产品，对于普性产品需伴随不同行业不同规模的企业，况复杂难以预测，则比较合使用敏捷发；对于性化制产品需考虑产品的体规模，若规模小、易预测、实周短，则合使用瀑布法，若规模较、难预测、实周，则合使用敏捷法。

敏捷须知

1. 发模

在品发布模上，很多新型企业、成熟企业会采用发模：即限定时和质量，常 2 发布个新版本，用以规范发布、提升发布速率、规范系统成。

每公司都会自己的黑话，的叫“火车模式”，的叫“班车模式”，的叫“高铁模式”，方便家理解咱们就统称发车模式。企业的具体况以及团队能力，发布周会所不同，不必纠结于 2 周这频率。总之就发车一样，每间隔一段时就发布一次新版本，划、规律。

这样的好处于所人都清楚各版本发布时间节点、掌握项目度，较自由可控协调作任务、降低沟通本；紧凑的发布节奏，无形间形一种略微紧张的氛围，良性促发流程敏捷稳的发展。

设计师是通过设计手解决务需求，更多情况都是跟车角色，很发车。当我作为面试官，会查看求职者设计项目的发点是否基于务需求，作为项目真实性的评判标准。

2. 户故事

户故事是从户角描述户希望得到的功，基于 who、what、why，简单易懂的话帮助有人解具体的需求容，在项目启阶就达成共识，避免解偏差现“这是我想要的”反复改稿情况。户故事的经典书写形式为“As a …I want to…，so that …”，即“作为一个（户角色），我想要（么功），于（达到么目的）”。

比“为一个家长，我想要获取孩子的成绩单，以便孩子的学习情况”、“为一个用户，我想要预约排号，以便自由掌控排时间”

用户故事体形式多，这只列举常见的便签和表格供大家参考。

3. 燃尽图

在敏捷宣言一条释里我有提到，一企业在办区安置一块显示屏，上面投放项目进度、里程碑任务、燃尽图等等，将项目视化，信息透明是高效协的基础。

燃尽图容易被误认为 KPI 指标，这有必要说一下：燃尽图不是 KPI 指标，而是对工作情况进行监控调节的参考指标之一，它队效能、估算管理有关。燃尽图是一种剩余工作量的可视图，Y 轴为剩余的工作量，X 轴为 Sprint 工作日，以一条斜线代表预估的工作情况（工作量均配整个项目期间），另一条曲线/折线代表真实的工作情况。

曲线高于线，那么代表进度落后，需要及时调；若曲线低于线，那么代表进度快于预测；若曲线呈上升趋势，则代表新增任务工作量大于完成工作量。影响实曲线素很复杂，有可能是没有正确估算任务量与团队能力，有可能是需求变动，也有可能是团队没有及时更新等等。

敏捷工具

敏捷开发注重沟通协作，那除了通过跨职能队紧密协作，还有什方法能帮助进一步提升协作效率吗？在敏捷宣言第 2 条“工作的软件高于详尽的文档”可以找指示，可以使用项目管理工实现项目计划可视化，将项目状透公开。大多有效的项目管理工都是基于种方法：板和甘图。

1. 板

板是起源于丰田的一种生产流程管理工，以卡片的形式传递任指令。现在板已成为 scrum 极代表性的工之一，为“To Do”、“Doing”、“Done”，写着任的卡片在以上 3 个阶段间流转。所有人可以通过板清晰掌握成员职责、项目状、项目进度，更关注于任本身。当任发生变化，只需将任卡片进行移动或修改。且板极易使用，如果没有软件工（板），仅需便签纸也可以实现（物理板）。

我们可以将 doing 根据团队色进步细分，比如待办、设计、开发、测试、已完成；可以根据研发阶段进细分，比如 Sprint 0（迭代版本）、To Do（待办）、WIP（在制品）、Review（评审）、Done（已完成）

甚至可以定制设计团队任务看板，比如待办、设计、待过稿、设计评审、开发验收、上线跟踪、已完成

市上优秀看板工具纷繁样多，例如经典 Trello，全球千级用户使用项目管理工具，免费、简单、灵活；功能强大笔记软件 notion，不仅灵活美观，支持组数据多维度展现；有国内较知名 leangoo，基于看板项目协作工具，提供实时协作脑图功能；里 teambition，简洁、漂亮，符合设计师审美，另待办和网盘功能在测试阶段，很是期待。

2. 甘图

甘图是一种随间变化的进程管理表，常用于项目管理、生产管理、资源管理。在敏捷项目管理中，甘图水显示间轴，垂直显示任，相同的颜色显示同类型的任，灰色代表还未开始的任。所有人可以通过该图一目了然地查成员职责、任耗、间期限、项目进度。

前说发模可以让大家了解迭代发布时节，而甘特图更为细化，让所有了解单个迭代里各任务时节，帮助大家及时调节分配、控制成本。

如你所见，于期较长项目会占用较大空，于复杂项目（任务量大）会占用较大竖空。虽然有不少软件会固定表头和首列，便用户在屏显示不全情况阅读应信息，来回滚动、梳理信息，定程度上是存在较大理解成本。

所以看板适合任务状态展示，甘特图适合期较短小型项目查看时任务关系。大家可以根据实情况，将者结合使用。钉钉任务管家时支持甘特图和看板，不过需要付费，不太适合白嫖党。

推荐一轻的线甘特图具 UP Gantt，支持微信登录、多人协作，还可以制休法节假日，自动算作日数、度分比。

设计师如何介入敏捷

1. 介入方式

深理业务

无论是团中任一个角，对业务不就无法做出正确的决策。设计师常常被误认为是负责锦上添花的，在司没有什么语权，不像产品、运营有明显的开源价值，也不像开、运有明显的节流价值。我们需要主动深业务，洞察潜在机点有哪、影响项目的业因素有哪、市场上有哪决方案、背的原因弊是什么等等。

只有从业出发，提出切实有效的解决方案，才能让大家了解计是解决业诉求、为商业赋能的价值存在。

并肩而行

在敏捷，计不再是那个空等需求的美工，而是和开发在需求定义阶段就参进来，从业、产品、体验、术角度一同讨论解决方案，成员可以在初始阶段就达成共识，不会出现已完成计进入开发阶段，开发哥反馈实现问题、业逻辑问题，回产品重新梳理、重新计；成员还能提前了解彼此的初步解决方案，以及反馈矫正，或调整的对应方案。并肩而行，才能真正地做高效协同。

时我们需要注意和团队及时更新设计文档，议学习使用组件库、蓝湖、zeplin 或者 figma 来降低沟成本、提高协作效率。

进度优先

互网变化日新月异，商业机遇转瞬即逝，为了赶在间节点发布，有可能要放宽一些限制，不要在无伤大雅的细节上严苛要求。比如标签式、缓动曲线、行高段间距等等，不必行要求 100%还度，可以在灰度测要求 60%的还度，在发布前要求 80%的还度，上线后 1-2 次迭代要求 95%的还度。

要优先考虑项目进度，保证商业速度时，兼顾开发承受能力。敏捷核心思想本来是不追求开始尽善尽美，小步快跑，在快速迭代到更好。

2. 敏捷设计

咱说了这久敏捷开发模式、发布模式，但似乎对如何开展计工作没有多关系，计好像只需全程参进来就好了。既然咱要敏捷，那就来聊一聊敏捷计模式——Google Design Sprint。

Google Design Sprint（设计冲刺）是由谷歌风投团队提出套品设计法，帮助初创团队在 1-5 天快速研究、决策、设计、验证案。以其高协作、低风险特，风靡各大互联网企业，并在 Slack、Uber、H&M、Nest 等知名项目到了成功验证。

参与 Design Sprint 的我们的 scrum 团队，包含设师、产品理、发、用户研究员，如果可能还可以加入利益相关者，以及负责项目推的其他人员（运营推广营）。Design Sprint 分 6 阶段：理解、义、草图、决、原型、验证，不钻模型些？它们都发散→聚焦→再发散→再聚焦的过程。

理解

第一个阶段“理解”，需要理解这次 sprint 要解决什问题？背后的用户需求是什、业诉求是什、术资源限制是什？这个阶段只讨论问题，不谈解决方案，就好比答题第一步是先审清楚题目。这候可以借助用户访谈、问卷调研、竞品析、焦点组、实地研究、数据摸底等方法对问题进行深度剖析。

定义

二个阶段“定义”，对一阶段的问题散进行聚焦，确定次的问题重点是什么、设计价值机点有哪、设计目标是什么、设计原则是什么？时的主要手段有用户验地图、旅程图、KANO 模型、OKR 等等。

发散

该阶段也方案构思阶段，每人可以胆脑暴并分享自己的法（草图）。这时候一核原则“yes,and…”，即不批判别人的法，如果忍不住，那么提出相应的替方案，不一否决。会时，家应该都很讨厌那种只会否但任何建设性意见的人吧。我们此时需尽可能多的方案，不需急否。该阶段可以使用类比法、竞品分析、故事版方法，帮我们发散创意。

决定

进入第四阶段“决定”，我们根据实现成本、用户价值进投票，确定最终案。该阶段我们主要是成共识，选出最合适案快速进工作，有可能需要放弃些优秀案，秉持进度优先理念，不必过于执着。该阶段主要法有投票法、卡片分类法、决策矩阵等。

型

这个候开始进行型计，你可以在纸上画，也可以在 sketch、figma 等专业软件画。个人建议直在会上用纸画出主要的流程功能，向队进行复查验证，会后再详细地绘制、测（也就是把型、验证个阶段，在会议上和迭代发布前做了 2 次）。

验证

到六阶段，我们先内部技术确认、决策者审查，进行外部用户测试，主要是收集反馈建议，做进一步的优化。在正式前我们以进行分段测试，先对一小部分用户自由开放新版，旧版依旧用；选择一部分关闭旧版，只允许使用新版；最量上。其中每一分段收集用户反馈，进行护纠错。该阶段使用的方法有 A/B 测试、眼动追踪、问卷研、用走查等等。

到里我们的一个 Design Sprint 已经完成，很人以为把项目拆分进行小项目迭代就是敏捷，往往忽略跨职能团的紧密协，只学个空壳却依没有决问题。

Design Sprint 要求项目所有角色都参进来，集各个环节的息细节，集思广益、寻求共识，最终方案不仅队统一认可，还通过用户真实的反馈进行验证修正，尽最大的努力降低风险、控制成本。

如大家想看具体 Design Sprint 如何开展，刚才提到各法工具怎么使用，欢迎赞评论催更。赞过百，必有下（起来挖坑吖）

如何推动敏捷

说实话，敏捷动应该是由管理层来进，也许是研发 leader、PMO leader、设计 leader 等等，他们相于其他成员更有话语权。而家公司有自己固有流程规矩，不是那么容易改变。如你在初创企业或公司体系不那么完善，那么是可以尝试动敏捷，过动敏捷提高团队效率而走上管理岗例子也是真实存在，我们这里简单说下动思路。

1. 获取管理层支持

论你要动什么事情，管理层支持是绝关键，你需要从价值、成本度去动。比如 CPRIME 研究表示敏捷效率是瀑布 3 倍，用户满意度提升 53%，它可以帮助我们减少不确定性、提升生速度及质量、节省资、改善成员自主性。

2. 获团队成员支持

敏捷注团队沟协作，成员们也是敏捷接使用者，所以你需要从共赢度去动。比如它可以帮助我们做正确事、并正确做事，提升沟效率，减少不必要返工、加班。与此时，你需要帮助团队成员们了解敏捷。

3. 申请敏捷教练（Scurm master）加入

我们需要位经验丰富敏捷教练来指导培训，从管理层到开发团队都需要进培训，以确保上下游都有致开发理念与基础认知。接着在敏捷教练指导下，将敏捷代入项目实践落地。

4. 在小型项目试

在成员们经验未成熟情况下，最好选择在小型项目尝试敏捷开发使用，尽可能降低风险。

5. 持续提升

常在到两个敏捷期，团队已经适应敏捷节奏，并积攒了定经验与改进，可以逐步转入敏捷模了，并在此过程不断提高团队敏捷能力。

6. 扩展广

团队敏捷成熟度不断提升，可以尝试扩展到不业务线团队，逐步实现以个品价值流为心大型敏捷部队，最后到不业务板块多个品团队配合，业务驱动研发运体化终极敏捷。

欢迎关注作者微信公众：「梁17」