Хабрахабр

Как автоматизируют разработку команды различных размеров

Говорить мы будем, как понятно из заголовка, об автоматизации разработки. Прошедший в январе в Яндексе Team Leader Meetup подарил нам не только два часа видео, но и тему второй встречи, которые выбрали участники встречи в специальном чате.

Чтобы понять, с чем в таком случае столкнутся руководители команд, мы задали несколько вопросов нашим экспертам, среди которых Сергей veged Бережной, Иван ginkage Подогов, Роман shadart Пузиков, Сергей profitware Собко, Алексей alexmog Могилевский. Выбор инструментов автоматизации во многом зависит от размеров команды, поэтому важно отслеживать их эволюцию с учётом роста небольшого стартапа до огромной, компании, которая сама создаёт инструменты для разработки.

  1. Предположим, вы решили открыть свой стартап. В нём на старте работает небольшая команда (пять программистов). Какие инструменты автоматизации разработки вы внедрите?
  2. Стартап зажёг! Теперь в нём работает очень много людей. Что изменится? Что добавится?
  3. Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?

Виталий Левченко, руководитель группы разработки, МегаФон.ТВ

В нём на старте работает небольшая команда (пять программистов). Предположим, вы решили открыть свой стартап. Какие инструменты автоматизации разработки вы внедрите?
Для старта — самое понятное и простое.

  • 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], но все они обладали своими недостатками и не позволяли мне производить анализ настолько быстро и точно, как мой собственный инструмент.

Роман Пузиков, руководитель отдела сервисов для организаций, Яндекс

В нём на старте работает небольшая команда (пять программистов). Предположим, вы решили открыть свой стартап. Плюс интегрированный с ним Slack для оперативного взаимодействия команды. Какие инструменты автоматизации разработки вы внедрите?
Стартапу из пяти разработчиков отлично подойдёт, например, Github для работы с кодом, простейшего управления задачами и ведения проектной документации. Больше на старте не нужно ничего.

Теперь в нём работает очень много людей. Стартап зажёг! Что добавится?
Похоже, теперь у меня работают не только программисты! Что изменится? Это место — долговременная память организации. Значит, нужно какое-то общее место, где специалисты разных областей смогут делиться результатами своей работы, работать с общими документами, синхронизировать планы и так далее. Подойдёт любая Вики – чем проще, тем лучше. Тут важен минимальный порог входа, хороший поиск и навигация. Поэтому из задач в Github придётся переехать в трекер задач посерьёзнее, в котором можно гибко настраивать workflow и где сможет жить не только разработка. Кроме того, с ростом организации неизбежно усложняются старые и появляются новые процессы. Хорошо подойдёт Jira или Яндекс.Трекер. Ещё у трекера обязательно должен быть хороший API, тогда он быстро обрастёт десятками интеграций с другими инструментами (от инструментов CI и деплоймента – до сбора обратной связи от пользователей).

Оказывается, сложно выбрать что-то одно, если твоя работа состоит в том, чтобы улучшать рабочие инструменты. Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
Неожиданно сложный вопрос. Неважно, о чём идет речь: о написании чего-то полностью с нуля или об интеграции чего-то большого и сложного в свои процессы. Сейчас меня больше всего беспокоит отсутствие удобного инструмента для верхнеуровнего планирования.
Если говорить о том, как именно этот инструмент создавать, то попробуйте собрать максимально простой прототип и проверить, действительно ли он вам нужен, прежде чем ввязываться в дорогостоящую разработку.

Сергей Собко Руководитель группы разработки Application Firewall, Positive Technologies

В нём на старте работает небольшая команда (пять программистов). Предположим, вы решили открыть свой стартап. Какие инструменты автоматизации разработки вы внедрите?
Вообще, под стартапом можно подразумевать как конструкцию, отстроенную с нуля, так и стартап в рамках большой компании (так называемый «внутренний стартап»).

Если внутренняя инфраструктура и возможность её поддержки уже есть, то это был бы Gitlab CE, если нет — Bitbucket: он предоставляет возможность иметь бесплатные закрытые репозитории. В первом случае это, скорее всего, были бы бесплатные (и желательно опенсорсные) инструменты, подобранные по принципу «нет времени объяснять». Этот инструментарий уже имеет встроенную поддержку вики-страниц и управления задачами. Если есть готовность заплатить немного денег, то лучше, наверное, взять Github — он привычнее. Можно использовать бесплатный Jenkins, если есть внутренняя инфраструктура. Ну и, соответственно, интеграции со всякими облачными CI-системами типа Travis CI.

Во втором случае было бы логично использовать то, что используют команды в остальной компании, потому что все грабли уже успели собрать до вас, кто-то уже умеет с этим работать, есть какие-то построенные workflow, которые можно приспособить к своей команде.

Теперь в нём работает очень много людей. Стартап зажёг! Что добавится?
На этом этапе команда уже всё отрефлексировала и выработала свой workflow. Что изменится? Самое главное – суметь на это переехать или внедрить, но при этом не вызвать бунт в команде. Тут уже становится понятна разница между инструментами, можно выбрать что-то, что подходит команде. Если не хватает инструментов аналитики процесса разработки, то трекер задач тоже можно выбрать несколько мощнее — Jira или, например, TFS. Например, если использовался Gitlab CE, то можно его проапгрейдить до Gitlab EE и получить дополнительные фичи. Последний, как я понял, из коробки позволяет и отпуска с capacity учитывать, и графики сгорания строить, и чего только не.

То есть, если у вас есть возможность интегрировать систему контроля версий и таск-трекер, подключив один плагин — это очень хорошо. При этом большая часть автоматизации всех процессов управления ложится на интеграции между различными системами. Проблемы могут возникнуть тогда, когда такие интеграции отсутствуют, либо когда они не покрывают все необходимые сценарии.

