Архитектура и дизайн в скраме
05.04.2018
Комментариев нет
2849
Есть 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
Алексей Бушманов
Сертифицированный скрам-мастер, тренер и коуч Сфера интересов: Развитие команд и организаций, тренинги и обучение
Рекомендуем посмотреть:
Какая коммуникация наиболее эффективна
23.06.2018