2. 敏捷的核心思想

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

知识补给：

MVP：最小可行性产品

3. 敏捷开发的由来

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

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

各种敏捷开发方法的差异在于理念、过程、术语不同，但相较于“非敏捷”，它们都更强调团队间的紧密协作、面对面的沟通、频繁的交付新版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

知识补给：

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

需要注意的是敏捷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所产生的价值总和，说人话就是新版产品，要求满足验收标准。

① 敏捷团队：即负责软件开发的跨职能团队，包含了产品经理、设计师、程序员、架构师、运维等角色，一个产品可以由多个敏捷团队分模块共同创建；为保证沟通质量，一个敏捷团队一般会控制在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要求项目所有角色都参与进来，汇集各个环节的信息细节，集思广益、寻求共识，最终方案不仅团队统一认可，还通过用户真实的反馈进行验证与修正，尽最大的努力降低风险、控制成本。

八、如何推动敏捷

说实话，敏捷的推动应该是由管理层来推进的，也许是研发leader、PMO leader、设计leader等等，他们相对于其他成员更有话语权；而且每家公司有自己的固有流程规矩，不是那么容易改变的。

如果你在初创企业或公司体系不那么完善，那么是可以尝试推动敏捷的，通过推动敏捷提高团队效率而走上管理岗的例子也是真实存在的，我们这里简单说一下推动思路。

1. 获取管理层支持

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

2. 获得团队成员支持

敏捷注重团队间的沟通协作，成员们也是敏捷的直接使用者，所以你需要从共赢角度去推动；比如它可以帮助我们做正确的事、并正确的做事，提升沟通效率，减少不必要的返工、加班。

与此同时，你还需要帮助团队成员们了解敏捷。

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

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

4. 在小型项目试点

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

5. 持续提升

通常在一到两个敏捷周期，团队已经适应敏捷节奏，并积攒了一定的经验与改进方式，可以逐步转入敏捷模式了，并在此过程中不断提高团队敏捷能力。

6. 扩展推广

当团队敏捷成熟度不断提升，可以尝试扩展到不同业务线的团队，逐步实现以整个产品价值流为中心的大型敏捷部队，最后到达不同业务板块多个产品团队配合，业务驱动研发运营一体化的终极敏捷。

参考资料：

https://bk.tw.lvfukeji.com/wiki/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91

https://www.jianshu.com/p/a24c6eb51e86

http://www.woshipm.com/pd/157297.html

https://designsprintkit.withgoogle.com/methodology/overview

作者：梁17，微信公众号：梁17

本文@梁17 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。