sys

前言 业务敏捷可以定义为一个组织重塑自我并快速适应环境变化的能力。克劳斯.利奥波德在他的书《Rethinking Agile》中提出，人们需要优化交付客户价值的流来实现业务敏捷。通过优化流，你迟早会注意到需要组织结构做什么样的调整来加以支持。 首先，关键是理解敏捷的真正含义，就像敏捷宣言中构想的那样，它并不是组织交付客户价值的速度，而是组织以低成本快速响应变更的适应性。（参阅《Scaling Lean & Agile Development》中 _Be Agile一章）。利奥波德对于组织变革还有这样一个观点：在持续地关注系统优化目标时，人们会注意到那些阻碍改进的因素。然而通过系统思考，长时间在实地的观察和实践，对现存系统动态的反思，人们也可以预见到那些阻碍快速适应能力的相对明显的现存组织障碍。在这个故事中，一个组织学习并最终看到影响大规模适应性的组织障碍，它经历了漫长而痛苦的过程。更糟糕的是，很多管理层试图保持传统管理现状而仅仅将事物标记为”敏捷”，而不是去预见 - 或者愿意去预见 - 相对明显的障碍并在一开始就进行必要的变革。简而言之，这个过程恰恰反证了LeSS中的关键导入原则（“对于产品团队，要在一开始就建立LeSS的组织架构，这对导入LeSS非常关键”_）以及由此带来的后果。 所以，接下来的案例说明了，如果组织没有在一开始进行合适的组织设计，会发生什么情况。从开始的传统组织架构和管理方式入手，可能混有一点伪Scrum元素，LeSS要求的组织设计_也许_会浮现。但这将会是一个更长、更危险的旅程，因为它可能不会带来导入LeSS所预想的好处。为什么？因为一旦没有立即采用新的组织架构，那股保持组织现状的强大力量极有可能会获胜（参阅拉曼组织行为定律）。 本案例的关键”反事实”洞察：如果你想开始业务敏捷的旅程，期望减少过程中的许多痛苦，并快速获得LeSS所预期带来的适应性上的提升，一定要在导入LeSS的开始阶段就建立合适的组织结构，就象LeSS规则所倡导的那样。 开始之前的评注 LeSS就是（多团队的）Scrum，Scrum就是单一团队的LeSS。（参阅原则：大规模Scrum也是Scrum）。为了让本案例中的描述更加准确，我还是会澄清哪些是Scrum指南中的规则，哪些是LeSS指导方略中的规则。在参与这个案例的过程中，我受到less.works网站的积极影响，参加了Bas Vodde和Craig Larman的LeSS实践者课程，并花费了大量时间阅读最初出版的两本LeSS书籍。可惜的是那时第三本书还没有出版。在这个案例中，我阐述了我们尝试过的LeSS实验，并且也会关联我们遵循的LeSS原则、规则和指南，尽管那时并不知晓。 简介 下面的案例涵盖了我从2015年2月到2016年9月在一家公司Sys的IT组织做外部教练的时光。Sys是一家来自德国的从事软件行业的跨国公司。因为我已签署保密协议，所以不能在此公布公司的真名和其他相关的公司信息。时间回到2014年底，Sys着手用一个平台来变革公司软件销售方式，取代现有各种外部合作伙伴平台。这个平台的诞生标志着Sys迈入电子商务新途径的里程碑，不仅重新思考了如何直接地向客户销售软件，还重新定义了卖什么（例如，除软件以外的数据）和怎么收费。 这背后的想法是创建一个网上商城，客户可以通过最小的交互，从Sys或是其他第三方软件发现、尝试和购买软件、内容和数据。目标是通过电子商务产品”SAP Hybris Commerce”来提供像亚马逊一样的简单流程，同时涵盖多样的产品部署（就地部署和云解决方案），支持不同的支付方式（信用卡和PayPal）。 2011年，我曾在负责所有内外部平台的Sys IT部门工作过，这些平台跟Sys商店很像，那时我们整个部门开始将瀑布模式替换成Scrum。在用（单团队）Scrum的方式搭建了两个平台之后，我离开了这家公司，去支援其他客户的敏捷之旅；在2015年的早期，我又重新加入Sys来支持这次重要的旅程。 变革之前 系统架构 在我加入的时候，有四个团队并行工作，研发新功能或者增强现有平台，并用固定的时间表合并代码，然后进行好几周的集成测试和验收测试。系统格局是一个复杂的三层结构，包含基于Spring框架的主要J2EE应用程序平台SAP Hybris Commerce，用于存储数据的SAP Hana 数据库，基于SAP PI服务器与SAP ERP和SAP CRM的同步，还有额外的第三方服务用作分析、处理信用卡支付或用户生成内容的集成。 变革之前的组织结构 图3是组织结构。有三个开发团队，两个在欧洲一个在美国，并行工作在系统的不同部分。还有一个架构团队，负责新特性的软件整体设计，以及一个测试团队，在不同团队的代码合并之后进行集成测试。此外，另有一些后台开发（SAP ERP/CRM）专家、DevOps专员和UI专家，他们没有加入任何研发团队，而是建立了自己的团队。欧洲的团队成员（随机地）分布在德国、波兰、西班牙、爱尔兰和保加利亚。这是因为Sys只有六名公司正式员工，其他所有团队成员均来自于专门从事SAP Hybris研发的第三方供应商。 除了技术团队，还有一个超大的业务组织来支持软件的研发和运营。在第一层，经理们带领一个小团队来进行特性的优先级排序、编写蓝图、执行用户验收测试并启用功能。在第二层，又有一个团队专门负责整个产品组合、需求排序以及业务方用户验收。在第三层，是由三个项目集经理组成的项目集管理，一个来自业务（Sys Digital），一个来自Sys IT，还有一个来自Sys Education的项目总负责人。另外，还有一个支持项目集管理的项目和质量管理办公室。为了跟踪研发和业务的进度，每周还有工作流周会，干系人状态周报，以及从项目办公室汇集到管理团队的书面项目集更新。 痛苦的最后期限和变革的必要 当我在2015年2月底加入时，平台基本上已经可以使用，只差正式宣布。各团队还在冲刺最终官方发布日期：2015年5月5日。到时候公司会在美国举行有史以来最大的会议，首席数字官会当场向公众演示这个平台。所有正在研发的功能都是官方需要发布的功能，所以，项目办公室制定了一个看起来能在5月2号发布所有功能的严格的项目计划。该计划包含了研发阶段、系统集成阶段，用户验收测试以及回归测试，就像我们通常说的瀑布模式。 在三月的最后两周和整个四月项目进入一个动荡期。时间表正渐渐延期。当并行工作在不同功能的团队将他们的代码合并到主代码仓库后，很多之前已经测试通过的功能不再能使用或者表现异常。不停修复这些问题又带来新的问题，并且还经常突然接到必须立刻实现的新需求。在此之上，之前从未考虑过的安全问题和负载测试现在也必须解决。管理层变得十分焦虑，每个人不得不工作更长的时间来尽量满足计划。在四月的最后两周，还建立了一个”作战室”，所有的经理、团队负责人和架构师都在这个房间从早到晚不停的清理障碍以保证发布的所有准备工作都做好。最后，开完数不清的升级会议和成百上千小时的加班之后，团队终于能够在大会的第一天发布平台的新版本。 经过了如此痛苦的发布，对管理层来说，毫无疑问现有的研发方式已经不能支撑公司的雄伟目标，那就是销售指数级增长，能快速尝试新的商业模式和推出完全不同的产品。Scrum作为一个敏捷研发框架，专注于首先交付最高业务价值，持续关注透明性、检视和调整，这些都建立在基于经验过程控制的理论之上，它成了一个自然而然的选择。然而要导入Scrum或者LeSS都被认为极其困难，不仅仅是因为组织层级设置和对分散在不同地方的各种技术专家的依赖，还受到巨大营销渠道的影响，即每年有两次不可更改的作为大里程碑的重要峰会。 引入变革 作为一个偏好大规模Scrum的经验丰富的敏捷和Scrum教练，我被要求建议”研发部门”应该如何改变工作方式以应对当前的挑战。 我的挑战因此是（1）让所有人都意识到为了应对挑战_不只是研发部门而是整个组织要改变_；（2）帮助参与者_通过理解为什么_来拥有变革背后的想法，而不只是跟随我的想法遵循我的建议而已。 在一次上层管理者（包含Sys首席数字官）的会议中，我展示了从和业务和研发代表的对话中收集到的关于挑战的总结。它包括： 业务挑战（摘录） 单个特性和产品能力的优先级不明确 _明确标注_已完成的工作在后期出现问题 技术挑战（摘录） 可用性和基础设施问题（性能，端口关闭等）妨碍了日常运行 整个部署流程耗时太长。常常缺少某些部分（模版，后处理等） “架构师”们忙于做构建流程、合并代码、以及基础设施的建立/配置这样的手动任务 使用各种分支而不是基于主干的开发，导致代码合并的工作量巨大；并且质量很低，有许多缺陷/问题 测试数据的的创建是一个非常耗时的过程并深受知识缺口的影响 在准备这个会议的过程中，我还收集了管理层的整体改革目标。基于与管理团队成员一对一谈话和访问，我总结了如下几点：