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

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

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

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

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

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

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

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

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

Вернемся к истории проекта Lolleaderz.com. Роджер и Ави столкнулись с проблемой на четвертом спринте, потому что администратор баз данных затянул с выполнением одной из тех специализированных задач, которая, казалась, была полностью и официально распланирована с первого дня. Эта общая причина провала проекта вызвана чрезмерным планированием. Руководитель проекта предполагает, что комплектованием задач будет заниматься один человек – как правило, эксперт, обладающий специальными навыками. Обычно именно эти задачи имеют больше шансов «провалиться». Когда это происходит, никто другой не может справиться с этими заданиями, поэтому начинаются каскадные задержки, сверхурочная работа, которая неизбежно снижает качество результата (и возможно, приводит к поиску таким специалистом новой работы!).

Scrum-команды, принимающие решения в последний ответственный момент, могут справиться с этим по-разному. Вместо того чтобы предполагать, что администратор баз данных вовремя выполнит все эти задачи, они выписывают их на карточки (или какой-нибудь электронный эквивалент) и вывешивают на доску задач в колонку «выполнить». Во время ежедневной планерки их видят все и кто-нибудь, как правило, задает вопросы, если предполагает, что задача может вызвать проблемы в ходе спринта.

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

Команде гораздо проще обнаружить узкие места во время митингов, чем в ситуации, когда командно-административный руководитель проекта заранее все за всех продумал. И когда команда видит, что приближается к этим узким местам, у нее есть время, чтобы найти обходные пути. Благодаря бдительности всех участников часто обнаруживается, что последний ответственный момент для некоторых задач находится на более ранних этапах спринта, чем для других. В этом ценность цикла «обзор-контроль-адаптация»: он дает возможность выявить потенциальные проблемы и принимать решения всей командой.

Что бы произошло, если бы Роджер и Ави эффективнее проводили ежедневные митинги? Вместо распределения заданий они тратили бы время на совместную работу с командой, чтобы выявить проблемы графика и самостоятельной постановки задач. Работая как одна команда, они могли бы быстрее понять, что им нужен кто-то другой, кроме DBA, чтобы начать работать над хранимыми процедурами, чтобы успеть выполнить эту работу до окончания спринта. Или, по крайней мере, выяснили бы, что «взвалили на себя больше, чем могут унести», и успели бы вовремя уточнить, будет ли работающее программное обеспечение поставлено к концу спринта.

Берите пример со «свиньи»

Во время этой встречи каждый член команды несет ответственность перед коллегами и должен объяснить, почему обязательство, взятое на предыдущей встрече, не выполнено. Представьте себя членом самоорганизующейся команды, действительно чувствующим ответственность за проект. Что нужно знать, чтобы делать нужную работу каждый день? Прежде всего – понимать, над чем вы работаете. Но если ваша команда действительно самоорганизующаяся, то вы не можете полагаться на некоего командно-административного менеджера проекта, все решающего за вас. Нужен другой механизм, чтобы получить текущее задание. Первое, что дают ежедневные scrum-митинги, – это ваша следующая задача. Если наступает очередь ответить на вопрос, что вы будете делать начиная с сегодняшнего дня и до следующей планерки, то в случае, когда вы уже выполнили все необходимые работы, ваша обязанность – взглянуть на задачи, которые все еще находятся в столбце «выполнить», и выбрать наиболее значимую для вас и для проекта. Если вы сделали неправильный выбор, то тот, кто действительно предан позиции «свиней», скажет вам об этом.