进阶必看！敏捷开发超强指南

Posted 2021-04-25 梁17

全文12109字，建议阅读时长30分钟。

谈互联网必谈敏捷，可你真的了解敏捷吗？你们公司用的是什么开发模式？一个健康的敏捷开发流程又是什么样的？设计师如何介入敏捷？如果你想到大厂上班，那么你必须要了解这些；如果你想职场晋升，那么利用敏捷帮助团队提效就是很好的机会。本次我将在团队内部的敏捷分享，进一步深挖，建议大伙小笔记记起来。

1.什么是敏捷开发

1.1 敏捷开发的定义

敏捷开发就是将项目拆分为多个子项目，独立开发、分别实现，尽快的产出交付给用户，收集用户反馈后立即调整优化，一直迭代到用户满意，最后集成为一个完整的极具用户价值的产品，且在此过程中产品一直处于可用状态。

1.2 敏捷的核心思想

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

知识补给

MVP：最小可行性产品

1.3敏捷开发的由来

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

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

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

知识补给

① 迭代：不断用变量的旧值递推新值，说人话就是改进优化。比如微信一开始只能纯粹的编辑消息，甚至无法复制粘贴，在后来的迭代中陆续支持复制粘贴、转发、撤回等功能。

② 增量式开发：多个子项目逐步增加、集成，也就是丰富维度。比如微信一开始的通信方式只有发送文字、图片，在后面的迭代中新增了语音消息、语音通话、视频通话、语音输入等多种形式。

1.4 敏捷宣言

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

① 个体和互动高于流程和工作：要想为产品持续做出正确的决策是很困难的，我们需要跨部门面对面的沟通交流，获取更多的有价值信息。同时，要让团队所有成员熟悉掌握项目本身、进展情况，帮助成员清晰了解全局，而不是一层一层地隔断信息却要求成员们具有全局观，良好透明的沟通才能保证项目的高效运转。

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

② 工作的软件高于详尽的文档：软件相对于文档更灵活轻量，毕竟文档无论是撰写还是维护，都需要花费大量的时间精力，于是各种高效有序的项目管理工具在协作中更受欢迎。但软件高于文档并不代表着要抛弃文档或草草记录，而是在快速迭代的周期里以软件协作为主，文档尽可能的精简，可以在复盘回顾时进行维护修补。

相比起软件，文档流传性、追溯性更强，规范的文档能帮助我们低成本的跨部门沟通；面对团队成员的更新换代，文档也能更好的帮助新人清晰地了解产品历程及全貌。

③ 客户合作高于合同谈判：软件开发初期，需求无法完全收集（我不知道想什么样的，你先做几版看看），且客户需求一直在发生变化，所以要和客户保持紧密频繁的沟通，如果条件允许最好与客户面对面沟通，甚至是在客户现场办公。这样可以第一时间获取反馈和详尽的信息细节，以减少理解偏差和决策误判，保证开发效率和质量。

④ 响应变化高于遵循计划：敏捷开发本身就是为了快速地响应市场变化，随时关注变化，以实际交付质量、真实的反馈去做衡量、决策，而不是遵循计划。我们需要做的就是调研要有足够的深度，方案要考虑后期的拓展性，尽量避免变化成为瓶颈甚至危机。如果你想晋升，更要关注学习整个过程中领导如何协调资源、解决困难、指导部署。

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

2.为什么要用敏捷开发

2.1 传统模式危机

①对外：跟不上业务发展，错失市场机遇

20世纪50年代，计算机刚投入实际使用时，软件开发大多是为了特定的应用在指定的计算机编制设计，供小范围使用，简单、规模小且没有文档资料，更不用谈系统化开发。随着技术发展（70年代-90年代），计算机应用范围的扩展，出现了数据量大、复杂程度高、软件稳定可靠的需求，催生了一些系统化的开发方法，其中以瀑布模型为代表（后面会说）。

系统化解决了过去的部分问题，但面对互联网时代（90年代-2007年）更大型、更复杂、陌生领域的项目，会产生更大且难以预测的问题。随着移动互联网时代兴起（2007年-现在），这些问题愈发凸显，面对日益激烈的市场竞争，企业的反应能力成为关键商业因素。

显然，传统模式适合中小规模、简单的产品，无法高度兼容需求升级；面对不断变化的市场需求，开发周期长，研发时常跟不上业务发展节奏，导致客户/用户满意度低，甚至有可能错失市场机遇。

②对内：团队耗能高、成本大、紧密度低

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

2.2 瀑布模型弊端

传统瀑布模型是一种线性顺序生命周期模型，将产品研发各阶段按照固定顺序展开工作：需求定义→产品设计→研发实现→测试验证→发布维护，像瀑布流水般自上而下。上一阶段成功完成后，才会移至下一阶段，相邻的两个阶段互为唯一的输入/输出，其他各阶段之间缺乏业务交流，这有可能导致细节疏漏、理解偏差，进而发展为项目延期或失败。

瀑布模型的优势在于在前期的需求分析和产品设计阶段，投入了大量的时间精力，较为全面深入地洞察问题，越早地发现问题，一定程度上降低了后期维护成本。但它成也结构化，败也结构化，很多时候甚至可以称之为僵化。

每一阶段都依赖于上一阶段的正确、完整，一旦某个阶段出现问题，需要回到上一阶段推到重来，如果是需求变动或者需求误判，那么所有已完成的工作都要付诸东流，越到后期风险成本越大。各阶段的信息断层，又会使得队员们在“可能是……”的反复改改改中丧失信心与创造力。

瀑布模型还是一种理想化模型：需求要足够稳定甚至不变、设计者要有超强的前瞻性、实现者要有极强的业务能力及适应性。而这些都存在着大量的不可控风险：市场/客户需求每天都在随着商业发展、技术发展在变化，我们无法完全预料到未来会发生的所有问题，研发也无法百分之百精准还原、完美集成

（我没有在针对开发小哥们，我没有！我不是！）。

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

3.Scrum敏捷开发流程

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

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

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

3.1 相关基础概念

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

② 产品列表（Product Backlog）：即产品需求列表，我更喜欢称之为需求池。其表现形式通常为用户故事（仙女指路