Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Как с помощью SAFe мы встраиваем качество в продукт на ранних этапах

Меня зовут Галина, я Program QA в компании Sitecore. Летом 2022 буду отмечать 10 лет в тестировании. У меня есть опыт работы в продуктовых и аутсорс-компаниях, на позициях от мануального тестировщика, автомейшина, лида до работы в сервисной команде и выполнения задач тест-менеджера.

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

Для общего развития статья будет полезна всем, кто обеспокоен построением процессов в ІТ. Но прям очень советую для менеджеров, dev и QA-лидов — тех людей, кто может повлиять на процесс разработки.

Дано:

  • Один проект
  • 35 компонентов
  • 15+ экстеншинов
  • 14 agile-команд в разных локациях

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

Решение: SAFe

Что такое SAFe

Scaled Agile Framework — это фреймворк (набор шаблонов, правил, принципов и практик), который помогает грамотно выстраивать процессы на базе Scrum.

Фреймворк очень живой и постоянно обновляется. Есть несколько вариаций имплементации — все зависит от масштабов и потребностей конкретного проекта.

Чтобы грамотно выбрать и внедрить принципы SAFe, в нашей компании есть специалисты, которые регулярно проходят сертификацию.

На официальном сайте можно увидеть вот такую картинку с табами (как раз таки вариациями скейлинга).

Предлагаю не уходить в детали, а посмотреть на разницу между привычным Scrum и SAFe. Точнее так: сам SAFe сохраняет все из Scrum и приносит немножко достаточно много нового.

По SAFe все команды едут в одном релиз трейне — иными словами, все команды работают над одним продуктом и движутся в заданном направлении.

Перейдем к итерациям и спринтам

На схеме можно найти несколько спринтов, объединенных в одну итерацию — Program Increment. Обычно один инкремент — это 4 привычных спринта с багами, фичами и всеми регулярными активностями, плюс 1 Innovation and Planning спринт. Что за спринт такой?

В этот период у команды нет задач. Это время для обучения, импрувментов, для воли фантазии и реализации своих идей. Ну и время для планирования на будущий Program Increment.

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

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

Минусы: приходится тратить больше времени на планирование.

В процессе появляются новые роли

Release Train Engineer (RTE) — это официальная роль в SAFe. Это человек, которые задает направление продукту, следит за тем, чтобы все команды разработки двигались с заданной скоростью, напоминает о таймлайнах, общается со всеми командами.

В процессе внедрения SAFe в нашем случае возникла потребность в новой роли — Program QA. Такой должности вы не найдете в документации, да и на просторах интернета тоже.

В случае моей компании есть 14 agile-команд с классическим составом: менеджер, Dev Lead, несколько девелоперов, QA lead, QA (s). Одна команда может работать сразу над несколькими компонентами (составляющими продукта). Все процессы проходят внутри команды, опираясь на специфику их кусочка. И это нормально. И если смотреть на каждый компонент отдельно, то это вполне качественный кусок продукта, со своей динамикой, своими налаженными коммуникациями, CI-ми, тестами на разных уровнях.

Но что будет, когда все кусочки соберутся вместе? Как понять, что качество каждого кусочка равно качеству продукта? Казалось бы, все легко, но нет. Частенько в сборке выплывали новые баги. Где-то не совпадали версии одинакового пакета, где-то поменяли лицензию. Получается, надо как-то координировать QA в командах, чтобы синхронизировать процессы тестирования и обеспечить одинаковое качество всех компонент и качество продукта в сборке.

Так появилась роль Program QA. Иными словами — это test manager, но на уровне продукта. Этот человек не состоит ни в одной agile-команде.

Задачей Program QA является написание тест-стратегии для продукта, составление тест-плана для продукта, выявление рисков во время планирования, организация тест-активностей, координация тестировщиков в командах, мониторинг качества сборки продукта.

Что дают эти новые роли? Из хорошего — есть один человек (RTE), который оркестрирует все команды, следит за таймлайном, помогает быстрее принимать решение в случае выявления каких-либо проблем. И еще один человек, который помогает всем в грамотном обеспечении качества на уровне продукта.

Из плохого — это дополнительные должности в компании, т. е. дополнительные расходы.

Команды

Конечно же, никакая разработка не пойдет без привычных agile-команд со стандартным набором ролей: Product owner, scrum master, dev lead, devs, QA lead, QAs.

Но SAFe подразумевает еще и сервисные команды. Поясню на примере компании, где я работаю. У нас есть несколько сервисных команд: DevOps team, System QA team, Security and Performance team.

