Есть ли лучшие практики в отношении перехода от архитектуры к разработке?

Мы стремимся улучшить процесс передачи задач от архитектуры к разработке.

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

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

Кто-нибудь нашел оптимальную золотую середину между этими крайностями? Какие артефакты вы доставляете в разработку? Например: модули, структура классов или диаграммы последовательности?

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

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

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

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

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

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

Единственный лучший способ смягчить эту проблему - ИЗМЕНИТЬ группу по архитектуре и, возможно, поставить их на позиции технического лидера. Роль группы по архитектуре должна быть более или менее «схваткой технических лидеров», если хотите. Они должны встречаться редко и обсуждать только технические вопросы высшего уровня, например. подумайте о переносе обсуждения с Java на Scala, отказ от Oracle для MySQL, возможно, написание общих утилитных библиотек, которые передают определенный тип процесса проектирования другому, переключаясь с StarUML на Altova UML.

Реальное и реальное проектирование программного обеспечения будет процессом сообщества, вовлекающим ВСЕХ разработчиков программного обеспечения, разработанного чрезвычайно высоким уровнем руководства группы Архитектуры.

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

• размер программного обеспечения
• сложность
• культура в вашей организации
• вера.

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

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

В основном для правительственных и финансовых проектов требуется, чтобы больше документации было написано заранее, и это может занять много времени без реальных отзывов о вашем выборе. На мой взгляд, главная причина того, что многие из этих проектов провалились. Тем не менее, если это ваша ситуация, я бы подготовил документацию в соответствии с требованиями И затем использовал вариант 1 или 2 для фактической сборки программного обеспечения и уточнения / адаптации документации.

Надеюсь это поможет.

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

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

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

Я не совсем согласен с ответом maple_shaft, но в комментарии не хватило места, чтобы сказать весь мой бит! ;-)

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

Чем крупнее, модульнее и в конечном итоге сложнее продукт, тем больше вероятность того, что различные части продукта будут обрабатываться разными группами разработчиков. Такие группы не должны понимать систему в целом, если они полностью понимают части системы, за которые они несут ответственность. Часто эти дополнительные группы привлекаются в качестве субподрядчиков для конкретной цели разработки модуля в определенной области технологии, в которой архитекторы или другие группы могут не иметь опыта. Мои собственные особые таланты заключаются в разработке API, и мне еще предстоит увидеть хорошо продуманный API, который был разработан полностью органично, без каких-либо проблем с юзабилити, или это не требовало, чтобы кто-то выделялся в качестве человека, который обеспечивал однородность между различными аспектами API. Я могу продолжить перечислять много примеров и причин, но я не думаю, что такого рода ситуации являются башней из слоновой кости, о которой многие могут подумать. К сожалению, есть много мест, особенно в сферах обороны, медицины и финансов, где корпоративная паранойя приводит к плохо заданным и еще более плохо управляемым разработкам продуктов, которые, я уверен, больше всего беспокоит maple_shaft. Это то, что, как мне кажется, дает архитекторам немного заслуженное дурное имя (вообще говоря). К сожалению, есть много мест, особенно в сферах обороны, медицины и финансов, где корпоративная паранойя приводит к плохо заданным и еще более плохо управляемым разработкам продуктов, которые, я уверен, больше всего беспокоит maple_shaft. Это то, что, как мне кажется, дает архитекторам немного заслуженное дурное имя (вообще говоря). К сожалению, есть много мест, особенно в сферах обороны, медицины и финансов, где корпоративная паранойя приводит к плохо заданным и еще более плохо управляемым разработкам продуктов, которые, я уверен, больше всего беспокоит maple_shaft. Это то, что, как мне кажется, дает архитекторам немного заслуженное дурное имя (вообще говоря).

Так где же середина, которую искал ОП? Ответ на этот вопрос связан с открытием каналов связи. Архитекторы должны передать спецификации, которые описывают их проекты достаточно подробно, чтобы команды разработчиков понимали, где находятся границы. Истории и тематические сценарии в широком смысле, где все считается черным ящиком. Затем архитекторам необходимо убедиться, что у команд есть время архитектора для подтверждения любых предположений, а также чтобы получить ответы на любые вопросы о спецификациях, которые кажутся слишком широкими или неясными. После этого нужно убедиться, что отдельные команды осведомлены о том, над чем работают другие команды, и что они знают, с кем связываться с другими командами, чтобы каждая часть системы хорошо играла с другими частями. Эти команды встречаются друг с другом напрямую. После того, как система была разработана на самом широком уровне, архитекторы должны стать теми людьми, к которым обращаются команды, когда им нужна проверка работоспособности, и обеспечить поддержание «видения» продукта. Они также должны принять во внимание любой требуемый процесс интеграции и обеспечить столь необходимое «воздушное прикрытие» для команд разработчиков из менеджеров, клиентов и любых других заинтересованных сторон, в то же время гарантируя, что все эти разные люди могут собраться вместе, чтобы работать между им, как все должно работать.

IMHO архитекторы должны быть в первую очередь фасилитаторами и коммуникаторами, а дизайнеры - вторыми. Что касается уровня спецификации? Я думаю, что лучшие архитекторы - это те, кто спрашивает свои команды об уровне детализации, которого хочет команда, и между ними находят баланс, который работает. У разных команд могут быть разные требования в отношении количества необходимой документации или направления. Старшие команды могут найти примерно нарисованную диаграмму, и для начала может быть достаточно быстрого чата, в то время как командам, заполненным относительно младшими разработчиками, может потребоваться немного больше, чтобы заставить их работать. Прежде всего, архитектор должен побудить разработчиков проявить свои собственные дизайнерские таланты, чтобы получить наилучший конечный результат от каждой команды.

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

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

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

Также есть место для новой команды, делающей предположения, которые являются недействительными.

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

Я бы сказал, что представления диаграмм классов, создающие как модель, так и код, - это решение. Диаграмма классов представляет статическое представление архитектуры вашего проекта. Я имею в виду, что у вас есть пакеты> классы, интерфейсы, enum> атрибуты, методы и т. Д.>> И т. Д. Если вы хорошо выглядите, метамодель UML2 имеет точно такую ​​же структуру, что и проект java или dotnet.

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

Он работает очень хорошо, и не нужно знать UML, потому что диаграмма классов очень проста, и обратный инжиниринг сделает работу и создаст графическое представление кода. Простая навигация, расширенные и подробные представления, где можно добавить множество комментариев с диаграммами, всегда актуальными и видимыми на CVS непосредственно в проекте. Моя диаграмма классов UML теперь Magic :-)