很多人都在强调用“敏捷”办公，但实际上并没有严格按照这个流程来，还存在着很多问题。作者结合自己的实战经验，总结了一些会遇到的问题以及实战中的几点经验，希望对你有所帮助。

前言

前段时间听身边的一个朋友吐槽自己公司喊着敏捷的口号，实际上却跑着假敏捷的流程（即非瀑布非敏捷），两个模式混着用，一天一个流程，搞得团队成员都非常难受。

本人是17年开始接触敏捷模式的，在18年的时候公司由瀑布模式正式转换为敏捷模式，期间也遇到过许多挑战和问题，所以趁机复盘总结一下心得。

一、问题剖析

听完朋友的吐槽之后，再结合我过往的经验，大概总结出了3个经典的问题：

1. 看似是不信任的问题，实则是不理解的问题

很多初次了解敏捷的人都会对敏捷不太信任，认为敏捷就是乱来胡搞，用敏捷反而会降低原来的效率，总之是各种不看好敏捷。于是我专门找了几位资深的瀑布研发大佬调研，在跟大佬们沟通完后，发现他们普遍存在2个误区，他们认为敏捷提出的“拥抱变化”=“产品经理可以随意变更需求” 以及 “轻文档”=“零文档”。

这其实是对敏捷不理解的原因，首先拥抱变化指的是整个团队拥抱变化，是公司的整体方向拥抱变化，当方向有变动时，可以及时调整，而不是说产品经理可以随意变更需求，在敏捷模式中产品经理变更需求或任务都是需要和研发团队商讨确认的。

其次轻文档并不是零文档，必要的文档该有还是要有的（如功能流程说明、业务逻辑说明等），敏捷强调的是重沟通轻文档，表示的是团队之间的一种协作模式。我们可以想一想文档的目的是什么？当然，不同类型的文档定位肯定是不同的，但所有的文档无非是2个目的：

1. 传递信息
2. 记录留存

而传递信息的最高效方法就是面对面沟通，所以在敏捷模式中强调的是重沟通；至于记录留存，如果有必要则可以将每次沟通的关键内容作为会议记录，甚至只需要记一张流程图或思维导图即可。而且在敏捷模式中，团队之间本身就有用户故事作为桥梁连接，用户故事也属于文档的一种。

2. 看似是推进困难重重，实则是没有上级支持

在企业刚开始推进敏捷时，势必会遭到大部分人的抵触和抗拒，这点很正常，从心理学上来讲人们都有习惯心理，我们习惯于常规事物，当有新鲜事物兴起时，这会与我们意识中的默认事物相冲突，所以我们会本能的选择逃避和抗拒，而新事物往往要求人们做出改变，但改变往往是伴随着痛苦的，所以会更加抗拒；其次是恐惧心理，人们最大的恐惧来自对未知的恐惧，而新事物带来的未知恐惧也会加强抵触情绪。

生活中如此，工作中更是如此，在生活中我们不能强迫他人接受新事物，但在工作中我们可以通过公司制度来管理团队。所以欲成其事，必先得领导支持，方可推进敏捷之事，否则这事儿就趁早打消念头吧。

3. 看似是团队低效的问题，实则是工具不行的问题

那位朋友还吐槽了一个经典的情况，就是他们的老板经常抱怨他们上了敏捷模式之后效率还是低下的问题。具体询问之下才知道他们还在用一种在线版的Excel来管理研发任务，那效率不低才怪呢，Excel固然很强大（各ERP系统的尽头就是导出Excel），但强大的工具也是要分使用场景的，工具使用不当，那效率必然低下，正所谓工欲善其事必先利其器，有了高效的工具才能有高效的输出。

市场上有很多关于敏捷流程的管理工具（有付费的、有免费的），总之找到一款适合自己团队的就行，但在购买付费版前，最好将公司的流程能完全跑通和让团队接受，否则你买了也只会浪费钱财。

二、敏捷实战

原计划是不在本文中讨论敏捷具体的实施步骤，因为关于敏捷的文章在网上一搜一大把，而且网上还有很多专业的敏捷教练可咨询，但不分享一点干货又感觉内容太水（哈哈哈~），由于本人之前一直实践的是敏捷Scrum模式，所以本次简单的分享一下敏捷Scrum实施经验。

首先，介绍一下敏捷Scrum的“334”基本框架，即3个角色、3个工件和4个事件。

1. 【3个角色】

① 产品负责人- Product Owner（简称PO）：一般由产品经理/产品总监担任此角色，PO是产品待办列表的唯一负责人，其职责是将团队开发的产品价值最大化，将产品待办列表中的史诗故事拆解为Sprint中可开发的用户故事，以及随时解答团队对用户故事的疑问。

② 敏捷教练 – Scrum Master（简称SM）：一般由专业的敏捷教练担任此角色，但大多数由公司比较有声望和懂敏捷开发的人员担任此角色，SM的职责是帮助团队理解Scrum的理论和实践，保障Scrum中的事件能按时完成以及帮助团队移除工作进展中的障碍。

