Переписывание программного обеспечения с использованием гибких методологий

Предположим, вам нужно переписать все приложение, используя методологии Agile, как бы вы это сделали?

Я думаю, вы могли бы написать большую кучу пользовательских историй, основанных на поведении вашей текущей системы. А затем реализуйте их небольшими итерациями. Но это не значит, что у нас есть требования UP FRONT ??

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

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

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

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

Как только вы выпустили один компонент в производство, переходите к следующему.

мы только что пережили такой опыт (я как владелец продукта Scrum). Нам потребовалось два года, чтобы добраться до чего-то освобождаемого. Но все же Agile принес нам много преимуществ.

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

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

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

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

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

• когда у вас будет 20-50 эпосов, попросите команду оценить их.

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

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

Выпусти сейчас, если сможешь

Ваш вопрос о том, когда вы начнете выпускать код, - отличный. Я думаю, что применяются две оговорки. Во-первых, что у вас «достаточно хорошее качество», а во-вторых, что вы соответствуете требованиям для MVP (минимально жизнеспособный продукт).

Рим (и Agile) не были построены за один день

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

Быть загрузчиком

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

Зачем выпускать раньше и часто?

Выпуск рано и часто является мантрой по многим причинам. Это дает жизнь нашим дискуссиям о том, каким должен быть продукт, оно делает реальным то, где мы находимся, и дает нам основу для итеративных / инкрементальных изменений. Темпы выпусков в значительной степени являются неизменными для гибких, с той разницей, кто получает релизы (суррогаты клиентов или конечные пользователи). До гибкого обслуживания, по оценкам, 60% стоимости программных систем. Это источник большого беспокойства для менеджеров и других, кто считает, что выпуск продукта - это то, где программное обеспечение умирает. Для них все после релиза переделывается и платит за исправление продукта, за который они заплатили уже один раз.

Предварительный релиз неестественный

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

Не критикуйте предыдущую команду

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

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

В ответ на комментарии @Chuck и ссылки на Netscape, по сути, говорят, что не переписывают, и действительные ответы, повторяющие, что он не спрашивает, должен ли он. - По-настоящему гибкий цикл разработки программного обеспечения исключает переписывание. Переписывание почти всегда нарушает многие принципы Agile. Используя текущее программное обеспечение в качестве основы, эти Agile-принципы (из Agile Manifesto ) не могут быть переписаны.

• Ранняя и постоянная поставка ценного программного обеспечения . - клиент не получит раннюю стоимость при сравнении с тем, что у него уже есть
• Поставляйте работающее программное обеспечение часто - от недель до месяцев - насколько велик проект, можете ли вы честно сказать, что клиент получит что-нибудь более полезное для него в ближайшее время.
• Рабочее программное обеспечение является основной мерой прогресса - работа по сравнению с базовой линией не будет происходить в спешке
• Гибкие процессы способствуют устойчивому развитию. - Учитывая, что у клиента есть рабочий базовый уровень, будет оказываться давление для обеспечения улучшенной функциональности. Это вряд ли будет сделано в темпе, который устойчивый
• Простота - искусство максимизировать количество не выполненной работы - очень важно. Это говорит все на самом деле ...

«Предположим, вам нужно переписать все приложение, используя методологии Agile, как бы вы это сделали?»

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

Подумайте, можете ли вы выпускать переписанное приложение по одному фрагменту за раз и иметь его в производстве рядом со старым.

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

Настольные приложения могут быть более сложными, но часто это возможно.

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

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

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

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

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

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

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