Гибкая методология: быстро и грязно или сначала планировать?

Agile вопрос: верит ли agile в налаживание работы и «быстрый и грязный путь» - или agile предпочитает строить с нуля с нуля? Или это не методологический вопрос, а вопрос, который вы оцениваете в каждом конкретном случае?

Технически я «переделываю» фундамент системы, после того как я уже построил большую часть самой структуры ... это не колоссальный объем работы ... если бы agile хотел, чтобы я сначала определил весь поток, проанализировал его, настроить, а затем построить? Я чувствую, что так лучше ... как только я создаю грязную систему, я лучше вижу, как это нужно делать ... с другой стороны, она не так организована ... просто любопытно, что лучше для развития практика в этом отношении.

Я считаю, что этот вопрос несколько отличается от Agile и создания прототипов, поскольку я не спрашиваю о прототипировании и одноразовом коде; Я заинтересован в гибкой для кода производственного класса.

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

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

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

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

В долгосрочной перспективе вы должны планировать стать умнее. Напишите гибкий код. Тогда умение не приводит к сожалению.

Мне не нравится, что для большинства людей это «быстрый и грязный» или «большой дизайн впереди». Они даже не считают, что есть другие варианты.

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

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

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

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

Ни.

Это «Начните с простого и улучшайте, пока вы двигаетесь вперед».

Быстрый и грязный хрупкий, но быстрый (если проект достаточно мал и недолговечен).

Сначала план жесткий, но стабильный (если проект завершается до того, как он сталкивается с финансовыми или временными ограничениями).

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

Одной из основных характеристик Agile является выполнение коротких итераций, а затем повторная оценка. Вы бежите вперед, чтобы исследовать новую территорию, учиться на ней, а затем составить план. Таким образом, ваш план будет лучше. И если вы потерпите неудачу (обнаружите, что ваша идея курса не работает), у вас будет «быстрый провал», и это хорошо.

Таким образом, ваш подход просто отлично. Тогда опасность состоит в том, чтобы сказать: «Хорошо, это работает, я закончил. Что дальше?». Вы еще не закончили, есть много острых углов, которые нужно выправить, и вы должны найти время, чтобы сделать это правильно, когда станет ясно, что ваш подход дает работоспособную и работоспособную систему. Это может быть написание тестов, документирование, StyleCop, оптимизация, обучение коллег о том, что вы делали и как вы это делали, проверяли ли они и т. Д.

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

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

Другими словами, планируйте ближайшую задачу, но не планируйте ничего дальше.