- PVSM.RU - https://www.pvsm.ru -
HR-специалист одной компании недавно сказал такую фразу: “разработчики не хотят к нам идти, как только узнают, что мы работаем по Agile”. И хотя я сам нередко слышу недовольство, высказываемое разработчиками в отношении Agile, такая категоричность меня удивила.
Ведь одна из целей Agile – создание комфортных условий для работы тех самых разработчиков. Agile-практики стремятся освободить разработчиков от рутины, поощряют творческий подход. Самоорганизация, минимизация бюрократии – всё это призвано упростить жизнь разработчиков. Happiness (счастье) разработчиков – одна из 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) разработчиков:
Разумеется, чтобы приносить результат, выводы из таких ретроспектив не должны оставаться на бумаге.
Как вы думаете, улучшится ли у разработчиков отношение к Agile, если воплотить в жизнь эти рекомендации? Что бы порекомендовали вы?
Об авторе: более 15 лет занимаюсь разработкой ПО, работаю в крупном банке в качестве тимлида. Более пяти лет практикую Agile в роли скрам-мастера.
Идеи данной статьи почерпнуты из следующих источников:
Автор: Ярослав Ставничий
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/347454
Ссылки в тексте:
[1] Источник: https://habr.com/ru/post/489538/?utm_source=habrahabr&utm_medium=rss&utm_campaign=489538
Нажмите здесь для печати.