Почему разработчикам не нравится Agile?
HR-специалист одной компании недавно сказал такую фразу: «разработчики не хотят к нам идти, как только узнают, что мы работаем по Agile». И хотя я сам нередко слышу недовольство, высказываемое разработчиками в отношении Agile, такая категоричность меня удивила.
Ведь одна из целей Agile — создание комфортных условий для работы тех самых разработчиков. Agile-практики стремятся освободить разработчиков от рутины, поощряют творческий подход. Самоорганизация, минимизация бюрократии — всё это призвано упростить жизнь разработчиков. Happiness (счастье) разработчиков — одна из Agile-метрик, которую нужно повышать.
Почему же не стыкуются отзывы реальных разработчиков с декларируемыми целями Agile?
- Сразу оговорюсь, что под «разработчиками» в этой статье я подразумеваю всю команду разработки (Scrum development team), включающую аналитиков, программистов, тестировщиков, дизайнеров и пр.
Давайте посмотрим на конкретные примеры — жалобы разработчиков на Agile:
- бестолковые ритуалы (в особенности, ежедневные стендапы) отвлекают от работы
- слишком много разговоров, совещаний; бесполезных, так как принятые решения никто не выполняет
- разработчик должен разрабатывать, а не практиковаться в социологии и маркетинге
- вообще не люблю ни с кем говорить, особенно с клиентом; с клиентом должны общаться специально обученные люди
- Agile подавляет свободу разработчика, навязывает уравниловку; получается, что команда выше, чем отдельный программист в ней
- нельзя плясать только под дудку бизнеса; в IT-компании должна быть инженерная культура
- может, для небольших стартапов это и хорошо, но не подходит для серьезной разработки, где нужен порядок, специализация, техническая экспертиза, стратегическое планирование
- в зрелых проектах, где уже сложились лучшие практики, переход на Agile может только всё испортить
- нет специализации — нет экспертизы, «санитар оперирует на сердце — чего хорошего можно от этого ожидать?»
- Agile — это постоянный стресс (оценки, обязательства, ежедневные отчеты), нет времени подумать
- нет долгосрочного видения
- Agile существует для того, чтобы держать сотрудников в ежовых рукавицах
- задача Agile выжать меня как лимон и выбросить
- не люблю, когда кто-то лезет в мой код
- не люблю писать тесты, которые всё-равно ничего не гарантируют
- Agile — маркер хаоса
- бездумно фигачим с багами, лишь бы быстрее
- бардак, нет ответственных, например, за рабочее тестовое окружение
- никто не отвечает за сроки
- никто вообще ни за что не отвечает, так как нет ответственных лиц
- … (напишите, пожалуйста, в комментариях, какие еще жалобы слышали вы)
Попытаюсь разделить эти жалобы на категории:
Бардак
Бардак — это когда слово расходится с делом.
Культура управления во многих компаниях несовместима с Agile. Если переход на Agile не сопровождается сменой культуры (что, пожалуй, даже важнее самого перехода на Agile), между словами и делом расхождений становится всё больше, а значит, множится бардак.
Это особенно бросается в глаза, так как при переходе на Agile звучит очень много обещаний, которые невозможно сдержать, сохраняя прежнюю культуру управления. Разочарование неизбежно.
Кроме этого, на Agile, как на любое нововведение, часто списывают бардак, напрямую с ним и не связанный.
Неправильное понимание принципов Agile
Помимо неправильной ассоциации Agile с бардаком, бытует немало и других разночтений. Это касается, например, кросс-функциональных команд и T-специалистов, долгосрочной стратегии, инженерной культуры. Неправильно толкуется отношение к документации, архитектуре, техническому дизайну проекта.
Перегибы на местах возникают из-за неправильного понимания Agile руководителями компаний и IT-департаментов.
В данной статье я не буду углубляться в то, как достичь правильного понимания по всем этим вопросам — каждый из них заслуживает отдельной статьи. Скажу лишь, что это задача Agile-менеджера и/или скрам-мастера — разъяснять идеи Agile всем членам команды и, что немаловажно, вышестоящему руководству.
На чем я хотел бы остановиться более подробно, это на следующей категории жалоб, где одними разъяснениями проблему не решить.
Нежелание работать в команде
Много проблем возникает из-за того, что Agile требует от людей настоящей командной работы, которая отличается от той «командной» работы, к которой они привыкли.
Раньше под командной работой подразумевали ответственность за выполнение своей части работы качественно и в срок, чтобы не подвести остальных. Нет обоснованных претензий к моей части работы, значит, я — успешный командный игрок.
Такой «командный» подход устраивает всех, потому что в нем по факту нет никакой командности. Каждый сидит в своем «колодце», ждет нового задания, выполняет его самостоятельно, ни к кому не обращаясь. Затем перебрасывает в другой «колодец». С глаз долой, из сердца вон.
Agile-команда, с другой стороны, подразумевает самоорганизацию. Задание не дают, его нужно взять, а для этого уже нужно выглянуть из «колодца». Потом это задание нужно самому и сформулировать, общаясь с Product Owner или даже (о, ужас!) напрямую с заказчиком. Вместе с командой надо запланировать спринт. А потом ещё нести ответственность за общий результат, а не только за свою часть. Для людей, не привыкших работать в команде, не доверяющих ей — это чудовищный дискомфорт.
Может ли Agile создать комфортные условия для работы не-командных игроков? Полагаю, что должен. Вопрос — как?
Здесь мы подходим к важнейшей составляющей работы Agile-менеджера и/или скрам-мастера — построению команды. Ведь сами люди из «колодцев» не выйдут.
Как вывести людей из «колодцев»?
Недавно прочитал такую метафору:
чтобы преодолеть изоляцию «колодцев» нужно опираться на то, что у них есть общее:
- земля под ногами — это наши ценности, то, ради чего мы живем и работаем
- небо над головой — это наши цели, к которым мы стремимся
Чтобы узнать о ценностях своих коллег, нужно просто поговорить об этом. Начать может быть трудно, но потом, вы удивитесь, насколько общие у всех ценности, и как сильно уменьшается глубина «колодца», как только все узнают об этом.
Цели — это, в первую очередь, вопрос к высшему руководству компании. Если оно не может вдохновить сотрудников, как эта компания вообще может жить (по факту может, но это печально)? Зачастую, цели у компании есть, но они плохо коммуницируются, разработчики не видят, как каждый их них может внести свой вклад.
Помимо целей компании, команда может сформулировать свои собственные цели. В этом и проявляется самоорганизация. Понятно, что противоречить целям компании эти цели не должны, но, как правило, они и не противоречат. Целями могут быть повышение комфорта работы внутри команды, профессиональный рост (который, кстати, непосредственно связан с успехом проекта), техническая эволюция продукта и пр.
Как интегрировать работу с командой в рабочий процесс?
Agile ретроспективы — естественное место обсуждения работы людей в команде, их самоорганизации, адаптации команды под нужды изначально некомандных игроков.
Вопросы ценностей и целей всегда должны быть на повестке дня.
Agile-гуру Jeff Southerland предлагает также на каждой ретроспективе оценивать счастье (happiness) разработчиков:
- по шкале от 1 до 5 насколько я доволен моей ролью в компании?
- по шкале от 1 до 5 насколько я доволен своей компанией в целом?
- почему это так?
- какая одна вещь в следующем спринте сделала бы меня счастливее?
Разумеется, чтобы приносить результат, выводы из таких ретроспектив не должны оставаться на бумаге.
Как вы думаете, улучшится ли у разработчиков отношение к Agile, если воплотить в жизнь эти рекомендации? Что бы порекомендовали вы?
Об авторе: более 15 лет занимаюсь разработкой ПО, работаю в крупном банке в качестве тимлида. Более пяти лет практикую Agile в роли скрам-мастера.
Идеи данной статьи почерпнуты из следующих источников:
- Книга Mark Goulston, Just Listen, 2010 содержит упоминаемую в тексте метафору, а также множество других советов о том, как строить отношения с людьми на работе и не только.
- Книга Jeff Sutherland, Scrum the art of doing twice the work in half the time, 2014 (есть перевод на русский язык) — обстоятельное руководство от одного из создателей Scrum.
- Книга Patrick Lencioni, The five dysfunctions of a team, 2002 (есть перевод на русский язык — «Пять пороков команды») — пожалуй, главная книга, когда речь заходит о командной работе.
