Архитектура и дизайн в скраме

Есть 10 типов людей: те, которые понимают двоичный код, и те, кто нет.

Неизвестный источник

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

Проблема:

Какой ширины и где строить пешеходные дорожки?

Решение:

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

Несмотря на сложность применения в продуктовом дизайне, это источник вдохновения в бережливом производстве и Agile-проектировании — развивающихся новых подходах к проектированию и разработке ИТ-продуктов.

Размышления о проектировании

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

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

  • (Существительное) Высокоуровневое описание структуры (нужно учесть, что реальная архитектура может отличаться от желаемой)
  • (Глагол) Применительно к процессу проектирования желаемой архитектуры (как правило происходит фиксация архитектуры в начале, часто в документах, которые накладываются на анализ требований)

Термин “архитектура” был позаимствован у строительных архитекторов. На самом деле, это слабая аналогия применительно к процессу разработки ПО. Здания сложны для переделки и поэтому в строительной сфере этап проектирования выполняется один раз до момента строительства — при этом архитектура фиксируется в виде проекта. Отметим также, что архитекторы отличаются от строителей.

Но программное обеспечение не является зданием, программное обеспечение в этом смысле является более “мягким” и гибким, а проектирование ПО не является процессом строительства. “Архитектура ПО” — это просто одна несовершенная аналогия из большого списка метафор, которые можно было бы выбрать.

Какие другие метафоры можно было бы использовать? В статье “Что такое дизайн программного обеспечения” Джек Ривз (Jack Reeves) отмечает:

… единственная документация ПО, которая которая. по видимому, соответствует критериям инженерного проекта — это исходный код.

… Исходный код является реальным планом. Процесс строительства (Build…) в данном случае — это шаг компиляции. Не случайно в инструментах разработки пункт меню называется как Build:

Рассмотрим такой сценарий: перед началом разработки какого-то продукта у нас есть документация, в которой описана архитектура и исходный код соответствует этой архитектуре. Но проходит 7 лет, вместо прежних нескольких программистов компания нанимает 300 новых разработчиков, которые не знают о первоначальных идеях, лежащих в основе текущего ПО и не заботятся о их поддержании. Представьте, что они добавили 9,5 миллионов строк кода. Предположим, что это 95% от общего кода и это беспорядок.

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

Первое наблюдение. Сумма всего исходного кода — это реальное описание проекта и архитектуры ПО.

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

Frederick Brooks, No Silver Bullet:

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

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

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

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

Можно представить эту ситуацию с использованием CLD — диаграммы причинно-следственных связей:

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

Источник: https://less.works/less/technical-excellence/architecture-design.html

Share

Сертифицированный скрам-мастер, тренер и коуч Сфера интересов: Развитие команд и организаций, тренинги и обучение

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *