Мифы об Agile. Миф №3: Agile – это микроуправление

За последние годы я видел довольно много историй с заголовками вроде «Agile отстой» и «Agile мертв», возникающих с некоторой периодичностью. Они появляются каждый год или около того и вызывают довольно оживленные, но неинтересные дебаты.

Большинство из них – просто вбросы и не заслуживают обсуждения. Но некоторые истории печальны и рассказывают удручающие истории об Agile-проектах, в которых доминирует микроуправление, подавляющее дух несчастных разработчиков. Истории о владельцах продукта с манией величия, скрам-мастерах с садистскими наклонностями и командах разработчиков, отправленных на марши смерти в рамках подхода, который был создан, чтобы избежать маршей смерти.

Но общая тема этих историй заключается в том, что Agile используется для микроуправления людьми и их работой. Микроуправление никогда не должно происходить, и это просто нечестное злоупотребление словом «Agile», если оно происходит.

Agile-проекты включают микроработу, но не микроуправление

Может показаться, что Agile-разработка программного обеспечения легко поддается микроуправлению. И все потому, что работа делится на очень маленькие партии, и эти партии определены явно, сделаны видимыми и могут контролироваться индивидуально.

В проекте Waterfall микроуправление маловероятно. Содержание определяется большими кусками, подкрепленными большими требованиями и большими спецификациями. И команда разработчиков говорит: «Мы собираемся взять эти три спецификации и построить эти три экрана в этой системе». Затем они убегают, и никто не видит их в течение двух месяцев.

Через два месяца они возвращаются и показывают, что они построили, а заинтересованные стороны узнают, что они получат. В Agile-проектах у вас есть небольшие команды с встроенными владельцами продуктов, которые создают небольшие компоненты, основанные на небольших «пользовательских историях» за небольшие временные отрезки.

Получается, все Agile проекты должны страдать от микроуправления? Нет. Если они построены правильно, в них не должно быть микроуправления. Почему? Потому что сами члены команды управляют работой, а не «босс» или «менеджер».

Agile-команды – это команды, наделенные полномочиями

Команды, наделенные полномочиями, которым доверяют найти наилучший способ сделать свою работу, являются основной концепцией Agile, и так было с самого начала. Давайте вспомним принципы Agile:

«Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им».

И еще:

«Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд».

Это было с самого начала. Если у вас нет уполномоченных команд, это не Agile. Если вы не доверяете своей команде в поиске наилучшего способа выполнения работы, это не Agile. И если ваши команды не самоорганизуются, это не Agile. Это так просто.

Следующие несколько пунктов относятся к скрам, который я знаю лучше всего, но большинство других вариантов Agile имеют довольно похожие правила.

Команда выбирает, какую работу она вытянет в спринт

В начале спринта, на собрании по планированию спринта, команда (не владелец продукта, не скрам-мастер, а команда, если вы мне не верите, прочитайте руководство по скраму) выбирает, какую работу сделать в этом спринте.

Примечание: они могут не взять в работу вообще ничего. Команда на 100% уполномочена сказать: «Ни одна из этих работ сейчас не имеет смысла, мы ничего не делаем». Или: «Ни одна из этих работ не определена достаточно четко, чтобы быть взятой в спринт, поэтому у нас нет ничего, над чем мы могли бы работать».

Это, конечно, случается очень редко, и, вероятно, будет основанием для скрам-мастера отменить спринт в целом. Но стоит указать, кто здесь имеет право голоса: команда. То есть люди, которые делают работу. Они выбирают, какую работу они будут делать.

Если они не могут выбирать, вы не наделили полномочиями свою команду, не используете скрам и вообще не участвуете в Agile. Потому что Agile-манифест гласит, что у вас должны быть уполномоченные и надежные команды. И потому что руководство скрам говорит, что команда решает, какую работу взять в спринт.

Команда выбирает, сколько работы вытянет в спринт

Если команда решает, что и сколько они вытянут в спринте, марши смерти вовсе не должны происходить, или очень редко, и только для одного спринта.

Если команда делает грубую ошибку в своих оценках и берет в спринт какую-то работу, но оказывается, что она намного сложнее, чем они думали, тогда они могут пересмотреть свои оценки и прогнозы для следующего спринта, и взять гораздо меньший объем работы.

Это также записано в руководстве скрам и в Agile-манифесте:

«Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки».

Видите? Устойчивое развитие. Работайте в разумном и постоянном темпе. Никто не может принудить Agile-команду к постоянному маршу смерти, потому что никто не может заставить команду делать какую-то работу. Команда вытягивает работу в спринт. Никто не может вытолкнуть работу в спринт.

Команда выбирает, как они будет делать работу, которую они втянули в спринт

Команда отвечает за составление плана выполнения работы. Владелец продукта не может планировать работу. Скрам-мастер не может планировать, как должна выполняться работа. Руководство по скраму ясно говорит об этом: опять же, прочитайте его, если не верите мне. Вот оно, ясно как день:

«Установив цель спринта и выбрав задачи из бэклога продукта для спринта, команда разработчиков решает, как она добавит этот функционал в готовый продукт за время спринта».

Я не понимаю, как еще лучше объяснить. Если ваши разработчики не могут выбрать работу, которую они выполнят в спринте, и как они это делают, то вы, вероятно, не используете Agile и определенно не используете скрам. Прочтите приведенную выше цитату, если вы все еще не поняли.

Но разве это не приводит к хаосу? И никто ничего не делает?

Вы можете подумать: «Это безумие! Люди по сути ленивы. Они усердно работают, только если на них кричит большой сильный лидер, который говорит им, что делать и как делать. И напоминает им, что их зарплата зависит от их усердия. Если мы позволим людям делать то, что они хотят, ничего не будет сделано! Все будут расслабляться или беспорядочно бродить, требуя четких указаний!».

Это проявление грустного и ошибочного мышления «Менеджмент 1.0». Так думал Фредерик Тейлор 100 лет назад.

Мир продвинулся дальше. Мы больше не строим виджеты по учебнику. Сегодня мы занимаемся совместной работой над получением знаний. Мы должны расширять полномочия и доверять нашим людям, чтобы они могли выполнить лучшую работу, какую только могут. Или мы должны прекратить работать с ними.

Вы должны доверять своим командам

Я работаю с командами, и я доверяю им найти лучший способ сделать работу. Я не говорю им, в каком порядке выполнять работу. Я не говорю им, кто из них должен выполнять ту или другую задачу. Я не говорю им, когда начать или остановить работу. Я не говорю им, сколько юнит-тестов написать. И я не говорю им, какой вариант графического интерфейса использовать. Я доверяю им самим все это решить.

Это потому, что я работаю с людьми, которым доверяю. Я доверяю им, и они доверяют мне. Доверие это все. Я верю, что все люди, с которыми я работаю, сделают все возможное, используя имеющиеся у них ресурсы, информацию и время. Я не заглядываю через их плечо, я не слежу за ними, я не управляю их работой.

Если вы не доверяете людям, не работайте с ними

Жизнь слишком коротка для плохих проектов, сварливых боссов, несчастных рабочих и микроуправления. Если вы не доверяете людям, с которыми работаете, не работайте с ними. Увольте их или увольте себя и пойдите работать в другую компанию.

Ладно, заканчиваю свою проповедь на сегодня. Пожалуйста, напишите, что вы думаете!

Продолжение следует…

Автор: Leon Tranter
Источник

Все статьи цикла «Мифы об Agile»

Мифы об Agile. Миф №1: в Agile нет планирования
Мифы об Agile. Миф №2: в Agile нет документации
Мифы об Agile. Миф №3: Agile – это микроуправление

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.