Постигая Agile

Существует распространенный метод, который используют scrum-тренеры и agile-коучи при обучении команд проведению ежедневных митингов. Суть его заключается в том, чтобы позволить команде потерпеть неудачу[35]. Люди, привыкшие к командно-административной системе, ждут от ежедневных встреч, что менеджер проекта или scrum-мастер возьмут управление в свои руки, выяснят у каждого статус проекта и укажут новые задачи. Команда считает такой способ работы естественным, она привыкла получать задание. Agile-коуч готов помочь команде проводить ежедневные митинги продуктивнее, поэтому он может посоветовать scrum-мастеру хранить молчание. Часто это приводит к неловкой паузе, которая длится минуту или две. Затем кто-нибудь начинает говорить о работе, которую проделал с момента последней встречи. Большая удача, если за этим рассказом последует вопрос «Какова моя следующая задача?».

Именно в этот момент scrum-мастер осознает свое отличие от менеджера проекта. Менеджер продолжит распределять между членами команды задачи, которые заранее приготовил. А scrum-мастер воспользуется ситуацией, чтобы организовать команде момент просветления, когда она наконец поймет, что надо делать дальше. Он мог бы это сделать, задавая вопрос «Что ты собираешься делать дальше?». Или он может просто молчать в зависимости от того, с какой командой имеет дело.

Дело в том, что сами члены команды – это ресурс, распределяющий задания. Каждый человек самостоятельно берет следующую задачу, как только закончит предыдущую.

Это происходит во время ежедневных scrum-митингов, когда остальная часть команды имеет возможность внести свой вклад и помогает исправить курс. Например, если разработчик берется за оптимизацию сложной базы данных, то администратор баз данных (DBA) может вмешаться и предложить отложить решение этой задачи на более поздний срок.

Но разве мы не можем заранее избежать узких мест при планировании работы?

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

Как ни странно, это самый распространенный источник проблем в области управления проектами. Очень сложные задачи оценить гораздо труднее, чем простые. Задания, требующие конкретного специалиста или ресурса, несут больше риска, чем те, которые могут быть выполнены любым членом команды. Не стоит удивляться, что сложные задачи, подвластные лишь конкретному квалифицированному человеку (как в примере с оптимизацией баз данных), скорее всего, будут реализованы с ошибками. Хуже всего то, что менеджеры проектов зависят от этого узкого специалиста как на этапе оценки, так и в процессе выполнения работ.

Невозможно все просчитать заранее. Существует несколько решений, принимаемых в начале проекта (Java или C#? Windows или Linux? Mac или PC?). И есть еще ряд задач, которые необходимо сделать конкретному человеку. Но вообще scrum-команды не распределяют задачи в начале проекта или спринта.

Они не пытаются придумать «окончательную» последовательность задач. Причина в том, что в большинстве случаев задач, и особенно задач по программированию, команда не знает точно, сколько ей потребуется времени, пока она не приступит к работе, и зачастую она обнаруживает зависимости только тогда, когда они становятся явными. Это также относится к заданиям, которые кажутся небольшими в начале, но становятся объемными в конце (и наоборот). Конечно, хотя перед командой и стоит общая задача обнаружить, что она пропустила во время спринта, это не снимает с нее ответственности за разработку настолько сложного или окончательного списка задач, насколько это возможно, во время планирования спринта.

Поэтому вместо декомпозиции работ на задачи в начале спринта, упорядочивания задач, распределения их между членами команды перед началом любой работы и отслеживания плана agile-команды следуют простому правилу планирования. Они принимают все решения в последний ответственный момент[36].