Скелет и сердце скрама
Все практики скрама держатся на скелете
итеративно-инкрементального процесса. Если говорить проще, то команда
определяет срок и главные задачи и полностью отдается процессу работы, чтобы на
выходе получить готовый продукт. В ходе работы команда прилагает все усилия, а любые
заинтересованные лица не отвлекают команду. Когда временный промежуток
заканчивается, команда представляет получившийся продукт, чтобы его могли
проверить и занести нужные правки. До начала работы команда изучает требования,
рассматривает доступные технологии и оценивает свои возможности и навыки. Затем
они обсуждают как будут создавать продукт. Важна природная гибкость – команде
придется почти ежедневно менять подход к работе, потому что будет много
столкновений с трудностями и неожиданностями комплексного окружения. Команда
сама выбирает наилучший способ реализации. В скраме есть три роли: владелец
продукта, команда разработки и скрам-мастер.
Владелец создает бэклог
продукта – определяет первоначальные общие требования. Также он определяет цели
по возврату инвестиций и добивается регулярного финансирования проекта.
Владелец продукта
ответственен за поставку заинтересованным лицам максимальной ценности:
гарантирует, что наиболее ценная функциональность будет реализована в первую
очередь. Для этого делается регулярный пересмотр порядка задач в бэклоге.
Команда разработки отвечает
за создание функциональности. Она самоуправляющая, самоорганизующаяся и
кросс-функциональна. Команда несет ответственность за организацию своей работы
и за решения о том, как в рамках итерации превратить часть бэклога продукта
в инкремент потенциально поставляемой
функциональности(протопит, демо-версию продукта). Участники команды несут
коллективную ответственность за успех каждой итерации и проекта в целом.
Скрам-мастер отвечает за
организацию процесса, за обучение скраму всех участников проекта, за то, чтобы
каждый следовал правилам и практикам скрама, за внедрение скрама так, чтобы он
и соответствовал культуре компании, и позволял получать ожидаемые преимущества.
Автор постоянно
подчеркивает, что люди, выполняющие эти роли, должны быть преданы проекту.
«Поэтому скрам так
настойчив в требовании полной прозрачности: всегда должно быть понятно, кто на
крючке, а кто просто назойливый советчик. Кто несет ответственность за возврат
инвестиций, а кто имеет долю в 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