Как вы контролируете архитектуру в гибком проекте?[закрыто]

Question

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

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

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

Answer 1

Обязательным условием для Agile-подходов является архитектура, которую вы уже умеете использовать.

Если архитектура не четко определена и не полностью понята, вы не сможете использовать Agile-подход.

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

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

Answer 2

Я мог бы объяснить, как бы я это сделал, но этот говорит это лучше, чем я мог бы.

Answer 3

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

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

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

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

Я думаю, что XP не умаляет роль архитектора (и архитектуры), а просто возлагает ответственность на всех членов команды и распределяет затраты на весь срок реализации проекта.

[редактировать]

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

Answer 4

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

Я бы предложил руководителю проекта контролировать архитектуру и обеспечивать соответствие всей новой работы ей.

Answer 5

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

Answer 6

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

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

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