Всем привет!
Статей на Хабр я раньше не писал и поэтому расскажу немного о себе.
ТТХ автора:
Имя - Андрей;
Возраст - 25 лет;
Опыт работы - мог бы быть и побольше.
Моя «стремительная» карьера разработчика началась в далёком 2019 году и за это время я успел поработать в двух компаниях. О первой компании скажу, что это был отличный опыт в отличной компании и я многому там научился. А сегодня я работаю разработчиком в блоке развития и поддержки Автоматизированной Банковской Системы (АБС) в РСХБ-Интех, чему я очень рад.
Эта статья написана, чтобы поделиться своим мнением о первом опыте взаимодействия с Agile, поэтому она может быть полезна таким же начинающим разработчикам как я или тем, кто ещё не сталкивался с подобного рода командами.
Итак, что мы имеем?
Я — разработчик со сравнительно небольшим опытом разработки и, как следствие, гипертрофированной жаждой нового опыта, она и побудила меня написать эту статью. И с самого начала моей работы меня преследует вопрос: «Как же мне этот опыт заполучить?» Для ответа на него я не стал придумывать ничего нового, а пытался залезть везде, где только можно, вернее, подписывался и подписываюсь на любые задачи, которые попадают в поле моего зрения. Временами это выходило мне боком, но сегодня не об этом.
А сегодня вот о чем
Мне, как, наверное, многим другим разработчикам в начале карьеры было трудно детально представить себе процесс разработки в различных командах. А с учётом того, что до недавнего времени я был частью корабля команды с, по большей части, классической моделью управления «водопад», почерпнуть опыт и развеять все мои домыслы насчёт Agile мне не доводилось. Надо сразу отметить, что в основном, принцип работы в предыдущей команде был классическим, но были в нем и некоторые заимствования: скрамы, рэтро и несколько вариантов канбан-доски. Так что я не был совсем новичком в этом вопросе.
Так вот, несколько месяцев назад коллегам, работающим над единым фронт-офисным решением (ЕФР), потребовался ресурс разработчика АБС и мне выпала возможность окунуться в Agile и немного потрогать интеграционные сервисы. А, как было написано выше, я не могу устоять перед такими возможностями. Выбор слов тут не случаен, мне выпала возможность поработать именно «С» командой. Дело в том, что команда, в которой мне предстояло работать, состоящая из двух разработчиков (включая меня) и двух аналитиков, имеет отдельный бэклог задач. Но двигается по нему параллельно разработке, ведущейся в основной команде, конечно же с соблюдением приоритетов и сроков.
Так что там с Agile?
Естественно, как любой другой разработчик, прежде чем столкнуться с неизведанным, я полез освежать память о том, как же будет строиться дальнейшая работа и с чем мне, собственно, предстоит иметь дело. Прочитав существующую информацию во внутреннем пространстве о том, как работает Agile в Интехе, я двинул в открытый интернет читать мнения людей, которые уже столкнулись с этим зверем на практике. Освоив ещё несколько статей у меня сложилось мнение, что предстоит мне работать в корпоративной секте, а я не очень-то большой их фанат.
Итак, первое, что пишут: Agile — идеология со своим манифестом и жертвоприношениями. У неё есть свои методологии, самые известные — это Scrum и Kanban, используя которые можно добиться воплощения принципов, описанных в манифесте. Обе, кстати, практикуются в нашей компании. Затем я дошел до описания вещей, которые не сделали мой день лучше. Я говорю о большом множестве непонятных терминов, должностей и разнообразии собраний, которые пафосно называются «Церемонии». Помимо этого, были ещё различные критерии приёмки, метрики работы команды, инструменты для работы и конечно же сбор обратной связи. Прочитав всё это в первый раз, я не понимал почему, чтобы улучшить процесс разработки, необходимо всё так усложнить.
Всё же разобравшись со всеми терминами и вроде бы усвоив как всё должно работать, мне не терпелось узнать, как это работает на самом деле. Честно говоря, на месте Agile команды фантазия рисовала мне толпу эдаких слишком позитивных людей, которые замотивированы так сильно, что каждый второй из них коучер с застывшей улыбкой на лице. Но больше всего меня беспокоил не вопрос «сектантства», а проблема большого количества бесполезных мероприятий, о которых я уже начитался. Учитывая, что все действия происходили на удалёнке, первые церемонии прошли для меня сумбурно.
Первый день
Моё знакомство с коллективом началось с ежедневного скрама, так называемого «Дейли». На протяжении практически всей встречи я пытался понять, кто есть кто, кто за что отвечает и что я должен сейчас сделать. Это при том, что я к ней готовился. Прошло всё мягко говоря не так как ожидалось. Не то чтобы я ожидал бурной реакции на своё появление, но я надеялся получить хотя бы какую-то конкретику по моим дальнейшим действиям. А на деле всё ограничилось приветствием и парой слов о себе, оно и понятно, надо было уложиться в отведенное время, но как-то уж очень быстро для первого раза.
Не получив необходимой информации, я пошёл стучаться в двери, людей которых мне представили. И тут я столкнулся с прелестями самоорганизации, о которых раньше не подозревал. К кому идти за постановкой задачи, если нет руководителя в привычном понимании этой должности? Отвечая себе на этот вопрос, я принял, как оказалось, правильное решение и пошёл к скрам мастеру, а затем к владельцу продукта, попутно пообщавшись с будущим напарником по разработке. От коллег узнал, что бэклог и текущие задачи, помимо ежедневных статусов, обсуждаются на отдельной встрече для команды разработки АБС, которая состоится на следующий день. Что ж, обложившись материалами, полученными в ходе коротких бесед, ушёл готовиться к следующему дейли и обсуждению бэклога.
Наконец-то задача
На обсуждении бэклога всё стало потихоньку проясняться. Во-первых, на него было отведено больше времени и спешки как на дейли не было. Во-вторых, встреча подразумевала совершенно другой формат и, на удивление, так оно и оказалось. На обсуждении бэклога мне ещё раз представили команду и уже подробно рассказали обо всех тонкостях взаимодействия моей команды с основной частью Agile команды. А я в свою очередь ещё раз задал все беспокоившие меня вопросы, насчёт процесса разработки, так сказать узнал из первых уст. К концу встречи мы обсудили все задачи, проставили им приоритеты и статусы, и я, полный решимости, отправился разбираться с постановкой своей первой доработки.
Разобравшись в требованиях и расправившись с основной частью разработки, для меня настало время первоначального тестирования. И здесь меня опять поджидал новый опыт. Так как сервис, над которым я трудился, был интеграционным и это была первая задача на новом месте, помогать мне взялись разработчики ЕФР вместе с технологом, а это на минуточку первое прямое взаимодействие с командой Agile. Думаю, надо сказать, что все опасения «сектантства» показались мне полнейшей глупостью. Коллеги оказались абсолютно адекватными и знающими своё дело людьми, и мы довольно быстро разобрались со всеми проверками. Пугающей улыбки я конечно же не видел, удалёнка все-таки, но наитие мне подсказывало, что этот бред можно смело забыть.
Трудовые будни
Дальше я с головой погрузился в трудовые будни. Занимался своими задачами, на статусе по бэклогу обсуждал текущую и будущие разработки, а на дейли отчитывался о проделанной работе и слушал как то же самое делает остальная команда. Не было ничего сверхъестественного или того, что смущало меня до начала работы на новом месте. Не могу сказать, что та работа, которую я видел сильно отличалась от того, что я видел раньше.
Всё шло спокойно и размеренно пока не подошёл конец спринта. Глядя в календарь, я ужаснулся. Начались бесконечные встречи. Дейли сменял статус по бэклогу его сменяло дэмо, а вишенкой на торте было рэтро и всё это разбавляли встречи по моим задачам. А как известно, где заканчивается один спринт, там начинается другой. Следовательно, меня ждали новые встречи по планированию вперемешку с дэйли, мозговыми штурмами и прочими встречами по текущим вопросам с коллегами. Во время такого количества собраний довольно сложно переключиться и сфокусироваться на текущей задаче. Ко всему этому надо, конечно, привыкнуть.
Однако, из всех этих встреч я бы хотел выделить дэмо. На нём я увидел итог двухнедельной работы всех участников команды в виде работоспособной части глобального продукта. И, честно сказать, было приятно почувствовать себя хоть немного, но причастным к результату.
Подведём итоги
На самом деле всё оказалось не так страшно. По прошествии нескольких спринтов, я привык к установленным правилам, окончательно разобрался со всеми терминами и обязанностями каждого члена команды и, как мне кажется, окончательно влился в процесс. Если бы меня кто-нибудь попросил кратко описать происходящее, то я бы сделал это так:
«Разработка ведётся в рамках двухнедельных отрезков времени, так называемых спринтов. В начале спринта, на планировании, командой формируется список задач (Бэклог) для достижения цели спринта, в конце спринта проводится его обзор — Дэмо (что было сделано за спринт) и Рэтро - встреча с обратной связью о работе в спринте. Также каждый день проводятся пятнадцатиминутные встречи на которых обсуждается статус по текущим задачам.»
Это стандартный, но очень грубо урезанный сценарий процесса.
Если подытожить всё, что я увидел и узнал, то можно сказать следующее. Команда, с которой я работаю, соблюдает основные каноны работы по методологии Scrum, и я окунулся во все, обязательные и не очень, церемонии. Как оказалось, в обычный день, церемоний проводится не так много. Но, конечно, всё же больше чем хотелось бы, особенно в начале и в конце спринта, а некоторые из них, такие, как рэтро могут стать настоящей проблемой для людей застенчивых или не привыкших к публичным выступлениям. И естественно ни о каких сектантах и коучерах не идет и речь, команда хорошо подобрана и показывает результаты. Я не застал ни одного провального спринта, равно как и не столкнулся с большинством проблем о которых читал. На момент написания статьи мне не довелось прочувствовать всей гибкости используемой методологии, т.к. во время работы не было глобальных изменений в постановках к моим задачам, следовательно мне не приходилось перекраивать решение. И я считаю, что это заслуга людей, которые работают в данной команде и их отношения к своей работе.
На мой взгляд, результат во многом зависит от того, насколько хорошо подобран состав команды не только в плане компетенций, но и личностных качеств. По моему скромному мнению, не всем будет комфортно работать в Agile командах, из-за большого значения взаимодействия между всеми их участниками. Но это, конечно же моё субъективное мнение, а вот, что мне удалось узнать у коллег про гибкие методологии.
Мнения более опытных коллег о работе с методологиями Agile
Светлана — Руководитель направления, Блок банковских технологий:
«Учитывая большой опыт работы в проектах с классической моделью управления, работа в Agile нравится. Нравится регулярно видеть результат, задачи проходят более короткий круг от идеи до выпуска в прод. Отсутствует бюрократия в виде множества лиц, участвующих в процессе согласования документов, сейчас время, затрачиваемое на все согласования по конкретной задаче, сократилось до 4 раз.»
Кристина — Исполнительный директор, Блок ИТ-развития фронтальных решений розничного бизнеса:
«Конечно к Agile у меня только положительное отношение. Могу сказать, что в плане мотивации и качества работы команды сто процентов Agile работает лучше, чем классическая методология, потому что есть члены команды с компетенциями в разных областях, есть фокус на конкретной задаче и нет необходимости тратить время на то чтобы утверждать задачу в банке, ждать пока выделят ресурс и утвердят её в план. В Agile у нас уже есть необходимый ресурс и всё время тратится на решение конкретных задач результаты выполнения, которых мы наблюдаем в конце каждого спринта. На данный момент гибкости пока нет большой, но мы идём к ней. Ситуация улучшается.»
У меня всё, надеюсь, что нигде не приврал. А что вы думаете об Agile? Пишите в комментариях.