В этом случае актором взаимодействия нескольких систем является внешняя по отношению к ним система. В этом может помочь, как я её называю, внешняя автоматизация. Тем не менее, внешнюю автоматизацию можно реализовать, не притаскивая в наш зажёгший стартап тонны кровавого энтерпрайза. Если приводить аналогию с какими-нибудь тяжелыми BPM-системами, то это был бы KIE Execution Server от Red Hat для выполнения бизнес-процессов.

Собственно, когда команда стала больше пяти человек и появилось много рутинной работы, к очевидному набору инструментов в моей команде я добавил только внешнюю автоматизацию.

Изначально я реализовал прототип, который работает и по сей день, и неспешно теперь заменяю его продакшн-решением по кускам. Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
Пресловутую внешнюю автоматизацию я и реализовал — чтобы, с одной стороны, не въезжать в полноценную BPM-парадигму своими силами, а с другой – иметь полный контроль над управлением своей командой. И это только начало — я напишу об этом отдельную статью на хабр. Для этого при поддержке Positive Technologies я даже выложил основную часть этого продакшн-решения в опенсорс на Github — это проект Flower для интеграций с системами контроля версий (Gitlab и Github), трекерами задач (Jira, TFS, etc.) и мессенджерами (Slack, Exchange).

Например, кто-то хочет иметь правила распределения задач по матрице компетенций в виде регулярных выражений и простых правил (это мой случай), а кому-то и машинного обучения для принятия таких решений будет мало. Идея в том, чтобы каждый мог собрать свою автоматизацию с нуля из готовых кубиков «Lego», дав разработчику конечного решения полный контроль над тем, что ему нужно. При этом, если у вас меняется трекер задач или система контроля версий (стартап-то зажёг) — вам достаточно было бы поменять адрес подключения, не меняя концепцию и общую логику.

Как я уже говорил, распределение задач с использованием матрицы компетенций. Что же я автоматизировал в своей команде? Далее – создание заявок и рассылка сообщений о приходе нового сотрудника, напоминания о днях рождения, текущие задачи и ещё некоторые, вроде и тривиальные, но требующие однотипных ручных действий, вещи. Второе — автоматический мердж и перевод задач в завершенный статус при прохождении кросс-ревью.

Павел Соломин, лидер чаптера Platform Engineering Sberbank Online

В нём на старте работает небольшая команда (пять программистов). Предположим, вы решили открыть свой стартап. На этом этапе пытаться внедрять для всех какие-то общие инструменты скорее вредно, чем полезно, ведь много усилий будет потрачено на приведение всех к общему знаменателю и обучение. Какие инструменты автоматизации разработки вы внедрите?
В условиях минимального количества участников за каждую область компетенции будет отвечать один человек. Тем не менее, есть области, где общие инструменты полезны. Вероятнее, что это замедлит получение MVP и не факт, что как-то поможет в дальнейшем. Для совместной работы над API подойдет любая wiki-система, мне больше других нравится Atlassian Confluence. Например, API между client-side и server-side, передача задач из дизайна в разработку. Кроме этого, даже пятью программистами нужно как-то управлять. Для передачи дизайна ничего лучше Zeplin пока не придумали. Я бы делал это при помощи Jira или Trello.

Теперь в нём работает очень много людей. Стартап зажёг! Что добавится?
У нас в Сбербанке есть проекты, над которыми одновременно работает более сотни разработчиков. Что изменится? Если попытаться уйти от этой специфики, то можно сказать следующее. Для их организации требуются довольно специфические инструменты и практики. Кроме этого нужен какой-то софт для организации сред continuous integration, continuous deployment. Для совместной работы абсолютно точно нужна система контроля версий. Где-то отслеживать таски. Где-то нужно совместно вести документацию. Мой фаворит здесь – продукты компании atlassian. Я бы использовал для решения всех этих задач софт, произведённый одной компанией – в таком случае за счёт интеграции можно бесплатно получить ряд плюшек, которых иначе либо не будет совсем, либо нужно будет как-то отдельно прикручивать. Отдельно я бы начал уделять внимание архитектуре того, как ваши приложения взаимодействуют друг с другом, иначе вся конструкция вполне может стать неуправляемой. Bamboo, Jira, Bitbacket, confluence. Тут мне нравится Sparx Enterprise Architect.

Разработчиков – больше 100 на каждое приложение. Какой несуществующий инструмент (или даже тип инструмента) вам был настолько нужен, что вы не выдержали и сделали его для себя сами?
У нас над проектом работает очень много маленьких команд – 80+. Для этого мы написали собственное приложение. Для управления эффективностью работы этих команд мы решили работать не с показателями каждой команды, а с теми случаями, которые мы считаем отклонениями от нормальных показателей. Как оно работает? Точнее, адаптировали приложение, которое было разработано для управлением продажами в наших отделениях. В том случае, если у какой-то команды это не выполняется, на её владельца продукта вешается задача разобраться с причинами. Например, мы считаем нормой, если >80% сторипойнтов, запланированных за спринт, сгорает. Таким образом задача может дойти до заместителя председателя правления (и если проблема системная, так вполне может произойти). Если через спринт ситуация повторяется – задача эскалируется на руководителя владельца продукта, если не решается ещё спринт – ещё выше. Но я сомневаюсь, что она нужна в компаниях меньшего, чем у нас, размера. Подобная система позволяет управлять ситуацией на каждом уровне организационной структуры.

На ней можно будет задать вопросы докладчикам и поделиться своим опытом. Следующая встреча, на которую ещё можно зарегистрироваться, состоится 22 мая 2018 года в московском офисе Яндекса.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть