敏捷：反思的实践和应用

关键要点

• 我们应该把重点放在全局上。
• 最重要的是用户，而不是开发人员。
• 软件开发是一项团队活动。
• 好的回顾是至关重要的。
• 引导（Facilitation）是一项未被充分认识的技能。

作为一名敏捷教练，很容易陷入理论而忽略了实践，因为有些主题理解起来很容易，但实践起来却很难。

我们看到了很多敏捷转型失败，也看到了很多糟糕的看板和 Scrum 实践，有时我们会感觉到成功的喜悦，而有时也会感到失望。这些概念既不复杂也不新颖，只是我们很难找到长久持续的方式来有效地实现它们。

成功的敏捷软件开发基于以下三个思维过程，它们既有相似之处又相互交织，如果缺少了其中任何一个，都会让整体的效果大打折扣。

• 系统思维
• 群体观念
• 反思实践和应用

有时候，我们过于关注原则和价值观。“敏捷软件开发宣言”有一句非常重要的话：“我们通过实践和帮助他人实践来发现更好的软件开发方式“。

敏捷宣言的核心是关于如何更好地交付软件：“我们正在发现更好的方法”。这是一个发现之旅，所以我们并不知道所有问题的答案，并且是“通过实践并帮助其他人实践”来寻找答案。这不仅仅是理论，我们需要与他人分享我们的成功，这样他们就可以从我们过去的成功和失败中吸取经验。

系统思维

这看起来很棒，或许我们用一个不那么高大上的标题会更好些，但问题的关键在于你不是宇宙的中心。“你”可以是指你个人或你的团队。

我们的目标是通过软件有效地为用户解决问题。我们的系统是指这样的一个过程，从确定需求到提供解决方案，通过解决方案来满足需求，然后找出下一个更为重要的需求。

我们的系统不是关于如何编码，也不会将卡片从一个栏位移动到下一个栏位。

分支上的代码写得再好，如果用户在数月或数年内（或许永远不会）用不到它们，就不会给用户带来任何价值，无论你对它们感到多么自豪。对于用不到的功能或架构来说也是如此。

最近，我与一个团队合作开发了一个解决方案，可以将一项常规活动的时间缩短 15 分钟。因为这项活动经常举行，因此节省了大量的时间，从而省下了数百万美元的成本。原先的计划是将它与其他功能放在一起，并在大约 6 个月后交付。但当被指出这事关几百万美元，他们似乎感到困惑和惊讶。一旦清楚地知道影响有多大，团队就有动力减少部署时间。

转型失败

根据我的经验，由于团队成员未能意识到他们是更大系统的贡献者，因此我将大部分不成功的转型（以及很多业务失败）归因于此。这听起来似乎不那么相关，但团队成员是大链条中的连接元素，就像机器中的一个齿轮。过分关注局部不会给整个组织或系统带来任何帮助。

然而，我们却在提高局部效率方面付出了很多努力，却没有意识到，如果缺少了上下文，你的努力就白费了。太过专注于局部效率，可能会导致不必要的浪费，最好的情况是不会给大系统带来任何好处，最坏的情况是降低大系统的效率。对编码效率的痴迷杀死了很多软件产品。我看到有些团队为越来越多需要测试的用例而自豪，或者前端团队为他们开发出不尽其数的特性从而让后端团队赶不上他们而自豪。可悲的是，这些团队似乎没有意识到，他们并没有为系统带来价值。

我的一个朋友最近分享了她的故事：他需要为一个活动准备 10 个蛋糕，但只有一个烤箱。她的丈夫提出要帮忙，她让他提前准备好蛋糕的原料，这样就可以更快让下一个蛋糕进入烤箱。

但当她来取蛋糕的原料时，它们还没有准备好，她的丈夫按照自己的想法忙了一通，但并没有朝着目标的方向走。他先是准备了 10 份面粉，然后是 10 份……等等，他觉得反正后面需要用到它们，他这样做要比每次只做一份然后切换来切换去更有效率。

结果是，虽然他感觉自己很有效率，但系统却要停下来等他，他的效率是以价值交付（蛋糕烘焙）的巨大损失为代价的。

或许，如果他能够了解全局以及他的贡献将如何影响价值流，他会采用不同的方式？他可以一次准备好一块蛋糕的原料，即使对他来说效率有点低。但从整体来看，他们将更快地完成他们的目标。

群体

系统思维是指上下文和领域，但在上下文和领域内部是团队——通常是很多团队。团队是个体的集合——每个个体都是截然不同的——而且个体之间的合作（或不合作）的能力决定了整体的交付能力。在一起合作并共同成长的团队可以完成惊人的壮举，而未能建立信任的团队就像一盘散沙，甚至不会取得任何进步。

