Хабрахабр

Внутренняя кухня Veeam: как устроен R&D процесс

Вечер. Очередное R&D-собеседование подходит к концу, и наши интервьюеры настраиваются на неожиданные вопросы от будущего коллеги. Но никаких сюрпризов: соотношение, выведенное Вильфредо Парето, работает и здесь. В 80% случаев мы слышим четыре вопроса — примерно 20% от общего числа получаемых. Как у вас устроен процесс? Чем я буду заниматься? Как стать сеньором/тимлидом за год? Что по поводу релокации в Европу?

В этом посте мы ответим на первый вопрос и расскажем о процессе разработки в Veeam — от команды к команде этот ответ изменяется меньше всего.

Это повторяемая последовательность действий, ведущая к достижению успеха изо дня в день, ну или хотя бы иногда.
Итак, процесс. Паркуетесь не на стук – освоили процесс. Вы научились готовить борщ и каждый раз получается одинаково вкусно – процесс. Мозг освобождается для творчества. Процесс позволяет мозгу не задумываться каждый раз над рутиной, превращая ее в механическую работу.

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

Классический коробочный продукт без конкретного заказчика. Мы в Veeam делаем массовые продукты для бэкапа и репликации дата-центров — чтоб ничего не потерялось. На первый взгляд, вещь простая, но есть нюансы, поэтому делаем уже второе десятилетие.

Действующие лица

Каждый релиз — это результат работы нескольких групп:

  • Продакт-менеджеры, или аналитики. Они расставляют приоритеты в работе, общаясь с внешним миром — клиентами и партнерами. Партнерство может быть в том числе технологическим. Например, дистрибьютор может подсказать, чего ему не хватает для увеличения продаж, а производитель гипервизора — рассказать о планах на будущее. Для этой команды важно «умение говорить», способность ловить и приоритизировать тенденции в бурном потоке мнений. А затем отстоять выбранную позицию, сказать «нет», объяснить, почему что-то сделано именно так, а не иначе. Неважно, в пресс-релизах, на конференциях или в частном порядке. Эти люди обучают мир сейлзов.
  • Служба технической поддержки. Телефон доверия наших клиентов. Важнейшие показатели команды — время реакции на проблему и время ее разрешения (SLA). В течение месяца обслуживается порядка нескольких тысяч обращений. Команда многослойна, включает в себя как группы взаимодействия с клиентами, так и группы аналитики обращений, выработки обходных решений и т.д. На основе информации, получаемой саппортом, формулируется список улучшений и срочность — реализовать ли в приватном фиксе, следующем обновлении или отложить на мажорный релиз.
  • R&D-разработчики. Люди, которые материализуют запросы в код.
  • Тестировщики, или QA. Первоиспытатели, танковый полигон и вибростенд одновременно.  Они не только проверяют то, что уже реализовано — но и подключаются к работе еще на этапе задумки. Повторяя задачи администраторов в инфраструктуре, приближенной к боевой, легче понять, насколько удобен созданный интерфейс или производительны выбранные алгоритмы. Когда техническая поддержка приходит к мнению, что в продукте есть дефект, QA воспроизводит проблемные сценарии и контролирует исправления.
  • Команда технических писателей. Они создают документацию для конечных пользователей, а также специфические документы типа «How it works» и «Deployment guide». Материал для работы они получают от разработчиков, тестировщиков и аналитиков.


Некоторые команды предпочитают open space, но чаще — кабинеты

Мы реализовали ее на базе Microsoft Team Foundation System, так как исторически использовали ее как систему хранения версий исходников. Команды связываются посредством системы учета требований. В каждый выпуск вовлечены сотни участников, которые работают над тысячами задач, требований и дефектов. В системе хранятся требования (requirements), дефекты (bugs) и обращения в саппорт (issues), требующие участия QA и разработчиков. Система помогает удержать все это и, что более важно, равномерно распределять нагрузку, расставить приоритеты для разработчиков.

Годичные кольца: циклы разработки

