Управление продуктом. Российская практика - страница 12

1. Люди и их взаимодействие важнее, чем рабочие процессы и инструменты.

2. Функционирующий продукт важнее, чем регламенты, написание инструкций, задания.

3. Сотрудничество с заказчиком важнее, чем просто подписание договора.

4. Адаптивность и оперативная реакция важнее, чем слепое следование плану.

Agile подразумевает итеративный процесс, в котором сначала создается базовое решение, которое затем со временем расширяется. Допустим, вы хотите сделать сайт для электронной торговли. В Agile вы не будете тратить месяцы на создание ресурса, вместо этого вы разработаете базовую первую версию – MVP (Minimum Viable Product – минимально жизнеспособный продукт). Возможно, просто страницу, чтобы начать продавать. Затем вы итеративно будете ее усовершенствовать, добавляя все больше разделов и функций. Эти итеративные улучшения называются инкрементами или потенциально готовыми к поставке приращениями продукта (PSPI, Potentially Shippable Product Increment) – ценностью, предоставляемой клиенту через элементы бэклога продукта, которые были выполнены во время спринта.

Agile-манифест на самом деле не описывает выполнение работы, то есть сам процесс. Когда компании решают использовать эти принципы, они должны выбрать его самостоятельно. Можно расценивать Agile как зонтик, под которым находятся процессные фреймворки, соответствующие его принципам и ценностям: Scrum, Kanban, LeSS, SAFe и др. Большинство технологических компаний не следуют ни одному из них буквально, а используют гибридные подходы, ориентированные на практические результаты, в виде набора практик (рис. 1.2).

Рис. 1.2. Agile как образ мышления и набор практик[5]

Мне нравится визуализация Ахмеда Сидки – основателя Международного Agile-консорциума, который изобразил континуум от образа мышления, ценностей Agile-манифеста к принципам и практикам.

Например, существует множество компаний, которые рассматривают гибкую разработку как серию «небольших водопадов». А есть компании с сильной функцией DevOps и микросервисной архитектурой, в которых частота релизов очень высока. В последнем случае начинает размываться смысл самого спринта, и процесс разработки эволюционирует от Scrum к линейному бэклогу и работе с использованием канбан-досок. Я всегда восхищаюсь командами разработки, которые научились выпускать релизы часто, идеальный вариант – несколько раз в день. Это служит важным фундаментом для успешного перехода к продуктовому подходу.

Большинство продуктовых команд работает по Scrum или в гибридном подходе Scrum + Kanban. Основным артефактом для работы становится бэклог продукта – список всех желаемых работ, обычно в виде пользовательских историй (user story), отсортированных в порядке приоритета. Он развивается по мере появления новых требований (или идей в нашем случае). В начале каждого спринта происходит планирование, в результате которого пользовательские истории переносятся из бэклога продукта в бэклог спринта с оценкой объема работ. Затем команда встречается на ежедневном стендапе, где делится ходом работы. В конце спринта проводится его ретроспектива.

Самый популярный фреймворк на данный момент – Scrum Кена Швабера и Джеффа Сазерленда. В его основе лежит идея работы короткими циклами – спринтами, в которых принимают участие и бизнес, и ИТ.

Спринты – регулярные ограниченные промежутки времени, в течение которых Scrum-команда выполняет заданный объем работы. Средняя продолжительность – 2–4 недели. По итогам команда обязуется создать новую версию продукта с приростом ценности для клиента (функционала) – инкрементом. Спринты выпускаются в определенные даты. Все это приводит к упорядочиванию работы ИТ. Поскольку вы действуете итеративно и попутно создаете продукты, вы можете предоставить больше гибкости своим конечным пользователям и клиентам и вовлечь их в процесс разработки и тестирования.