Agile-разработка сопровождает создание программного обеспечения уже довольно давно. Почти каждая уважающая себя команда разработчиков, от небольших стартапов до enterprise-гигантов, гордо заявляет, что внедрила ту или иную гибкую методологию: Scrum, Kanban или их гибриды.
Внешне всё выглядит идеально: команды регулярно проводят утренние стендапы, где делятся прогрессом и соображениями по проекту, организуют сессии планирования спринтов, проводят встречи для поддержания общего состояния бэклога, а также рефлексируют на ретроспективах.
Однако суровая реальность такова: простое внедрение Agile не становится панацеей от старых хронических проблем.
В этой статье мы подробно разберём типичные ошибки внедрения Agile в проектную разработку и устоявшийся жизненный цикл команды.
О чем мы поговорим:
-
Почему возникает «Карго-культ» Agile и как его распознать;
-
Как гибкие методологии разбиваются о жесткий микроменеджмент;
-
Почему Agile бессилен, если внутри команды процветает токсичность;
-
В чем разница между скоростью закрытия задач и реальной бизнес-ценностью;
-
Как пошагово заставить Agile работать на ваш продукт, а не на отчетность.
Вы узнаете, почему команда, которая искренне надеялась на качественное изменение процессов, в итоге снова скатывается в хаос, бесконечные кранчи перед дедлайнами и перманентный «пожарный» режим, а Agile по-настоящему так и не приживается.
Проблема 1: Agile часто внедряют как набор ритуалов, а не как подход
Одной из самых главных проблем современного IT является внедрение Agile как набора механических ритуалов, а не как фундаментального подхода к работе и мышлению.
Помнится, мы работали над приложением доставки для крупной сети ресторанов. Это был наш первый по-настоящему крупный проект: мы были молодыми специалистами, только недавно вышедшими на серьёзный рынок как самостоятельная команда.
Хотя мы знали о методологиях разработки и читали статьи на профильных ресурсах, внедрить какую-то из гибких методологий на практике оказалось невероятно сложно. Мы поступили «как написано в умных книгах»: разбили работу на двухнедельные спринты, завели доску в Jira, каждый день ровно в 10:00 проводили стендапы, после которых формировали бэклог фич и задач. Но были критически важные нюансы, которые пустили всю работу под откос:
-
Стендап ради галочки. Когда на очередном daily-митинге, команда не обновляет общую картину работы, а каждый просто бубнит под нос: «Вчера делал таск 123, сегодня делаю таск 124, проблем нет». Стендап нужен для синхронизации и выявления блокеров, а не для отчета перед менеджером.
-
Игнорирование ретроспектив. Если на ретроспективе в конце спринта выявляются крупные недочёты в архитектуре, но команда просто фиксирует их на стикерах и оставляет всё как есть — эффективность внедрения Agile падает до нуля.
-
Мёртвый бэклог и спринты без цели. Часто команды забывают регулярно актуализировать бэклог. Его сформировали на этапе старта проекта, запустили первый спринт, в процессе встреч хаотично что-то добавляют и набивают в новый спринт всё подряд. Возникает эффект «замыленного взгляда»: разработка уходит в обсуждения «на словах» и в чатах Telegram, а не в отчётность бэклога, а логика построения приложения ломается.
В итоге под конец месяца приходится тратить часы лишнего времени, чтобы актуализировать информацию на Scrum-доске задним числом. Это делается лишь для того, чтобы показать заказчику мнимую скорость работы, радуя его закрытыми задачами «в кредит». Именно эти, на первый взгляд, процедурные мелочи чаще всего убивают Agile на корню.
Проблема 2: Agile не исправляет слабое управление
Возвращаясь к теме панацеи: обычно Agile начинают экстренно внедрять в компаниях именно тогда, когда становится очевидно, что работать по-старому уже экономически невыгодно.
Может ли причиной этого быть отсутствие координации со стороны разработки? Безусловно. Но является ли это единственной причиной снижения эффективности? Практика показывает, что отнюдь не так.
Прежде чем внедрять какие-либо инновации, важно честно задать себе вопрос: те ли проблемы мы пытаемся решить?
Иногда команда не готовы к гибкости
В проектах ключевую роль играют не только разработчики, пишущие код, но и топ-менеджеры, стейкхолдеры и заказчики. И вот что происходит при слабом управлении:
-
Директивный спуск задач. Менеджеры в обход бэклога и Product Owner’а прибегают к разработчикам с криками «Это нужно сделать еще вчера!». Эти побочные «хотелки» незаметно, но критически раздувают сроки основных запланированных работ спринта.
-
Имитация бурной деятельности. Из-за слабой коммуникации аналитиков с конечным заказчиком команда может неделями «менять цвет кнопок» в интерфейсе, вместо того чтобы заниматься разработкой реально нужного бизнес-функционала.
-
Размытие ответственности. Если никто на управленческом уровне не несёт финансовой или репутационной ответственности за конечный результат, а главная задача программиста сводится к тому, чтобы в трекере было списано ровно 8 часов в день, то никакая прогрессивная методология не поможет.
Без честного и глубокого аудита процессов — в первую очередь оценки управленческой зрелости организации и готовности бизнеса делегировать принятие решений — внедрение Agile почти всегда остаётся красивой галочкой в годовом отчете о внедрении инноваций.
Проблема 3: Agile не лечит проблемы команды
В уравнении эффективности любой методологии главной переменной является сама команда. Мы уже обсудили проблемы, связанные с формальным отношением к правилам. Однако главные трудности лежат на гораздо более глубоком уровне — в человеческом факторе и командной психологии.
Представьте типичную картину
-
В команде есть блестящий Senior-разработчик, который недолюбливает остальных, считает их некомпетентными и работает исключительно изолированно, забирая самые сложные задачи себе и не делясь знаниями.
-
Джуниор боится увольнения, поэтому предпочитает скрывать, что не понимает архитектуру. Он молча гуглит и пишет «костыли», пытаясь решить проблему в одиночку, пока баг не выстреливает на продакшене.
-
Кто-то из мидлов недобросовестно перекидывает неудобную, рутинную задачу по кругу, пока единственный QA-инженер (который, к тому же, весь прошлый месяц был в отпуске) не зарабатывает нервный срыв из-за накопившегося хаоса из десятков непроверенных тикетов.
Если вы находитесь на позиции Product Owner’а, Scrum Master’а, тимлида или технического директора — всё это в первую очередь ваши прямые проблемы, а не издержки процесса. Именно руководитель должен активно участвовать в выстраивании культуры работы в команде.
Сильная, сплочённая и доверяющая друг другу команда способна эффективно и быстро поставлять качественную ценность даже без всяких методологий, общаясь в простом текстовом чате (рис. 1).
Проблема 4: Скорость работы ≠ Ценность продукта
«Скорость, нам нужна скорость! Мы не успеваем к дедлайну. Давайте сегодня закроем побольше мелких тасков, чтобы график сгорания задач выглядел красиво, и в следующем месяце мы получили премию!»
Ах, эта сладкая погоня за скоростью. Зелёные галочки в Jira, выполненные KPI и довольный на презентации заказчик — приятная картина, не правда ли? Но здесь кроется главная методологическая ловушка Agile.
Ловушка Story Points
Быстрое накопление абстрактных story point-ов не может быть самоцелью в IT-разработке. Это всего лишь внутренняя метрика. Она полезна для прогнозирования емкости спринта команды, но, как и любая метрика, она работает только в балансе со здравым смыслом и вот почему:
-
Субъективность оценки. Оценка в story point-ах — процесс относительный и субъективный. Закрыть 50% от запланированного объема поинтов совершенно не означает, что продукт готов наполовину.
-
Избегание сложного. Команды часто попадают в ловушку «легких побед»: они набирают в спринт десятки мелких, откладывая критически важные, но сложные архитектурные задачи на потом. В метриках «загруженность» выглядит на идеальные 100%, но продукт при этом не развивается.
Фокус на ценности и проверка гипотез
Разработка продукта по Agile — это история не про скорость написания строчек кода, а в первую очередь про скорость поставки реальной ценности для конечного пользователя и бизнеса.
В этой парадигме важно именно соотношение скорости разработки к той ценности, которую мы хотим привнести. Иначе даже проверить гипотезы, что выстраивались в процессе разработки не получится вовремя, что критически повлияет на дедлайны.
Проблема 5: Agile требует корпоративной зрелости, а не только следования инструкциям
Многие из проблем, перечисленных в предыдущих разделах, упираются в понятие зрелости. Причем зрелости не только технической, но и эмоциональной.
Если у вас как у коллектива есть общая цель, то над построением доверительной среды обязаны работать абсолютно все участники процесса:
-
Взаимовыручка. Когда в команде каждый доверяет другому хотя бы на базовом уровне, люди спокойно могут попросить помощи и сами предложить поддержку коллеге, застрявшему на сложной задаче.
-
Прозрачность. Команда не боится открыто подсвечивать проблемы на ретроспективах, даже если ошибка произошла по вине руководства.
-
Осознанность. Специалисты одинаково сильны как в самостоятельности, так и в командной дисциплине. Они решают задачи, понимая их конечную продуктовую ценность.
Роль стейкхолдеров в гибкой среде
Немаловажную, а порой и определяющую роль играют Product Owner и конечный заказчик. Важно помнить, что они тоже живые люди. Хотя их ежедневная вовлечённость в процесс разработки сильно ноже, но они являются неотъемлемой частью Agile-команды и подчиняются тем же правилам взаимодействия. Качественная обратная связь от PO и заказчика позволяет команде:
-
Своевременно отклонять нерелевантные изменения;
-
Избегать раздувания скоупа проекта;
-
Удерживать общий «корабль» продукта на плаву в условиях меняющихся требований и идти на контакт (рис. 2).
Что действительно помогает Agile работать?
В этой статье мы довольно много говорили о том, какой «должна быть хорошая команда» и каким «должен быть каждый сотрудник». И это правильный фокус, ведь в идеале принципы здравого смысла работают независимо от выбранной методологии.
Однако при осознанном внедрении Agile появляется новая веха в развитии процессов. Вот конкретные шаги, которые помогают команде совершить качественный скачок от хаоса к предсказуемой и ценной разработке:
-
Жесткая приоритизация. Ещё до планирования и оценки в story point-ах команда и Product Owner должны определить строгий приоритет каждой задачи в бэклоге.
- Фокус на цели спринта. Из приоритизации вытекает понятная цель итерации. Команда должна спрашивать: «Что мы получим через 2 недели?». Именно для формирования этого понимания и проводятся встречи по планированию.
- Культура открытой обратной связи. Если инженер видит системную проблему, у него должно быть право открыто заявить об этом на ретроспективе. Замалчивание проблем будет копиться, пока не уничтожит проект.
- Непрерывный анализ результатов. При работе спринтами важна железная дисциплина: анализируйте не только процесс, но и итог. В конечном счете именно результат определяет ценность работы команды.
Напутствие вместо итогов
Product Owner, заказчик бизнеса и команда разработчиков — это экипаж одного судна. Их общая цель — стабильно доставлять бизнес-ценность и фокусироваться на решении реальных болей пользователей. Суть гибких методологий в том, чтобы стратегически корректировать курс, грамотно обходя подводные камни и опираясь на показания радаров. И такой корабль при правильном управлении движется к цели значительно эффективнее и безопаснее, чем неуправляемый плот.
Agile — это мощный и полезный инструмент, но никак не волшебная палочка, которая по щелчку пальцев превратит убыточный хаос в единую командную волю. Он действительно масштабирует и усиливает сильные стороны слаженной команды. Однако вместе с этим Agile моментально и ярко делает заметными все скрытые слабые места в управлении, коммуникациях и продуктовой работе, которые раньше мешали создавать хороший продукт.
Поэтому главный вопрос на вашей следующей планерке не в том, внедрён ли Agile по всем правилам учебника. Главный вопрос звучит иначе: помогает ли он команде реально и предсказуемо создавать ценный результат? Если ответ «нет» — время ломать формальные ритуалы и начинать общаться с людьми.
Источник: Пётр Третьяк, руководитель IT-проектов в компании «Фактура»
