Как автоматизируют разработку команды различных размеров
Прошедший в январе в Яндексе Team Leader Meetup подарил нам не только два часа видео, но и тему второй встречи, которые выбрали участники встречи в специальном чате. Говорить мы будем, как понятно из заголовка, об автоматизации разработки.
Выбор инструментов автоматизации во многом зависит от размеров команды, поэтому важно отслеживать их эволюцию с учётом роста небольшого стартапа до огромной, компании, которая сама создаёт инструменты для разработки. Чтобы понять, с чем в таком случае столкнутся руководители команд, мы задали несколько вопросов нашим экспертам, среди которых Сергей veged Бережной, Иван ginkage Подогов, Роман shadart Пузиков, Сергей profitware Собко, Алексей alexmog Могилевский.
- Предположим, вы решили открыть свой стартап. В нём на старте работает небольшая команда (пять программистов). Какие инструменты автоматизации разработки вы внедрите?
- Стартап зажёг! Теперь в нём работает очень много людей. Что изменится? Что добавится?
- Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
Виталий Левченко, руководитель группы разработки, МегаФон.ТВ
Предположим, вы решили открыть свой стартап. В нём на старте работает небольшая команда (пять программистов). Какие инструменты автоматизации разработки вы внедрите?
Для старта — самое понятное и простое.
- Github. Там есть всё необходимое для старта: задачи, проекты с kanban, pull request, простое wiki.
- CI: любой облачный сервис, например drone.io.
- Оркестрация и релиз менеджмент в ansible.
- Коммуникации и уведомления: slack.
Стартап зажёг! Теперь в нём работает очень много людей. Что изменится? Что добавится?
- JetBrains стек (YouTrack / Upsource / TeamCity): быстрое, гибкое и относительно простое решение. Для Java/Python/JS очень удобно.
- Kaiten.io: если потребовался сложный kanban процесс.
- Confluence: база знаний. Вне конкуренции.
- Система конфигурации и релиз-менеджмента — под задачи. Для автоматического масштабирования удобен стек Kubernates/Mesos с виртуализированной сетью и CI/CD внутри. Оно же — для простоты запуска cron/batch задач и оркестрирования A/B тестов.
- Ad hoc боты для автоматизации рутинных процессов коммуникации.
Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
Мне сложно провести границу между использованием готового инструмента и созданием нового на его основе. Деплой сервиса на пару тысяч строк кода и конфигурации — это уже новое или ещё старое? Динамическое создание сред микросервисов с гибким роутингом для A/B тестов? Система отображения и анализа агрегированной статистики в БД с автоматической реакцией на триггеры? Точно новое — простые боты для интеграции сервисов: запуск деплоя из CI, slack бот, выгрузка отчётов из YouTrack.
Алексей Могилевский, ведущий разработчик интерфейсов, Яндекс
В прошлом — разработчик и архитектор MS Office и Internet Explorer, Microsoft
Предположим, вы решили открыть свой стартап. В нём на старте работает небольшая команда (пять программистов). Какие инструменты автоматизации разработки вы внедрите?
Признаться, я всегда работал в проектах, на которых было занято как минимум 20 разработчиков и которые обслуживали как минимум миллион пользователей. Так что я могу размышлять о современных стартапах только гипотетически. Тем не менее, очевидно, будет необходима система контроля версий и трекер. Я бы использовал Visual Studio Online, так как в нём хорошо решены все задачи контроля над кодом. И, кроме того, он будет работать и на большом проекте. Для коммуникаций на пять человек, думаю, хорошо подойдёт Slack.
Стартап зажёг! Теперь в нём работает очень много людей. Что изменится? Что добавится?
Для большего проекта, особенно, если он весьма динамичен, следует всерьёз рассмотреть Microsoft Teams. Сюда удобно интегрированы многие потребности, которые обычно решаются никак не связанными между собой инструментами: мессенджерами, календарями, программами для видео-конференций и так далее.
Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
Большинство самодельных инструментов исправляют проблемы в недостаточно интегрированных стандартных системах. Телеметрия почти всегда имеет что-то самодельное. Может. это нормально, а может — потенциал для создания полезного продукта.
В прошлом — руководитель службы риалтаймовых рекламных технологий, Яндекс
Предположим, вы решили открыть свой стартап. В нём на старте работает небольшая команда (пять программистов). Какие инструменты автоматизации разработки вы внедрите?
Выбор инструментов зависит от того, чем стартап будет заниматься. Создание веб-сервиса, настольного приложения, мобильного приложения и разводка печатных плат — сильно отличающиеся области деятельности. Инструменты автоматизации тестирования и оптимизации производительности в этих случаях отличаются довольно сильно. Также решения зависят от выбранного языка программирования, необходимости выхода в Open Source, и так далее. С другой стороны, в маленькой команде ориентироваться следует на те инструменты, с которыми привычно работать большинству участников. Поскольку их всего пятеро, не составит проблемы узнать мнение каждого: для стартапа критично дать всем возможность двигаться максимально быстро. Наконец, стартап — это своего рода приключение, так что почему бы не попробовать те инструменты, с которыми давно хотелось познакомиться, но не доходили руки? Для меня это, например, Яндекс.Трекер и PVS Studio.
Стартап зажёг! Теперь в нём работает очень много людей. Что изменится? Что добавится?
Для большой команды становятся критичными style guide, автоформатирование кода, документация, покрытие тестами (и presubmit-проверки) и минимизация сакральных знаний. Иными словами, важно обеспечить взаимозаменяемость членов команды, повысить bus factor. В маленькой команде обмен знаниями обычно происходит органически, а вот в большой появляется потребность в стендап-встречах, корпоративной почте, полноценном таск-трекере (тогда как для пяти человек можно было обойтись и канбаном). Выбор инструментов во многом обуславливается их масштабируемостью. Скажем, в качестве основного репозитория наверняка подойдёт GitHub с его же wiki и code review. Если же команда пользуется Jira, то к ней можно пакетом докупить Bitbucket для репозитория, Confluence для документации и Crucible для code review. Когда компания станет совсем большой, появление собственных инструментов станет практически неизбежным.
Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
Когда-то мне потребовалось оптимизировать потребление оперативной памяти в ряде приложений. Для этого пришлось написать анализатор java heap, учитывающий особенности Android и позволяющий «схлопывать» граф ссылок в крупные кластеры, чтобы можно было оценить использование памяти на уровне целых компонентов, а не отдельных классов. Частично такую задачу решают Android Studio, Eclipse MAT и ahat [https://android.googlesource.com/platform/art/+/master/tools/ahat/README.txt], но все они обладали своими недостатками и не позволяли мне производить анализ настолько быстро и точно, как мой собственный инструмент.
Роман Пузиков, руководитель отдела сервисов для организаций, Яндекс
Предположим, вы решили открыть свой стартап. В нём на старте работает небольшая команда (пять программистов). Какие инструменты автоматизации разработки вы внедрите?
Стартапу из пяти разработчиков отлично подойдёт, например, Github для работы с кодом, простейшего управления задачами и ведения проектной документации. Плюс интегрированный с ним Slack для оперативного взаимодействия команды. Больше на старте не нужно ничего.
Стартап зажёг! Теперь в нём работает очень много людей. Что изменится? Что добавится?
Похоже, теперь у меня работают не только программисты! Значит, нужно какое-то общее место, где специалисты разных областей смогут делиться результатами своей работы, работать с общими документами, синхронизировать планы и так далее. Это место — долговременная память организации. Тут важен минимальный порог входа, хороший поиск и навигация. Подойдёт любая Вики — чем проще, тем лучше. Кроме того, с ростом организации неизбежно усложняются старые и появляются новые процессы. Поэтому из задач в Github придётся переехать в трекер задач посерьёзнее, в котором можно гибко настраивать workflow и где сможет жить не только разработка. Ещё у трекера обязательно должен быть хороший API, тогда он быстро обрастёт десятками интеграций с другими инструментами (от инструментов CI и деплоймента — до сбора обратной связи от пользователей). Хорошо подойдёт Jira или Яндекс.Трекер.
Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
Неожиданно сложный вопрос. Оказывается, сложно выбрать что-то одно, если твоя работа состоит в том, чтобы улучшать рабочие инструменты. Сейчас меня больше всего беспокоит отсутствие удобного инструмента для верхнеуровнего планирования.
Если говорить о том, как именно этот инструмент создавать, то попробуйте собрать максимально простой прототип и проверить, действительно ли он вам нужен, прежде чем ввязываться в дорогостоящую разработку. Неважно, о чём идет речь: о написании чего-то полностью с нуля или об интеграции чего-то большого и сложного в свои процессы.
Сергей Собко Руководитель группы разработки Application Firewall, Positive Technologies
Предположим, вы решили открыть свой стартап. В нём на старте работает небольшая команда (пять программистов). Какие инструменты автоматизации разработки вы внедрите?
Вообще, под стартапом можно подразумевать как конструкцию, отстроенную с нуля, так и стартап в рамках большой компании (так называемый «внутренний стартап»).
В первом случае это, скорее всего, были бы бесплатные (и желательно опенсорсные) инструменты, подобранные по принципу «нет времени объяснять». Если внутренняя инфраструктура и возможность её поддержки уже есть, то это был бы Gitlab CE, если нет — Bitbucket: он предоставляет возможность иметь бесплатные закрытые репозитории. Если есть готовность заплатить немного денег, то лучше, наверное, взять Github — он привычнее. Этот инструментарий уже имеет встроенную поддержку вики-страниц и управления задачами. Ну и, соответственно, интеграции со всякими облачными CI-системами типа Travis CI. Можно использовать бесплатный Jenkins, если есть внутренняя инфраструктура.
Во втором случае было бы логично использовать то, что используют команды в остальной компании, потому что все грабли уже успели собрать до вас, кто-то уже умеет с этим работать, есть какие-то построенные workflow, которые можно приспособить к своей команде.
Стартап зажёг! Теперь в нём работает очень много людей. Что изменится? Что добавится?
На этом этапе команда уже всё отрефлексировала и выработала свой workflow. Тут уже становится понятна разница между инструментами, можно выбрать что-то, что подходит команде. Самое главное — суметь на это переехать или внедрить, но при этом не вызвать бунт в команде. Например, если использовался Gitlab CE, то можно его проапгрейдить до Gitlab EE и получить дополнительные фичи. Если не хватает инструментов аналитики процесса разработки, то трекер задач тоже можно выбрать несколько мощнее — Jira или, например, TFS. Последний, как я понял, из коробки позволяет и отпуска с capacity учитывать, и графики сгорания строить, и чего только не.
При этом большая часть автоматизации всех процессов управления ложится на интеграции между различными системами. То есть, если у вас есть возможность интегрировать систему контроля версий и таск-трекер, подключив один плагин — это очень хорошо. Проблемы могут возникнуть тогда, когда такие интеграции отсутствуют, либо когда они не покрывают все необходимые сценарии.
В этом может помочь, как я её называю, внешняя автоматизация. В этом случае актором взаимодействия нескольких систем является внешняя по отношению к ним система. Если приводить аналогию с какими-нибудь тяжелыми BPM-системами, то это был бы KIE Execution Server от Red Hat для выполнения бизнес-процессов. Тем не менее, внешнюю автоматизацию можно реализовать, не притаскивая в наш зажёгший стартап тонны кровавого энтерпрайза.
Собственно, когда команда стала больше пяти человек и появилось много рутинной работы, к очевидному набору инструментов в моей команде я добавил только внешнюю автоматизацию.
Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
Пресловутую внешнюю автоматизацию я и реализовал — чтобы, с одной стороны, не въезжать в полноценную BPM-парадигму своими силами, а с другой — иметь полный контроль над управлением своей командой. Изначально я реализовал прототип, который работает и по сей день, и неспешно теперь заменяю его продакшн-решением по кускам. Для этого при поддержке Positive Technologies я даже выложил основную часть этого продакшн-решения в опенсорс на Github — это проект ((https://github.com/PositiveTechnologies/flower Flower)) для интеграций с системами контроля версий (Gitlab и Github), трекерами задач (Jira, TFS, etc.) и мессенджерами (Slack, Exchange). И это только начало — я напишу об этом отдельную статью на хабр.
Идея в том, чтобы каждый мог собрать свою автоматизацию с нуля из готовых кубиков «Lego», дав разработчику конечного решения полный контроль над тем, что ему нужно. Например, кто-то хочет иметь правила распределения задач по матрице компетенций в виде регулярных выражений и простых правил (это мой случай), а кому-то и машинного обучения для принятия таких решений будет мало. При этом, если у вас меняется трекер задач или система контроля версий (стартап-то зажёг) — вам достаточно было бы поменять адрес подключения, не меняя концепцию и общую логику.
Что же я автоматизировал в своей команде? Как я уже говорил, распределение задач с использованием матрицы компетенций. Второе — автоматический мердж и перевод задач в завершенный статус при прохождении кросс-ревью. Далее — создание заявок и рассылка сообщений о приходе нового сотрудника, напоминания о днях рождения, текущие задачи и ещё некоторые, вроде и тривиальные, но требующие однотипных ручных действий, вещи.
Павел Соломин, лидер чаптера Platform Engineering Sberbank Online
Предположим, вы решили открыть свой стартап. В нём на старте работает небольшая команда (пять программистов). Какие инструменты автоматизации разработки вы внедрите?
В условиях минимального количества участников за каждую область компетенции будет отвечать один человек. На этом этапе пытаться внедрять для всех какие-то общие инструменты скорее вредно, чем полезно, ведь много усилий будет потрачено на приведение всех к общему знаменателю и обучение. Вероятнее, что это замедлит получение MVP и не факт, что как-то поможет в дальнейшем. Тем не менее, есть области, где общие инструменты полезны. Например, API между client-side и server-side, передача задач из дизайна в разработку. Для совместной работы над API подойдет любая wiki-система, мне больше других нравится Atlassian Confluence. Для передачи дизайна ничего лучше Zeplin пока не придумали. Кроме этого, даже пятью программистами нужно как-то управлять. Я бы делал это при помощи Jira или Trello.
Стартап зажёг! Теперь в нём работает очень много людей. Что изменится? Что добавится?
У нас в Сбербанке есть проекты, над которыми одновременно работает более сотни разработчиков. Для их организации требуются довольно специфические инструменты и практики. Если попытаться уйти от этой специфики, то можно сказать следующее. Для совместной работы абсолютно точно нужна система контроля версий. Кроме этого нужен какой-то софт для организации сред continuous integration, continuous deployment. Где-то нужно совместно вести документацию. Где-то отслеживать таски. Я бы использовал для решения всех этих задач софт, произведённый одной компанией — в таком случае за счёт интеграции можно бесплатно получить ряд плюшек, которых иначе либо не будет совсем, либо нужно будет как-то отдельно прикручивать. Мой фаворит здесь — продукты компании atlassian. Bamboo, Jira, Bitbacket, confluence. Отдельно я бы начал уделять внимание архитектуре того, как ваши приложения взаимодействуют друг с другом, иначе вся конструкция вполне может стать неуправляемой. Тут мне нравится Sparx Enterprise Architect.
Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
У нас над проектом работает очень много маленьких команд — 80+. Разработчиков — больше 100 на каждое приложение. Для управления эффективностью работы этих команд мы решили работать не с показателями каждой команды, а с теми случаями, которые мы считаем отклонениями от нормальных показателей. Для этого мы написали собственное приложение. Точнее, адаптировали приложение, которое было разработано для управлением продажами в наших отделениях. Как оно работает? Например, мы считаем нормой, если >80% сторипойнтов, запланированных за спринт, сгорает. В том случае, если у какой-то команды это не выполняется, на её владельца продукта вешается задача разобраться с причинами. Если через спринт ситуация повторяется — задача эскалируется на руководителя владельца продукта, если не решается ещё спринт — ещё выше. Таким образом задача может дойти до заместителя председателя правления (и если проблема системная, так вполне может произойти). Подобная система позволяет управлять ситуацией на каждом уровне организационной структуры. Но я сомневаюсь, что она нужна в компаниях меньшего, чем у нас, размера.
Следующая встреча, на которую ещё можно зарегистрироваться, состоится 22 мая 2018 года в московском офисе Яндекса. На ней можно будет задать вопросы докладчикам и поделиться своим опытом.