Разработка нашего продукта циклична, каждый цикл заканчивается выпуском очередной версии — релизом. Вот что находит отражение в релизах:

  • Долгоиграющие тенденции на рынке. Например, виртуализация и появление облачных инфраструктур. Изменение парадигм работы IT занимает годы — в это время пользователи переходят от подозрения и отрицания («что это за хрень») к массовому признанию («да все так делают»). Виртуализация дата-центров в свое время породила Veeam, так как в условиях виртуализации старые продукты для резервного копирования машин были неэффективны.
  • Поддержка новых платформ. Когда-то давно Veeam был предназначен только для виртуализованных дата-центров на платформе VMWare. С ростом количества и размера клиентов возникла потребность в поддержке новых платформ. В довесок к VMWare появились другие гипервизоры (Hyper-V), физические сервера, облачные платформы (AWS, Azure) и т.д.
  • Тактические изменения на рынке. Выпускаются очередные версии операционных систем и гипервизоров. Накапливается опыт использования предыдущих версий нашего продукта. Например, так у нас появилась поддержка item-level — выборочное восстановление из популярных серверов приложений, таких как Microsoft Exchange, Microsoft SQL Server, Oracle Databases и т.д.
  • Дефекты. Несмотря на все наши старания, жизнь нет-нет, да и преподносит сюрпризы. Разумеется, мы стараемся сводить их к минимуму.

Каждый квартал у нас выходят обновления (апдейты), примерно раз в год — крупные (мажорные) релизы. Они хороши тем, что минимизируют накладные расходы на создание объемной функциональности, связанной с поддержкой новых платформ и сменой парадигм. Исходя из особенностей бюджетирования, IT-департаменты клиентов наиболее активны в конце года, так что и большие релизы мы тоже выкатываем в это время.

В обновлениях мы собираем все исправления дефектов, обнаруженных у клиентов с момента выпуска мажорной версии. Квартальные апдейты в основном преследуют две цели — поддержку новых версий защищаемых серверов и устранение дефектов. По условиям SLA Veeam должен добавить поддержку новой версии гипервизора не более чем за три месяца.
А что делать, если продукт не работает у конкретного клиента? Также с помощью обновлений мы оперативно реагируем на изменения в поддерживаемых платформах. Такие фиксы выпускаются каждую неделю и не всегда связаны с дефектами в продукте. В этом случае выпускаем приватное исправление — проще говоря, костыль. Выпуская приватный фикс, мы анализируем частотность проблемы и решаем, стоит ли включать фикс в последующее квартальное обновление. Например, настройки системы безопасности у клиента могут быть несовместимы с продуктом.

От рассвета до заката: хроника релиза

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

Оптимальное количество людей в команде — пять. Разработчики и тестировщики делятся на команды. В последнем случае команда самодостаточна, содержит разработчиков с экспертизой в нескольких областях. Команды бывают как функциональными, так и универсальными. Люди из разных функциональных команд образуют виртуальные команды, которые начинают реализацию требований. Функциональные команды более узконаправленные — они работают над пользовательским интерфейсом, системными компонентами и т.д. Ответственным за требование назначается тимлид одной из функциональных команд. Здесь, как минимум, собираются представители PM-группы, команд разработки и тестирования.

Виртуальная команда встречается еженедельно. Начинается работа над требованием. Он же решает вопросы, которые внутри виртуальной команды решить невозможно. Участники рассказывают об успехах за прошедшую неделю и планируют работу на следующую.
Ответственный за требование тимлид модерирует встречи и протоколирует результаты. Например, если нужно сдвинуть сроки или отложить часть задач.

Как правило, недельный план делится на задачи длительностью не более двух-трех дней. Внутри функциональных команд разработки или тестирования точки контроля расставлены более плотно. В некоторых командах прижились скрам-практики с ежедневными летучками, где-то более эффективно работает взаимодействие «точка-точка» между тимлидом и командой.


Типичная переговорка для обсуждения текущего статуса проекта

В ходе первых итераций нужно создать минимально работающий функционал, который в дальнейшем будет обрастать мясом — например, расширенным пользовательским интерфейсом, API для клиентов и т.д. Вся разработка делится на недельные или двухнедельные итерации. А главное, что наличие скелета уже позволяет тестировщикам заводить фичу.

С их помощью мы показываем новые функции внешнему миру и заранее собираем отзывы. Релизный цикл включает в себя альфа- и бета-релизы. До состояния альфы и беты сценарии доводятся не сразу, а пачками. При необходимости меняются решения по архитектуре или функциональности. Как правило, в релизном цикле присутствует порядка двух бет.

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

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

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

Это значит, что продукт уже готов к передаче потребителям. И вот он волнительный момент, именуемый RTM — Ready To Market. Он будет показываться на презентациях. В течение двух недель его будут терзать журналисты, сервис-провайдеры. В это время происходят и внутренние изменения: готовятся новые ветки разработки, осуществляется депонирование кода. Спустя две недели продукт станет доступен всем. После публичного выпуска (GA), наступает горячее время для службы технической поддержки. И, конечно, поднимается билд-инфраструктура под следующую версию. А остальные уже работает над следующей версией.

О приоритетах