Про DevOps знают все. Security and Performance team — это команды, которые выполняют нефункциональные виды тестирования для каждой сборки, которую потенциально мы могли бы отдать кастомеру. А вот System QA team состоит только из Senior QAs и выполняет очень много задач на уровне продукта. Нет, эти ребята не тестируют ничего, они налаживают процессы, предоставляют лучшие практики, пишут и поддерживают тест-фреймворк для всех agile-команд, налаживают тест-инфраструктуру (иногда в коллаборации с девопсами), пишут общие скрипты для автоматизации — это могут быть скрипты и для CI, и для локального развертывания сложных инфраструктур, разворачивают комплексные сложные окружения для тестирования.

Что там за окружения такие, что команды сами не могут справиться? Бывает и такое, т. к. продукт поддерживает много фичей с базами данных, несколько серч-провайдеров, различные типы скейлинга.

Как по мне, наличие сервисных команд упрощает жизнь agile-командам в разы. Если сравнить с написанием кода, то эти команды выполняют постоянное ревью и рефакторинг что ли :)

С другой стороны, agile-команды не прокачивают свои скилы в прилегающих к разработке темах.

Страшное слово — митинги

Я знаю, практически все терпеть не могут больше 1-2 митингов в день. Я знаю, что они всех раздражают и никаких позитивных эмоций даже при одной крошечной мысли о них вы не испытываете. Но, поверьте, не все так ужасно.

В SAFe митингов достаточно много. Это и привычные митинги Agile: backlog grooming, teams planning, retrospective, sprint demo, etc. И несколько новых: PI Enablers review, PI Kickoff meeting, PI Planning, Program Level PI Planning. Поговорим о каждом из них.

Сначала — PI Enablers review

Давайте сделаем шаг в сторону для того, чтоб понять, что это за тип задач такой, и кто их создает, когда и для чего?

Такие задачи — это чаще описание того, что затронет все (или хотя бы несколько) команд в рамках PI. Может создать любой сотрудник инжиниринг-команды. Поводов может быть несколько: изменение архитектуры продукта, изменение инфраструктуры, обновление зависимостей, тестовые активности. PI Enablers создают до начала IP sprint для того, чтобы в неделю планирования все уже увидели эти задачи и могли грамотно составить свой будущий PI план.

Например, мы используем серч провайдер Solr. Мы знаем, что этот продукт объявил новый релиз. Мы хотим всегда быть up to date и использовать стильные модные молодежные фичи как только, так сразу. PM создает PI Enabler, в котором описывает, что мы должны обновить версию Solr до 8.2 (допустим, это последняя) и убедиться, что наш продукт работает корректно. Мало того, PM знает, что в этой версии есть еще новая фича, которую мы хотим поддерживать. Поэтому хайлайтит фичу в задаче. Ставит сроки в соответствии с таймлайном — в конкретном спринте, пишет, какие команды предположительно будут затронуты и сколько приблизительно времени на команду надо для реализации всех задач, вызванных таким энейблером.

Вернемся к самому митингу PI Enablers review. Он проходит на уровне команды. Команда собирается и открывает весь список PI Enablers на будущий PI, внимательно читает, задает вопросы, если что-то не ясно, если Enabler как-то затрагивает команду — то команда создает необходимые задачи.

Например, я работаю в команде, которая делает только UI-часть и обновление версии серч-провайдера меня никак не аффектит — моя команда просто будет считать такой PI Enabler как задачу информационного характера.

Но если я из бэкенд-команды, где функционал серча используется активно, то моей команде исходя из PI Enablers нужно будет запланировать и dev-задачи, и QA-задачи.

После этого приходит время для PI kickoff meeting

Это митинг, где принимают участие представители каждой команды, RTE, Program QA. Тут обсуждают вопросы от команд (если такие есть, а они есть всегда) к задачам типа PI Enabler и убеждаются в том, что все понимают всё одинаково. После этого митинга PI Enablers больше не могут быть изменены.

Следующий на очереди — PI Planning

Это митинг уровня команды. Ниже очень грубая схема PI planning sheet. Тут мы видим 5 спринтов. Желтые квадратики — это фичи и эпики, над которыми команда будет работать в этом спринте. Каждой задаче дают оценку, все оценки суммируются в цифру Load. Второй показатель — Capacity — это сумма доступных поинтов на этот спринт. Например, в команде 5 человек, мы планируем, что каждый продуктивно работает 6 часов, то capacity= 5×6 = 30. Итого, тут мы сразу видим, сколько мы можем взять в этот спринт: не более 30 стори поинтов. А лучше — меньше, чтоб учитывать незапланированные риски. В идеале — крайний спринт должен быть без задач — это спринт творчества, вы помните, да?

