说透如何学习敏捷开发流程和运用
共 9328字，需浏览 19分钟
·
2021-09-18 08:42
敏捷开发是目前很流程的开发方式，通过版本迭代能快速的更新升级产品，今天就讲讲敏捷。
前言：
我的敏捷开发经历
什么是敏捷开发流程？
敏捷开发方法有哪些？
从哪些方面做到敏捷开发流程？
项目怎么开始使用敏捷开发？
传统的开发模式
传统模式踩过的坑
敏捷开发的概念
敏捷宣言
什么是 Scrum？
需求澄清会
计划分析会
站立会
评审会
回顾会
快速迭代
让测试人员和开发者参与需求讨论
多沟通，尽量减少文档
做好产品原型
怎么才能评估团队是否已经敏捷了？
敏捷开发可谓是产品快速迭代的规范化流程，所谓敏捷开发？就是快速灵活的意思？并不是这样，其实敏捷开发是以用户的需求进化为中心，采用快速迭代、循序渐进的方法进行软件产品的开发。
在敏捷开发中，一个软件项目在构建时被细分成多个子项目（故事），各个子项目（故事）的成果都经过测试，是独立的，可以独立运行的，而又是可以合在一起变成整体的。
通过这点来看，敏捷开发便比普通开发多了很多优势。
在本场 Chat 中，会讲到如下内容：
什么是敏捷开发流程？
敏捷开发方法有哪些？
从哪些方面做到敏捷开发流程？
项目怎么开始使用敏捷开发？
怎么才能评估团队是否已经敏捷了？
我的敏捷开发经历
首先我先讲一下我接触敏捷开发的经历，2010 年到 2015 年工作期间，所在的几家公司一直都是做移动互联网产品的，当时还没有接触敏捷开发的概念，还是使用传统的开发模式。
传统的开发模式
这里我简单说一下传统的开发模式，以及我使用的开发模式的缺陷。
传统开发模式包括：
传统的瀑布式开发
原型模型
螺旋模型
可能有些人看到上面的三种传统开发模式还是不太清楚，具体指什么？
下面我们一一介绍一下，相信大家就能更具体的明白，并且知道你深处什么开发模式下。
1. 传统的瀑布流开发模式
流程如下：
从需求到设计 -> 从设计到编码 -> 从编码到测试 -> 从测试到交付
大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计得越完美，提交后的成本损失就越少。这样就是典型的瀑布模型。
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。
步骤成果作为衡量进度的方法，例如需求规格、设计文档、测试计划和代码审阅等等。
瀑布流式的主要的问题是，它的严格分级导致的自由度降低，项目早期即作出承诺，导致对后期需求的变化难以调整，代价高昂。
瀑布流式方法在需求不明，且在项目进行过程中可能变化的情况下，基本是不可行的。
有统计它是造成 70% 软件开发失败的原因。
哪些情况导致项目失败？
需求前期不明确后期变化大
开发的功能和客户预期要的功能不一致
项目做好才能有一个可以演示的版本（开发期间无法保证版本的正常使用）
项目进度无法保证
上面这些情况我相信 90% 的小伙伴都亲身经历过，并且有些小伙伴还在这种水深火热中煎熬着。
2. 原型模型
原型模型第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。
所谓原型模型：说的直接一点就是 需要有一个原型效果，这种可以是一些建模图形，或者快速开发出来的简单静态界面效果流程，或者一些原型图的快速创建。
比如我们可以通过一些开源平台提供的支持，做一些需求流程的原型图，通过原型图来展示所需项目的需求，通过原型图呈现出来产品的流程。
比如下面的一个开源平台，可以创建不同平台（手机、Web 等等）的原型图。
https://www.xiaopiu.com/
我可以通过一个效果给想伙伴们展示一下，该平台的好处，这里我只展示手机端的原型图效果，当然需要其他的小伙伴可以自行去看，学习。
3. 螺旋模型
螺旋模型就是，将瀑布模型和快速原型模型结合，并特别强调项目风险。
通常分为四个阶段组成：
制定计划
风险分析
实施工程
客户评估
一般第一个版本原型只是双方交流的参考，随着后面的版本添加和完善，最终达到目标。这种螺旋模型开发，比较适合大型项目。
传统模式踩过的坑
好了，上面说了这么多，主要就是讲述了，传统的开发模式存在的一些弊端，这些模式也是在未使用敏捷管理之前所使用的，当然也踩了很多坑。
当时我在开发中主要就是使用的瀑布流模式，每次拿到一个新项目，几乎很难理解该项目的整体流程和使用场景，首先要做的就是分析需求，分析明白需求文档，才能去尝试开发功能，为什么说是尝试呢，因为即使我们通过文档也不一定理解的和客户想要的一致。当时没有更多的会议，需求确认会议都没有正式开过一次。
打个比方，需求是客户与项目经理沟通产生的，那么项目经理的理解有可能和客户理解有一定的偏差，但是需求就是这么多，没有具体的细节，我们又无法针对每一个细节和客户面对面沟通，这样会导致，开发中一直按照的是文档表述的开发的，但是真正到项目开发完成才发现，和客户预想的结果不一样，不一样。
这种项目可以想象一下成功的几率有多低。
举个很典型的例子：
记得做一个电商项目的时候，前期开发是比较困难的，因为需求不明确，动不动都需要和客户开会讨论确认需求，客户每次都是，口头表达他们的预期功能和效果，但是开过几次会议发现，上次开会说的客户不认账了，比如：上次他们明明说的一个需求点就做成 1，但是这次他们说应该是做成 2，因为没有明确需求，所以也无法和客户过多地辩论。
最后我们为了避免这种事情的发生，考虑做会议记录，并且会议上核客户一一确认，会议后再通过邮件全部发送有关人员知晓，这种做法也在一定程度上减少了这种事情的发生。
不难想象这种开发是盲目的，也是无法避免的，所以在这几年时间里，我真正做好，做成功的项目 寥寥无几，即使有一些小小的成功，也是在耗费预期时间的几倍 才勉强换来的。
正是因为有这些弊端和缺陷，并且有些是致命的，才有一种新的东西的产生：敏捷开发流程。
在这样的情况下我开始了解敏捷开发的流程。
我当时入手敏捷开发的时候国内还没有几家了解和实行敏捷流程的（最起码我一家都没有听说过），当时所在公司也是很看好这一块，觉得这是一个空白区，当然这也是一个很大的调整，因为没有参考，没有对比，鉴于国内没有在做的企业，所以想着能不能参考国外一些企业的敏捷理念和一些敏捷资料做一个自己的敏捷流程平台。
开始动手做敏捷流程，我们想到的就是从两点做起：
如何高效处理问题
如何组织有效的会议
为什么从这两方面入手呢，这也是根据我们公司当时的现状。
问题 1，就是当项目中遇到问题时没有人主动去处理，和追踪这些问题，不了了之，导致有一些问题在出版本或者项目上线的时候才发现。
故事：记得很清楚的一次，我们做的一个视频播放器，在开发中其实已经出现了一些资源的无法加载问题，播放不了，但是开发人员和测试人员都认为是公司网络问题，理想地认为其他网络可以播放，一点都没有在意，也没有做任何记录，结果在上线的时候很多类似视频资源无法播放，导致客户对我们产品一下失去了信心。
虽然最终找到是客户提供视频资源转换的问题，但是这也反应出了我们的问题，产品开发和测试中发现了问题没有人去处理和追踪，也导致客户对我们的开发能力大打折扣。
问题 2，另一个就是很少组织会议，平常的项目需求讨论会议都很少，即使开了也是很少有人发言。
这种情况直接影响到了公司同事之间的沟通，因为没有会议的沟通，会下他们也很少沟通，有时候遇到问题的同事去跟踪问题，和其他同事讨论的时候很不畅通，时不时出现“这块不是我做的，我不知道”这样的话语字眼。
当时做了这两部分以后，发现工作效率提高了不少。
工作中我们要求公司开发和测试人员每天都要提出来两到三个问题，这些问题都是在自己名下，并且自己要一直追踪，直到完成。
这样做提高了问题的处理效率，这时候会发现，每个人会开始关心和自己有关的问题，并主动，愿意去处理。
我们还要求每周有一次周会，每天有一个站立会议。
周会是说一下我们本周的工作、整体情况 （比如：本周哪个项目出版本了，下一步要做到什么？）当然这些不是汇报，是同步我们的工作情况，这点很重要，有些公司很容易把会议开成汇报会议，这样就没有任何意义了。
站立会议，我们当时主要是说两方面 ：
昨天完成了什么？
今天做什么？
其实说到这里有些小伙伴就会说，这不是现在敏捷中站立会议的内容吗？
其实不是，当时我们只做了这两点，至于问题，我们还是会单独拉会议去说，会议时间很短，主要是大家说一下自己的工作进度和情况，让团队成员互相了解一下项目进度。
会议的主持人我们采取每个人主持一周，每周主持的人员，不仅要提前准备好开会的设备设施，还要主持好这次会议，比如当会议被其他无关的问题打断的时候，主持人一定及时制止，可以记录一下问题，帮助他们组织另一个会议，或者让他们自己组织一个会议单独讨论。
过了大概三个月时间，发现团队沟通明显顺畅了很多，之前每次开会都是沉默不语，现在每个人都会发表自己的意见和想法。
每个人的会议组织能力也明显提高，遇到问题会及时拉起会议来沟通，很少有拖拖拉拉的。
通过这两点我也是发现了敏捷的好处和前景，也开始整体和系统的入手敏捷开发流程，当时从用户故事、迭代……一直到现在的整理流程的把控。
上面说了一下我的经历，为什么使用敏捷和解决了我当时企业的什么问题，可能有很多小伙伴也有类似问题，下面我们说重点。
什么是敏捷开发流程？
敏捷开发的概念
敏捷软件开发又称敏捷开发， 是一种从 1990 年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不 尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
简单说，敏捷开发就是以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，每个子项目在分割成多个用户故事，各个子项目的成果都经过测试，具备集成和可运行的特征（就是每天或者每个迭代的版本都是可随时运行，随时出版本）。
换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别去完成，在此过程中软件一直处于可使用状态。
敏捷最大的特色是迭代式开发。
通过下面了解敏捷的开发阶段：
敏捷宣言
2001 年 2 月，敏捷宣言发表，敏捷联盟成立。敏捷宣言中所表述的价值观分为四个方面：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
敏捷开发方法有哪些？
和其它一些项目管理方式一样，敏捷开发也有一定的方式。
前面说了很多主要讲述，敏捷它其实是一种指导思想，或者说是一种开发方式，但是它没有明确告诉我们，到底采用什么样的流程进行开发，更没有告诉我们，怎么做才能是敏捷开发流程。
敏捷管理也有自己的流程方式，而 Scrum 和 XP 就是敏捷开发的具体方式了，我们可以采用 Scrum 方式，或者采用 XP 方式。
那么这两种方式的区别是什么呢？
Scrum 偏重于过程
XP 则偏重于实践
两种方式，一个偏于过程，一个偏于实践，但是实际工作中，两者结合一起应用才是最好的方式，当然我们这里只说偏好的一种，这里主要讲 Scrum。
什么是 Scrum？
Scrum 是一个敏捷开发框架流程模式，是一个增量的、迭代的开发过程。通常使用于敏捷软件开发。
Scrum 原词来自于橄榄球运动里面的一个专业术语。在橄榄球比赛的每次冲刺前。都将有一个计划安排的过程，但冲刺開始后则由队员在原计划的基础上随机应发。
在传球的过程中需要所有成员的认真配合，信念一致并且目标明确。
这个过程体现了对一个高效合作团队的所有要求。
说到底，敏捷开发就像是一场疯狂的橄榄球比赛。
Scrum 的组成：
一个开发过程
几种角色
一套规范的实施方法
在 Scrum 中，产品需求就是产品需求列表（Product Backlogs）。所有的产品需求列表都是 从一个简单的想法开始，并逐步被细化（简单到复杂），梳理出来多个故事线，并且每个故事线就是一个单独的模块，可以被开发。
Scrum 将开发过程分为多个 Sprint 周期，每个 Sprint 代表一个 2~4 周的开发周期，有固定的时间长度。
Scrum 敏捷流程图
从哪些方面做到敏捷开发流程？
上面讲到了敏捷开发的方式 Scrum 以及 Scrum 的概念，并且梳理了敏捷流程图。那我们需要从哪些方面去做到敏捷开发流程呢？
要使用或者实践敏捷开发 开始就要从 5 个会议入手，完全掌握了这 5 个会议，才能算真正地掌握 Scrum 敏捷开发实战。
这里我们说一下 Scrum 的项目成员组成：Scrum 中有三个角色，分别由 PO（Product Owner）、Scrum Master、项目成员组成。
一般情况下产品经理在需求分析、确定需求之后就需要开始做原型设计和写一些需求文档了。但是在 Scrum 开发模式下，不需要写过多需求文档的，我们会把所有想法体现在原型上，必须加上相应的备注说明，如果在开发中，开发人员有什么疑问可以面对面沟通交流。
这也是 Scrum 的最关键的点就是多沟通，用沟通来替代文档。可以做到少文档，但是不能没有沟通。
如果开始就丢给开发一个原型图，或者原型流程，那他们肯定一脸茫然，甚至不知道如何开始工作，那么这种怎么解决呢？
为了项目负责人工作能够更有效，团队能够更和谐，所以这就涉及到接下来要说的 Scrum 五个会议：
需求澄清会
计划分析会
站立会
评审会
回顾会
下面我们举例一一说明一下这五种会议，搬起小板凳坐好，听好。
需求澄清会
需求澄清会议就是澄清需求的，有些小伙伴可以会问，不是有原型图吗？讲一下流程就行了，还澄清什么呢？当然不是这样的，澄清会议需要通过“用户故事”的方式来澄清。
表达方式例如：
如果我是这个产品的用户，我要实现什么功能，我需要怎么做？怎么做对用户更好。
这边的功能描述可能就是“作为用户或者作为体验者，我想要什么样的功能”，而不是详细到“我要点击那个操作怎么放置”。
简单点说，就是这个用户故事是有多种体现方式的，每个人的理解不一样就会导致实现不正确。这时候需要沟通，只有项目团队都确定了，要做的就是这样的一个东西，这样才算没有问题的需求。
对一个项目来说，每个项目几乎都要细分用户故事，我们可以把用户故事排一下优先级，然后根据优先级把用户故事分成几次不断地迭代。
保证每次迭代的周期很短，一般是两周或者是三周，还有迭代出来的一定是一个可以使用的产品，可能功能有点缺陷，但一定是可以正常使用的产品。
澄清会议需要大家的参与，功能沟通和讨论出没有异议的需求。一定要达到共识。
澄清会议需要项目经理或者项目负责人，知道会议的进行，首先讲解大体的需求，然后就行划分和讨论。
计划分析会
计划分析会，就是根据上一步的澄清会议的结果，原型还有用户故事再细分成任务。
这个会议一般由项目经理或者项目负责人来主持。
在此会议之前，开发人员也知道了需要开发什么样的产品，这时候就可以根据每个用户故事对着原型分任务。
当然这些任务的划分，一般都是有开发来分配的，并且时间也是开发来评估的，一般我们会根据敏捷的版本迭代，拿出来一个或者多个故事线，进行时间安排和划分。
比如：
前端开发看到这个页面，需要展示数据对接几个接口，每个接口大概需要多少小时，需要后台人员如何配合，这都是需要在这个会议搞清楚。所以为了后续的正常开发，这个会议将会是一个漫长的过程，大概需要 3~4 个小时左右。建议 前后端的开发工作分开进行，这样更有针对性。
当然这个会议要营照一个和谐，舒服的环境，不要让团队成员感到有压力，不能太拘谨，建议团队成员通过电视或者影像投屏，把计划让大家都看到，并且大家围在一起。每个成员要踊跃发言和沟通。最主要的非暴力沟通，对于自己的任务，要事实求是的评估时间，不要断章取义，更不要胡乱评估。
站立会
站立会议是每天都需要开的会议，每个项目成员都需要依次发言，内容一下：
昨天完成了什么？
今天需要做什么？
是否遇到难以推进的问题？
当然要强调的是这个会议不是汇报会议，团队成员不要从心理上认为是给 Leader 汇报工作，站立会议主要是为了同步自己的工作情况，目的是让团队其他成员知道，你做了什么？他们会根据你的工作情况来调整自己的工作情况，也方便团队负责人安排其他计划和工作。
这个会议主要目的是：同步工作，互相配合，就是为了避免工作阻塞。
举一个很简单的例子：
张三和李四做功能开发，两个功能快有一定的关联，在开发的时候需要配合才能进行，当张三遇到问题，或者有计划变动的时候，无法完成自己的本次迭代工作，需要及时让李四知道并且调整，站立会议就能很好地做到及时的同步这些问题，避免障碍。
评审会
主要是进行本次迭代的功能进行演示、评审，对照用户故事评审，我们是不是已经完成了这几个用户故事所说的内容。
评审会议需要团队成员一起参加，最好是各个有关领导和老板也一起参加，针对本次迭代的功能进行一一演示，演示完成后，要针对该版本的功能做评审，最好每个人都发言，说一下自己的理解和感受，要做好会议记录，最终做如下结果确认：
哪些需要调整
需要怎么调整
调整需要时间
需要做会议记录，通过上面的几点记录，用于下次版本的优化迭代。评审会议就是反复迭代更新过程的一部分。
回顾会
回顾会议主要是，分析这次迭代我们团队有什么优点、有什么缺点、可以怎样改进，产出对应的改进措施。
可以做出如下几个点的说明：
哪些做得好的事情
哪些做得不好的事情
有什么建议或者意见
值得高兴的事情
值得反思的事情
回顾会议的主要宗旨还是敏捷宣言：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
回顾会议主要就是不断地改进团队和不断优化工作流程。
上面五个重要的会议讲完，小伙伴应该都能很好地运用这几个会议了，这里我再说一下这五个会议的准备工作。
环境：
准备好投屏设备 （最好是电视）
演示设备 （演示使用的手机，或者链接电脑的软件等）
会议面板（一个可移动画板最好，用于记录会议中的重点）
计划：
计划好每个会议需要的内容点
计划好每一个会议的时间
计划好每次主持会议的主持人
计划好每次参与的成员
项目怎么开始使用敏捷开发？
敏捷管理，大家主要更关注在项目中怎么实践敏捷开发的流程，具体有哪些工作可以用于敏捷？下面通过几点说明一下，如何使用敏捷。
快速迭代
和传统开发模式比较，那种半年一次的大版本发布或者项目完成才发布来说，小版本的需求、开发和测试更加简单快速。
有些公司，一年才发布 3~4 个版本，发布的整个流程很缓慢、很不畅通，采用的还是传统瀑布开发模式，并且这些公司对敏捷开发模式的好处并没有挖掘出来，一直误解敏捷开发的好处。
这些公式任务一年发布 3~4 个版本是正常的，如果做到半个月发布 1 个版本，是不可能的事情。
但是现在来看，快速迭代已经成为事实标准，关键是要比目前的版本发布速度更快一些。
敏捷管理是提高团队效能的方式之一，要让团队发挥最高的效能，一定要让团队小而精。
在敏捷开发中要设置冲刺周，按照每周一个冲刺，来进行任务的迭代，这样更高效，能更快地调整、优化。
让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。
参与人员包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。
同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。
不要太重于细节
确定需求时，不要过度盯在细节上。需求报告过于详细，就是一种不敏捷的习惯，还浪费大家的时间。当然，不能错过好点子，但就是不要太细，因为项目真正实施起来时需求将会产生很大的变动。
敏捷项目中编写用户故事有一个常用模板：
作为一名 [用户类型]，我想要 [需求]，以便于 [原因]。
应用到这个例子，就是：作为一名用户，我想要将归档程序数字化，以便于增强沟通、提高分享效率。
可以通过 Excel 的模板形式提供大家，不断更新需求。
多沟通，尽量减少文档
任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。敏捷强调良好高效的沟通的重要性。
团队要确保日常的交流，面对面沟通比邮件强得多。
上面说的每日站立会议就是沟通所必需的，每天团队成员的几个人参与，时间控制在 15 分钟内。
每个人都依次说一下：
昨天完成了什么？今天要做什么？哪些问题仍待讨论？
对于一些问题阻塞在另开会议讨论。
所以这里强调敏捷的五个会议是非常重要的，沟通是根本。敏捷管理建议善于沟通。
做好产品原型
建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。
文档会导致无法把一个功能或者故事线 链接到一起。为了避免这一问题，可以模拟真实操作，改进模拟操作过程中难以理解和不清楚的操作行为。这样就可以使用原型图的操作，这个绘制原型图 可以使用如下：
比如下面的一个开源平台，可以创建不同平台的原型图。
https://www.xiaopiu.com/
怎么才能评估团队是否已经敏捷了？
敏捷开发是没有标准的可供参考的实践过程，所以很难通过某个过程而断定其开发过程是否使用敏捷了，那么如何来评估团队是敏捷的呢？
根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷，常见评估项目团队是否已经敏捷的方法如下：
团队有共同的目标，当然这个目标和公司的目标一致，并且对这个目标充满信心；
团队有明确的阶段目标计划并且为每个成员所知晓；
团队成员知晓当前计划，做什么、何时完成、预期效果等；
团队任务是低耦合的，并且紧密协作；
重点需要看，每次迭代版本发布过程是否是顺利并且轻松愉快的，构建版本并不断测试是常态行为之一。
要从最基础的工作做到敏捷开发。
当然敏捷是一个慢慢实践和优化的过程，需要我们大家齐心协力，共同做到、做好，否则一切都是空谈。
当我们个人做任何事情的时候，会主动沟通，不做被动者，就有效提高了自己的工作效率，然而当一个团队中人人都主动沟通，相互配合，主动承担责任和任务，就是敏捷的最好体现。
千里之行，始于足下。
好了，这里关于敏捷的几点就讲到这里了，关键是在项目中实践敏捷开发的流程，先做到自己工作的敏捷，慢慢和团队共同达到敏捷，实践敏捷的工作，接下来要靠大家的行动了，没有行动一切都是枉然，大家可以铭记敏捷宣言，从每天的一部分工作做起。
推荐阅读
史上讲解最好的 Docker 教程，从入门到精通（建议收藏的教程）
