您好！
我叫 Alexander，负责 UBRD 的 IT 开发！
2017 年，UBRD 信息技术服务开发中心的我们意识到全球变革，或者更确切地说，敏捷转型的时机已经到来。 在业务发展密集、金融市场竞争迅速加剧的情况下，两年是令人印象深刻的时期。 因此，是时候对这个项目进行总结了。
最困难的事情是改变你的思维并逐渐改变组织中的文化，其中常见的想法是：“谁将成为这个团队中的老板？”，“老板更知道我们需要做什么”，“我们已经在这里工作了 10 年，更了解我们的客户。”，我们知道他们需要什么。”
敏捷转型只有当人本身改变时才能发生。
我想强调以下阻碍人们改变的主要恐惧：
- 害怕失去权力和“肩章”；
- 害怕成为公司不必要的人。
走上转型之路，我们选出了第一批“老兔子”——零售部门的员工。 第一步是重新设计低效的 IT 结构。 提出了结构的目标概念后，我们开始组建开发团队。
温和地说，我们银行的建筑和许多其他银行的建筑一样，都是“垃圾”。 大量的应用程序和组件通过DB链接单片互连，有ESB总线，但它没有达到其预期目的。 还有一些ABS。
在组建 Scrum 团队之前，出现了这样的问题：“团队应该围绕什么组建？” 当然，罐头里有产品的想法已经存在，但只是遥不可及。 经过深思熟虑，我们决定团队应该围绕一个方向或部分聚集。 例如，开发贷款的“Team Credits”。 做出这一决定后，我们开始制定目标角色构成以及该领域有效发展所需的一系列能力。 和许多其他公司一样，我们考虑了除 Scrum Master 之外的所有角色——当时几乎不可能向 CIO 解释这个出色的人的角色是什么。
因此，在解释了组建开发团队的必要性后，我们组建了三个团队：
- 贷款
- 牌
- 被动操作
具有一组角色：
- 开发经理（技术主管）
- 开发人员
- 分析师
- 测试员
下一步是确定团队如何工作。 我们对所有团队成员进行了敏捷培训，让每个人都坐在一个房间里。 团队中没有 PO。 大概做过敏捷转型的人都明白，向业务解释一个PO的角色是多么困难，让他坐在团队旁边，给他权力就更难了。 但我们用我们所拥有的“步入”这些变化。
由于贷款流程和零售业务的其余部分涉及如此多的应用程序，我们开始思考，谁可能最适合这些角色？ 一个技术堆栈的开发人员，然后您会发现 - 您需要另一种技术堆栈的开发人员！ 现在你已经找到了需要的人，但是员工的愿望也是一个重要的事情，强迫一个人在他不喜欢的地方工作是相当困难的。
经过对贷款业务流程的工作分析以及与同事的长时间交谈，我们终于找到了一个中间立场！ 三个开发团队就这样出现了。
接下来是什么？
人们开始分为想要改变的人和不想改变的人。 每个人都习惯在“他们给我一个问题，我做到了，别管我”的条件下工作，但团队合作并不意味着这一点。 但我们也解决了这个问题。 总共 8 人中有 150 人在变革期间退出了！
然后有趣的事情开始了。 我们的跨组件团队开始自我发展。 例如，有一项任务需要您具备 CRM 开发人员领域的技能。 他在团队中，但他是孤独的。 还有一位 Oracle 开发人员。 如果您需要解决 CRM 中的 2 或 3 个任务该怎么办？ 互相教导！ 这些人开始互相转移他们的能力，团队扩大了能力，最大限度地减少了对一位强大专家的依赖（顺便说一句，在任何公司中都有知道一切并且不告诉任何人的超人）。
如今，我们已经组建了 13 个开发团队，负责业务和服务开发的各个领域。 我们继续敏捷转型并达到新的水平。 这将需要新的改变。 我们将重新设计团队和架构，并发展能力。
我们的最终目标：快速响应产品变化，快速为市场带来新功能，提升银行服务！
来源： habr.com