敏捷敏捷敏捷，这是一个咒语吗? 对敏捷时代的一些困惑和思考

原创2024-03-14小艾老师

Scrum Master敏捷专家认证（CSM）知识体系考证须知证书含金量培训大纲 3分钟小视频我要提问

Scrum Master 认证是针对 Scrum Master（敏捷项目管理中的角色）的专业认证。Scrum 是一种敏捷开发方法，Scrum Master 则是负责指导和推动 Scrum 团队的角色。获得 Scrum Master 认证可以证明个人在敏捷项目管理方面具备一定的知识和技能，并且对Scrum方法有深入的理解和实践经验。这对于在敏捷环境中工作的项目经理、团队领导或相关专业人士来说，可能有助于提升他们在职场上的竞争力和专业认可度。

中文名Scrum Master敏捷专家认证（CSM）
英文名Certified Scrum Master
英文简称CSM
颁证机构Scrum Alliance（Scrum敏捷联盟）
证书类别敏捷
同类认证ACP、ITIL4 HVIT、DevOps

不知道大家有没有这样的经历，公司和领导整天把“敏捷”挂在嘴边，就像念咒语一样。可是，敏捷真的是_的吗？为啥感觉实施敏捷之后，工作反而变得更复杂了呢？难道我遇到了假的敏捷？这可咋办呢？

今天小艾老师就来跟大家聊聊对敏捷时代的一些困惑和思考。

一、敏捷是什么？

敏捷并不是一个新鲜的概念，它源于软件开发领域，是一种迭代式、增量式的开发方法，旨在通过快速响应变化、频繁交付价值来提高项目的成功率。敏捷强调团队协作、客户参与和持续改进，以适应不断变化的需求和环境。

二、敏捷是_的吗？

敏捷并不是解决所有问题的银弹，它并不是适用于所有项目和团队的_解决方案，它也有它的局限性。

例如，在一些复杂的项目中，敏捷可能会带来更多的管理和协调工作。由于敏捷强调的是快速交付，可能会导致团队在没有充分规划和设计的情况下就开始开发，从而增加了后期修复和改进的成本。此外，敏捷对于团队的协作和沟通要求较高，如果团队成员之间存在沟通障碍或缺乏协作精神，那么敏捷可能会带来更多的问题。

敏捷是需要团队具备一定的成熟度和协作能力的，同时也需要客户和管理层的支持与配合。如果在不具备这些条件的情况下强行推行敏捷，可能会导致更多的问题和混乱。

三、为什么实施敏捷之后反而会感到更复杂？

有些人在实施敏捷后反而觉得工作更复杂了，这可能是由于以下原因：

缺乏明确的目标和范围：敏捷强调频繁交付价值，但如果没有明确的目标和范围，团队可能会陷入无休止的迭代中，感到无所适从。
不合理的迭代周期：如果迭代周期过短，团队可能无法完成有意义的工作；如果迭代周期过长，可能会导致反馈周期过长，无法及时调整方向。
团队成员之间的协作问题：敏捷强调团队协作，但如果团队成员之间缺乏沟通和协调，可能会导致工作效率低下，增加工作的复杂性。
不适当的工具和技术：敏捷需要合适的工具和技术来支持协作和沟通，如果选择了不适当的工具和技术，可能会导致工作更加复杂。
项目本身的特性不适合敏捷方法。有些项目可能需要更传统的瀑布式开发方法，因为它们需要更全面的规划和设计。

我们需要认识到，敏捷并不是一个死板的公式，它需要根据实际情况进行调整和优化。每个团队和项目都有其独特的需求和挑战，我们需要灵活地应用敏捷原则，找到_适合自己的方法。

四、假敏捷，是怎么一回事？

走形式的会议：每天站会、迭代计划会是开了，但就是走个过场，没啥实际交流。
死命做计划：敏捷讲究迭代和增量，可还是有人要搞详细的大计划，不看实际需求。
质量靠边站：光图快，不重视代码质量和测试，结果后期一堆 bug，修都修不完。
没有自主权：团队成员做啥都要请示汇报，等上面下命令，没法快速应对变化。
还是老一套：说是敏捷，干的还是瀑布那一套，一步到位，不管实际情况。
乱估时间：敏捷估算乱来，任务根本完不成，时间都浪费了。
沟通不顺畅：团队里大家有问题不说，有意见不提，影响项目进度。
团队不灵活：团队结构死板，不能根据项目需求变化调整。
不把用户放心上：口口声声用户至上，实际开发却不考虑用户真正的需求。
不看数据乱决策：做决定不靠数据分析，全凭个人感觉或经验。
……

你们有没有遇到过这些情况？这就是“假敏捷“、“僵尸敏捷”、“罪恶的敏捷”！

假敏捷就是一种表面上的敏捷，它只是借用了敏捷的一些概念和工具，但它忽略的是敏捷的精神和原则，从而导致了工作变得更复杂、更低效。

敏捷的成功与否与实施的过程密切相关。如果实施过程中存在问题或偏差，那么敏捷的效果可能会大打折扣。一些公司可能只是表面上实施了敏捷，却没有真正理解和贯彻敏捷的核心原则。他们可能只是简单地将项目分成迭代，而没有真正实现团队合作、持续交付和快速反馈的理念。这种假的敏捷实施只是形式上的变化，却无法真正发挥敏捷的优势。

五、怎么办？

敏捷需要重新启动，我们必须回到根本，必须抛开那些僵化的“敏捷公式”。 “敏捷”团队应该定期回顾敏捷宣言和12条原则，而不是仅仅关注于流程和工具。如果我们自己的“敏捷”实践想要保持敏捷，还需要不断地去修剪它们，找出_适合我们的敏捷方法。

敏捷宣言：

敏捷12原则：

我们_优先做的是通过尽早的，可持续的交付有价值的软件来使客户满意
拥抱变化——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，_有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽_大可能减少不必要的工作。这是一门艺术。
_佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

敏捷相关角色及关键点：

结束语

敏捷开发作为一种有效的项目管理方法，仍然具有重要的价值。敏捷思维，也同样能运用在各行各业。然而，要实现真正的敏捷，企业需要回归敏捷_初的那份简单和基础，需要深入理解敏捷的核心原则，避免形式主义的敏捷实践。通过培养敏捷文化、改善沟通和协作，以及持续学习和改进，组织可以更好地适应不断变化的环境，提高项目的成功率。

如果你想要系统地学习敏捷的知识、方法和技能，小艾老师向大家推荐学习：

1、Scrum Master敏捷专家（CSM）认证

2、高级Scrum Master（A-CSM）认证

3、PMI-ACP敏捷项目管理认证