Использование Scrum для миграции клиентов на уже запущенный продукт

Стоит ли работать двухнедельными спринтами и в стиле Scrum, если на то пошло, для проекта миграции клиентов из устаревшей системы в систему, которая уже работает, и с другими клиентами (программное обеспечение с белой этикеткой)?

Мне кажется несколько бесполезным пытаться уложить задачи в 2-недельные спринты, так как независимо от того, сданы они или нет, никто не будет жаловаться (поскольку клиент уже живет на устаревшем ПО). Единственным эффектом будет перенос даты миграции (установленной руководителем проекта) на более раннюю или более позднюю дату, которая пересматривается каждые 2 недели.

Я думаю, что стиль Канбан более уместен, так как рабочая нагрузка известна (без сюрпризов или областей для изучения), и это займет столько времени, сколько потребуется для доставки программного обеспечения. В Scrum нет дополнительных функций, как это было бы с инкрементными выпусками, потому что клиент все еще находится в устаревшей системе. Может ли кто-нибудь привести какие-либо аргументы за или против использования Scrum для перехода клиентов с устаревших продуктов на новые действующие продукты?

Проголосовал. Очень интересный вопрос.
В мире постоянной миграции систем я удивлен, что эта тема недостаточно обсуждалась!

Ответы (2)

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

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

Конечно, вы можете по-прежнему хотеть использовать Канбан, а не полностью отказываться от Agile. Его ограничения Work In Progress по-прежнему будут приносить пользу, даже вместо меняющихся требований. Точно так же, если ваша команда привыкла к Agile, можете просто придерживаться его; Канбан довольно легкий, с очень небольшими накладными расходами.

Спасибо за ваши комментарии, они очень актуальны. Итак, чтобы ответить на ваши вопросы: PO получает передачу от BA, которые подписали бизнес-требования с клиентом для миграции, т.е. какие элементы программного обеспечения он хочет. Затем они передаются PO, который создает эпики и истории и устанавливает отставание. У нас нет поставляемого продукта в конце спринта, у нас просто есть дополнение, но все это не работает. Мы по-прежнему рассказываем истории стейкхолдерам, то есть бизнес-аналитику и нашему внутреннему отделу, который в конечном итоге использует продукт.
Кроме того, приоритизация осуществляется на основе «какой функциональности нам нужно включить, чтобы следующая функциональность работала?». Например, вам нужно включить подключение API, чтобы затем вызвать службу. Оба существуют, их просто нужно настроить для каждого клиента.
Цель Agile — справляться с меняющимися обстоятельствами , а не только с меняющимися требованиями. Что делать, если разработчики нездоровы? Что, если конкретная история или задача окажется сложнее, чем предполагалось изначально? И даже при такой миграции некоторые предположения и даже требования в какой-то момент неизбежно изменятся.

Использование подхода Scrum, безусловно, имеет смысл.

Владелец продукта будет расставлять приоритеты в невыполненной работе, основываясь на том, какие функции системы наиболее ценны.

Доставка будет частой и работающей системы (хотя и не со всеми функциями, доделанными до конца).

Значение, которое вы получаете от этого:

  • Прозрачность прогресса. По мере того, как команда предоставляет рабочие функции, клиент обретает уверенность.
  • Возможность предоставить клиенту расписание, которое обновляется в соответствии с реальным достигнутым прогрессом.
  • Возможность проводить непрерывное тестирование в производственной среде (включая приемочное тестирование пользователями, чтобы убедиться, что новая система соответствует устаревшей системе). Помогает снизить риски при доставке, не оставляя тестирование на конец проекта.
  • Все остальные преимущества Scrum: самоорганизующаяся команда, ретроспективы, каданс и т. д.
  • Приоритизация функций перемещает наименее ценные функции в конец проекта, делая их менее важными.
Возможно, я недостаточно ясно выразился: основное программное обеспечение работает (с другими клиентами). Существующий клиент, подлежащий переносу, не работает с этим программным обеспечением, он живет с устаревшей версией. Когда проект миграции будет завершен, клиент перейдет к новому продукту. Так что до сих пор мы строим итерации и держим их в среде контроля качества. Клиент — это наши внутренние команды, которые в конечном итоге будут его использовать. Мы даже не показываем им демо, потому что вещи очень технические, и они не могут их понять. Также в системе нет вещей, более/менее ценных для расстановки приоритетов, есть известный MVP.
Затем вам нужно перевести их на новое программное обеспечение и эмпирически адаптировать это программное обеспечение к их потребностям.
Использование Scrum для миграции клиентов на уже запущенный продукт
СпросиСетьПолитика конфиденциальности1y, 0v