引文

几天前

思思问我：“什么时候给我们讲讲敏捷？”

我说：“好啊，咱们安排个时间，我讲一讲，内容比较多，不过咱们可以分几次，每次讲个几个小时吧！”

思思问：“能不能短点，每次5分钟？”

好吧！我得怎么安排这5分钟

敏捷是什么？

先来看看这张图，听我给你讲个故事

13年的时候，我参加了CSM认证课程，初识Scrum，当时对敏捷的理解：它是一种研发的方法论。一群技术大咖经过探讨，找到了提升研发效率的理念----《敏捷宣言》，Scrum是将这种方法论付诸实施的框架，透过这个框架我们可以达到提升研发效率的预期。

当时在我看来这种思想是研发的灵丹妙药，回来试了试，尝试了信息透明化，让小组成员尝试自组织，不过事情并没有那么简单，研发团队每次拿到的产品设计都是”天衣无缝“的几百页文档，而不是拆分成有效的用户故事，团队没有稳定的节奏，初期尝试结果并不理想，

好，如果我将推行敏捷视为一个产品，那么这个产品出了什么问题呢？有什么是我没有想到的。

后来我找到了一个可能的原因，这个产品的最终用户包含整个研发环境的每个人，而我只把它，推给了一部分用户（研发人员）。

再来，我继续学习了CSPO认证课程，希望把SCRUM中产品经理的角色弄明白，回来后大失所望，因为Scrum团队中的产品经理被定义为Police Officer,对产品方向有决策权和定价的能力，好吧，这种角色在我们团队里并不是一个人。

好，如果敏捷中的PO角色，对于我们来说是一组人，我如何把他们都纳入到敏捷的团队中来呢？

这个领域如何攻克呢？我找到了两个方式，一个是U型变革，它一种驱动组织内部演变的实践；另一个是精益看板，在不改变现有流程的情况下将信息透明化并逐步改进的方式。

回想一下，当时我是被第一种方式吸引了，在公司内部发起了一个小学习组织，还拉上几个同事一起学习，而后又因为U型理论学习了专业教练，希望借此增强我对U型和敏捷教练的理解和能力......

---

故事先讲到这里，现在我们回来看看上面那张图，我将敏捷分成三层：

第一层叫技能，可以说我最初学习敏捷是从这里开始的，从0-100，有各种各样的技能供我们选择，比如：产品设计需要Design Thinking，这是通过使用原型快速验证想法并持续迭代的方法。研发和管理流程可以使用Scrumban，Xp，TDD，DevOps通过工程实践和可视化工具提升交付效率和协作质量，市场营销使用Growth Hacker分析并找到用户增长的途径等等。这一层我又称其为表象层，就像浮在海面的冰山一样，乍一看这些技能可以快速习得。

第二层叫能力，能力分为两种一种叫天赋，是我们每个人与生俱来的，比如说，有的人审美好，同等技能下，做出来的UI原型就比其他人做出来的漂亮易用；另一种是通过后天习得并需要刻意练习的，比如说，同理心，如何从用户的角度出发理解用户的能力，勇气，当遇到困难时敢于及时寻求帮助，是需要勇气的，这一点在喜欢埋头苦干的程序员身上体现地十分明显。（注，本次我画的五种能力是Scrum的5个核心价值观，这些都是”冰山“能够有效实施的基础）

第三层叫认知，是真正体现一个人或组织敏捷性的所在，如同《U型理论》中谈到，对于未知事物的接受程度，决定了一个集体的进化程度，及会涌现出怎样的新事物。这一层需要的不只是训练，同时还需要内在持续反思觉察，比如：近年来欧美流行的正念练习，教练等对提升认知很有帮助。

好了，现在当有人问你敏捷是什么？你知道如何回答了吧。而这一切都是以持续向用户交付价值为核心，并在任何情况下保持一种持续改进的状态。

后记

我为何把敏捷这些东西都画出来？因为我在接触敏捷的时候又接触了视觉记录，记得应该是13年的时候，当时参加一个外部工作坊，首次接触到视觉记录，看着几位视觉记录大咖把一天的活动内容做成了一幅画，而当我用短短的几分钟去看这幅画的时候，犹如再次体验了这一天的经历，所以后续我会通过这样的形式来来和大家交流。

---

我是Bright

一个活跃在敏捷社区的专业教练，一个专业教练中的视觉引导师。