在互联网公司工作的各位应该或多或少都应该听过敏捷，目前，敏捷(Agile)的概念应该已经相当的普及，尤其是在一些大公司内部，搞敏捷已经成了项目相关人员的日常活动。2019年由Scrum.org和Age of Product出版的Scrum Master趋势报告明确表示敏捷变革将会是未来企业项目管理的大势所趋。
运用敏捷方法进行项目的部分企业
然而，并不是每个人都喜欢敏捷。艾威小编和学员聊天的时候总能收到不少关于敏捷的抱怨：什么效率低下啦，工时增长啦，士气低迷呀，浪费时间什么的，等等。
那么敏捷真就如此不堪，除了折腾员工外什么用都没有吗？
其实并不然。让我们从埃森哲讲起……
可能从事IT相关工作的朋友都还有印象，在本年4月底左右的时候朋友圈里曾经有一篇讲埃森哲的文章刷过屏……
耗费2个多亿，耗时2年多，连一个可用的网站或者APP都没有交付出来。
想要完工？那就再交1000万美元。
……
因为项目要再进行下去，还需要发现并纠正埃森哲工作中的缺陷，以及开发埃森哲本应交付但未能交付的功能。
美国汽车租赁公司赫兹(Hertz)终于忍无可忍，一纸诉状将埃森哲告上法庭。
把事情拖成这样似乎是大组织的通病。无独有偶，2016年俄勒冈州政府起诉Oracle，1亿美金不能如约履行医疗网站交付；2017年滨州政府起诉IBM，1.7亿美金不能履行税务系统交付。
可能有人会问，埃森哲难道不用敏捷方法吗？难道Hertz的IT部门不知道敏捷吗？要是他们用了，事情还会变成这样？
别笑人家，其实说不定觉得自己已经对敏捷流程了然于心的你都不知道敏捷真正的样子。大部分人提到敏捷可能_时间想到的还是“上午出案子，下午就测试，跑通就上线，一周一版本”“每天早上开个晨会就拉倒”这种流于表象的内容，项目内容不多还好，一多了就容易变成“加班三重奏”。别忘了，敏捷有着自己的价值观：
个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客服合作 高于 合同谈判 响应变化 高于 遵循计划 敏捷缺少了价值观引导会变成什么样子呢？ 1.项目团队缺乏对敏捷的正确认识，单纯的认为敏捷就是快，就是追赶进度,就可以不受任何制度约束。大家可能听说过这样的对联，“这个功能很简单，怎么实现我不管。”横批：“明天上线”。也曾听说有些公司要开发一个新功能，因为实施了scrum，于是要求项目团队加班加点，将2周甚至3周以上的开发任务在一周内就发布上线。实施Scrum意味着项目团队“漫无天日”的加班，这导致了项目团队对敏捷有一种“恐惧”感； 2. PO不能胜任工作，无法拆分有效的用户故事，或者用户故事拆分的不合理，无法实现迭代增量开发； 3.Scrum对于自组织的团队要求很高，但许多同学认为自己达不到自组织的标准； 4.Scrum倡导工作透明化，项目实时完成情况和每个人的任务认领情况通过项目看板和项目燃尽图一览无余，许多人对此不太适应； 5.在迭代的过程中无法及时发现问题，或者发现问题，无法有效解决问题，使项目团队有一种挫败感。等等。 这其中的每一点，都可能成为企业在推行敏捷化管理的“败因”。
既然如此，“真正的敏捷”是什么样子呢？ 以Scrum为例子，当我们学习Scrum的时候，首先要明确Scrum 是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。
而为了_这个开发过程时刻处于可视、可集成和可运行状态，就需要项目在一个稳定的敏捷流程中运转，它包括：
产品分析用户需求，按照商业价值依次排序估算，输出计划产品功能列表。 经过计划会议讨论，按照计划面板梳理功能列表，输出产品版本迭代任务。 进入开发迭代周期，按照任务面板增量迭代开发，输出可交付的迭代版本。 进入评审验收环节，按照发布面板汇总问题原因，输出迭代周期报表数据。
不难发现该流程中存在4个输出/输入，3个关键图表，3个相关会议，具体的流程细节这里就不细表了，已经给出了图片说明，而且……
敏捷开发作为一种团队协作方法论，高效与清晰是两个特别明显的特点，保持敏捷开发的理念开始Sprint工作的团队，一定有正向的开发BUFF加成，我们需要面对的是如何将敏捷开发的流程执行到位，_大化的获取加成收益。
小编很认同一些学员对敏捷开发对于精英团队的加成是_大化的观点，因为大家目标清晰，技术能力完善，执行力强，这是_理想的工作模型。但对于现实中的非理想工作模型，特别是在国内的“非典型项目环境下”，我们可以从以下几个方面去试着加强这种团队加成效果：
首先，产品BACKLOG的来源一定要尽可能的准确，_好是有明确的数据分析结果作为支持依据，Sprint BACKALOG的任务细化尽可能细致，_在后续的Sprint迭代过程中，团队的工作目标清晰明确。因为没有人会希望自己的工作量_后转化为无用功，而不是KPI，这对于团队士气是一种相当沉重的打击。如果还是出现了这种情况，Sprint负责人也要积极转移大家的情绪，劝慰大家尽快投入下一个更加正确的Sprint周期中去。
值得注意的是，为了_开发过程中灵活性，敏捷开发往往为了高效而不会过多的对成员做工作流程上的束缚，需求在迭代过程随时可发生变动，开发任务清单可由团队成员自主选择，任务面板由成员自主更新，是一种以沟通为主的工作模式。所以在这个过程中，团队成员之间要尽可能形成积极沟通的氛围，以_各职能团队之间的信息沟通准确对称(其实无论是在什么管理中，_沟通准确都是_项目成功的关键点之一)。
再一个，以国内大家比较习惯的情况来看，项目团队成员在工作分配上更倾向于被动接受。所以开发经理在安排工作任务清单的时候需要根据项目团队成员的能力维度进行合理安排，尽_大可能避免团队成员因为能力方面的原因导致进度延期、工作效率低下、士气低落等不利于团队建设的情况出现。
Sprint周期内团队成员的组成结构尽量_不变动，尤其是处于核心的主导成员。因为在这个周期内，需要高度集中团队整体的开发关注力，如果这时团队的头部成员发生更换，一定会存在沟通成本损耗，影响整体迭代效率。
还有一点务必注意，Sprint开发过程中，会议的频次与时长是需要进行适当的把控的。现在很多人抱怨敏捷瞎开会的原因之一就是有些会议的RIO并不成正比，耗时且没有正向的工作计划输出。所以每次开会_好由负责人主导会议，做好会议相关数据报表的输入输出，阶段性的展示成果，给予团队积极的正向会议反馈。
本次分享就到此为止，祝愿还在各种特色敏捷中各种糟心的同志们早日脱离苦海，走向真正的敏捷。
艾威国际网校
艾威天猫旗舰店
艾威官方微信
艾威网校官方微信
艾威官方视频号
艾威知乎号
企业微信客服
2025全年课表
查看全部课程
《哪吒2》票房数据是怎么“算"出来的?数据清洗和预处理的关键技术和步骤(入门指南)
未来的企业架构是什么样的？AI对企业架构（EA）的深度改造
