Предположим, вам нужно переписать все приложение, используя методологии Agile, как бы вы это сделали?
Я думаю, вы могли бы написать большую кучу пользовательских историй, основанных на поведении вашей текущей системы. А затем реализуйте их небольшими итерациями. Но это не значит, что у нас есть требования UP FRONT ??
Кроме того, когда вы начнете выпускать? Agile говорит, что мы должны выпускать рано и часто, но не имеет особого смысла выпускать его до того, как будет завершена полная перезапись.
Ответы:
Разбейте его на эпопеи высокого уровня. Возьмите каждую функциональную область приложения, один шаг за раз.
Разбейте одну эпопею на группу историй (пригодные для использования куски - все, что улучшает приложение) и управляйте ими, как если бы у вас не было существующего приложения, с одним исключением: если это возможно, сделайте так, чтобы вы может реализовать эту часть функциональности как часть или вместе с оригинальным приложением.
Когда Agilists говорят «выпускайте рано и часто», это не обязательно означает производство. Если вы собираетесь заменить существующее приложение, вы должны использовать промежуточную область для частого выпуска и убедиться, что ваши пользователи там тестируют систему. Это по-прежнему даст им возможность расставить приоритеты для следующей части работы и убедиться, что продукт, выпущенный вами для производства, не обесценивает продукт.
Как только вы выпустили один компонент в производство, переходите к следующему.
источник
мы только что пережили такой опыт (я как владелец продукта Scrum). Нам потребовалось два года, чтобы добраться до чего-то освобождаемого. Но все же Agile принес нам много преимуществ.
Во-первых: полное переписывание по своей природе совсем не проворно. Вместо этого вы должны рассмотреть возможность рефакторинга существующего продукта по частям. Это обсуждалось в другом вопросе. Итак, давайте предположим, что это должно быть переписано.
Затем, действительно, вы начинаете с обратного журнала, который охватывает все соответствующие варианты использования существующего продукта. Но, пожалуйста, не подходите к этому как к написанию спецификаций. Это было бы слишком много деталей. Это должно быть завершено (иначе вы не можете планировать релиз). И это не должно быть слишком сложным (иначе вы пишете спецификации заранее). Вот как мы подошли к этому:
классифицировать пользователей старого продукта. Определите пользователей, которым нужна только небольшая часть старого продукта, и при этом получите что-то полезное. Они определяют ваши первые эпосы.
Затем добавьте эпопеи, которые позволят другой категории пользователей перейти на новый продукт. И т.д. до тех пор, пока у вас не появится обратный журнал, который охватывает всех пользователей.
Скорее всего, эти эпопеи потребуют дальнейшего расщепления. Если возможно, попробуйте разделить так, чтобы каждая часть все еще имела какое-то значение. Если это невозможно, то хотя бы убедитесь, что каждая часть может быть продемонстрирована.
когда у вас будет 20-50 эпосов, попросите команду оценить их.
разделите верхнюю часть эпопей на истории пользователей, которые, по мнению команды, могут быть выполнены в спринте. Пока не делайте этого для всех эпопей, только для тех, что наверху. У вас будет достаточно времени, чтобы разделить остальное.
Когда выпустить внешне! Это деловое решение. По крайней мере, такой подход дает вам возможность выпустить ранее для определенных категорий пользователей. Это может быть полезно, если руководство нервничает по поводу этого, казалось бы, никогда не заканчивающегося проекта.
источник
A total rewrite is by nature not agile at all. You should instead consider refactoring the existing product piece by piece.
Более правдивые слова никогда не произносились.Выпусти сейчас, если сможешь
Ваш вопрос о том, когда вы начнете выпускать код, - отличный. Я думаю, что применяются две оговорки. Во-первых, что у вас «достаточно хорошее качество», а во-вторых, что вы соответствуете требованиям для MVP (минимально жизнеспособный продукт).
Рим (и Agile) не были построены за один день
Может быть, вы готовы с гибкой командой под ключ, чтобы вступить во владение в первый день. Для большинства организаций есть работа и затраты на обучение, переоснащение и обычный цикл формирования, штурма, нормирования, построения команды. Будьте честны относительно рисков и затрат, будьте осторожны, чтобы установить реалистичные ожидания, и будьте в курсе и готовы отстаивать ваш подход.
Быть загрузчиком
Как и сила слияния, повторное использование кода есть и всегда будет будущим решением наших экономических проблем. У меня такое ощущение, что разработчики часто говорят, что верят в повторное использование, но только в тот тип повторного использования, который начинается после создания новой инфраструктуры, а не в тот тип, в котором они основываются на том, что уже сделал кто-то другой. Как это может работать, пока кто-то не захочет строить на чужом фундаменте? В лучшем случае это означает переписывать каждые несколько лет, когда меняется командное руководство.
Зачем выпускать раньше и часто?
Выпуск рано и часто является мантрой по многим причинам. Это дает жизнь нашим дискуссиям о том, каким должен быть продукт, оно делает реальным то, где мы находимся, и дает нам основу для итеративных / инкрементальных изменений. Темпы выпусков в значительной степени являются неизменными для гибких, с той разницей, кто получает релизы (суррогаты клиентов или конечные пользователи). До гибкого обслуживания, по оценкам, 60% стоимости программных систем. Это источник большого беспокойства для менеджеров и других, кто считает, что выпуск продукта - это то, где программное обеспечение умирает. Для них все после релиза переделывается и платит за исправление продукта, за который они заплатили уже один раз.
Предварительный релиз неестественный
Кент Бек пишет, что предварительная версия - это неестественное состояние для программных продуктов. Это, безусловно, неудобное время, потому что это время, когда у вас нет клиентов, и вы платите за продукт, а не за продукт, платящий за вас.
Не критикуйте предыдущую команду
Хотя это может настроить разработчиков, которые возьмут на себя переписывание, как героев и спасение проекта, я думаю, что стоит критиковать достижения предыдущей команды.
источник
В ответ на комментарии @Chuck и ссылки на Netscape, по сути, говорят, что не переписывают, и действительные ответы, повторяющие, что он не спрашивает, должен ли он. - По-настоящему гибкий цикл разработки программного обеспечения исключает переписывание. Переписывание почти всегда нарушает многие принципы Agile. Используя текущее программное обеспечение в качестве основы, эти Agile-принципы (из Agile Manifesto ) не могут быть переписаны.
Вопрос основан на ложной предпосылке - что переписывание можно считать гибким.
источник
Подумайте, можете ли вы выпускать переписанное приложение по одному фрагменту за раз и иметь его в производстве рядом со старым.
В частности, для веб-приложений может быть достаточно легко переместить отдельную часть приложения на новую платформу, и ваш балансировщик нагрузки направит запросы в соответствующую систему. Затем напишите истории, которые позволят вам запустить свою первую страницу в производство, и доставьте их гибким способом.
Настольные приложения могут быть более сложными, но часто это возможно.
Вы ищете швы - места, где старая система может взять на себя ответственность за новую, не требуя полного переписывания.
Возможно, существует некоторая автономная бизнес-логика, которую можно перенести в новый веб-сервис или инфраструктуру, и старое приложение можно изменить, используя его вместо старого кода. Просто продолжайте резать куски по швам до тех пор, пока все, что осталось, не станет управляемым за один укус.
Если вы не можете найти какие-либо швы, то вам, возможно, придется поискать подход большого взрыва, предложенный в некоторых других ответах. Но будьте готовы к долгому маршу, прежде чем достигнете своей цели, особенно если от вас ожидают, что вы продолжите разрабатывать старую систему параллельно ...
источник
На самом деле, ИМХО, это ключевой момент - чем раньше вы получите части переписанного приложения в производстве (и в идеале заменяющие функциональность старой системы), тем больше шансов, что ваш проект будет успешным. Если вы думаете, что в этом нет особого смысла, подумайте об этом сложнее - почти всегда есть возможность выпустить детали.
Это, вероятно, будет означать, что кто-то должен что-то изменить в старом приложении, например, добавить несколько новых интерфейсов для взаимодействия с переписанным приложением в то время, когда перезапись не завершена. Но, по моему опыту, такая дополнительная работа всегда окупается.
Как только первые части нового приложения будут запущены, гибкий итеративный подход станет очевидным. Требования будут меняться, ваши пользовательские истории будут меняться или приобретать новые приоритеты, и, надеюсь, вы будете заменять все новые и новые функциональные возможности старой системы небольшими шагами.
источник