Зачем разбивать на Спринты цельный и длительный кусок разработки?

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

Декомпозиция уменьшает продуктовые риски сделать что-нибудь ненужное или сделать что-то нужное неправильно, снижает стоимость риска за счёт быстрого получения обратной связи и позволяет получить знания, подтверждённые практикой (Validated Learning), чтобы использовать их для развития Продукта.

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

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

Такой подход к разработке называется End to End. Если мы ведём разработку по кусочкам функциональности End to End, то заказчик может сразу начать их использовать и находить ошибки. В дальнейшем мы будем использовать тот опыт, который получили при решении ошибок, и развитие Продукта пойдёт совсем не по первоначальному плану.

Главное

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *