sita

边境安检系统：LeSS与离岸开发 背景 背景与客户 SITA创建的产品可帮助全球各地政府确保边境安全。我们正在创建的产品是用于自动化边境的解决方案，以在不影响安全性的前提下优化前往各个国家旅行者的流程。该产品是这样构建的，获取前往相应国家的所有旅行者数据，根据可用的监视列表对每个旅行者进行筛选，并针对被政府机构（例如，警察、移民等等）用系统标记的旅行者采取并记录必要的行动。 原文链接 开始 2010年SITA赢得了一项为期18个月的大合同，以创建和实施边境安全系统。该系统包括高度安全的数据中心和部署在该国所有口岸的软件解决方案。 Frank West（产品交付总监）聘请我为内部顾问，来帮助他们采用敏捷的工作方式。 双方之间的合同是构建整个系统（产品和数据中心），并在18个月后以一次性的方式进行部署。但是软件开发总监对这种方法感到不安，因为过去他多次在一次性交付中吃过亏。这次的情况尤其如此，因为该系统非常复杂并且由许多未知数组成。因此，他想（再次）探索敏捷的工作方式，并雇用我来帮助他以迭代、增量和自适应的方式交付该系统。 我加入时，SITA的组织结构非常等级化，划分成独立的职能部门。看起来像这样： 业务团队存在类似的结构，主要由项目经理、销售顾问和业务解决方案架构师（主题专家SME）组成。 向Scrum过渡（但不是LeSS） 我们从为期三天的研讨会开始，了解敏捷宣言、敏捷原则及Scrum。从正确的教育入手至关重要。我们想确保建立一个长期的学习型组织，因此我们将重点放在激发与提供适当的教育方面，以实现更多的协作、迭代和增量式的工作方式。我提供了Scrum概述的培训，然后我们讨论了如何组建开发团队。在与开发团队和管理层进行了大量讨论之后，我们提出了如下的团队结构： 对我们而言，从一开始就建立适当的结构非常重要，以确保我们创建真正的团队，同时牢记“文化遵循结构”，这是“拉曼的组织行为法则”的第五条的一部分，因此我们首先创建了两个跨职能的Scrum团队。这些团队由SME、BA、开发人员、测试人员和架构师组成。尽管我们的确是由一组专家组成的团队，但每个团队成员只有一个头衔即“开发人员”。对团队的承诺和期望是他们将不再担任专家，整个团队将朝着Sprint目标努力，并选择实现Sprint目标所需的下一个任务。 我们的主题专家（SME）人才是边境控制流程和航空业的高技能领域专家。 我与弗兰克（Frank）讨论过，我们不需要项目经理，但他还是坚持要求保留两个人（项目经理和解决方案架构师）来管理公司报告和一些售前活动。他们俩都对要出售给客户的产品有很好的领域知识。 弗兰克（Frank）明白，将来我们不再需要这两个“角色”，但是他建议保留这两个人的角色，在目前将有助于我们跟销售团队就一直在开发的产品保持同步，以便让他们不要将其作为单独的“项目”出售。弗兰克要求他们两个都与销售团队工作，并且他们也定期与产品负责人工作，以了解我们产品的进度，以便他们可以相应地为我们的潜在客户提供建议。 我们继承了组件团队 从总体上讲，整个解决方案是从航空公司收集每位乘客的数据，并根据观察列表对每位乘客进行筛选，以了解是否有不受欢迎的人试图访问该国。该解决方案主要分为两大部分：数据获取系统（DAS）和风险评估系统（RAS）。所以团队也是按这一结构来创建。Black团队（每个团队用颜色来命名）负责获取数据，Green、Blue和Purple团队负责风险评估（译者注：与作者确认最开始只有Green团队）。因此我们从组件团队开始，当时看起来很“合乎逻辑”。 从组件团队到特性团队 最终，我们意识到组件团队在团队之间引入了许多不必要的依赖与移交，这导致了迟来且昂贵的反馈，在整体回顾中我们也讨论了这些反馈。使用这些反馈，我们开启了以避免不必要的依赖的从组件团队转向特性团队的对话。在对话期间我们还意识到，如果我们不尽快转向特性团队（跨团队管理依赖关系将是一场噩梦），将来很难有效地添加更多团队，因此我们开始讨论创建特性团队的方法。 在对话期间，团队还提出了组建特性团队的如下问题： 并非每个团队都有实现下一个优先级条目所需的技能和知识 跨不同架构组件的特性实现的设计可能会变得混乱 特性团队可能会卡在设计决策上 所有这些都是重要点，因此我们决定从一个特性团队开始（“*指南：过渡到特性团队*”），而不是大张旗鼓。我们创建了一个特性团队，并要求他们端到端地交付特性。我们遵循XP（极限编程）的建议，为每个组件引入了“组件牧羊人（Component Shepherd）”作为导师，以避免最初出现任何技术故障。 “组件牧羊人”的主要作用是指导特性团队改动相应的组件，并在团队进行改动时提供利弊对比。所有牧羊人都更像旅行者（“*指南：旅行者*”）那样工作，因此他们大部分时间都可以自由地辅导和指导多个团队。团队逐渐地（9-12个月）积累了多个组件的知识，从而很少再需要“组件牧羊人”的指导。 过渡到LeSS Scrum的实施对我们最初的两个团队工作良好。我们提供的最初产品收到了客户的良好反馈，从而引起了其他潜在客户的极大兴趣。我们的潜在客户喜欢我们交付的特性，但他们也希望产品中有许多新功能。一旦有更多的客户注册了我们的产品，我们就决定增加更多的团队。 我们没有多团队合作的经验，因此开始探索可用于帮助我们的资源。我们发现了两本书，分别是Craig Larman和Bas Vodde撰写的《*精益和敏捷开发大型应用指南*》和《*精益和敏捷开发大型应用实战*》。对于我们的案例，它们看起来像是完美的指南，尤其是关于大规模Scrum框架2（现为巨型LeSS）的概念，因为我们预计将来会增长到大约20至30个团队。 这些书籍在提供有关规模化（以及由此对组织提出的挑战）的准则方面如此丰富（现在仍然如此），以至于它成为我们在整个过程中进行规模化的指导力量。我们开始定期探索这些书中的想法，并进行了一本书中的许多“*尝试和避免……*”的实验。 多地点的离岸开发 尽管我们强烈推荐在同一地点办公，但我们在当前办公室的物理空间仍然受到一些组织上的严格限制，并且需要与位于不同时区的客户进行互动。当我们要求管理层（执行委员会）提供额外预算（主要是更多的团队）时，他们要求我们与位于印度和基辅的现有离岸合作伙伴进行合作，以确保我们在多个时区都有团队存在（主要是中东和澳大利亚）来吸引和支持我们的新客户。 我们接受了挑战，但有一个条件，即一旦选择供应商，我们将像在英国一样进行面试和组建团队，而不是接受下一个可用人员或团队的典型离岸模式（“*避免……外包商说，交给我们吧，我们为您做到敏捷*”）。我们还决定在每个地点都有一些位于同一地点的团队（“*指南：在LeSS中组织多地点办公*”），以确保团队之间能够相互学习，这只有在同一地点的团队中才有可能。我们还将把离岸团队带到英国至少进行4次Sprint（“*尝试……离岸之前先在一起进行几次迭代*”）。 我们以为在管理方面会遇到困难（基于过去的类似经验），但是令我们惊讶的是，在开始离岸供应商选择流程之前，我们的管理层和离岸合作伙伴都毫不费力地达成了一致。我认为他们了解过去离岸团队的加入一直很痛苦。但是当他们意识到我们一直在以新的工作方式交付成果时，他们允许我们尝试与离岸团队合作的方式。 我们办公室内的多地办公体验 我们与团队讨论了多地办公的试验，并确保不会对他们的工作产生任何影响。因为他们也知道我们需要更多的团队，并且对物理地点有很大的限制。尽管大多数人都有多地办公的经验，但这不是我们最近的（检视和调整）工作方式。在对话中，一名团队成员问，在敏捷环境中与多地的团队合作感觉如何？由于我们都没有与多地敏捷团队合作的想法，因此团队中的一位成员给了我们一个想法，即我们在其它地点加入新团队之前，先要经历多地环境的挑战。她建议“为什么不将现有的一个团队搬到另一楼层，而仅使用电话或Skype与另一团队进行沟通，即 没有面对面的交流，看看这带来了什么挑战。我们非常喜欢这个想法，它与书中的一项实验一致（“*尝试……即使位置靠近也按多地思考*”） 一个团队在下一个Sprint搬到的另一楼层（幸运的是，我们在那层上有一个可以容纳团队的空间，但只能用2周）。很快，我们可以看到，即使他们位于同一栋大楼且只有一层之隔，团队也意识到了多地办公向他们施加的挑战。尽管他们已经合作了很长时间，但是无法看到他们，只能通过电话、电子邮件和Skype进行交流，他们还是因此失去了紧密的物理协作（例如白板会议）。 这是一个很好的实验，可以为即将到来的“离岸团队”建立“现场”团队的同理心（这就是他们一开始的看法）。 离岸合作伙伴的选择 我们访问了三个地点（印度两个，基辅一个），并受到了所有人的热烈欢迎。 这些人都从大量的Powerpoint演示开始，介绍了他们的“敏捷”能力和已交付的“敏捷项目”的经验。 很快就很明显，他们对敏捷工作方式的大多数理解都是“错误的”。一次又一次的演讲，很明显这些团体要么是在大肆宣传，要么是对他们所说的“敏捷”一无所知。我们认为他们在“创建Powerpoint幻灯片”方面要熟练得多，但通过交付迭代和增量的软件来交付持续的价值呢？不见得行。 我们想知道为什么他们对敏捷的工作方式没有这么了解。毕竟，这些公司可以访问所有内容（培训、书籍、聘请顾问和教练等以帮助他们）。我真诚地问了他们的一位经理，以便从他们的角度来理解这个问题。他的回答非常有趣且提供了有用的信息，帮助我们了解了离岸IT公司的工作方式。总而言之，离岸公司不向客户提供咨询服务。他们的商业模式通常围绕以低廉的成本提供人员，并与客户期望他们工作的方式保持一致。因此，他们不会真正地投资任何新事物，直到成为主流，并且客户希望他们对新事物有所了解。 在拜访了所有离岸候选人之后，我们意识到这将是一个漫长、痛苦而又令人兴奋的旅程。因此基于跟他们的经历，我们建议仅从印度班加罗尔的那个团队开始。按照《精益和敏捷开发大型应用实战》（“*尝试……更少的地点*”）一书中的实验，我们不想从多个离岸合作伙伴的多个地点开始，以创建不必要的复杂性。 “商业部门”推动我们同时使用这三个地点。但是，当我们向他们解释了多个地点及多个合作伙伴的负面影响（沟通、协调失灵、语言和文化差异、与其中一个地点的签证问题等）之后，尤其是在敏捷开发环境中，我们被允许先选其中一家，但他们还是期望将来可以用所有的三个地点。 除了上述提到的多个离岸地点的负面影响之外，我们还希望保持组织的简单性，并继续我们*成为敏捷(be agile)*而不是*做敏捷(do agile)*的旅程。我们已经在Scrum和Extreme Programming工程实践方面有了一个良好的开端，我们希望增加更多的团队，但不增加任何不必要的协调、离岸管理等开销，以保持以客户为中心。基本上，我们希望通过消除客户和团队之间任何不必要的复杂性来简化组织，从而扩展产品的开发规模。在成功试验两个地点（英国和另一个地点）之前，我们致力于避免不必要的、人为的管理多个地点的复杂性。我们深知与离岸IT公司合作会带来不必要的开销，例如与项目经理、现场协调员、离岸项目经理、多个时区等打交道。 当我们自己试图简化组织设计保持以客户为中心时，我们理解了为什么“商业部门”会迫使我们选择这三个地点。高层迫使他们将新工作移至离岸地点以降低成本。他们表现得像一个会计师（还是一个很好的会计师），却不了解其行为的整体系统含义。简而言之，这是经典的*局部优化*。 我们部门的业绩在整个组织中引起了积极的反响。我们的成功故事（高质量的产品、满意的客户、提早交付和持续交付、更多的业务等等）也触及到产品开发外部的各种人员（例如HR、商务等），他们对我们不同的做法感到好奇。我们邀请商务部门的人员与我们的团队会面，以便向他们解释我们的工作方式。这与LeSS的采用规则有关：“*对于产品组以外的大型组织，请使用现场现地（Gemba）来采用LeSS演进，创建以实验和改进为准则的组织。*”。访问我们的时候，他们惊讶地看到我们在部门内创建的可视化效果。他们可以轻松地查看我们的产品待办事项列表（墙上的故事地图），每个团队的Sprint待办事项列表（白板上），构建的统计信息（构建状态，缺陷数量等），监视器等，以及在地板上合作（主要是人们一起工作的噪音）（译者注：在地板上合作指的是大家走来走去，面对面的沟通）尽管来自非技术部门，但他们的反应是您为什么不采用这种方式工作，这是如此明显。他们还真心想帮我们跟离岸供应商协商一个更低的价格，如果我们愿意直接与10多个团队工作的话。我们礼貌地拒绝了，并意识到我们还有很长的路要走，以使我们的组织精益化和系统化思考。他们显然看不到增加10多个团队相比于1个团队来说的系统影响。他们只是从自身降低成本这一局部优化目标来看，而没有意识到这样做可能是增加了总体成本。 我们与离岸合作伙伴约定的条件之一（在我们决定与他们合作之前）是我们寻找“长期合作伙伴关系”，而不是临时的项目方式（“尝试……将离岸组织视为内部合作伙伴 ”）。实际上，这意味着： 我们将采用相同的工作方式（如Scrum和XP中的工程实践）和 相同的团队组成（跨职能和自我管理）。 我们还提供了帮助，以Scrum、XP和精益思想为基础，让离岸管理人员理解和适应工作方式，这样做我们实质上是忽略了组织边界。我们说过，我们将在最初的3-6个月内提供一名教练，以帮助他们建立和完善对精益思维和敏捷工作方式的理解。这位敏捷教练的费用不需要他们承担，因为我们将这视为与他们建立长期可持续伙伴关系的投资。