Новые возможности с SAFe. Часть I
Мы уже рассказывали какие плюсы в разработке и для бизнеса принесло внедрение SAFe у нашего Заказчика. В этой статье 10 сотрудников DexSys решили рассказать о том, какие положительные перемены и новые возможности принес SAFe участникам команды разработки.
Статья о том, как внедряли SAFe на этом проекте:
SAFE и новая структура
Благодаря внедрению SAFe у нас появилась возможность попробовать себя в ролях «Scrum Master», «Product Owner», а также в достаточно специфических для SAFe: «RTE» и «System Engineer».
Одна из основных компетенций SAFe - культура непрерывного обучения, причем не только в своей профессии, но и в смежных навыках, вплоть до полного перехода в новое направление. Такой подход позволяет командам компенсировать недостающие компетенции.
Осуществить такой переход или совмещать несколько ролей, например, быть одновременно Scrum Master-ом и при этом оставаться аналитиком, тестировщиком или разработчиком, в SAFe позволяют гибкость, подразумеваемая методологией, поддержка со стороны Lean-Agile лидов и специально заложенные технические спринты. В каждом пятом спринте помимо стандартных мероприятий заложено время на развитие, как проекта, так и своих навыков. Например, функциональный тестировщик может попробовать инструменты автотестирования.
Наша команда решила поделиться своими впечатлениями от изменений, произошедших в нашей профессиональной деятельности после внедрения SAFe.
Scrum Master, Release Train Engineer, тимлид:
«Мой путь от тимлида группы разработки сначала в Scrum Master и затем в Release Train Engineer (RTE):
Ещё до внедрения SAFe на нашем проекте мне повезло пройти обучение Leading SAFe с другими руководителями Заказчика, поскольку на других проектах SAFe уже активно внедрялся. В этот фреймворк я влюбилась сразу и по ходу обучения поняла что мне интересна роль RTE: мне нравятся процессы, мне нравится Agile, а теперь и SAFe.
Я чувствовала что могу принять активное участие в перестроении текущих процессов и их развитии на нашем проекте. RTE — это скрам скрамов, если можно так сказать, поэтому я решила для начала попробовать свои силы в рамках команды в качестве SM. Работа в роли SM помогла почувствовать себя на месте ребят-скрамов, с которыми мне предстояло плотно работать в качестве RTE, погрузиться в трудности, с которыми сталкиваются команды, прокачать soft skills.
Кроме того, мы начинали изменения в проекте с двух команд и ни о каком поезде речи еще не было, стояла задача наладить Agile. Поэтому переход к RTE пришлось немного отложить и какое-то время я была SM в одной из команд. А после обучение на RTE я окончательно и бесповоротно убедилась что это работа моей мечты :) Учёба очень помогла в понимании своих обязанностей (у RTE, как выяснилось, это довольно внушительный список), инструментов, метрик и много чего ещё. Стало понятно, чего в процессах нам не хватает и куда двигаться дальше.
Если сравнивать две роли, то быть SM - интересно, непредсказуемо и сложно, роль SM больше ориентирована на людей, а RTE — на процесс, кроме того роль RTE охватывает масштаб всего поезда, а не только одной команды. Мне нравится работать с людьми в команде, но всё-таки быть «хранителем SAFe» и принимать участие в управлении всем поездом мне ближе».
Product Owner, backend-разработчик, тимлид:
«На момент, когда наша команда присоединилась к разработке нового проекта, другие команды уже работали над ним по методологии SAFe. До этого наша команда занималась поддержкой старого проекта, а я совмещал в ней роли тимлида и разработчика, в том числе отвечал за поставки на продуктив.
В связи с изменением методологии с «водопада» на SAFe, у меня была возможность выбрать роль Product Owner (PO) или Scrum Master (SM). Я выбрал PO, так как это лучше подходило с точки зрения поддержки старого проекта. В роли SM меня пугала необходимость «работать с людьми». Тогда я ещё не понимал насколько важно общение для гибкой разработки. На регулярных встречах мы прорабатывали детали реализации продукта, легко подстраиваясь под возникающие в процессе разработки новые требования.
Через почти год работы по SAFe общая повестка для меня поменялась с негативной (поддержка - это баги, проблемы и т.д.) на созидательную (строим новый продукт).
Роль PO довольно сложно совмещать с полноценной разработкой и поддержкой, поэтому сейчас я почти не пишу код для нового проекта. Вместе с тем, при необходимости я помогаю команде в написании документации и в тестировании, т.к. методология поощряет развитие во всех направлениях. Я получил много опыта в командной работе, развил soft skills. Например, очень полезным был курс по фасилитации - благодаря подобным навыкам команда эффективнее строит внутреннее взаимодействие».
Системный аналитик:
«На проекте возникла потребность в аналитиках, и мне поступило предложение попробовать себя в новом направлении. Поначалу я сомневался в этой идее, поскольку на тот момент я был функциональным тестировщиком и планировал дальнейшее развитие с уклоном в автотестирование. Но, поразмыслив немного, решил согласиться - аналитика меня уже давно интересовала. Все аналитики казались жрецами, обладающими сакральными знаниями системы и имеющими доступ ко всем сокровенным тайнам проекта.
К тому же, при работе в команде по SAFe, легко можно совмещать эти роли: тестировать, будучи аналитиком, и писать документацию, будучи тестировщиком. Следовательно, смену роли я воспринял как расширение компетенций, которое откроет мне доступ к чему-то тайному и неизведанному.
Итоги от смены направления можно выделить следующие: прежде всего, я не получил доступ к чему-то сакральному, тайному, дающему ответы на все вопросы о системе.
Однако, я освоил кое-что получше: это принцип работы, позволяющий создавать из желаний и требований заказчиков работающий функционал и новые алгоритмы. Одновременно с этим у меня появилось новое понимание ответственности за свои результаты.
Командная работа позволяет держать на контроле процесс превращения описанных мной алгоритмов в новый готовый продукт и оперативно решать все возникающие проблемы и нестыковки в разрабатываемом функционале.
И, конечно, в аналитике очень пригодился прежний опыт тестирования, уже при написании документов постепенно пришло понимание «куда могут залезть» тестировщики в своих тест-кейсах и возможность заранее описать эти «спорные» моменты, предотвратив множество будущих багов».
Frontend-разработчик
«С внедрением SAFe на проекте у меня появилась возможность попробовать себя в роли куратора гильдии frontend-разработчиков.
В рамках данной роли я помог коллегам составить их первые индивидуальные планы развития, которые позволили им лучше понимать и отслеживать свой рост в профессии, менторил новичков, проводил технические интервью и one-to-one.
Роль куратора потребовала прокачки soft skills, поэтому я прошел тренинг по получению обратной связи, который помог мне эффективнее коммуницировать с коллегами.
С самого начала я хотел проверить насколько мне подходит данная роль. Попробовав на практике, понял, что на данном этапе мне хочется заниматься разработкой, T-shape развитием и, в перспективе, двигаться в сторону System Engineer.
Однако, я продолжаю участвовать в проведении технических интервью, а также менторить новичков, поскольку напрямую заинтересован в тех, с кем буду ежедневно работать. Помимо этого я провожу ретроспективы в своей команде, потому что считаю это важной частью процесса, которая сближает команду, помогает выявлять проблемы и анализировать результаты. И, хотя мои навыки фасилитатора далеки от идеала, я работаю над их улучшением.
Здорово, что SAFe позволяет попробовать себя в разных качествах и поощряет всестороннее развитие. Получается действительно гибко».
Системный аналитик, Scrum Master:
«К моменту, когда мы прошли обучение и стали внедрять новый фреймворк, я проработал системным аналитиком на проекте менее полугода.
После обучения мы сформировали несколько команд полного цикла разработки, в каждую команду вошли системный аналитик, back- и front-разработчики, функциональные тестировщики, автоматизатор, Scrum Master (SM) и Product Owner.
В нашей команде роль SM выполнял выделенный для этой роли сотрудник, который проходил дополнительное обучение и в дальнейшем планировал стать RTE, Scrum Master-ом Scrum Master-ов, человеком, отвечающим за координацию, фасилитацию и организацию процесса работы программы.
Буквально через 3 месяца был поставлен вопрос, кто в дальнейшем будет исполнять роль SM в нашей команде. Вариантов было два: искать внешнего SM или обойтись внутренними ресурсами уже достаточно зрелой команды. Решили идти по второму пути, на эту роль предложили мою кандидатуру.
Первое время меня пугала новая задача. Я опасался, что дополнительные коммуникации и организационные вопросы будут отнимать слишком много времени и это негативно скажется на качестве моей работы как системного аналитика.
Заручившись поддержкой моей команды и коллег, которые также совмещают свои основные роли с ролью SM в других командах, я прошел дополнительное обучение и приступил к исполнению роли SM.
Роль SM позволила мне повысить дисциплинированность, навыки организации, проведения и протоколирования итогов встреч, увеличивая их эффективность и целенаправленность; научила меня помогать команде, выявлять и устранять препятствия, для достижения поставленных целей.
Когда у меня возникают вопросы или проблемы, с которыми я не могу справится самостоятельно, я всегда могу обратиться за помощью или советом в гильдию Scrum Master-ов, которая объединяет более двадцати участников.
Я продолжаю расширять свои компетенции - в нашей команде мы продолжаем развивать T-shape. Мы осуществляем разработку 2-х недельными спринтами. В конце спринта на тестировщиков ложится максимальная нагрузка, поэтому помимо роли системного аналитика и SM периодически я исполняю роль тестировщика, подключаясь к разбору ошибок, а также результатов выполнения автотестов. Это позволяет нашей команде довести до конечного пользователя максимальное количество выполненных задач, повышая его лояльность и удовлетворенность продуктом.
Я не пожалел о своем решении и готов продолжать расти как специалист в команде и за ее пределами».