③ 开发团队 – Team（简称：Team）：Team由各种跨职业人员组成，包含前端、后端、测试、架构等……，在Team中所有人平等，没有头衔之分，都属于团队成员，其职责是将产品待办列表中的需求转换为可交付的产品增量。

2. 【3个工件】

① 产品待办列表：该列表由PO全权负责，该列表项应具有这些属性：描述、次序、估算和价值，产品待办列表是动态的，需要持续更新以反映出产品需要什么来保持其适用性和竞争力。

② Sprint待办列表：该列表由团队全权负责，Sprint待办列表是由产品待办列表中选出的一组优先级最高的用户故事列表，Sprint待办列表是高度可见的，是团队在当前Sprint内工作完成情况的实时反映。

③ 产品增量列表：产品增量是一个Sprint中完成的所有产品待办列表项的总和，以及之前所有Sprint所产生增量的价值总和，无论产品负责人是否决定发布它，增量都必须可用。

3. 【4个事件】

① Sprint 计划会：该事件由PO在Sprint的第一天主持召开，会议时长视迭代周期而定（周期为2周的一般不超过4小时；周期为4周的一般不超过8小时），参会人员包含PO、SM、团队所有成员，会议内容由PO向开发团队讲解当前Sprint需要完成的用户故事，PO讲解完当前Sprint用户故事后，由团队成员一起将用户故事拆解为具体的开发任务，同时计划会也标志着一个新Sprint的开始。

② 每日立会：该事件由团队成员在一个Sprint周期中每天自行组织召开，会议时长建议不超过15分钟，参会人员包含SM和团队所有成员（PO为非必要参加），会议内容由所有团队成员以“我昨天做了什么……”、“我昨天遇到了什么问题……需要什么帮助……”、“我今天准备做什么……”3个为话题依次发言，发言完毕后现场领取任务（即承诺今天要完成的任务），该事件的召开时间点可自由选择，根据本人之前的实践情况，建议固定在每天早上9点10分进行。

③ Sprint 评审会：该事件由团队成员在一个Sprint的最后一天召开，会议时长视迭代周期而定（周期为2周的一般不超过2小时；周期为4周的一般不超过4小时），参会人员包含PO、SM、团队所有成员、需求干系人等，会议内容由团队向需求干系人演示Sprint中完成的功能以及解答干系人在会议上提出的问题，同时评审会也作为一个Sprint的结束标志。

④ Sprint 回顾会：该事件由团队成员自行组织召开（建议在Sprint的最后一天执行），会议时长视迭代周期而定，回顾会一般不超过3小时，参会人员包含PO、SM、团队全体成员、视情况邀请/拒绝领导参会，会议内容由团队成员回顾当前Sprint中遇到的问题并针对上述问题讨论解决方案，以便于下个Sprint改进；同时还需要检视上个Sprint中问题的改进情况。（注：此会议为非正式会议，团队成员可自由发言，甚至可以购买一些零食边吃边聊。此会议的目的为：使团队能不断回顾自身不足之处，找到可改进的地方，让团队像产品一样自我迭代更新，从而变的更强。）

介绍完敏捷Scrum基本框架后，其次就是框架的具体运用了，在开始实施敏捷流程前，我们需要先制定一个Sprint的周期。通常一个Sprint周期为2~4周（当然也可以超过4周，根据企业自身情况而定），根据本人之前的实践情况来看，最终认为2周为一个Sprint是最佳的，所以附上一个Sprint周期为2周的“Sprint事件周期图”：

在理解了Scrum框架后，再套上这个Sprint事件周期图执行，我相信你的团队已经走在真正的敏捷道路上了，可能一开始团队会有各种水土不服，各种不适，但这些不适之处，正是团队可改进之处。

当然，也不用按部就班的去执行Sprint事件图中的每一个流程事件，核心是掌握敏捷思想，企业可根据自身的情况灵活调整运用，以上Sprint事件周期图就是我们团队根据敏捷官方指南多年迭代后产出的内容，这里面其实也去掉了一些官方指南中的内容。

三、敏捷的定义

最后，我在梳理这篇文章时产生了一个疑问：我们常挂在嘴边的敏捷到底是什么？而敏捷的定义又是什么呢？

为了想明白这个问题，我咨询了身边多个有接触过敏捷的朋友们，听到最多的回答是：敏捷是一种开发方法、是一种开发模式；也有说敏捷是一种观点的，是以小步快跑、快速迭代、拥抱变化、持续改进等为核心。

我还查阅了一下敏捷官方指南的描述，官方指南给出的定义是：敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

在思考许久后，我认为敏捷是一种思想、是一种文化，它以人为本，尊重团队每一位成员，以开放透明化的管理方式使团队可以更专注和更高效的运作。

所以我相信天下没有不适合敏捷的团队，因为敏捷是有章可循，从方法流程入手，以团队为核心，自我迭代更新，从而转变为一种思想，甚至成为一个团队的文化或企业文化。

因此“敏捷到底是什么？”这个问题也许没有标准答案，只是我们每个人对敏捷理解的深度不一致而已。

各位看官，您认为呢？