软件开发首先是关于人的，这听起来可能有点奇怪。但软件开发的方方面面都是关于团队内部的沟通、与用户的沟通、与利益相关者以及其他团队之间的沟通，等等，可以说有效的沟通推动了软件开发。

那些意识到开发产品其实就是一项以人为本的团队活动的人将会得到更好的发展。那些意识到我们建立跨职能团队是为了让自组织和自激励的团队能够创造出优秀的软件的人，他们更有可能取得成功。

从把自己看成是一个个体到把自己当成是群体的一员，这种思维上的转变是很难的，但当我们能够以有利于群体的方式行事，而不是只为了自己，那么我们就开始成为一个高绩效的团队。但需要注意的是，只是简单地将一群高绩效的人聚在一起，并不会创建出一个高绩效的团队。那通常是一场灾难。当意识到我们不只是简单的机械组合，才有可能组合出高绩效的团队。

其次是在社区中分享知识，并为他人提供支持。敏捷宣言提到，要变得敏捷，不仅要自己实践，还要帮助其他人一起实践。

反思实践和应用

最后，我们必须经常花时间进行反思，这样才能变得善于自我反思，并向其他人提供反馈，帮助他们自我反思。

我相信每个团队——不仅仅是技术团队——都应该定期停下来进行反思。无论你做什么，都可以得到改进，但你需要一个有利于思考的环境。如果你能够学会进行有效的反思，那么进行反思的一小时可能会成为一周中最富有成效的一小时。

当我们忙于日常工作时，专注于眼前的事物，而看不到全局。我们提醒自己真正的优先事项，以及我们对团队和组织的影响。直到我们停下来，开始审视我们的错误信念——太忙而忽略了改进。小的变化可以产生巨大的影响，而且合作是团队在另一个环境中建立联系的好时机。

引导回顾

引导回顾是一项艰巨的技能。有时候人们害怕出现分歧，所以回避困难的话题。但其实如果我们想要提高，正向的冲突通常是有必要的——意见分歧是真正可以促进发生改变的地方。通过噪音来解决真正的问题可能很困难，并需要技巧和练习，但随着时间的推移，辅导员和团队会变得更好，特别是如果他们能够反思如何提高这项技能。多样性很重要，但诚实开放的对话是关键。

作为既是群体也是个体的我们，应该花一些时间找到学习的机会。我们应该不断观察自己和团队，寻找改进的方法。我们学习如何以有助于我们成长而不是削弱我们的方式提供和获取反馈。提供反馈是一种技能，就像接受反馈一样。正如所有技能都需要练习一样，我们应该定期给出好的和不好的反馈。在这两种情况下，都需要秉持开放的态度，并准备好聆听，你或许可以从中学到一些东西。

我们挑战我们的思想，质疑我们的信念，并寻求改进的方法。我们通过尝试和观察新事物学习如何以结构化方式进行实验，并且我们在团队和产品中了解度量指标的价值。

但是，如果我们不应用我们学到的东西，那么学习和反思就是徒劳无功，应用成为我们可以发展的另一项技能，我们中的大多数人都会变得善于析和观察，但不管我们看到什么，我们都会继续做同样的事情。采取行动并承担责任是至关重要的，每天进行评审并且只说不做将让你一事无成。

有一句众所周知的格言很好地概括了我们所讨论的问题：“如果你总是做一直在做的事情，你将永远只能得到你已经得到的东西”。

学会以结构化和有效的方式应用我们的观察和反思是另一个挑战，这个时候应用系统思维是至关重要的。我们应该把重点放在对我们造成的阻碍最多的问题上，单独处理它们，然后重复这个过程。

试图修复太多问题或者每次只关注一个主题，可能会导致混淆，特别是如果你正在评估变化所带来的影响。如果你同时改变了几件事，那么就很难知道是哪一件造成了影响。

这三个思维过程是重叠的，它们交织在一起并且往往相互依赖，当它们结合在一起时会变得非常强大，我们因此能够更好地交付软件并帮助其他人也做到。

关于作者

John Yorke 是 WWT Asynchrony Labs 的敏捷教练，他在 Asynchrony 负责 Product Owner Chapter，并在圣路易斯组织 Product Ownership Meetup。John 拥有超过 20 年的软件交付经验，他的角色是开发人员、设计师、项目经理和部门负责人。现在，作为一名教练，他为客户提供敏捷转型方面的支持，并在企业内部指导交付团队。他还是敏捷相关主题的作家和演讲者。

查看英文原文： Agile: Reflective Practice and Application