转载

克服范式，达成真正的敏捷

Arie van Bennekum提出；“你需要真正的敏捷，为转变为此你需要克服范式”。van Bennekum是敏捷软件开发宣言的作者之一、Van Wemanity集团的思想领袖。他在 Spark the Change伦敦2016大会的报告中，将敏捷开发比作为新陈代谢。

Van Bennekum指出为取得成功，需“达成敏捷”而非“去做敏捷”。克服范式是十分必要的；为了达成敏捷，人们需要正确的心态。敏捷是一种基于敏捷软件开发宣言的、在价值和原则上的互动理念。Van Bennekum声称：“技术促进了敏捷起作用，但是工具并不能使你达成敏捷。”，敏捷并非是仅去实现一件事情，而是一种增进企业适应性的变革。

一些人也分享了他们关于转变为和达成敏捷的观点。Vijaya Devi在她的一篇关于企业采纳敏捷开发方法的文章中写道：

关于敏捷的神话之一是，人们和企业倾向于相信通过对诸如日常Scrum、Sprint周期及回顾会等一系列活动的实践，他们就能达成敏捷。恰恰相反，想达成真正的敏捷的公司需要转变它们的心态。

在十种敏捷失败之路一文中，Oren Kdoshim和Ilan KirschenbaumIn对如何达成敏捷给出了他们的解释：

达成敏捷是一个困难的事情。这需要面对很多挑战，这里给出其中的几个，包括：需要持续地实践、打破旧的习惯，以及采用新的心态等。在企业中这意味着对企业文化进行调整，需要投入大量的精力。

在与Mario E. Moreira的访谈一文中，InfoQ就达成敏捷的商业利益所在咨询了Mario E. Moreira：

达成敏捷的首要商业利益在于，你开始真正地理解客户价值是什么样的。你将变得高度关注和理解何事对客户具有价值，并用更小的软件增量改进去构建、验证和改进产品，这样你所交付的产品将恰好看齐于客户的价值所在。如果你做到了如此（将你构建的软件产品与客户认为其价值所在恰好看齐），企业最终将可挣更多的钱。这可能就是敏捷所不为人知的小秘密。

在 InfoQ对Belinda Waldock《在商业中达成敏捷》一书的访谈中，Belinda Waldock阐述了达成敏捷是如何有助于人们预见改变并在未知中正确前行的：

敏捷有助于我们看清工作和环境中的趋势及模式，这样我们可开始了解项目的节奏和流程，并能以预测未来可能会发生什么。使用敏捷有助于团队内的交流和对信息及洞察力的分析，并且许多伴随着变化和不确定性而来的痛苦都可被使用敏捷的团队所处理。总存在一些我们所不能预测的事情，但是通过使用敏捷，我们能放缓软件构建过程以规划这些不确定性。

InfoQ就此访谈了Arie van Bennekum，所涉及的话题包括：其在软件产业内所见到的关乎敏捷的主要变化，为什么人们感到难以接受范式的偏移，敏捷价值和原则的成功实例及服务型领导的采纳，如何增进公司范围内的合作，公司培育敏捷心态的做法等。

InfoQ：你是敏捷软件开发宣言的签署者之一。在软件产业中你看到了哪些与敏捷相关的主要变化？

Arie van Bennekum：首先，行业内涌现了对承担职责的渴求。现在无论我走到那里，每个企业都至少在某些地方上具有达成敏捷的积极性。我们都了解重大的事件，但却常常不记得引发这些事件的火花。这些火花通常是由项目执行层面的人所引发。看到团队中更多的人逐渐地渴求去承担职责，这是很棒的事情。

其次，当前具有一个普遍共识，就是我们需要更短时间去走向市场。越来越多的企业转向更短的交付周期。虽然在我们撰写敏捷软件开发宣言之前，我们中的大多数人就试图去解决这个问题，但不幸的是时间和预算依然超支。不过认识到了该问题这也是向正确方向前进的一步。

InfoQ：为什么当人们工作于团队中或者是在管理团队时，感到难以去接受范式的偏移？

Van Bennekum：说实话，我并非一个治疗师，但你也能对模式进行观察。我们太长时间地处于独立的筒仓式工作的状态。有趣的是在足球赛中，我们都能看见每个人都多元化的，他们可互相配合，为共同的团队目标而努力。

