Текст книги "Гибкое управление проектами и продуктами"

Процессы

Большинство процессов Scrum носят характер встреч, так как данная методология основана на качественных коммуникациях. Все встречи жестко ограничены по времени (time-boxed).

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

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

Спринт может быть отменен владельцем продукта в случае, если цели спринта устарели.

У планирования спринта две основные задачи: выбор элементов журнала пожеланий для реализации и их декомпозиция. Планирование проводится в самом начале спринта и обычно занимает не более дня для спринта длиной в месяц.

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

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

1. Что было сделано с предыдущего скрам-митинга?

2. Какие есть проблемы?

3. Что будет сделано к следующему скрам-митингу?

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

Обзор спринта (Sprint Review, «демонстрация», или сокращенно «демо») – демонстрация владельцу продукта и заинтересованным лицам работающего функционала продукта, сделанного за спринт. Основная задача проведения обзора спринта заключается в получении обратной связи, общий цикл чего выглядит следующим образом.

Получение обратной связи в рамках Scrum

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

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

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

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

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

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

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

Структура ретроспективы. Обычно ретроспектива занимает от 30 минут до четырех часов и ее продолжительность зависит от таких факторов, как:

• длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;

• размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;

• наличие проблем: со временем команда решает проблемы, и ретроспективы сокращаются по времени.

В процентном соотношении принято выделять такую структуру.

Структура ретроспективы

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

1. Что было сделано хорошо?

2. Что можно улучшить?

3. Какие улучшения будем делать?

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

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

Если у команды отсутствуют серьезные проблемы, желательно следующие темы обсудить на ретроспективе:

• скорость команды и ее изменение по сравнению с предыдущими спринтами;

• нереализованные истории пользователей и причины опоздания;

• дефекты и их причины;

• качество процессов (нарушения, отступления).

К паттернам можно отнести анализ сделанных улучшений за несколько прошлых спринтов. Такая «ретроспектива ретроспектив» может проводиться раз в четыре спринта и позволяет контролировать уровень сделанных улучшений.

Артефакты

В Scrum определены три артефакта.

• Журнал пожеланий продукта (Product Backlog) – фактически приоритезированный список требований. Обычно он состоит из бизнес-требований, которые приносят конкретную бизнес-пользу и называются элементами журнала пожеланий.

• Журнал пожеланий спринта (Sprint Backlog) – часть журнала пожеланий продукта с самой высокой важностью и суммарной оценкой, не превышающей скорости команды, отобранная для спринта.

• Инкремент продукта – новая функциональность продукта, созданная во время спринта.

Глава 3. Управление продуктом

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

Построение бизнес-модели

Наиболее подробно построение бизнес-моделей описано в работе Александра Остервальдера (Alexander Osterwalder) и Ива Пинье (Yves Pigneur) «Построение бизнес-моделей. Настольная книга стратега и новатора» (Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers). Бизнес-модели «Канвас» представляют собой способ визуализации бизнес-моделей, и их можно адаптировать к проектам по разработке ПО (табл. 3.1).

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

Персоны

Практика анализа персон пришла в управление продуктами из практик User Experience (опыт использования). Она заключается в описании пользователя создаваемого продукта как реального персонажа с конкретными ценностями и целями.

Таблица 3.1.

Бизнес-модель в виде Lean Canvas

Инструмент Story Mapping

После выявления персон нужно перейти к определению функционала, который необходимо реализовать для персон. Для этого используется Story Mapping (стори маппинг) – способ визуализации и планирования функционала.

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

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

• дополнительных возможностей;

• безопасности;

• удобства использования;

• производительности.

Чем ниже мы опускаемся по подзадачам, тем меньше у них важность.

Визуализация журнала пожеланий продукта с помощью Story Mapping

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

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

 Уникальный числовой идентификатор истории – обычно совпадает с идентификатором истории пользователя из трекера, которым пользуется команда. Этот идентификатор позволяет точно сказать, о какой истории пользователя в данный момент идет речь.

 Название истории пользователя – короткое (примерно до десяти слов) описание функционала с точки зрения пользователя, сформулированное в виде тройки «роль – действие – цель», например: «Пользователь вводит логин и пароль, чтобы авторизоваться на сайте».

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

 Оценка – числовая относительная оценка истории пользователя по специальной шкале.

Указанные поля удобно размещать на стикере, который прикрепляется на доску. Например, историю пользователя для авторизации на сайте с оценкой 10 очков (Story Points), важностью 200 и номером в трекере 1453 можно представить на стикере так.

История пользователя для авторизации на сайте

