Как реализовать Scrum за 10 шагов. Шаг первый.

Итак, вы хотите попробовать реализовать Scrum?

А вы хотели бы сделать это легко? Тогда слушайте. Это первый шаг из моей серии:  «Как реализовать Scrum за 10 шагов».

Но это не просто первый шаг. Это самый важный шаг.

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

Прежде всего, с чего же вам следует начать?

1. Установите связь с бизнесом


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

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

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


2. Начните с BAU (Business As Usual)


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

Итак, вы выбрали продукт, который вы будете разрабатывать, используя Scrum. И у вас есть, по крайней мере, один человек, который будет посвящен в продукт (или линейку продуктов). Для простоты вы выбрали продукт, который находится в обычном бизнес цикле (исправления ошибок и улучшения).

3. Найдите добровольца на роль Product Owner (владельца продукта)

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

 

Если по каким-либо причинам этот шаг является проблемой для вас, НЕ СЛЕДУЕТ ИДТИ ДАЛЬШЕ.


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


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

 

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

4. Выступите в роли Scrum-мастера

Допустим, вы смогли все это организовать. У вас есть один продукт, приложение или линейка продуктов. Вы имеете, по крайней мере, одного человека, разрабатывающего продукт (Scrum Team). А также одного владельца продукта (Product Owner). А вы, поскольку читаете эту статью о реализации Scrum, я буду полагать, Scrum-мастер.

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

5. Создайте Product Backlog

А теперь вы должны создать Product Backlog.
Поскольку вы сейчас читаете эту заметку, и я говорю о назначении (добровольном) владельца продукта, вам, вероятно, придется создавать или способствовать созданию Product Backlog. Если говорить строго, то этот список должен принадлежать владельцу продукта. Но вы можете первым ударить по мячу.

 

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

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

Но ... очень важно только Product Owner может приоритезировать Product Backlog.

6. Product Backlog может содержать все что угодно. Это может быть все, что связанно с продуктом. Ошибки. Улучшения. Целые проекты. Вопросы. Риски. Что угодно.

Пункты, включенные в Product Backlog,  в идеале должны быть выражены в терминах предметной области, которые имеют вполне определенную ценность для пользователя (или клиента, или бизнеса в целом). Но не в виде технических заданий.


Функциональные требования должны быть выражены в виде фич. Нефункциональные требования также могут быть включены в Product Backlog, например, “продукт должен быть быстрее, мы должны обеспечить защиту продукта", "мы должны отказаться от старой платформы”, существует высокий риск простоя из-за одной ошибки. Они могут не являться фичами, как таковыми, но они полностью оправданы в качестве пунктов в Product Backlog.

7. Приоритезируйте Backlog

Владелец продукта приоритезирует Product Backlog. Пунктам в этом списке не присваиваются конкретные значения 1, 2, 3 или что-нибудь в этом роде. Приоритет определяется порядковым номером в списке. Product Owner добавляет пункты в Product Backlog в порядке их значимости.


Пункты из нижней части списка могут быть сделаны не скоро или вообще никогда не сделаны. Они могут быть описаны неопределенно, только в общих чертах. Поэтому не тратьте время на описание вещей, к которым вы не приступите в ближайшем будущем, а то и вообще. Если какие-то из добавленных в Backlog фич оказались не самой удачной идеей, то Product Owner должен это объяснить тем, кто добавил эти пункты, почему они будут удалены из Backlog'a. Однако, если какая-то фича не так уж и плоха, но не может быть в ближайшее время реализована, просто переместите ее в нижнюю часть списка и объясните автору, насколько она (не)согласуется с приоритетами проекта.


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


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


Наличие Product Backlog поможет решить эту проблему.

Кроме того ...

Вышеупомянутые меры могут оказать глубокий и мощный эффект ...

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


И громкие крики больше не являются способом для выстраивания приоритетов. Так что не стоит кричать.

Если вы думаете о какой-нибудь  технической проблеме или риске, из-за которого вы потеряли сон, но вам не дают возможности довести это знание до адресата, просто добавьте это в Product Backlog. Хотя Produсt Owner может решить, что другие вещи могут иметь более высокий приоритет. Но право собственности на риск будет уже успешно передано.


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


Итак, что же у вас теперь есть? У вас есть Scrum-команда.


Scrum-мастер. Product Owner и Product Backlog. Вы познакомили вашу команду с заказчиком. Вы создали прозрачный механизм управления требованиями продукта. Ваша команда работает согласованно. А в итоге вы получили механизм, систему массового обслуживания, которая работает на основе приоритетов.


Если у вас всего этого нет, то значит вы не сделали этот шаг. А до тех пор, пока вы его не сделаете, не следует идти дальше.


Источник: agileguru.ru