当我们工作时，我们却躲进了筒仓。就我所见而言这种筒仓是由传统的管理方式所导致的。这种管理出现于一个世纪以前，基于经理在项目中知晓并决定一切的观点。筒仓是安全的（清晰地给出了你必须要做的工作），可为你给出工作的状态，对工作中是否进入或离开筒仓具有清晰的处理方式（纸面材料和签名）。

团队工作，就是我们作为一个团队而工作，具有一套事情去做，服务于一个共享的目标，并在其中现场决定团队中谁应承担承担什么的工作，这对我们而言已不仅仅是一种工作方式。我们市场尝试去走出筒仓并如上去开展工作，但一旦有事情出错，作为标准的条件反射而言我们将会重新躲回我们的筒仓中、恢复到旧的模式、文档、工作交接等。这就是为什么我使用“新陈代谢”一词的原因……

InfoQ：在此你能给出在公司中成功实现了敏捷价值和原则的一个例子吗？为此他们采取了怎样的做法？

Van Bennekum：我能给出一些例子，但是我并不确认这些公司是否愿意公开它们，所以在这里我并不会给出具体的公司名称。我将给出在各类的公司中使用敏捷转换的三个实例来解释这个问题，这三个实例分别发生在一个大型的零售商、一个中等规模的能源提供商和一个大型的技术企业中。

克服范式是十分重要的。这包括管理范式、开发范式、职责中的范式等。为做到这一点，你需要使以下三件事情到位。

首先，垂直提交对于敏捷工作而言是十分重要的。诸如透明度、固有规程、可视化、优先次序等方面不仅需要管理层的支持；也必须由管理层将这些方面进行角色模型化。尤其是经历了旧有的层次型文化，人们倾向于去拷贝管理行为。这也是为什么当我们在敏捷转化中对团队和个人进行指导时，我们（当然是与其它活动组合在一起）必须在各个层级对管理付出特别的关注。

其次是环境的安全性；人们只有在感觉足够安全时，才敢于尝试错误。学习意味着去尝试、开发、犯错误等，并且做这些需要假以时日。对此人们的标准条件反射是掉回到旧的模式中去。当你没有时间去犯错误并且管理层也不支持时，人们将遵循上述的条件反射行为，这使得改变成为不可能。

第三，除非企业深陷危机，否则我们在事实上更乐于去依照企业原有方式而工作。我们让人员处于自身的安全环境中，并在开发的浪潮中启动改变。其中的经验教训，尤其是关于如何进行改变的，就是如果仅将改变推动到团队中，企业是不会真正使其持续下去的。

InfoQ：是什么使得采用服务型管理取得成功？

Van Bennekum：证据……管理者们需要证据（绝大部分时间下）。包括：案例研究，参考资料，参观访问相似的处理领域，尤其是针对有助于克服类似于“非我所创”和“好主意但是不适用于我们”之类的事情。顺便说一下，这不仅仅是针对管理者的。很多人都需要其各自的专业领域内的证据，即使如此你还将会听到不少由“虽然如此但是”所引出的说法。

InfoQ：打破企业各部门间的隔离墙是一项十分具有挑战性的工作。你对完成这个目标以增进企业范围内的合作有什么好的见解吗？

Van Bennekum：心跳是十分必要的。所有的利益相关者需要参与进来，他们是在传统开发过程序列（无论你开发什么产品）中具有话语权的人。结合我对上一个问题的回答，我可对这个问题的做如下的解答。

正如上面所说的，我们将保持公司的原样。我们改变了项目或其他开发类型中的交流方式。我们将除去序列，并与所有利益相关者一起在多元化团队工作。这些利益相关者依旧在相关部门中任职，但在团队中，他们已授权在必要时可在他们各自的领域中进行决策、接纳或改变。这样考虑到了开发人员以及架构师、法务部、企业营销传播，只要他们是开发过程中任何过程的利益相关者。

心跳就是将所有团队中所有授权为利益相关者的人聚集在一起的时刻（这样他们可从源头得到信息）。从我们建立产品待做事项及设计原则的早期时刻，一直到最终产品的交付，这些心跳(最好每个星期一次）就是我们取得成功的要素。