Трудно сказать, какой из описываемых мной этапов самый важный. Реально вся цепочка последовательных действий, будучи выполнена в такой последовательности, приводит к успеху Agile-проекта. Но в создании бэклога продукта заложено больше всего важности и ответственности за то, как потечет поток проекта: стремительно по тщательно подготовленному руслу, либо извилисто, с подводными камнями и случайными водопадами.
По методологии бэклог продукта составляет Владелец продукта. Но, учитывая важность этого процесса, мы подключаем к этому этапу и Заказчика, и некоторых членов команды, и специалистов и экспертов из подразделений, не вошедших в периметр проекта. В общий пакет возможных действий, пожеланий потребителей, требований бизнеса – иными словами, в бэклог продукта не включаются частности или мелкие детали. У команд будет впереди множество возможностей вносить коррективы в этот основополагающий документ, потому что он живой и подвижный. Как и все в Agile.
С другой стороны, если сделать бэклог крупным мазками, не конкретизировать задачи, это может привести к такому положению, когда на каждом бэклоге спринта образ продукта сильно меняется, и создается впечатление, будто работу надо начинать сначала.
12. Первое рабочее собрание команды (команд) – уровень нулевого спринта.
На этом уровне Владелец продукта представляет команде или всем командам (это зависит от размеров проекта) бэклог продукта, обрисовывает образ цели. На этом же этапе после всестороннего обсуждения образа продукта, участники определяют размеры спринтов, которые отныне будут неизменными отрезками времени, в течение которого команды будут выдавать минимально готовый продукт (во всех проектах, кроме Agile в продажах, но об этом позже) и представлять его на тестирование Заказчику и потребителям, если того требуют условия.
Для обсуждения всех параметров проекта мы используем инструмент стратегического планирования Александра Остервальдера – Canvas. Этот инструмент позволяет увидеть всестороннюю картину цели, а именно:
• клиентов, для которых делается проект;
• каналы сбыта продукта;
• взаимоотношения с клиентами, какие коммуникации будут предприняты;
• предоставленная ценность, показывающая, как доставляется продукт потребителям;
• ключевые виды деятельности, которыми будет заниматься команда;
• ключевые ресурсы, которыми располагают участники;
• партнеры, помогающие команде достичь результата;
• издержки, что придется потратить на реализацию проекта, и доходы, которые команда получит по итогу.
Этот инструмент мы с Марией Куршиной впервые применили при создании Agile-команд в науке в Первом Московском государственном медицинском университете имени И. М. Сеченова. Этому важному в нашей деятельности и в продвижении Agile-философии во многие сферы жизни проекту будет посвящена отдельная глава в книге.
Как составная часть входит Canvas и в SWAY – методологию Agile в продажах, автором которой является Марина Алекс. И с ней читателей ждет далее отдельное интереснейшее интервью.
13. Бэклог первого спринта – уровень разделения проекта на отдельные команды.
С этого момента все участники проекта начинают работать непосредственно внутри своих команд, со своими Владельцами продукта и SCRUM-мастерами. Задача этого уровня – создать первый бэклог спринта, чтобы приступить к работе как можно быстрее. Это действие дает возможность проверить все ранее полученные знания на практике под наблюдением и при непосредственном участии консультантов.
Определяя, каким будет минимально готовый продукт в конце спринта, члены команды забирают из большого набора действий именно те, которые позволят создать этот продукт. Все действия должны быть направлены только на это, иначе бэклог спринта будет либо не полным, либо перенасыщенным, и придется что-то возвращать в бэклог продукта, который получится в конце спринта.
Так начинает заполняться SCRUM-доска, первая плоскость которой, как мы помним, это перечисление того, что надо сделать.
14. Распределение задач спринта – уровень действий.
Этот уровень означает, что все подготовительные работы закончились и наступила пора создавать ценность – разбирать задачи из плоскости «что надо сделать» в плоскость «в работе» и присваивать этому действию свое имя.
Типичные ошибки этого периода таковы, что члены команды выбирают из бэклога продукта слишком большие по объему задачи, из-за того, что нет навыка «есть слона по частям». Мы помогаем людям преодолеть эту привычку и объясняем, как брать задачи для реализации в течение минимального времени.
