Новые возможности с SAFe. Часть II

«Роль Scrum Master (SM) мне предложили попробовать, так как текущий SM решил покинуть проект. Я согласилась, мне было интересно выйти из зоны комфорта.

Как SM я научилась организовывать, проводить и фасилитировать встречи, заботиться о команде и следить за настроениями внутри неё.

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

В какой-то момент я поняла, что настал момент, когда я готова двигаться дальше и пробовать себя в роли PO, мне хотелось выйти на следующий уровень управления командой и ожиданиями заказчиков, более активно участвовать в планировании. Благодаря SAFe мне представилась такая возможность.

С момента внедрения SAFe у меня повысилась вовлеченность в проект и в то, чем мы занимаемся. Появилось понимание, как и для чего нужно выстраивать процессы, желание их улучшать. А возможность попробовать себя в двух ролях позволила увидеть разные стороны одного и того же процесса. Например, опыт в роли SM мне помогает учитывать интересы команды, несмотря на то, что в роли PO я заинтересована в отстаивании интересов заказчика».

«Я работаю системным аналитиком около 6 лет. За это время пришло понимание, что у меня есть мысли по улучшению процесса, но организация работы на тот момент, а мы работали по водопаду, не очень позволяла их реализовать.

Переход в SAFe улучшил ситуацию: во-первых, один из столпов гибких методологий — это постоянное совершенствование процессов, а во-вторых, скоординировать и «подкрутить» процесс в Agile-команде гораздо проще, и даже есть специально выделенная для этого роль — Scrum Master (SM).

Как только появилась такая возможность я начал совмещать эту роль с системной аналитикой. «Разрешение» на такое совмещение появилось только в последней версии методологии, но практикуется это уже давно, и существует мнение, что это позволяет SM не отрываться от рабочих реалий.

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

«Я пришел на проект обычным разработчиком. По ходу онбординга я стал замечать, что некоторые процессы или подходы можно улучшить. Первое, на что мне удалось повлиять - это подход к ветвлению. Мы перешли с классического Gitflow на Trunk Based Development, на тот момент это был эксперимент в одном репозитории. Сейчас мы в большинстве своих сервисов перешли на этот подход. TBD рекомендован методологией SAFe, ведь он позволяет максимально быстро реализовывать и доставлять фичи, проводить пилоты и проверки гипотез, что вкупе с хорошо построенными процессами CI/CD даёт большую гибкость и эффективность.

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

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

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

Но потом пришёл SAFe. Уже на этапе формирования Agile команд стало понятно, что роль Product Owner (PO) нужно примерять кому-то из команды проекта. Если вы спросите, видел ли я себя в этой роли, то я отвечу - да, видел, но мне критически не хватало знаний и опыта в работе PO. Теоретические знания помогло получить обучение SAFe, где стали понятны процессы и обязанности ролей в команде. Но опыт пришел уже со временем. Коммуникации с заказчиками, обработка требований, декомпозиции задач, коммуникации с командой и донесение бизнес целей той или иной задачи. PO, это человек, который должен понимать ценность фичей и говорить на одном языке с PM, но при этом отстаивать интересы команды. До получения всех этих навыков и знаний элементарные вещи (это мне так сейчас кажется) вызывали сложности, а иногда и ступор.

Это был шаг в новое. Шаг на новый уровень. Я рад, что мне представилась возможность этот шаг сделать!

Сейчас впечатления каждый день новые. Есть понимание и ощущение причастности к тому, что ты разрабатываешь! Иногда приходится делать выбор в пользу того или иного решения, иногда даже приходится нежно давить и аккуратно подталкивать бизнес-заказчиков к правильному решению. Я уж не говорю о подготовке задач к груммингам, можно отдельную статью написать.

Работа в команде профессионалов - это, я вам скажу, дорогого стоит! Я всегда чувствую ответственность за продукт, над которым мы работаем. Но я также чувствую ответственность и за команду. PO - это то самое звено, на которое бизнес складывает свои запросы, и от которого команда ожидает увидеть переработанные задачи для разработки. Это обостряет чувство ответственности.

А вообще, я ни разу не пожалел о том, что примерил на себя кепку PO!»

«До работы в DexSys я не работал в больших командах по Agile и SAFe и мне было интересно попробовать разработку в крупной команде с выстроенным процессом, и работа в этой компании идеально подошла.

От работы с SAFe у меня наилучшие впечатления! Мы планируем и оцениваем задачи всей командой и нет «дамоклова меча» оценки в часах, когда ты оценил задачу в 12-16 часов, но по разным причинам вылезаешь за пределы оценки. С одной стороны, понимаешь, что невозможно оценить все факторы, с другой стороны, «ты обещал, что сделаешь задачу за 12-16 часов». Также бизнес понимает, когда ожидать фичу в «бою» и видит работу команды.

Отдельно хочу отметить смену своей роли DevOps на разработчика. Если раньше я думал о таких ценностях, как стабильность работы системы для всей команды, покрытие мониторингом ключевых метрик и удобство работы с логами, владение самыми различными инструментами, то после переквалификации в разработчика больше времени уделяю тому, как написать фичу в виде кода, который смогут прочитать другие разработчики, покрыть его unit-тестами, чтобы в будущем не бояться вносить изменения в код и быть уверенным что он работает.

Поэтому, кажется, что сейчас я занимаюсь совершенно новыми вещами и это интересно.

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

То есть SAFe дал мне возможность:

Не бойтесь пробовать новое, это развивает, вдохновляет и вносит в рабочую жизнь свежие краски. Даже если поймёте, что новая роль не для вас, всегда можно вернуться к тому, с чего начали (есть у нас и такие примеры). Это не больно ;)»