Сегодня целая плеяда профессионалов в сфере agile рассказывают о том, как внедрять эту методологию на практике. Однако я знаю немало команд, которые сломали копья при попытке перейти на рельсы agile в строгом и не слишком строгом соответствии изначальным рекомендациям гуру. В этом посте я хочу поговорить о том, можно ли внедрять agile как более мягкую практику с позиций моего собственного опыта.
Меня зовут Михаил Долгополов, и я — инженер по тестированию продуктов в компании Киберпротект. И нет, я не коуч и не эксперт по agile. Тем не менее, как и любой человек из IT, я понимаю, что этот подход, в теории, должен привести к качественным изменениям при разработке и развитии продуктов. Достаточно пролистать ленту Хабра, чтобы увидеть целую кучу материалов, посвященных теме agile. Можно найти и методологии, и их вариации, и пошаговые инструкции, и истории чудовищных провалов при внедрении agile. И у меня, как любого интересующегося, но не погруженного на все 100% в тематику лица, возникает вопрос: «Можно ли приступить к внедрению практики, не затевая масштабных трансформаций в компании и не приглашая в штат дорогостоящих специалистов?»
Как люди понимают agile и к нему относятся
У каждого найдется свой ответ. И среди тех, кто ответит, будут и основоположники подхода, и теоретики (agile-коучи), и практики (тоже agile-коучи), и есть подопытные (компании и их сотрудники). И в рядах последних часто встречаются очень интересные мнения.
Среди подопытных гуляет байка, что agile — это что-то неэффективное и ненужное, особенно если практиковать все процедуры типа демо, дейли и ретро. И с недавнего времени я считаю, что это происходит по причине непонимания. Не каждый практик может передать свой опыт простыми словами. Интуитивно он понимает, что нужно делать, но не всегда может объяснить ЗАЧЕМ и ЧТО ДЕЛАТЬ С ТЕКУЩИМИ ПРОЦЕССАМИ?
Как это часто бывает, найти ответ на сложные вопросы удалось на стыке моих экспериментов с agile и трехлетнего опыта работы над собой, а также плотного общения с психологом. И этим практическим видением я хотел бы поделиться с вами сегодня.
Почему внедрять agile бывает сложно
И все же, agile — это хорошо. Но вместе с “махровым” agile к нам приходят множество форматов работы и взаимодействия, а также целый ряд различных правил и требований. С непривычки все это тяжело принять и внедрить в практику. Сидишь и думаешь: “Это мне не очень нравится…”, “А вот это я вообще не понимаю зачем?”
Существует точка зрения что подход agile как раз нужен для перестройки процессов разработки в командах. Но любая трансформация такого рода — это всегда снижение производительности труда, вызванное освоением нового. Когда это неприемлемо, компании начинают перестраивать процессы agile под себя.
В этом случае организация может достичь прозрачной отчетности, не меняя при этом подход к разработке, то есть не снижая темпов производства.
Что будет, если адаптировать agile под себя, а не наоборот?
Как мне кажется, в концепции изменения agile под себя главное — это смотреть не на форму, а на суть практики. Ведь мы же можем брать и просто адаптировать какие-то практические приемы из одной сферы, чтобы применять их в другой, верно? Это означает, что мы можем учесть принципы agile в своих повседневных процессах.
Учитывая, что agile — это главным образом искусство маленьких шагов, применение agile в рамках своих рабочих процессов — это, фактически, декомпозиция задачи на более мелкие и внедрение практики их постепенного выполнения с элементами планирования и отчетности.
Что из agile все-таки важно привнести…
Помимо общей идеи мелких шагов, на мой взгляд, в методологии agile есть еще множество полезных элементов, которые стоит привнести в любом случае. Например, очень полезны очные встречи, такие как демо и ретро. Но я сталкивался с тем, что ретро не проводится просто потому, что никто не знает как это делать, демо проводится, но без ориентации на результат, и так далее.
Если проводить демо формально — просто рассказывать о том, что было сделано, не подводить итоги, не подчеркивать достижения, то у команды постепенно теряется энергия для дальнейшего движения. Признаюсь, мне самому сначала казалось, что на каждом демо сложно выделить наличие чего‑то готового. Но ведь на демо не важно наличие готового продукта! Нужно просто понять, какой функционал мы хотели внедрить за спринт, убедиться, что он есть и работает, что мы готовы его отдать заказчикам. А в противном случае — проанализировать, почему спринт не принес ожидаемых результатов и и сделать выводы.
Недавно о том, где взять энергию для изменений, рассказывала agile‑коуч Анна Обухова — об этом можно почитать у коллег из Тинькофф здесь.
В моем понимании, один из самых важных пунктов — это авторизация результатов. Ведь когда разработчик не видит результата, ему очень сложно найти мотивацию двигаться дальше.
Если мы работаем на результат и разработчик что‑то не успевает, он неизбежно задается вопросом: «Как мне сделать так, чтобы в следующем спринте было что показать?». Фактически он адаптирует себя под agile. В этом случае результаты получаются (в зависимости от длины спринта) раз в две недели — и не просто в коде, а в работающем продукте.
Мне нравится идеология agile тем, что в итоге все члены команды оказываются вовлечены в продукт. Мы хотим показать результаты, привнести пользу. А не кодить «непонятно что, зачем и с каким результатом».
Scrum без scrum-мастера
Мой опыт говорит, что, познакомившись с agile, каждый заинтересованный в результате человек может сформировать новый взгляд на работу в рамках коротких спринтов. Таким образом появляется возможность выстроить «scrum без scrum‑мастера».
Например, вы не знаете, что делать на дейли‑митинге. Обсудите в команде, для чего могут быть полезны ежедневные встречи. Как минимум, они помогают кратко отразить результаты своей работы за день: подвести итоги и авторизовать результаты. И если ты сам этими результатами недоволен, то следует подумать, что можно изменить, чтобы завтра быть довольным.
Кроме этого, сама логика работы по спринтам позволяет научиться разбивать крупные задачи на более мелкие, и, выполняя их, отслеживать прогресс по крупной задаче. В итоге, благодаря работе по спринтам, в идеальном случае каждый разработчик научится разбивать крупную задачу на мелкие шаги и продвигаться по этим шагам. Это позволит честно отслеживать свой прогресс и исключает ситуацию, когда я «пилю‑пилю эту задачу, уже надоело, а там еще конца не видно».
В общем‑то разобраться в agile самостоятельно можно, но у этого подхода есть большая проблема — умению подводить итоги надо учиться. И если никто в команде не обладает таким опытом на достаточно высоком уровне, scrum‑мастер все‑таки понадобится.
Или все-таки внедрять agile по полной?
Впрочем, можно ведь и пойти проверенным путем, приступая к полномасштабному внедрению agile. По моему мнению, это можно делать только в тех ситуациях, когда:
Вы донесли идею до разработчиков, и она им действительно понравилась и люди готовы меняться к лучшему.
У вас есть полгода на то, чтобы трансформировать компанию под agile, вы можете на это время допустить снижение темпов разработки.
Команда делает продукт, который ей нравится. Разработчики заинтересованы в результате.
У вас есть сотрудник, который точно знает, что такое agile, может поделиться опытом и выстроить процессы, например, по scrum.
Как начать двигаться к agile, если вы не готовы полностью за-agilit-ся
Да, на этот шаг сегодня могут пойти не все компании. Поэтому путь адаптации agile под себя остается достаточно привлекательным. Он позволяет добиться работы спринтами, ставить выполнимые задачи и координировать действия команды так, чтобы достичь результатов. И уже после этого можно будет выполнить еще несколько шагов и перейти к 99,9% классическому agile, и сделать это будет намного проще.
Учитывая, что я пытался подойти к agile с разных сторон, могу поделиться основными препятствиями, которые мешают сделать первые шаги:
Желание достичь идеального результата, когда на текущем этапе можно обойтись достаточно хорошим (т. н. «good enough»). Это касается и разработки, и самого внедрения agile.
Боязнь совершить ошибку/сделать что‑то неправильно. Это приводит к тому, что сотрудник или целая команда фактически перестает действовать (и получать результаты). Тут главное не забывать, что отрицательный результат — это тоже результат. Если оперативно оценить его, можно скорректировать действия и превратить негативный результат в позитивный.
Фокусировка на каком‑то одном «оптимальном» пути. Она мешает смотреть широко и менять подход, если приходит понимание, что мы в чем‑то просчитались.
Отсутствие возможности пополнять бэклог и брать в спринт недавно пришедшие задачи. Если забыть об этом, мы свалимся в обычную водопадную модель с короткими спринтами разработки. Это тоже неплохо, но сильно съедает плюсы agile.
Подводя итог скажу, что метод подгонки agile под себя кажется мне оптимальным в текущей ситуации. Ведь, в сущности, он уже меняет подходы к разработке и модернизирует как процессы оценки результатов работы команды, так и процессы планирования. В каком‑то смысле в итоге мы применяем agile‑идеологию для внедрения agile — проводим изменения мелкими шагами и можем постепенно прийти к большей степени agile‑ности в компании.