Блистательный совет для сохранения времени

В «Руководстве по Скраму» не упоминаются пользовательские истории – у владельца продукта могут быть и другие способы объяснить свои идеи. Пользовательские истории в основном просто самый популярный метод.

Не распыляйтесь, тратя время на другие варианты, – идите по проторенному пути.

 

Планирование спринта

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

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

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

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

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

Блистательный пример

Команда разработки решает, какой объем работы войдет в спринт, но Владелец продукта и Скрам-мастер тоже принимают в этом участие.

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

• Выберите пользовательскую историю с наивысшим приоритетом. Проверьте критерии успеха – всем они должны быть понятны.

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

• Если ответ «нет», разберитесь в причинах. Например, если история слишком большая, ее следует разбить на подзадачи. Если ответ все еще «нет», продолжайте обсуждение.

• Повторяйте этот процесс, пока журнал спринта не станет, возможно, непростым, но главное – выполнимым.

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

• Сделано!

Ежедневная летучка

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

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

– Да, иногда наши совещания бывают весьма динамичными

 

Ежедневное совещание придерживается очень простого формата: каждому члену команды задается три вопроса.

• Что вы делали вчера? Отслеживание прогресса.

• Что вы будете делать сегодня? Обсуждение плана.

• Какие затруднения у вас возникают? И это – самый главный вопрос.

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

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

 

Блистательный пример

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

• Шумный наблюдатель – тот, кто не входит в состав команды, но будет пытаться встать и вмешаться в обсуждение. Скрам-мастер должен объяснить, что любые посторонние могут только наблюдать! Любые замечания можно выслушать потом.

• Опоздавший – приходит на встречу поздно, а затем просит пересказать ему то, что он пропустил. Не делайте этого (разве что это совершенно необходимо), поскольку уступка только поощрит эту дурную привычку.

• Отвлекающий – прерывает встречу, часто непреднамеренно, но всегда с отрицательными последствиями. Совет: придерживайтесь сценария; все послушают о вашем неудачном свидании в другое время.

• Скептик – не хочет находиться на встрече и, как следствие, ничем не помогает. Либо вы тут, либо нет, потому что все в команде должны играть по правилам.

• Тихоня – даже если кто-то немного застенчив, он должен выступить. Правило: каждый вносит свой вклад. Это не тот случай, когда молчание – золото.

• Футуристы – пытаются заглянуть в будущее, вместо того чтобы сосредоточиться на здесь и сейчас. Оставьте все концепты Владельцу продукта и сконцентрируйтесь на следующем выпуске.

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

Следите за такими нарушителями, особенно за теми, кто проявляет несколько черт из этого списка.

 

Обзор итогов

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

• Облегчение контроля над выпуском продукта: команда знает, является ли то, что они делают, в корне верным или нет.

• Обзор стратегических целей: проверка выполненности целей спринта с возможностью обсудить любые проблемы.

• Удовлетворение ожиданий заинтересованных сторон: уже на ранней стадии разработки они видят, что получат! И никаких сюрпризов в последнюю минуту.

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

Блистательный пример

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

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

Придерживайтесь простого формата и не слишком углубляйтесь в детали – представьте, что среди слушателей сидит ваша пожилая и нетерпеливая тетушка Роуз и вам нужно говорить понятно, но в то же время профессионально. И не слишком увлекайтесь – нет ничего плохого в том, чтобы управиться за 15 минут.

• Скрам-мастер представляет команду, определяет обстановку и озвучивает согласованную цель спринта.

• Все карточки помещаются на стол, а Скрам-мастер поясняет, все ли было закончено, а если нет, то почему.

• Скрам-мастер обновляет пользовательские истории, входящие в спринт.

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

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

• Скрам-мастер дает Владельцу продукта последний шанс прокомментировать или внести какие-то предложения, прежде чем принимать решение о том, готов ли он принять рабочий пакет.

• Прочим присутствующим предоставляется возможность высказать свое мнение.

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

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

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

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

Сосредоточивайтесь на том, что впереди, а не оглядывайтесь постоянно назад.

Колин Пауэлл (бывший государственный секретарь США)

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

Блистательный пример

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

Как только команда все записала, предложите просмотреть записки и сгруппируйте их по темам. Каждой теме дайте название.

 

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

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

 

Артефакты Скрама

Артефакты Скрама – это элементы, необходимые команде для успеха. Обязательная большая тройка – это журнал пожеланий продукта, журнал пожеланий спринта и диаграмма сгорания задач. Есть и другие инструменты, но эти основные. Большинству более чем хватает и этих трех.

Журнал требований продукта

Журнал требований продукта (бэклог продукта) – это список идей, которые нужно воплотить в продукте; можно также назвать его списком желаний. Этот журнал служит для того, чтобы требования владельца продукта были донесены до команды в четком, ясном и постоянно доступном формате. Он включает в себя все, что может понадобиться команде в ходе работы, – не только специфические задачи, но и прочие пожелания.

 

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

 

Журнал требований спринта

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

 

Диаграмма сгорания задач

Одной из самых сильных сторон Скрама является метрика текущих задач. Вы можете навсегда попрощаться с долгими днями споров о прогрессе или замораживании работ в состоянии «практически готово». Диаграмма сгорания задач – это простое и наглядное отображение прогресса, и она используется командой для отслеживания хода разработки продукта во время спринта.

 

Блистательная мысль

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

 

Блистательная мысль

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

Особенно будьте внимательны в случае задач, которые завершены на 99 %.

Завершающие слова

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

Прежде чем применять Скрам, нужно не только разобраться в его основах, но и понять, как именно все элементы методологии работают вместе. Можно встретить так называемые Скрам-команды, работающие без каких-то ключевых ролей или артефактов; некоторым из них это даже вполне удается. Но для стабильного успеха необходимо предварительно всесторонне изучить теорию. Не забывайте: причина номер один всех аварий на дорогах – неопытные водители.

 

Блистательный итог

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

• Вам нужны четкое видение и журнал требований проекта; убедитесь в том, что только Владелец продукта определяет их содержание и расставляет приоритеты.

• Выпускайте продукт с бизнес-ценностью в конце каждого спринта. Единственное мерило успеха – работающий продукт.

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

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

• Лучший способ начать – это просто начать!