Кроме этого, в PI planning sheet есть отдельные секции для рисков, зависимостей, и работы, которая не вошла в PI. Риски у каждого могут быть свои: нет опыта работы с AI, нет инфраструктуры, не успеют нанять тестировщиков, и т. д.

А вот зависимости могут выглядеть так: «Мы, „команда А“, ожидаем от „команды Б“ готовую фичу „Scalable reads in MySql“ (тут линк на фичу в багтрекере) в спринте 2». И с таким успехом «команда А» может планировать в спринте 3 работу, опираясь на то, что в спринте 2 фича от «команды Б» уже будет готова.

Program level planning

А этот митинг уже уровня программы для представителей каждой команды, PMs, RTE, Program QA. Тут все команды по очереди презентуют свой PI Plan, с кратким описанием целей на PI, рисков и зависимостей. Так, во время такого митинга мы задаем вопросы другим командам и пытаемся минимизировать риски и грамотно разрулить зависимости.

Обычно проходит все в два этапа — драфт, после делаем корректировки, и файнал, где уже учтены все пункты из драфта.

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

Другое

Адаптируя фреймворк под свои процессы у нас возникло еще немножечко митингов:

  • это синк-митинги для RTE, Program QA, Build Engineer, PMs
  • QA Leads и Program QA синк митинги, где мы делимся новостями, происходит шаринг знаний, обсуждаем горящие вопросы, презентуем Program Level Test Plan для релиза
  • Program QA и Non-functional teams синки — где есть возможность проговорить статус нефункциональных видов тестирования в конкретный момент разработки для всего продукта

Каждый синк занимает до 30 минут, проводится раз в неделю или раз в спринт.

Подводя итоги, хочу оправдать такое огромное количество митингов. Если хорошенько подумать, то положительных сторон не мало: перед каждой итерацией мы видим контекст от бизнеса (на PI Kickoff meeting), мы точно знаем, на какое количество рабочего времени мы рассчитываем, мы не планируем много и «впритык», мы знаем все зависимости от других команд, мы знаем все риски и или принимаем их, или находим план смягчения, мы можем грамотно составить тест-план на уровне программы (во время и после PI Planning), мы всегда знаем актуальный статус в разработке/тестировании благодаря синк-митингам.

Из негативных сторон — это занимает достаточно много времени, но в конкретный период времени.

Как в этом процессе мы поддерживаем built-in quality

У всех команд единый таймлайн с общими майлстоунами.

  • Визибилити на каждом шагу — все в открытом доступе для каждого участника процесса разработки — багтрекинговые системы, CI, дашборд с метриками.
  • PI Planning помогает еще до начала разработки выявить практически все зависимости и риски.
  • Правила для всех: если есть процесс — все команды ему следуют. Если вчера была дата фичекомплита, то ты должен успеть закончить все работы над фичей вчера, или выбросить фичу из релиза.
  • Фокус на деливерабилити. Наши пайплайны настроены так, что каждую ночь мы имеем сборку, которую потенциально можем отдавать нашим кастомерам.

Выводы

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

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Scaled Agile Framework — это фреймворк (набор шаблонов, правил, принципов и практик), который помогает грамотно выстраивать процессы на базе Scrum.

Це не зовсім коректне твердження. ’The Scaled Agile Framework® (SAFe®) is a system for implementing Agile, Lean, and DevOps practices at scale.’ Тому, радше, масштабований Аджайл.

Команди всередині ART можуть працювати як по скраму, так і по канбану. Деякі вендори всередині фреймворку можуть взагалі не мати ніц спільного з аджайлом.Звісно, деякі конкретні імплементації SAFe можуть базуватися лише на скрамі, проте, це буде лише частковий випадок.

Сложно читать смесь русского и английского. А так...хорош agile но не везде и не всегда.

Благодарю за отзыв, учту на будущее.
Про «не везде и не всегда» — согасна. К любому выбору нужно приходить осознанно.

На официальном сайте можно увидеть вот такую картинку с табами

напомнило
генералу Стэнли Маккристалу, командующему войсками США и НАТО в Афганистане, показали в Кабуле слайд в формате PowerPoint, призванный продемонстрировать всю сложность американской военной стратегии. Он был больше похож не на схему, а на тарелку спагетти.

