День 289. Agile (VI)

Типичные проблемы и ошибки начинающих команд в SCRUM

1. Владелец продукта не принимает решения от лица бизнеса или не имеет полномочий на это

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

2. SCRUM-митинги превращаются в обычные статус-митинги

Многие команды не понимают разницу между командно-административным управлением и самоорганизацией. В таком случае все митинги, присущие SCRUM (daily meetings, ретроспективы) по сути являются обычными совещаниями, единственная цель которых — донесение информации о ходе работ по проекту до менеджера. Цель же этих митингов в SCRUM иная — выявление блокирующих задач и планирование новых работ на ближайший период времени.

3. SCRUM-мастер следит за всеми разработчиками

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

Пользовательские истории, скорость работы команды и общепринятые практики SCRUM

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

Стейкхолдеры и пользователи продукта ненавидят непредсказуемость.

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

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

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

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

Многие команды пишут свои истории пользователей по следующему шаблону:

Я как <роль> хочу <конкретные действия, которые я предпринимаю>, чтобы <цель>.

Такой формат позволяет легко сформулировать критерии приеки (удовлетворенности пользователя) для того, чтобы понимать, какие задачи могут считаться завершенными.

Во время планирования спринта команда совместно определяет, сколько они смогут сделать в текущем цикле, чтобы создать программное обеспечение для поставки по его итогам. Но как именно команда это делает?

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

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

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

Почему сторипойнты работают

— Они простые

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

— Они формальные

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

— Команда контролирует их

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

— Разработчики их не боятся

Уже довольно много разработчиков имеют опыт выставления оценок в процессе работы. Затем эти оценки передаются руководителю проекта, после чего устанавливается жесткий дедлайн плана проекта. Подобное никогда не случится с очками историй, потому что они не превращаются в часы или конкретные сроки. Единственная зафиксированная величина — это дата окончания спринта, а запланированный объем работ может быть изменен во время ежедневного scrum-митинга в ходе цикла «обзор-контроль-адаптация».

— Они помогают команде выяснить, в чем заключается смысл истории

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

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
сейчас на сайте
Читателей: 21 Опыт: 786.781 Карма: 6.74063
все 22 Мои друзья