Scott Staples：敏捷开发实践仍然活着并活得很好

　　 Scott Staples 是 Mindtree 公司（一家全球IT服务公司）的联合创始人兼总裁。Staples读了“敏捷已死”的头条新闻之后，解释了为什么他认为敏捷开发实践仍然活着并活得很好，为什么“敏捷”不应该是一个目标而是组织应关注于结果，为什么许多组织仍在与敏捷的落地做斗争，以及敏捷以后是什么。

　　为什么组织应该关心敏捷？它不是已经过时了吗？

　　在提到敏捷的大多数时候人们会想起Scrum。Scrum相对简单，在很多方面帮助企业提高其整体的应用开发。然而，仅仅有日常站会和两周的sprint并不是真正的敏捷。这些给了企业一些短期的收益，并且IT团队可以告诉CXO们他们正在做敏捷，这是一种虚假的成就感。采用敏捷和获得持续交付必杀技的真正挑战是文化变革。敏捷的问题在于，很多人相信他们无需改变那些在过去让他们慢下来的基础组织结构，也可以获得令人难以置信的生产率的增长。我们实际上应该收回“敏捷”一词，而真正只关注结果。组织寻找的是可以增加市场份额和降低成本的方式。要做到这一点，需要“组织的敏捷性”，而不是敏捷软件开发。所以，真正的问题是如何用敏捷的概念帮助组织转型。

　　为什么这么多的敏捷实施并不成功？

　　敏捷不是魔术。很多人都觉得如果他们说“敏捷”这个词够多，那么神奇的事情就会发生。现实情况是，在敏捷方面胜出的企业通常在第一天就开始采用敏捷了。他们构建了持续改进的文化，使得业务和IT一开始就有共同的上下文和目标。他们创造了非常扁平化的组织结构和促进协作、创新和赋权的文化。敏捷文化也是接受失败的文化，但要确保你快速失败并继续前进。许多公司都在与接受失败的思想作斗争，但你必须失败才能持续的改进。这意味着需要进行大量行政人员的培训和参与，因为如果它只由IT和中层管理推动，敏捷将无法正常工作。

　　那么组织应该如何实施敏捷呢？还是应该有一个不同的目标？

　　让我先从“为什么”开始。是什么使得一个组织转型到敏捷紧急迫切？请注意，我们谈论的是“组织”，而不是IT或OPS ......它必须是整个组织。 “为什么”的原因成为召集的最后一搏和组织信标。它可能是因为要更快地进入市场、也可能是企业生存、在代码和产品上有更好的质量、降低的成本等等。所有这些因素都可以通过实现敏捷和精益实践得到改善。有企业因为这是个热门话题在试图变得更加敏捷吗？或者他们在试图变得更加以客户为中心、更灵活、快速和敏捷？敏捷不仅仅只是关于IT。一旦你确定了“为什么”，那么重点就应该放在组织变革上。这将需要一段旅程的规划，它会需要花费几年的时间，而不是几个月。计划和沟通是必不可少的。如果CxO组织在敏捷和精益建构上不够流畅，实施将会受到挑战。这是一场组织变革的投入，而不是一种软件开发的新方法。

　　现今已经有很多适应不同规模的敏捷模型了。那么如果一个公司简单的采用其中的一个模型，遵循它的规则就可以理所当然的成功吗？

　　不可能。它不是那么简单。遵循一个敏捷框架的规则不会造成持久的变化。它可能改善一个或两个项目，但在大多数情况下，它将分离团队并产生额外的官僚主义和政治，这会使组织动摇。再说一遍，文化是关键。对个人而言，你需要强调并专注于为什么这对他们有好处，给他们工具和培训帮助他们成功。从组织的角度，你需要敏捷信徒、布道人和教练。最后，环境需要改变。对于坐在一个个独立隔断里的团队，或者业务人员和IT人员坐在不同楼层，甚至在不同建筑物里（就如我们常见的）的组织而言，协作、想法和创新是很难达到的。企业需要打破传统的孤岛，并去除官僚主义和等级。这将使他们走在不断改进和持续交付的道路上，是否选择了SAFe、DAD、LeSS或者Nexus作为自己的框架并不关键。

　　什么是超越敏捷？

　　简单的回答是......更敏捷。正如前面提到的，敏捷是一段旅程而不是终点。对绝大多数公司来说，他们才刚刚开始。这段旅程仍然需要帮助企业获得持续交付（DevOps）的能力，去除作为单独职能部门的测试，而将测试融入团队，打造全栈的工程师，并推动文化变革。虽然敏捷已经存在了很长一段时间，我们其实仍在敏捷实施的最早期。这将是一段奇妙的旅程，一个将永远改变软件开发的旅程，而它也将改变企业的运营，以及IT和业务将来如何协同的工作。能够见证这段旅程真是太好了，而Mindtree也将在其中一起见证。

 

 

返回网站首页>>