本文要点
\
- 探究持续四年多的渐进式改革是什么样子；\t
- 探索为什么在变革软件和组织设计时要遵循康威定律；\t
- 看看如何将领导力应用到不同的团队、领域和层级；\t
- 举例说明变革管理如何依赖于理念和一贯的长远目标；\t
- 了解从职能型团队到跨职能团队的变革需要做多少工作以及能带来多少回报。
\
简介
\
过去几年，eSailors IT Solutions在技术和组织层面进行了重大变革：从功能筒仓到跨职能团队，从看似装配线的工作流到动态循环，从单体平台到微服务，从层次化的命令-控制到团队运作的领导力。本文将简要介绍他们的变革之旅。本文将带你了解大约四年之前我们从哪里开始，经历了哪三个主要的变革阶段才成为现在这个样子。对于每个阶段，本文都将概要地介绍以下几个方面的内容：
\
- 我们当时的组织设置；\t
- 主要的技术栈；\t
- 我们面临的最重要的挑战；\t
- 我们希望取得的变革成果以及我们实际取得的成果；\t
- 我们的经验教训以及它们如何推动了进一步的改进。
贯穿本文的一个重要主题是康威的假说“设计系统的组织……其产生的设计和架构等价于组织间的沟通结构。”1我们将把这一理论作为一面特殊的镜子，用它来照一照我们自己的历史。将组织设计和软件设计对照有什么意义们从对公司沟通模式的探究中学到了什么什么康威定律仍然在伤害着我们/p>\
我们从哪里开始
\
以前，在汉堡，对于那些只有75名工程师、全部员工大约只有120多人的小型软件公司而言，生活很简单。面对着大约300万的客户，我们的点子来自当事人、市场或法律部门。我们的平台平均要服务于大约35万活跃客户，每年2.5亿订单。工作流程是由项目经理组织的。知识被职能筒仓完全隔离：软件部门负责编写特性，质量保证部门负责保证质量，运维部门负责确保软件的稳定运行。如果我们需要修改任何基础设施组件（如增加新服务器、不同的操作系统程序包），一个隶属于其他部门（及国家）的团队就需要进行必要的安装准备。由于各种各样的预算、合作和/或沟通问题，这种方法经常导致严重的延期。
\
\
图2：eSailors最初的组织设置
\
为了变得更加敏捷，每个产品开发团队都竭尽全力。图3展示了我们的团队设置。在本图及后续出现的图片中，DEV表示开发人员，QA表示质量保证，PM表示项目经理。即使每个团队都有一名质量工程师，最终的质量检查和软件审批也还是由一个专门的质量部门所完成。团队的质量工程师必须以一种质量部门审批时能够执行的方式准备测试。
\
\
图4：第一步：新的团队设置
\
检讨我们的装配线问题，我们决定创建跨职能团队，由他们对整个系统开发的生命周期负全责。为了达到这个目标，我们从组织设置入手。我们解散了Bug修复团队，让特性团队为自己的错误负责。这也可以帮助他们更好地理解操作上的需求。我们认为，跨职能团队应该包含全栈职责，所以我们将原先共享的前端团队的成员分配到特性团队。同时，我们将冲刺周期改为两周，一周用来开发，一周用来测试。
\
我们希望从这些组织变革中得到什么呢根本上说，我们希望提高软件质量，缩短交付时间。我们实际上得到了什么呢了，我们的结果让人觉得有点矛盾。一方面，加大团队的自主权和责任感让人们更清楚问题所在。但是，所有团队都开始寻找可持续的解决方案，而不是修复问题。这种情况就是由图4所示的新的组织设置所导致的。
\
让开发团队负责Bug从许多方面改善了运维和开发部门之间的沟通。DevOps交流项目启动（开发人员在一个冲刺期间呆在Ops部门，反之亦然）。开发人员主动请求参与呼叫中心的工作及使用监控工具。组织文化日益趋向于端到端职责，这种变化越来越明显。开发人员、运维人员和基础设施人员开始定期讨论系统和管理问题。这是进一步改进的关键。简化后的装配线如图5所示。
\
\
图6：新的组织设置和工作流程
\
\
图8：现在的开发团队设置
\
我们还加大力度，使重要的信息尽可能地透明。可视化管理系统的问题变得愈加重要。产品经理引入了所谓的“墙”来展示有关当前业务选项和即将到来的变更的信息。图9展示了设在办公室中央开放空间里的这块板子的最新版本。通过这种方式，我们增加了业务流程的透明度，从通过评估和选择创建业务选项，到开发、验证和完成——这块看板增强了人们的求知欲，促进了沟通交流。
\
\
图10：2016年eSailors的组织方式
\
\
图12：eSailors的开发周期
\
我们的技术也发生了极大的变化。从原先一个很小的技术集和占主导地位的“大泥球”，我们设法减少了后者，并增加了前者的多样性。我们不再什么系统都仅使用一种数据库解决方案（Oracle），而是在生产环境中使用多种不同的数据库（Oracle、Mongo、Redis、Elasticsearch、Cassandra）。我们不再仅仅关注一门编程语言（Java），我们现在使用不同的语言（Java、Scala、Go、Swift）。还有其他新的工具和库，例如，docker、ansible、vagrant、angularJs、consul或openstack。每个团队都有特定的功能领域。他们现在有权自己选择最适合团队需求的技术栈，为他们的特性构建解耦合的微服务。通过选择恰当的工具，而不是实现某项共享技术的变通方案，将新特性交付到生产环境变得越来越快越来越简单。这是可能的，因为团队的工程师现在可以专注于自己的部分，并对自己所开发的服务的全生命周期负责。如果不是对技术栈全权负责，如果需要向其他部门进行彻底地交接，那么这种技术的异构性是不可能的。
\
我们还没有完成我们的微服务架构，但是我们使用微服务实现了所有的特性。我们还在继续逐步地改进我们的架构。发布新服务的提前期也有了显著的改善。现在，新服务几分钟内就可以构建、标记、测试和部署到生产环境。有时候，从构思到完全实现只需要一天，而不是几周。
\
虽然我们取得了许多成果，但是我们仍然面临着巨大的挑战。一方面是技术挑战，比如我们的架构的复杂性、我们接下来的微服务旅程或者保证设施随时可用的困难。同时，我们面临着组织和业务上的挑战。在通向始终如一的精益敏捷企业的道路上，我们还面临着一项挑战，就是团队没有真正的得失责任。即使一个产品团队成功地使其价值流的所有干系人都参与进来，其工作的整体成本和回报对这些人来说也是不透明的。
\
完备的企业产品管理职责是当前困扰我们的一个问题。产品经理关注收益（收入、注册量……），而成本本身（人员编制、工资、硬件、外部服务、培训……）是工程成本中心的一部分。内部基础设施的成本或者产品的营销成本根本没有体现到产品团队上。
\
为了追踪行动的成本和收益，我们在数据及KPI可视化方面取得了很大的进步。但是，因为无法将实现成本、基础设施的成本和工作映射到这类行动上，所以通常很难评价一项实现是否增加了任何价值。
\
跨团队交流和整个系统的公共视图是困扰我们的另一个问题。现在，我们还不是很清楚应该如何改进我们的端到端工作流。目前，我们即将研究如何使用我们的“墙”（见图9）作为一种方法来更好地管理我们的价值流——即所谓的看板“飞行高度（flight level）”34。通过扩大业务视角，我们可以从一步一步的价值创造流程中获得新的视角……而且，为了统一监控和积极控制整个公司里正在发生的事情，我们考虑将所有领域的代表都包含进来。我们坚信，这可以提升我们的能力，让我们可以更好地区分选项，改善提前期，通过较小的努力提供更大的价值。
\
参考资料
\
- “How Do Committees Invent Melvin E. Conway\t
- “分析师瞭望：Water-Scrum-fall是敏捷的现状”Dave West\t
- “领导自组织团队” Siegfried Kaltenecker（免费下载）\t
- “看板的飞行高度” Klaus Leopold
关于作者
\
Sigi Kaltenecker是Loop Consultancy的联合常务董事，专注于精益和敏捷变革。他已参与了多家国际性公司的改革，包括Alcatel、bwin.party、eSailors、Kaba、ImmoScout24、Magna、RWE、Swiss Federal Railways或Thales Group。Sigi是《领导自组织团队》、《看板改革领导力：创建持续改进文化》（Wiley 2015)）的作者，并在“Peer Feedback Loops”上发表了一系列的文章。感兴趣的读者可以通过电子邮件（siegfried.kaltenecker@loop-beratung.at）联系他。
\
Hans Gruber是eSailors汉堡公司的工程负责人和董事总经理。他有很强的工程背景，在类似Tele2和bwin.party这样的国际性企业里逐步建立起自己的专长。他致力于通过采用精益和敏捷实践来改善团队，因为他坚信，技术和产品团队可以做到精益求精，并借此提供卓越的客户价值。感兴趣的读者可以通过linkedin联系他。
\
查看英文原文：Agile Sailors – A Journey from a Monolithic Approach to Microservices
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91286 人正在系统学习中 相关资源：旅行家航旅行程信息打印软件-旅游工具类资源-CSDN文库
来源：weixin_34268753
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！