«Когда мы поймем этот слайд, мы выиграем войну», сухо заметил генерал Маккристал

Працював з повним SAFe на Volvo Cars. Спочатку було не звично, а потім стало зрозуміло, що для великих проектів це ледь не єдина дієздатна модель. І для розробників було все зрозуміло, що й коли робити, і менеджмент мав зворотній зв’язок і міг прогнозувати розвиток продукту більш-менш чітко.
Сумую за цією моделлю.

А теперь как оно в реальной жизни....

1 Innovation and Planning спринт

— Забудьте об этой плюшке. Это первое, что зарежет эффективный менеджмент (если вы делаете SAFe, это автоматически значит, что менеджмент у вас эффективный). Будете в это время судорожно допиливать то, что не успели в предыдущие спринты. Это вдвойне выгодно для менеджмента, т.к. если у вас не будет времени изучать новые требования, то вы не придете на ивент с неудобными вопросами и просто подпишитесь под то, что нужно менеджменту.

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

— долгосрочное планирование это не Эджайл. (responding to change over following the plan)
— разбивать все так же придется. Промежуточные спринты все так же остаются со всеми требованиями к ним.
— плюс здесь один — заставить ненавистных инженеров подписаться под безумными планами менеджмента пока те еще недостаточно в курсе дела.

Задачей Program QA является написание тест-стратегии для продукта, составление тест-плана для продукта, выявление рисков во время планирования, организация тест-активностей, координация тестировщиков в командах, мониторинг качества сборки продукта.

Не льстите себе. Главная роль этой личности — быть козлом отпущения для всех проблем с качеством, которые происходят.

PI Planning помогает еще до начала разработки выявить практически все зависимости и риски.

Если вы и вправду так думаете, значит вы просто не в курсе того, чем занимаются команды. Они разруливают все на р2р уровне не привлекая внимания санитаров.

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

Так не бывает. Всегда есть ненулевое количество важных девелоперов, которые кладут на процессы, но заменить их слишком накладно. Как вы их заставите работать по процессам? Либо кто-то заметает за них, либо нифига этот пункт не работает.

И небольшие уточнения:

Scaled Agile Framework — это фреймворк (набор шаблонов, правил, принципов и практик), который помогает грамотно выстраивать процессы на базе Scrum.

нет, как минимум упоминается возможность работы команд по кан-бану.

14 agile-команд с классическим составом: менеджер, Dev Lead, несколько девелоперов, QA lead, QA (s).

В классическом скраме нет НИ ОДНОЙ из этих ролей, кроме девелопера (и то с оговоркой). Рад что этот простой факт не мешает вам строить истинный Эджайло-скрам.

Вот, сразу видно чем практик отличается от евангелиста ;-)

SAFe — это попытка переизобрести ватерфолл с эджайл терминологией. Пока получается.

И продать курсы.

Хотел бы обратить Ваше внимание на то, что в SAFe нет такой роли как PM.

Добрый день, Алексей. Спасибо за ваш комментарий.
А вроде как есть такая роль www.scaledagileframework.com/product-management
Но вы же знаете, что все гибкие и подстраивают процессы под себя:)

Извините, я подумал, что речь шла о роли Project Manager.

А в составе Скрам команды из 5 упомянутых ролей нет 4х. Ну и подумаешь, не надо придираться.

Например, в команде 5 человек, мы планируем, что каждый продуктивно работает 6 часов, то load = 5×6 = 30. Итого, тут мы сразу видим, сколько мы можем взять в этот спринт: не более 30 стори поинтов.

я правильно понял — у вас 1 сп = 1 час?

Добрый день Денис. Да, для примера была взята такая единица. Но это просто пример)

Это и привычные митинги Agile: backlog grooming, teams planning, retrospective, sprint demo, etc. И несколько новых: PI Enablers review, PI Kickoff meeting, PI Planning, Program Level PI Planning.
у нас возникло еще немножечко митингов:
это синк-митинги для RTE, Program QA, Build Engineer, PMs
QA Leads и Program QA синк митинги, где мы делимся новостями, происходит шаринг знаний, обсуждаем горящие вопросы, презентуем Program Level Test Plan для релиза
Program QA и Non-functional teams синки — где есть возможность проговорить статус нефункциональных видов тестирования в конкретный момент разработки для всего продукта

Мало мітингів. Відлюдькуваті ви якісь, напевно.

Галя, хотя бы из твоей статьи узнаю как у нас все устроено ;) :)

Підписатись на коментарі