Стоит прочитать: обзор книги Джеффа Сазерленда «Скрам. Революционный метод управления проектами»

Сергей Раков

руководитель направления в ООО «РТК ИТ»

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

Автор книги призывает использовать Scrum даже в повседневной жизни и в целом это возможно, но необходимо ли — решать вам. В книге описаны примеры его внедрения в процесс обучения в школе в Голландии и даже при обмене практической информацией между фермерами в Уганде. Почитайте, очень интересно, но истории из жизни добавляют книге объема.

Итак, давайте перейдем к ключевым моментам книги.

Владелец продукта и скрам-мастер

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

Владелец продукта должен понимать как устроен процесс разработки в команде и уметь оценивать ее возможности. Также он должен уметь анализировать рынок и понимать его потребности и, соответственно, хорошо разбираться в сути продукта.

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

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

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

Команда

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

На практике же часто применяют матричную структуру управления в командах и собирают команду из нескольких функциональных групп разработчиков. В такой ситуации очень часто бывает, что один и тот же сотрудник может принимать участие сразу в двух и более проектах. Старайтесь этого избегать, т.к. переключение между контекстами проектов отнимает у исполнителя много сил и времени. А иногда задачи из этих проектов будут конфликтовать между собой и тут уже появляется проблема определения очередности выполнения этих задач. Старайтесь исключить такое разделение ресурсов, а если не получается, то пытайтесь минимизировать количество переключений между проектами — выделяйте сотрудников целиком и полностью на длительное время. Но моя практика показывает, что это не работает. Всегда найдутся проблемы и баги в другом проекте, которые потребуют срочного участия разработчика и команде придется подождать.

Бэклог

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

Начинайте работу с тех фичей, которые принесут максимальную пользу. И помните — бэклог может и должен меняться. Те фичи, которые были нужны месяц назад могут оказаться неактуальными сейчас. Будьте готовы даже исключать фичи из бэклога. Знаю, это тяжело, но это только сначала.

Важно, что владелец продукта говорит что нужно сделать, но не как. Какими инструментами пользоваться и как реализовать фичу решает команда самостоятельно.

Хорошо, бэклог составили, приоритеты расставили и обычно следующий вопрос: «Ну что, когда сделаете?». Кто из вас давал оценки в часах или датах? И как часто вы попадали в эту оценку? Да, если задач на неделю или даже месяц, то можно попасть с высокой степенью вероятности, но что делать если проект на год или даже больше? Очень часто оказывается, что уже через неделю бэклог может измениться — появятся новые фичи, например. И из-за этого надо опять все переоценивать. Это сложно и не нужно. И мы подходим, пожалуй, к самому сложному для понимания моменту в Scrum — это оценка задач и планирование сроков. Скажу сразу — если вы пробовали и у вас не получилось, то значит надо пробовать еще, т.к. это действительно работает и можно прогнозировать сроки в длительных проектах с бо́льшей точностью.

Автор предлагает оценивать задачи по уровню их сложности, а не по времени. И брать для этого относительные размеры, например футболок: S, M, L, XL, XXL. А еще лучше использовать последовательность Фибоначчи: 1, 2, 3, 5, 8, 13, 21.

Перед оценкой бэклога разбейте свои фичи на пользовательские истории и опишите в них сюжет: Как X, я хочу Y, для того, чтобы Z. Пользовательские сценарии оценить проще и при оценке используйте дельфийский метод или покер планирование. Суть у этих двух методов одна — собрать объективную оценку каждой пользовательской истории со всех участников планирования без влияния одного мнения на другое. И что еще важно, оценка не должна привязываться к скиллам разработчиков. Например, нельзя оценить задачу в 5 поинтов, если ее будет делать джун и в 2 поинта, если синьор. Нужно оценивать именно сложность, например пусть будет 3 поинта. Просто джун будет делать ее дольше, но это все равно 3 поинта. Тогда получится, что сеньор сделает за спринт задач на 40 поинтов, а джун только на 10. Именно это и нужно.

«Ну и кому нужны эти абстрактные числа? Как сказать когда работы будут выполнены?» — спросите вы. А вот как — мы уже поняли, что мы оцениваем сложность и за один и тот же промежуток времени разработчики с разным опытом реализуют задач на разное количество поинтов. Т.е. для оценки сроков нам нужно сначала узнать производительность всей команды — это сумма поинтов всех выполненных задач в спринте. И после того как команда пройдет от двух до четырех спринтов и научится одинаково оценивать сложность задач, вы сможете получить среднюю производительность команды в поинтах. А дальше простая математика — вам нужно разделить сумму поинтов всего бэклога на производительность команды и вы получаете количество спринтов, которое вам понадобится для выполнения всех задач из бэклога.

Спринты

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

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

На моей практике еще ни один спринт не обходился без вбросов от заказчика. В случае если объяснения, что так делать не нужно не работают, то я обычно, закладываю процент в спринт на внезапные задачи. А этот процент вычисляется так же как и производительность команды — исключительно опытным путем.

Стендап-митинги

Это ежедневные встречи команды, которые, по мнению Сазерленда, должны длиться не более 15 минут. Каждый участник должен ответить на три вопроса:

1. Что ты делал вчера, чтобы помочь команде завершить спринт?
2. Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?
3. Какие препятствия встают на пути к достижению цели спринта?

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

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

Обзор спринта или демо

Джефф говорит, что это встреча, на которой команда рассказывает, что сделано за спринт и демонстрирует готовые части продукта. Также он предлагает проводить встречи открыто и приглашать всех заинтересованных лиц — заказчика, представителей руководства и даже потенциальных потребителей. Команда должна показать только то, что действительно завершено и готово к использованию.

Ретроспектива спринта

Автор предлагает еще один инструмент — ретроспектива спринта. Это встреча команды после демонстрации результата прошедшего спринта, на которой все садятся за общий стол и обсуждают ряд вопросов:

1. Что прошло хорошо?
2. Что можно было сделать лучше?
3. Что можно сделать лучше в следующем спринте?
4. Какое улучшение можно внедрить прямо сейчас?

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

Далеко не у всех команд присутствует ретроспектива, т.к. не все понимают ее важность.

Если вы используете Scrum, но при этом мои примеры неудачного применения вызвали у вас улыбку или вы просто недовольны процессом разработки в вашей команде — обязательно прочитайте эту книгу и у вас будет понимание к каким процессам должны стремиться менеджеры.