Кен Швабер «Скрам. Гибкое управление продуктом и бизнесом»

Автор:

Скелет и сердце скрама

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

Владелец создает бэклог продукта – определяет первоначальные общие требования. Также он определяет цели по возврату инвестиций и добивается регулярного финансирования проекта.

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

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

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

Автор постоянно подчеркивает, что люди, выполняющие эти роли, должны быть преданы проекту.

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

Процесс скрама

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

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

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

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

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

Необходим и ежедневный скрам — это 15-минутное совещание, на котором каждый участник команды делится информацией о ходе работы, а также команда вписывает встречи.

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

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

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

3. Какие препятствия могут помешать мне и команде достичь цели спринта?

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

Каким должен быть бэклог, что такое инкремент

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

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

Автор называет «поросятами» тех, кто предан проекту и готов рисковать, брать ответственность. «Цыплята» – заинтересованные зрители.

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

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

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

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

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

Как это работает

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

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


ПОЛНЫЙ ТЕКСТ НОМЕРА ДОСТУПЕН ТОЛЬКО ОФИЦИАЛЬНЫМ ПОДПИСЧИКАМ (для получения полного номера зарегистрируйтесь у нас на сайте).

© КОПИРОВАНИЕ МАТЕРИАЛОВ САЙТА ВОЗМОЖНО ТОЛЬКО С ПИСЬМЕННОГО СОГЛАСИЯ ПРАВООБЛАДАТЕЛЯ TP@TOP-PERSONAL.RU


 Об авторе:
Кен Швабер — разработал скрам вместе с Джеффом Сазерлендом в начале 1990­х годов. Являясь одним из 17 авторов «Манифеста гибкой разработки программного обеспечения» в 2001 году, он впоследствии основал Agile Alliance, Scrum Alliance, а в 2009 году — Scrum.org. Cоавтор «Руководства по скраму».


Альпина Паблишер
МОСКВА
2019