И напоследок немного матчасти. Как известно, в троице «быстро, качественно, недорого» можно выбрать максимум два варианта. Качество, сроки и функциональность постоянно дерутся между собой. У нас в коробочном продукте качество стоит на первом месте. Хм, а что есть какая-то область, где качество неважно? Конечно же, нет. Весь вопрос в определении качества.
Для нас качество – это:

  • Сохранение надежности и производительности в зоопарке конфигураций. У одного клиента скромный дата-центр из двух серверов времен Бородинской битвы, а у другого – high-end инфраструктура в соседнем ангаре с Amazon. Продукт должен работать адекватно в обоих случаях.
  • Простота использования. Пользователь должен напрягаться по минимуму и уж точно справляться без всяких инструкций. Но за внешней простотой далеко не всегда скрывается аналогично простой код — попробуйте скрестить ужа с ежом бесшовно.
  • Наследуемость. Инвестиции у предприятий многолетние, и финансовые директора не будут тратиться на IT без веской причины. Так что нужно сохранять совместимость и с предыдущими версиями, и со смежными продуктами. Нередко при перестройке дата-центров в стену замуровывают почтовые сервера эпохи 80-х. А они все жужжат и помирать не думают.

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

В случае обновлений сроки выпуска задаются SLA, в случае больших релизов — бизнес-календарем. Вторым, почти нерушимым приоритетом являются сроки. По статистике в каждом релизном цикле почти 50% времени уходит на разработку, 50% — на доведение продукта до ума (стадия багфикса).

Здесь помогает приоритизированный список требований, или бэклог. Что может изменяться, так это функциональность очередного релиза. Когда время близко к исходу, останавливаетесь и выпускаете очередную версию продукта. Теоретически все просто: выбираете из бэклога следующую по приоритету функцию, смотрите за оставшимся временем. Дьявол же скрыт в нюансах:

  • Неопределенность требований. Например, требование «поддержать резервное копирование физических машин на OS Linux» может в дальнейшем сильно уточняться. Какие ядра должны поддерживаться? Какие дистрибутивы? Какие файловые системы? Одно и то же высокоуровневое требование можно реализовать и за месяц, и за год. Вопрос в полноте.
  • Команды имеют специализации. Не любое требование может быть взято любой командой. C#-разработчик не напишет драйверы, разработчик системных компонентов не всегда справится с web-разработкой.
  • Требования зависят друг от друга. Это не всегда видно на уровне пользовательских сценариев, но внутри такие связи есть. С точки зрения внешнего мира поддержка резервного копирования с файловых систем NTFS и ExtFS могут быть требованиями с разным приоритетами, но внутри вначале надо будет написать общий движок.
  • Требования делятся на откладываемые и неоткладываемые. Если рынок ждет в очередной версии какую-то функцию, и она была анонсирована, то отложить ее не получится.
  • Часть требований предполагает исследовательскую работу. Без результатов исследовательской работы невозможно планировать сложность задачи (может, она вообще невыполнима), а спрогнозировать эти результаты бывает сложно.

Здесь вступает в дело гибкая разработка. Для нас гибкая разработка означает необходимость периодического перепланирования. Стали известны новые обстоятельства — поменяли планы. Добавились новые приоритетные требования в бэклог — поменяли планы. Не успеваем с неоткладываемыми требованием — режем часть задач или изменяем требование. В теории технического управления это называется системой с обратной связью. Вспомните, как работает автопилот.

Экспертная оценка ответственного за требование тимлида является тем элементом, который делает весь последующий процесс четким и структурированным. Любое планирование в условиях выше опирается на экспертную оценку. Это когда вы на основании предыдущего опыта и интуиции принимаете решение. Иное название экспертной оценки — «метод ленинского прищура», как любит повторять Александр Орлов из «Стратоплана». Работает, как и все наши описанные выше процессы. Несмотря на возможную критику, это работает. Если у вас остались по ним вопросы, приглашаем в комментарии.

Что дальше?

Текущий техпроцесс комфортен и уютен как домашние тапочки. Проблема только в том, что в Veeam какое-то невидимое шило всегда подгоняет: быстрее, больше, еще, еще.
Cовсем недавно строили пилотные офисы в Финляндии и Чехии, а уже в этом году готовимся к большому открытию Пражского R&D центра на несколько сотен человек.


Лобби нашего пражского офиса

Увеличивается количество совместных проектов разработки с HP, NetApp, Nutanix, EMC.
Мануфактура превращается в географически распределенный конвейер, а вместе с тем кристаллизуются и новые процессы. Недавно появился офис разработки в Израиле, растут команды в Канаде и Германии. Впрочем, это тема для отдельной статьи.
Stay connected.

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

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

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

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

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