Менеджмент цифрового продукта. От идеи до идеала

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

3.3.3. Запланированное ухудшение качества системы

Запланированное ухудшение качества системы происходит, когда владелец продукта принимает на себя решение понизить качество системы, часто для увеличения скорости поставки.

Например, для демонстрации на мероприятии с фиксированной датой нужно занизить критерии, принятые в DoD. Для этого при оценке элемента бэклога на прояснении бэклога новые критерии заносятся в критерии приемки. Чтобы впоследствии не забыть исправить ухудшение, советую завести связанную пользовательскую историю с уже нормальными критериями.

Например, на прояснении бэклога команда оценила историю «Я как пользователь могу просмотреть видеофрагмент, чтобы принять решение о просмотре целиком». Разработчики оценили историю в 20, так как согласно DoD нужно всегда обеспечивать HD – качество видеопотока, что невозможно в сложившейся ситуации без существенных доработок. В этом случае владелец продукта разделяет историю на две (табл. 3.11).

Табл. 3.11. Пример планирования ухудшения качества в бэклоге

Первая история была реализована в необходимые сроки, вторая отложена для реализации в более удобное время. Такие отложенные доработки по восстановлению качества системы называются техническим долгом (technical debt, техдолг).

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

Лучшие практики по работе с запланированным ухудшением качества

➠ Максимально стараться избегать образования и накопления техдолга.

➠ Если без этого невозможно, обязательно создавать связанную историю в бэклоге.

➠ Оперативно устранять известные запланированные ухудшения в системе.

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

➠ Выделить в бэклоге спринта определенный буфер под работы по устранению техдолга.

3.3.4. Незапланированное ухудшение качества системы (дефекты)

Незапланированное ухудшение качества системы, обнаруженное во время спринта или уже после релиза, называется «дефект». Дефекты, обнаруженные в процессе разработки, по возможности исправляются разработчиками в процессе спринта, чтобы инкремент соответствовал DoD. Дефекты, обнаруженные после релиза, заносятся в бэклог продукта.

Например, если обнаружилось что в результате одной из поставок перестала работать история «Я как пользователь могу удалить элемент списка», то она добавляется в продуктовый бэклог в той же формулировке, оценивается исходя из актуального DoD и приоритизируется владельцем продукта.

Лучшие практики по работе с дефектами

➠ Разработчики исправляют небольшие дефекты сразу, если это не приносит ущерба цели спринта.

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

➠ В бэклоге спринта выделяется определенный буфер под работы по устранению дефектов.

3.3.5. Масштабирование гибких подходов

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

Масштабирование гибких подходов происходит в двух случаях: масштабирование в процессе роста и масштабирование внутри уже существующей компании.

3.3.5.1. Масштабирование в процессе роста

В данном случае мы говорим о масштабировании из небольшого стартапа, который, как правило, создается вокруг одного продукта. Если перед компанией встает вопрос о необходимости масштабирования Agile, значит, для оперирования выбран какой-то фреймворк, скорее всего, Scrum. В этом случае в процессе роста важно сохранить гибкую культуру и выбрать правильный фреймворк масштабирования, который позволит быстро расти без избыточного найма. Один из таких фреймворков масштабирования для компаний, растущих с нуля, – LeSS, о котором поговорим в п. 3.4.5.3.

3.3.5.2. Масштабирование в уже существующей компании

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

Рис. 3.23. Горизонтально интегрированная компания