Get best of the week

如何让邻居从事他们的项目或银行的InnerSource工作

Sber的发展是什么？在普通IT专家的眼中：“这是编写代码的地方，到那里去！” 但这长期以来一直是一种刻板印象，而且不好。开源的飞速发展证明，这种文化早已过时，并且企业（如果很聪明的话）也长期修改了基于筒仓的开发方法。 以开源方式发布所有银行软件是自杀的有效方式，这是一个颇具争议的决策，需要某种中间阶段。有了银行的规模，我们可以启动内部开放源代码，而不必尝试检查可以向所有人展示的内容，并为我们的小小大秘密而感到恐惧。





什么是InnerSource？


在2000年，Tim O'Reilly将内部来源一词描述为迈向一家封闭的公司进入美丽的开源世界的可能步骤。这是公司内部开放源代码的最佳实践的应用：从普遍开放和主动互助到形成最佳解决方案市场。该公司继续编写专有代码，但是其每个员工都有机会完善任何内部系统。

InnerSource的优势可以长期列出：减少产品上市时间，提高代码质量，用内部人员替代外部人员，改善跨团队互动等。

困难在于，上述所有内容都需要改变员工与团队之间的沟通文化，而在一个已经工作数十年的组织中，要做到这一点并不容易。

当然，Sberbank并不是发生这种事情的唯一一家公司。 2015年，创建了InnerSource Commons社区，该社区普及了该方法，并消除了术语中的空白，从而使其更易于在搜索引擎中找到。该社区收集了数十家公司的经验，并为在您的公司中实施InnerSource提出了有效的建议，并且每年召开两次经验交流会议。自Pechenegs和Polovtsy成为主流以来，仍然有许多知名的技术公司在这样做。

据我们所知，在俄罗斯，只有一个带有绿色徽标的建筑服务市场中的大型零售商积极参与有意实施的InnerSource，其他公司要么不宣传其经验，要么不参与社区活动。

这些公司中的每一个都有自己的正面和负面经验。在这种情况下的总体结论非常相似：只有在绝大多数人的参与下才能获得最可口的好处。

我为什么要收集它？


在Sberbank中，几乎所有有关开发的讨论都提到“您有多少个程序员？”这个问题。在全国范围内，我们有上万个机构，他们正在积极开发成千上万的组件，系统，库以及类似的组件。由于数量众多，我们每天都必须解决管理对相关团队的依赖性，领导者的关系以及水星阶段的问题。

在关于对工程师造成伤害的调查的最后，于2018年底在Sber决定创建一个部落SberWorks，以接管与银行中生产软件的流程和工具相关的所有内容。该部门的任务和目标几乎完全是从开发人员收集的清单中得出的。

我很ham愧地承认，去年年底最大的痛苦是缺乏对车间内邻居甚至在露天场所的相邻街区做什么的了解。因此，我们不仅发明了轮子，而且发明了两个轮子（代替所需的数量），它们在不同的城市和附近的工作场所中以不同的单位使用。结果，我们的团队拥有大量资源，通常不乘飞机去火星，而是跑耙，不知道附近的耙子早已被收集。



这一切怎么办？


时间。为了解决集成问题并找到合适的人，为银行的所有系统创建一个具有大量自动化功能的API注册中心：调用生成，API下一版本的存根，版本控制等。现在，此注册表已变成一个单独的很酷的产品，绝对值得在其文章中提及，但这是另一回事了。

二。使用一个搜索引擎在所有工程工具（JIRA，Confluence，Bitbucket，Nexus）上创建一个“伞”，将内部和外部部分（是的，臭名昭著的alpha和sigma）组合在一起。

三。除明确禁止开放安全性的代码，积压和工件外，所有公司员工均应开放。

有什么建议？


在与开发人员进行沟通的过程中，我们确定了内部团队如此封闭的主要原因：产品之间当前的交互方式。有关相关系统优化的任何讨论都是根据以下三种情况之一进行的。


“等待”

最常见的交互方式。相邻的团队设定了最后期限，这通常适合我们，我们将任务推迟到更深的待办事项中。
通常，一个可接受的选项。但是，如果该链依赖于多个团队，并且该功能需要像往常一样在昨天的生产中显示，那么您需要寻找折衷方案。



妥协

通常，此方法称为升级。带上一个更重要的经理，并与相邻的团队一起工作，以使您的任务在待办事项中更高。这种方法的缺点很明显：大多数团队只能使用此卡几次，此后团队之间的关系就会恶化。



“临时永久存根”

