В идеальном Agile-мире вы быстро создаете небольшое, но полезное подмножество желаемой конечной системы и даете ее пользователям. Они взволнованы, потому что это полезно, они начинают использовать это и дают обратную связь. Затем вы решаете, что добавить к нему, строите это и повторяете, пока не закончится время.
У меня недавно было несколько проектов, которые включали замену какой-то рабочей системы. Вышеприведенная модель просто не работала: пока вы не создали систему, которая включала бы практически все функциональные возможности существующей системы, пользователи не интересовались вообще. Они не будут использовать это.
Как применить Agile, когда «наименьшее полезное подмножество» - это «все»?
agile
scrum
users
iterative-development
Стив Беннетт
источник
источник
Ответы:
Гибкое решение может заключаться не в том, чтобы заменить все за один раз, а в постепенной поэтапной замене.
Представляйте новую систему постепенно, постепенно, сохраняя работоспособность частей старой системы. Старая система не отключается сразу, она просто исчезает. Новые детали предоставляют новые функциональные возможности или другие преимущества, поэтому пользователи с удовольствием их используют. Это также менее рискованно, так как у вас всегда есть 100% работающая система.
источник
Вместо того, чтобы переписывать существующую систему (что, как вы упомянули, потребует некоторых усилий, прежде чем новая система будет соответствовать существующим функциональным возможностям), подумайте о подходе с удушением . По сути, вы реализуете новую функциональность, используя ваш новый подход поверх существующего приложения. В конце концов, когда вы исправите недостатки старой системы для решения новых функций, новый код полностью заменит старый.
Это требует большей точности и усилий, чем «перезагрузка» старого приложения. Но вы получаете более короткое время для окупаемости инвестиций. Кроме того, проходя этот процесс, вы можете установить хуки, чтобы «новая» система была легче задушена следующей «новой» системой.
источник
Выпуск небольших приращений в мир может работать для новых проектов, но даже тогда небольшое количество функций может быть не слишком полезным.
Скрам утверждает, что после каждого спринта продукт «Потенциально может быть отправлен». Это не должно быть отправлено, но должно иметь качество отправляемого продукта.
Если вы хотите предоставить пользователям инкрементную версию приложения, тогда вы можете классифицировать ее как Альфа, затем Бета, а затем версии Кандидата, при этом настоящее приложение еще будет использоваться.
Вы можете обнаружить, что новые функции добавляются, а старые - удаляются, если вы включаете отзывы пользователей.
источник
Я работал над масштабной заменой бизнес-приложений для крупной национальной сети кабельного телевидения. Разработка новой системы была выполнена с помощью SCRUM, это был проект разработки, рассчитанный примерно на 18-24 месяца, чтобы повторно внедрить почти все основные подсистемы; которым было около 10 лет.
Был этап планирования примерно за 6 месяцев до начала разработки, но он также был обозначен как SCRUM. Именно здесь владелец продукта написал магазины высокого уровня и эпопеи после существующего системного анализа и опроса клиентов.
Существующая система была чрезвычайно стабильной, поскольку перешла в режим критического обслуживания были исправлены только проблемы с отображением пробок, все было просто зарегистрировано для исторических целей и чтобы убедиться, что те же проблемы не появились в новой системе.
Новая система развивалась, как описано в Agile процессе, по большей части она была чрезвычайно гладкой. Когда заменяющая система достигла особой детализации, она пошла не в производство, а в параллельные производственные испытания. Подгруппа некритических работников начала использовать обе системы, чтобы подтвердить, что новая система вела себя как старая; со старыми ошибками, исправленными, конечно.
Когда новая система достигла почти 100% новых функций, она была развернута для общих параллельных производственных циклов, которые длились пару месяцев.
После того, как клиент посчитал, что он удовлетворяет свои потребности, старая система была заархивирована, отключена и установлена. Я предполагаю, что они переназначили старое системное оборудование, потому что им никогда не нужно было возвращаться к старой системе после отключения.
источник
Я все еще думаю, что Agile добавляет большую ценность в этом сценарии.
Просто у вас есть четкая конечная цель «заменить существующую систему».
Agile методы и процессы могут еще более эффективно помочь вам .
Например:
Вы все еще можете выполнять в системе итеративно и небольшими спринтами.
Вы все еще можете использовать гибкие методы, чтобы расставить приоритеты в работе после общения с ключевыми людьми.
Вы все еще можете использовать Agile для планирования на основе наблюдаемой скорости.
Вы по-прежнему можете использовать гибкие методы и принципы, такие как распространение знаний, TDD, чистое кодирование, чтобы повысить качество и внутренний дизайн проекта.
Если у вас есть люди, которые действительно «не заинтересованы» в проекте и не участвуют в проекте до тех пор, пока у них не будет идеальной замены, у вас возникнет более серьезная проблема, независимо от того, используете ли вы водопад, Agile или какой-либо другой процесс.
источник
Он работает так же, но этот подход будет сложнее продать существующим пользователям. Они могут не захотеть новую систему и не хотят, чтобы их прерывали периодические испытания. Они хотят подождать как можно дольше, а затем просто проверить это в конце. Большинство пользователей чувствуют этот путь в определенной степени, но ответственные должны обучать их. По их мнению, вы работаете с существующим приложением, поэтому вы должны знать, что оно должно делать, зачем их беспокоить?
Заставьте их понять, что вы не хотите делать это таким образом, потому что вы думаете, что это будет весело, и вы одиноки, используя процесс водопада. Это сделает лучшее приложение в долгосрочной перспективе.
Ключевой момент продажи может заключаться в том, чтобы реализовать это одно изменение во время создания нового приложения, которое они всегда хотели, но никогда не могли получить в старой системе.
источник
Если у меня есть старая ржавая машина, на которой мне нужно ездить, чтобы добраться до работы, и я иду в автосалон, чтобы купить новую машину. Требуемой модели нет в наличии, поэтому они должны заказать ее с завода, и пройдет немного времени, прежде чем она поступит в продажу.
Дилер тогда добросовестно решает дать вам блок двигателя автомобиля, пока не приедет заказанная вами машина. Что вы должны делать с двигателем автомобиля? Конечно, я могу подключить некоторые компоненты, чтобы протестировать его и заставить его работать, но это действительно не поможет мне завтра работать, где работает старая ржавая машина.
Конечно, между созданием автомобиля и созданием специального программного обеспечения существует много различий, но давайте проигнорируем это ради аргумента. Суть истории заключается не в том, чтобы озадачиться тем, что клиент не находит пользы для постепенных изменений, когда у него уже есть достаточно хорошее программное обеспечение, чтобы выполнить работу сейчас. Это уже удовлетворяет их потребность в настоящее время.
Это не означает, что Agile не является важной частью процесса, потому что он позволяет непрерывно получать отзывы клиентов о состоянии проекта. Они могут гарантировать, что прогресс будет достигнут до основных этапов и результатов. Они могут определить потенциальные проблемы и проблемы раньше, чем это станет слишком дорогостоящей ошибкой, чтобы ее можно было исправить.
Может быть, как клиент автомобиля, вы просто хотите посмотреть и оценить двигатель, чтобы убедиться, что вы действительно получите то, что ожидали. Ой, я действительно хотел двигатель с 6 цилиндрами вместо двигателя с 4 цилиндрами! Разве я не говорил тебе это раньше? Нет проблем, давайте внесем изменения в заводской порядок.
Продайте клиентам идею о том, что в их интересах использовать новые выпуски программного обеспечения не просто как замену, а для того, чтобы оценить их и убедиться, что они довольны каждым шагом на этом пути.
источник