Как работает agile при замене работающей системы?

15

В идеальном Agile-мире вы быстро создаете небольшое, но полезное подмножество желаемой конечной системы и даете ее пользователям. Они взволнованы, потому что это полезно, они начинают использовать это и дают обратную связь. Затем вы решаете, что добавить к нему, строите это и повторяете, пока не закончится время.

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

Как применить Agile, когда «наименьшее полезное подмножество» - это «все»?

Стив Беннетт
источник
3
У меня есть вопрос, является ли эта новая система прямым зеркалом существующего набора функций, и если да, то почему вы меняете его?
Пользователи могут проявить интерес или никогда не получить новую функциональность. Это их выбор, но в некоторых бизнес-ситуациях у них могут быть руководители, которые думают иначе.
JeffO

Ответы:

14

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

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

MarkJ
источник
2
+1 даже не видел здесь вашего ответа, прежде чем я сказал практически то же самое. Великие умы и все;)
Майкл Браун
+1 за демонстрацию того, что Agile не может быть идеальным подходом для определенных видов реализаций в реальной жизни.
Пап
@pap Да, agile (TM) был раскручен так сильно, что существует опасность слепого использования одной фиксированной методологии, не думая о вашей конкретной ситуации.
MarkJ
Поддержание работоспособности частей старой системы подразумевает затраты на разработку для интеграции со старой системой, верно?
Стив Беннетт
1
@SteveBennett: Да, это так. Это, конечно, компромисс. Но выигрыш значительно снижает риск, и вам нужно только переделать ту часть, которую нужно переделать.
Слёске
6

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

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

Майкл Браун
источник
5

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

Скрам утверждает, что после каждого спринта продукт «Потенциально может быть отправлен». Это не должно быть отправлено, но должно иметь качество отправляемого продукта.

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

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

aqwert
источник
1
+1 именно так мы и подошли. Хотя сама идея «начинать заново» очень скучна. Насколько сильно вы пытались задуматься о замене старого решения по крупицам?
Крис Ван Баел
@KrisVanBael это теоретически лучше (и определенно идеал), но это еще один из тех вопросов, которые «зависят» - некоторые старые решения действительно старые (так что каждый смотрит на изменения платформы) или процесс подключен / интегрирован в систему сквозной и «биты» могут быть довольно большими.
Мерф
Я работал где-то, где оригинал был отправлен на рынок очень быстро, и поэтому дизайн был довольно плохим. У нас была идея начать с лучшего понимания того, что делать, и, надеюсь, лучшего кода. Он никогда не продвигался вперед, что в лучшем случае было выгодно, а затраты на него были невыгодны. Если существующая система работает, со временем внесите в нее небольшие улучшения.
Акверт
3

Я работал над масштабной заменой бизнес-приложений для крупной национальной сети кабельного телевидения. Разработка новой системы была выполнена с помощью SCRUM, это был проект разработки, рассчитанный примерно на 18-24 месяца, чтобы повторно внедрить почти все основные подсистемы; которым было около 10 лет.

Был этап планирования примерно за 6 месяцев до начала разработки, но он также был обозначен как SCRUM. Именно здесь владелец продукта написал магазины высокого уровня и эпопеи после существующего системного анализа и опроса клиентов.

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

Новая система развивалась, как описано в Agile процессе, по большей части она была чрезвычайно гладкой. Когда заменяющая система достигла особой детализации, она пошла не в производство, а в параллельные производственные испытания. Подгруппа некритических работников начала использовать обе системы, чтобы подтвердить, что новая система вела себя как старая; со старыми ошибками, исправленными, конечно.

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

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


источник
Здорово. Важнейшей вещью в этой истории было наличие работников, желающих работать одновременно в обеих системах.
Стив Беннетт
2

Я все еще думаю, что Agile добавляет большую ценность в этом сценарии.

Просто у вас есть четкая конечная цель «заменить существующую систему».

Agile методы и процессы могут еще более эффективно помочь вам .

Например:

Вы все еще можете выполнять в системе итеративно и небольшими спринтами.

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

Вы все еще можете использовать Agile для планирования на основе наблюдаемой скорости.

Вы по-прежнему можете использовать гибкие методы и принципы, такие как распространение знаний, TDD, чистое кодирование, чтобы повысить качество и внутренний дизайн проекта.

Если у вас есть люди, которые действительно «не заинтересованы» в проекте и не участвуют в проекте до тех пор, пока у них не будет идеальной замены, у вас возникнет более серьезная проблема, независимо от того, используете ли вы водопад, Agile или какой-либо другой процесс.

Бенджамин Вуттон
источник
1

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

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

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

JeffO
источник
0

Если у меня есть старая ржавая машина, на которой мне нужно ездить, чтобы добраться до работы, и я иду в автосалон, чтобы купить новую машину. Требуемой модели нет в наличии, поэтому они должны заказать ее с завода, и пройдет немного времени, прежде чем она поступит в продажу.

Дилер тогда добросовестно решает дать вам блок двигателя автомобиля, пока не приедет заказанная вами машина. Что вы должны делать с двигателем автомобиля? Конечно, я могу подключить некоторые компоненты, чтобы протестировать его и заставить его работать, но это действительно не поможет мне завтра работать, где работает старая ржавая машина.

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

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

Может быть, как клиент автомобиля, вы просто хотите посмотреть и оценить двигатель, чтобы убедиться, что вы действительно получите то, что ожидали. Ой, я действительно хотел двигатель с 6 цилиндрами вместо двигателя с 4 цилиндрами! Разве я не говорил тебе это раньше? Нет проблем, давайте внесем изменения в заводской порядок.

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

maple_shaft
источник
Да, но мой опыт заключается в том, что, следуя метафоре, покупатели автомобилей ничего не знают о двигателях и не могут сказать вам ничего полезного, глядя на них. Когда они находятся в гипотетическом режиме, обратная связь довольно поверхностна: «О, похоже, она будет делать то, что мы хотим», и вы не получите ничего, пока они не используют ее впервые, чтобы решить реальную проблему.
Стив Беннетт