Эти четыре поля являются фактически обязательными, но часто используются и дополнительные поля, которые, например, заносятся в трекер.

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

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

♦ пользователь вводит логин root и пароль pass и переходит на страницу личного профиля на сайте;

♦ пользователь вводит логин root и пароль wrongpass и получает сообщение Введен неправильный логин или пароль.

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

Размер журнала пожеланий и стратегическое планирование

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

Противоречие между тактическим и стратегическим планированием

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

Более важные элементы журнала пожеланий определены точнее

Как видите, чем позднее планируется реализация того или иного функционала, тем более крупные фрагменты функционала берутся. Отмечу, что это также согласуется полностью с принципами KISS (Keep it simple, stupid – «Не усложняй, тупица») и YAGNI (You аin’t gonna need it – «Вам это не понадобится»).

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

• рефакторинг модуля;

• оптимизация производительности;

• исправления сложного дефекта;

• настройка инфраструктуры.

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

Определение приоритетов историй пользователя

 
I can’t get no satisfaction,
I can’t get no satisfaction.
‘Cause I try, and I try, and I try, and I try.
I can’t get no, I can’t get no.
 

The Rolling Stones

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

Рассмотрим более точную модель – модель удовлетворения потребностей Кано. Японский профессор Нориаки Кано (Noriaki Kano) предложил ее в работе «Привлекательное качество и необходимое качество» (Attractive Quality and Must-Be Quality) еще в 1984 году.

Разделим всю функциональность продукта на три категории в соответствии с удовлетворенностью пользователя и полнотой функциональности продукта.

Типы функций продукта

Таким образом, можно выделить три типа функций продукта.

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

2. Линейные функции – чем больше и качественней они реализованы, тем больше доволен пользователь. К примеру, это долгая работа сотового телефона без подзарядки.

3. Привлекательные функции – функции, которые придают вашему продукту wow-эффект. В качестве примера можно рассмотреть эргономику и удобство использования (юзабилити) Apple IPhone.

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

1. Как вы отнесетесь к наличию данной функциональности в продукте?

2. Как вы отнесетесь к отсутствию данной функциональности в продукте?

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

В качестве ответов опрашиваемому пользователю предлагаются следующие варианты ответов:

• нравится;

• ожидаю этого;

• все равно;

• могу смириться с этим;

• не нравится это.

После такого опроса можно проводить анализ результатов с помощью следующей таблицы (табл. 3.2).

Таблица 3.2.

Анализ результатов

В результате функции продукта разобьются на шесть категорий:

• A (attractive) – привлекательные;

• O (one-dimensional) – линейные;

• M (must-be) – обязательные;

• R (reverse) – обратные (ненужные);

• Q (questionable result) – сомнительный/противоречивый результат;

• I (indifferent) – безразлично.

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

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

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

По завершении опроса необходимо подвести итоги, просуммировав ответы пользователей (табл. 3.3).

Таблица 3.3.

Суммы ответов пользователей

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

Умные цели для спринта

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

Владелец продукта должен ставить перед собой и командой четкие и понятные цели, для чего существует несколько критериев, которые собираются в английскую аббревиатуру SMART («умный») (табл. 3.4).

Таблица 3.4.

Расшифровка SMART

Есть замечательный закон Мерфи, который можно в нашем случае сформулировать так: «Если есть несколько способов понять задачу, то кто-то обязательно поймет ее неправильно». Поэтому при постановке целей необходимо делать их максимально точными и конкретными, чтобы исключить различные интерпретации у постановщика и исполнителя (табл. 3.5). Хорошей практикой также будет запись целей либо на бумагу, либо в электронном виде, благо сейчас имеется множество соответствующих программ и веб-сервисов.

Таблица 3.5.

Запись целей

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

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

Таблица 3.6.

Измеримость целей

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

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

Недостижимые. При постановке таких задач заранее понятно, что исполнитель с ними заведомо не справится. Например, нельзя за день нарисовать 1000 качественных макетов для разных сайтов. Такие задачи перед подчиненными ставить нельзя.

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

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

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

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

Релевантность целей нужно рассматривать с двух сторон: релевантность для исполнителя и для компании. Релевантность (значимость) для исполнителя тесно связана с его мотивацией. Например, сотруднику, который любит изучать новые технологии, можно и нужно поручить исследовательский проект, а не рутинную работу. Когда команда понимает, что цель важна, усилия, которые она направит на ее достижение, будут заведомо больше усилий, направленных на «неважную» цель. Отмечу также, что букву R (и другие буквы аббревиатуры SMART) расшифровывают по-разному.