Интересное выступление Randy Shoup, VP of Engineering и Chief Architect в Ebay, который отвечает за работу платформенных команд. Рэнди рассказывает про то, как за 2 года инженерная команда Ebay, что состоит из 4к инженеров, научилась работать в два раза эффективнее. Если суммировать выступление, то никаких секретных компонентов в этой трансформации не было:
- Компания была в
- Они нарисовали product lifecyle (plan -> development -> delivery -> post-release iteration) и дальше сфокусировались на части про deployment & delivery, пытаясь ускорить изменения и уменьшить их стоимость
- Дальше они стали измерять DОRA метрики для каждого важного сервиса (lead time, release frequency, mttr после неудачных релизов, rate неудачных релизов). Здесь автор вспоминает книгу "Accelerate" (у меня есть ее обзор в трех частях: 1, 2, 3) и приводит данные о том, как в среднем выглядела ситуация по DORA метрикам в Ebay и в сравнении с отраслевым бенчмарком
- Потом они провели опрос продуктовых разработчиков в стиле "Если бы вам нужно было релизить условно ежедневно, то что мешало бы такой частоте релизов" - именно этот набор проблем стал бэклогом для платформенных команд. Здесь автор вспоминает книгу "Team Topologies" (у меня есть ее обзор в трех частях: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery)
- А дальше автор рассказывает как выглядела сама трансформация и что именно делали продуктовые и платформенные команды, чтобы удвоить продуктивность (как сфокусироваться на пилотных командах и системах, чтобы не размывать фокус, как деливерить результаты понемногу, но улучшая общую ситуацию, улучшать процессы разработки и перепроектировать критические части систем)
- Дальше автор рассказывает про совместную кооперативные треки движения платформенных команд (измерение velocity, улучшение билдов, локальных тестов, CI, стейджинга, mirroring трафика, автоматизация deployment, тренинги и воркшопы для инженеров), а также продуктовых команд (автор показывает как команды из разных доменов вовлекались в трансформацию)
Интересно, что ребята гнались за ускорением разработки, а по итогу получили более высокую продуктивность команд разработки и лучшую надежность сервисов.
Это соответствует тому, что утверждали авторы "Accelerate" - они отмечали, что в отличие от старого подхода к разработке, где надо было выбирать между стабильностью и скоростью, в новом подходе с повышением adoption правильных практик ты получаешь и то и другое в комплекте.
#Engineering #Software #SoftwareEngineering #Architecture #CI #Derlivery #Management #Leadership #Devops