- PVSM.RU - https://www.pvsm.ru -
Вечер. Очередное R&D-собеседование подходит к концу, и наши интервьюеры настраиваются на неожиданные вопросы от будущего коллеги. Но никаких сюрпризов: соотношение, выведенное Вильфредо Парето, работает и здесь. В 80% случаев мы слышим четыре вопроса — примерно 20% от общего числа получаемых. Как у вас устроен процесс? Чем я буду заниматься? Как стать сеньором/тимлидом за год? Что по поводу релокации в Европу?
В этом посте мы ответим на первый вопрос и расскажем о процессе разработки в Veeam — от команды к команде этот ответ изменяется меньше всего.
Итак, процесс. Это повторяемая последовательность действий, ведущая к достижению успеха изо дня в день, ну или хотя бы иногда. Вы научились готовить борщ и каждый раз получается одинаково вкусно – процесс. Паркуетесь не на стук – освоили процесс. Процесс позволяет
Процесс разработки — это последовательность действий, превращающих желания пользователей в материальные продукты. Эти желания формулируются аналитиками и продакт-менеджерами, реализуются разработчиками, критически оцениваются тестировщиками, описываются техписателями.
Мы в Veeam делаем массовые продукты для бэкапа и репликации дата-центров — чтоб ничего не потерялось. Классический коробочный продукт без конкретного заказчика. На первый взгляд, вещь простая, но есть нюансы, поэтому делаем уже второе десятилетие.
Каждый релиз — это результат работы нескольких групп:
Некоторые команды предпочитают open space, но чаще — кабинеты
Команды связываются посредством системы учета требований. Мы реализовали ее на базе Microsoft Team Foundation System, так как исторически использовали ее как систему хранения версий исходников. В системе хранятся требования (requirements), дефекты (bugs) и обращения в саппорт (issues), требующие участия QA и разработчиков. В каждый выпуск вовлечены сотни участников, которые работают над тысячами задач, требований и дефектов. Система помогает удержать все это и, что более важно, равномерно распределять нагрузку, расставить приоритеты для разработчиков.
Разработка нашего продукта циклична, каждый цикл заканчивается выпуском очередной версии — релизом. Вот что находит отражение в релизах:
Каждый квартал у нас выходят обновления (апдейты), примерно раз в год — крупные (мажорные) релизы. Они хороши тем, что минимизируют накладные расходы на создание объемной функциональности, связанной с поддержкой новых платформ и сменой парадигм. Исходя из особенностей бюджетирования, IT-департаменты клиентов наиболее активны в конце года, так что и большие релизы мы тоже выкатываем в это время.
Квартальные апдейты в основном преследуют две цели — поддержку новых версий защищаемых серверов и устранение дефектов. В обновлениях мы собираем все исправления дефектов, обнаруженных у клиентов с момента выпуска мажорной версии. Также с помощью обновлений мы оперативно реагируем на изменения в поддерживаемых платформах. По условиям SLA Veeam должен добавить поддержку новой версии гипервизора не более чем за три месяца.
А что делать, если продукт не работает у конкретного клиента? В этом случае выпускаем приватное исправление — проще говоря, костыль. Такие фиксы выпускаются каждую неделю и не всегда связаны с дефектами в продукте. Например, настройки системы безопасности у клиента могут быть несовместимы с продуктом. Выпуская приватный фикс, мы анализируем частотность проблемы и решаем, стоит ли включать фикс в последующее квартальное обновление.
Каждый релизный цикл начинается с планирования — на уровне продукта в целом и на уровне отдельно взятого требования. В первом случае решается вопрос бизнес-приоритетов и распределение требований между командами. В первую очередь, обсуждаются самые срочные требования или эпики. По-хорошему, на эпики стоит отводить не более 60% всего объема работ над релизом, чтобы была подушка времени. Продуктовое планирование осуществляется на уровне руководителей департаментов — продакты, тестировщики, разработчики.
Разработчики и тестировщики делятся на команды. Оптимальное количество людей в команде — пять. Команды бывают как функциональными, так и универсальными. В последнем случае команда самодостаточна, содержит разработчиков с экспертизой в нескольких областях. Функциональные команды более узконаправленные — они работают над пользовательским интерфейсом, системными компонентами и т.д. Люди из разных функциональных команд образуют виртуальные команды, которые начинают реализацию требований. Здесь, как минимум, собираются представители PM-группы, команд разработки и тестирования. Ответственным за требование назначается тимлид одной из функциональных команд.
Начинается работа над требованием. Виртуальная команда встречается еженедельно. Участники рассказывают об успехах за прошедшую неделю и планируют работу на следующую.
Ответственный за требование тимлид модерирует встречи и протоколирует результаты. Он же решает вопросы, которые внутри виртуальной команды решить невозможно. Например, если нужно сдвинуть сроки или отложить часть задач.
Внутри функциональных команд разработки или тестирования точки контроля расставлены более плотно. Как правило, недельный план делится на задачи длительностью не более двух-трех дней. В некоторых командах прижились скрам-практики с ежедневными летучками, где-то более эффективно работает взаимодействие «точка-точка» между тимлидом и командой.
Типичная переговорка для обсуждения текущего статуса проекта
Вся разработка делится на недельные или двухнедельные итерации. В ходе первых итераций нужно создать минимально работающий функционал, который в дальнейшем будет обрастать мясом — например, расширенным пользовательским интерфейсом, API для клиентов и т.д. А главное, что наличие скелета уже позволяет тестировщикам заводить фичу.
Релизный цикл включает в себя альфа- и бета-релизы. С их помощью мы показываем новые функции внешнему миру и заранее собираем отзывы. При необходимости меняются решения по архитектуре или функциональности. До состояния альфы и беты сценарии доводятся не сразу, а пачками. Как правило, в релизном цикле присутствует порядка двух бет.
После стадии беты команды переходят в режим регрессионного тестирования. На этой стадии продукт, в целом, уже работает, пользовательский интерфейс и сценарии работы уже затвердели и меняются с меньшей интенсивностью. В дело вступает команда технических писателей. Параллельно происходит обучение команд технической поддержки.
Регрессионное тестирование ведется двухнедельными циклами. Длительность цикла определяется временем, необходимым на просмотр всех сценариев продукта. Чем больше продукт, тем больше сценариев и, соответственно, циклов. Перед последним циклом объявляется кодлок. Это значит, что в продукт будут вноситься только критически важные изменения — и только после многочисленных код-ревью. Такие драконовские методы нужно нужны для того, чтобы случайно не внести в продукт новые дефекты.
Чем ближе момент релиза, тем больше свободного времени у разработчиков и меньше — у всех остальных. Продакт-менеджерам нужно подготовить пресс-релизы, скоординировать работу служб маркетинга. Тестировщики должны проверить фиксы и осуществить финальное регрессионное тестирование. Технические писатели дописывают пользовательскую документацию. В это благодатное время разработчики разворачивают исследовательскую деятельность для требований уже следующей версии.
И вот он волнительный момент, именуемый RTM — Ready To Market. Это значит, что продукт уже готов к передаче потребителям. В течение двух недель его будут терзать журналисты, сервис-провайдеры. Он будет показываться на презентациях. Спустя две недели продукт станет доступен всем. В это время происходят и внутренние изменения: готовятся новые ветки разработки, осуществляется депонирование кода. И, конечно, поднимается билд-инфраструктура под следующую версию. После публичного выпуска (GA), наступает горячее время для службы технической поддержки. А остальные уже работает над следующей версией.
И напоследок немного матчасти. Как известно, в троице «быстро, качественно, недорого» можно выбрать максимум два варианта. Качество, сроки и функциональность постоянно дерутся между собой. У нас в коробочном продукте качество стоит на первом месте. Хм, а что есть какая-то область, где качество неважно? Конечно же, нет. Весь вопрос в определении качества.
Для нас качество – это:
С таким набором приоритетов для сохранения качества нужно всегда что-то комбинировать, причем как разработчикам, так и тестировщикам. Небольшие изменения в поведении функций могут привести к вынужденному интеграционному перетестированию львиной доли продукта. Попробуйте добавить поддержку азиатских локалей в продукт и поймете, о чем речь. Поэтому вопрос приоритетов — это вопрос совместного обсуждения PM-ов, тестировщиков и разработчиков.
Вторым, почти нерушимым приоритетом являются сроки. В случае обновлений сроки выпуска задаются SLA, в случае больших релизов — бизнес-календарем. По статистике в каждом релизном цикле почти 50% времени уходит на разработку, 50% — на доведение продукта до ума (стадия багфикса).
Что может изменяться, так это функциональность очередного релиза. Здесь помогает приоритизированный список требований, или бэклог. Теоретически все просто: выбираете из бэклога следующую по приоритету функцию, смотрите за оставшимся временем. Когда время близко к исходу, останавливаетесь и выпускаете очередную версию продукта. Дьявол же скрыт в нюансах:
Здесь вступает в дело гибкая разработка. Для нас гибкая разработка означает необходимость периодического перепланирования. Стали известны новые обстоятельства — поменяли планы. Добавились новые приоритетные требования в бэклог — поменяли планы. Не успеваем с неоткладываемыми требованием — режем часть задач или изменяем требование. В теории технического управления это называется системой с обратной связью. Вспомните, как работает автопилот.
Любое планирование в условиях выше опирается на экспертную оценку. Экспертная оценка ответственного за требование тимлида является тем элементом, который делает весь последующий процесс четким и структурированным. Иное название экспертной оценки — «метод ленинского прищура», как любит повторять Александр Орлов из «Стратоплана». Это когда вы на основании предыдущего опыта и интуиции принимаете решение. Несмотря на возможную критику, это работает. Работает, как и все наши описанные выше процессы. Если у вас остались по ним вопросы, приглашаем в комментарии.
Текущий техпроцесс комфортен и уютен как домашние тапочки. Проблема только в том, что в Veeam какое-то невидимое шило всегда подгоняет: быстрее, больше, еще, еще.
Cовсем недавно строили пилотные офисы в Финляндии и Чехии, а уже в этом году готовимся к большому открытию Пражского R&D центра на несколько сотен человек.
Лобби нашего пражского офиса
Недавно появился офис разработки в Израиле, растут команды в Канаде и Германии. Увеличивается количество совместных проектов разработки с HP, NetApp, Nutanix, EMC.
Мануфактура превращается в географически распределенный конвейер, а вместе с тем кристаллизуются и новые процессы. Впрочем, это тема для отдельной статьи.
Stay connected.
Автор: Александр Баранов
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/292462
Ссылки в тексте:
[1] мозгу: http://www.braintools.ru
[2] Источник: https://habr.com/post/422831/?utm_source=habrahabr&utm_medium=rss&utm_campaign=422831
Нажмите здесь для печати.