用拐杖和临时火箭筒看到了科学怪人的自行车，这些自行车复制了上瘾的系统的功能。最可悲的是，由于它几乎总是保留很长时间（如果不是永远），因此会产生重复的代码，并且团队被迫支持拐杖解决方案。

我们提出了第四种方法。在敏感团队的监督下完善相邻团队的代码库，从而减少执行时间。


内源

互动完成后，图片中的“ A”团队将收到宝贵的反馈意见，在相邻领域中培养专业知识，并减少其改进的TTM。展望未来，在银行中，这种交互会迅速获得各种类型的易货形式：“ A”团队在执行必要的改进时从“ B”团队的技术债务中关闭了任务。

我们的方式


从一开始，在我们看来，我们需要找到InnerSource现在将在最大需求量的地方。当我们在考虑如何做到这一点时，不要陷入无休止的民意测验的周期中，明智的领导者对此表示赞赏，并建议在年底前确保100％的Sberbank系统已准备就绪。我们紧张起来，经理问“百分之一百？”，系统数量减少了约20倍，成为现代的和/或对业务至关重要的。

之后，开始在团队中传播这种做法的常规过程，最后，我们看到了一个有盖的草地，上面列出了存储库和与每个存储库一起工作的规则。

我们在各个级别举行了很多会议，首先是与部门的技术负责人，然后是与团队负责人和服务所有者，最后是与团队成员。我们要求服务代表提供有关系统本身，开发堆栈以及到存储库，积压和文档的链接的信息。在相同的会议上，我们能够获得第一手的痛苦信息：无休止的积压，资源匮乏，旧技术堆栈（例如Delphi）。

在流通过程中，我们对银行的强弱环节形成了了解。有非常成熟的团队（例如，移动开发）已经在工业规模上按照InnerSource原则开展工作，并且共享了大量的方法。但是，由于缺乏自动测试，日志记录和代码审查实践，因此有几支团队（您好是Pechenegs团队）感到沮丧。

在我们的团队中，“我的部队正在执行最正确的任务”与“让我们一起冷静地完成工作”之间存在巨大的文化鸿沟。大多数反应非常单调：“我们不想接受别人的代码然后再回答”，“我们不想给我们的开发人员，因为他们会离开，但总有资源”。在这一点上，决定对文化进行投资，而不是对技术进行投资：

  • HR : Google, , 10 % .
  • PR : Microsoft, open source.
  • : , - Delphi GraphQL, 10 % , !
  • , API, JIRA- .


遇到一些错误，我们学会了跟踪在BitBucket中进行的团队之间的交互，并收到的信息表明，我们每个月增加了大约30-50位InnerSource更改的新作者。就银行中开发人员的数量而言，这个数字并不令人印象深刻，但这仅仅是对业务任务的改进。

可以预料的是，各种集成总线和ETL服务中的数据驱动型更改变得非常流行。大量的任务和较低的改进成本很容易解释这一点。

我们以ESB为例仔细研究了此类改进。她计划在不久的将来过渡到新的解决方案，因此不会给团队分配任何额外的资源，而对修订的要求只会增加。在InnerSource上，这些家伙看到了救赎，迅速坐立不安，并组建了一个优先级排序器，如果您准备好自己做的话，它会尽可能地提高您的任务。从数量上看，它看起来像这样：在10月至11月，几乎一半的请求（209个请求中的101个）都是由团队自己完成的。这使得等待时间从2.5个月减少到2.5周，减少了四倍。

出乎意料的是，设计师积极参与其中，当相关团队缺乏资源或需要焕然一新时，他们乐于为相关团队提供帮助。事实证明，有很多团队可以100％利用设计师，他们本身就是有创造力的，并且乐于将注意力转移到某些新产品上。

后记


在习惯于遵守企业法则的公司中，引入透明度和团队之间的互动始终是最困难的第一步。我们可以肯定地说，第一道墙已经被突破，并且已经积累了足够多的成功的InnerSource故事，因此，Sberbank内部的移动将获得动力。

未来我们面临的主要挑战是避免遵守古德哈特法律。在任何大中型公司中，都必须衡量效率：提出一个数字并使其增长。在去年秋天在巴尔的摩举行的一次会议上，提出了几个案例，其中设定了团队准备程度的目标和改进的数量导致指标的破坏和运动领导者的精疲力尽。

我们认为，由此产生的收益完全阻碍了投入的精力，而开放本身具有无数的优势。我们准备更详细地讲述我们的道路并交流经验，请写信至call-innersource@sberbank.ru。吻，Sberbank。

More articles:


All Articles