Scott Staples 是 Mindtree 公司(一家全球 IT 服务公司)的联合创始人兼总裁。Staples 读了“敏捷已死”的头条新闻之后,解释了为什么他认为敏捷开发实践仍然活着并活得很好,为什么“敏捷”不应该是一个目标而是组织应关注于结果,为什么许多组织仍在与敏捷的落地做斗争,以及敏捷以后是什么。
为什么组织应该关心敏捷?它不是已经过时了吗?
在提到敏捷的大多数时候人们会想起 Scrum。Scrum 相对简单,在很多方面帮助企业提高其整体的应用开发。然而,仅仅有日常站会和两周的 sprint 并不是真正的敏捷。这些给了企业一些短期的收益,并且 IT 团队可以告诉 CXO 们他们正在做敏捷,这是一种虚假的成就感。采用敏捷和获得持续交付必杀技的真正挑战是文化变革。敏捷的问题在于,很多人相信他们无需改变那些在过去让他们慢下来的基础组织结构,也可以获得令人难以置信的生产率的增长。我们实际上应该收回“敏捷”一词,而真正只关注结果。组织寻找的是可以增加市场份额和降低成本的方式。要做到这一点,需要“组织的敏捷性”,而不是敏捷软件开发。所以,真正的问题是如何用敏捷的概念帮助组织转型。
为什么这么多的敏捷实施并不成功?
敏捷不是魔术。很多人都觉得如果他们说“敏捷”这个词够多,那么神奇的事情就会发生。现实情况是,在敏捷方面胜出的企业通常在第一天就开始采用敏捷了。他们构建了持续改进的文化,使得业务和 IT 一开始就有共同的上下文和目标。他们创造了非常扁平化的组织结构和促进协作、创新和赋权的文化。敏捷文化也是接受失败的文化,但要确保你快速失败并继续前进。许多公司都在与接受失败的思想作斗争,但你必须失败才能持续的改进。这意味着需要进行大量行政人员的培训和参与,因为如果它只由 IT 和中层管理推动,敏捷将无法正常工作。
那么组织应该如何实施敏捷呢?还是应该有一个不同的目标?
让我先从“为什么”开始。是什么使得一个组织转型到敏捷紧急迫切?请注意,我们谈论的是“组织”,而不是 IT 或 OPS …它必须是整个组织。 “为什么”的原因成为召集的最后一搏和组织信标。它可能是因为要更快地进入市场、也可能是企业生存、在代码和产品上有更好的质量、降低的成本等等。所有这些因素都可以通过实现敏捷和精益实践得到改善。有企业因为这是个热门话题在试图变得更加敏捷吗?或者他们在试图变得更加以客户为中心、更灵活、快速和敏捷?敏捷不仅仅只是关于 IT。一旦你确定了“为什么”,那么重点就应该放在组织变革上。这将需要一段旅程的规划,它会需要花费几年的时间,而不是几个月。计划和沟通是必不可少的。如果 CxO 组织在敏捷和精益建构上不够流畅,实施将会受到挑战。这是一场组织变革的投入,而不是一种软件开发的新方法。
现今已经有很多适应不同规模的敏捷模型了。那么如果一个公司简单的采用其中的一个模型,遵循它的规则就可以理所当然的成功吗?
不可能。它不是那么简单。遵循一个敏捷框架的规则不会造成持久的变化。它可能改善一个或两个项目,但在大多数情况下,它将分离团队并产生额外的官僚主义和政治,这会使组织动摇。再说一遍,文化是关键。对个人而言,你需要强调并专注于为什么这对他们有好处,给他们工具和培训帮助他们成功。从组织的角度,你需要敏捷信徒、布道人和教练。最后,环境需要改变。对于坐在一个个独立隔断里的团队,或者业务人员和 IT 人员坐在不同楼层,甚至在不同建筑物里(就如我们常见的)的组织而言,协作、想法和创新是很难达到的。企业需要打破传统的孤岛,并去除官僚主义和等级。这将使他们走在不断改进和持续交付的道路上,是否选择了 SAFe、DAD、LeSS 或者 Nexus 作为自己的框架并不关键。
什么是超越敏捷?
简单的回答是…更敏捷。正如前面提到的,敏捷是一段旅程而不是终点。对绝大多数公司来说,他们才刚刚开始。这段旅程仍然需要帮助企业获得持续交付(DevOps)的能力,去除作为单独职能部门的测试,而将测试融入团队,打造全栈的工程师,并推动文化变革。虽然敏捷已经存在了很长一段时间,我们其实仍在敏捷实施的最早期。这将是一段奇妙的旅程,一个将永远改变软件开发的旅程,而它也将改变企业的运营,以及 IT 和业务将来如何协同的工作。能够见证这段旅程真是太好了,而 Mindtree 也将在其中一起见证。
查看英文原文: Scott Staples on Why Agile is Still Relevant
感谢张龙对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论