Архитектурные ретроспективы отличаются от архитектурных обзоров тем, что они сосредоточены не на оценке и улучшении самой архитектуры, а на анализе и улучшении того, как команда подходила к созданию архитектуры.
Программная архитектура определяется решениями, которые команда разработчиков принимает по архитектурно значимым вопросам. Архитектурные ретроспективы сосредоточены именно на том, как команда принимала эти решения, и на поиске способов улучшить процесс принятия решений.
Одна из сложностей ретроспектив заключается в том, чтобы не тратить слишком много времени на обсуждение самих решений. Конкретные решения не являются фокусом ретроспективы.
Команды также должны быть осторожны, чтобы не превращать ретроспективы в «сессии поиска виноватых». Вместо этого им нужно искать предубеждения, которые могут мешать их способности принимать правильные решения.
Команды также не могут винить себя за то, что они не знали чего-то, что они узнали, создавая и тестируя часть архитектуры. Ретроспективы должны вместо этого сосредоточиться на том, задает ли команда правильные вопросы при формировании своих архитектурных экспериментов.
Часто цитируемое определение безумия — это делать одно и то же и ожидать разных результатов, но именно это и делают команды, которые никогда не анализируют свой способ работы. Проектирование программной архитектуры не является исключением: если вы никогда не останавливаетесь, чтобы проанализировать, как вы принимаете решения, ваши результаты могут отражать системные предубеждения в вашем подходе к решению проблемы.
Архитектурные обзоры важны, но они не заменяют ретроспективы, и мы рассмотрим причины этого. Обзоры сосредоточены на продукте и его архитектуре, но не на том, как принимались решения, формирующие архитектуру, или на том, как команда работает над реализацией этих решений. Ретроспективы являются ключевым элементом многих гибких подходов к разработке программного обеспечения по веской причине: они предоставляют время и психологическое пространство для команды, чтобы задуматься о том, как можно улучшить свой способ работы. В остальной части этой статьи мы рассмотрим, как и почему.
Цель архитектурных обзоров — улучшить архитектуру. В контексте подхода MVA, который мы описывали в других статьях, архитектурный обзор сосредоточен на оценке пригодности архитектурного инкремента (MVA) для поддержки инкрементного продукта MVP.
Поскольку вся цель работы по инкрементам заключается в сборе обратной связи, которая может быть использована для улучшения продукта (MVP) и связанной с ним архитектуры (MVA), архитектурные обзоры необходимы и должны проводиться каждый инкремент (например, спринт в терминах Scrum).
Это контрастирует с архитектурными обзорами в традиционном подходе, которые редко проводятся до тех пор, пока не станет слишком поздно. Тогда они превращаются в своего рода постфактум после крупного инцидента, целью которого является определить, что можно сделать для устранения проблем, возникших в ходе инцидента. Традиционный архитектурный обзор, особенно если он проводится внешними сторонами, часто превращается в упражнение по поиску виноватых. Вся цель регулярных архитектурных обзоров в подходе MVA заключается в том, чтобы учиться на опыте, чтобы катастрофические сбои никогда не происходили.
Архитектурная ретроспектива имеет другую цель: она сосредоточена на использовании опыта для помощи команде разработчиков в улучшении их навыков проектирования архитектуры и их способа работы при принятии архитектурных решений. Архитектурные ретроспективы — это возможность для команды разработчиков задуматься о том, что они могут сделать лучше в будущем, и они также полезны во время каждой итерации/спринта, так как почти всегда есть чему поучиться о том, как команда работает.
| Аспект | Архитектурный обзор | Архитектурная ретроспектива |
|---|---|---|
| Цель | Улучшить архитектуру продукта (MVA) | Улучшить способ работы команды и эффективность в разработке минимально жизнеспособной архитектуры (MVA). |
| Решения/Компромиссы | Остаются ли принятые решения и компромиссы приемлемыми? | Эффективен ли процесс, с помощью которого команда принимает архитектурные решения? Основан ли он на эмпирических данных, полученных в результате экспериментов? |
| QARs (Архитектурные требования качества) | Полны/правильны ли QARs? | Адекватен ли наш процесс поиска QARs? Основаны ли они больше на догадках и предубеждениях, чем на объективных фактах? |
| Частота | В классических проектах — очень редко, обычно когда что-то идет не так (т.е. «сессия поиска виноватых»). В подходе MVA — каждый инкремент/спринт. | В классическом подходе — почти никогда. В подходе MVA — каждый инкремент/спринт. |
| Навыки | Не рассматриваются; обзор сосредоточен на продукте/системе. | Достаточны ли навыки, представленные в команде, для разработки нашего продукта/системы? Нужно ли команде улучшить свои навыки в какой-то области? |
| Обратные связи | Используются для улучшения MVA. | Используются для улучшения процесса проектирования архитектуры. |
| Технический долг (ТД) | Измерение ТД и принятие решений о том, как/стоит ли его «погашать»/уменьшать. | Задавайте вопросы о том, что делает команда, чтобы ТД увеличивался/уменьшался, и помогает ли это команде достичь эффективной архитектуры. |
Если вы уже проводите ретроспективу, например, Спринт Ретроспективу в Scrum, вы можете просто выделить время в этом мероприятии, чтобы задать критические вопросы о том, как можно улучшить ваш архитектурный способ работы.
Если у вас еще нет мероприятия по ретроспективе, вы можете начать с выделения времени для обсуждения критических вопросов о вашем способе работы с архитектурными проблемами. Это, вероятно, расширится до общих вопросов о способе работы вашей команды, и это нормально; мы считаем, что оба аспекта важны, хотя эта статья сосредоточена на ретроспективах по архитектуре.
Вам может захотеться добавить раздел ретроспективы в ваш архитектурный обзор, но мы не рекомендуем этого делать; есть причина, по которой в Scrum, например, есть отдельные мероприятия для Спринт Обзора и Спринт Ретроспективы:
Это разделение задач (заимствованное, среди прочего, из Scrum) полезно, потому что оно помогает сосредоточить внимание. Обзор продукта или его архитектуры достаточно сложен без расширения его объема, и специальное внимание к способу работы помогает команде улучшаться.
Механика проведения сессии архитектурной ретроспективы идентична механике проведения Спринт Ретроспективы в Scrum. Фактически, архитектурный фокус может быть добавлен к более общей ретроспективе, чтобы избежать создания еще одного собрания, при условии, что все участники вовлечены в принятие архитектурных решений. Это также может быть возможностью продемонстрировать, что любой может принимать архитектурные решения, а не только «архитекторы». Добавление архитектурного фокуса означает задавание различных вопросов о том, как ваша команда принимает архитектурные решения:
Самое важное, что нужно помнить в любой ретроспективе, — это то, что цель ретроспективы — найти конкретные способы улучшить способ работы команды, в виде вещей, которые команда может попробовать. Цель не в том, чтобы критиковать или искать виноватых; когда это происходит, ретроспективы становятся бесполезными и даже вредными. Команды учатся только путем создания и тестирования архитектурных инкрементов (MVA), так как не каждая идея сработает так, как надеялись. Создание и тестирование идей необходимо для проб новых подходов и принятия лучших решений.
Некоторые люди скажут, что не обязательно проводить ретроспективу каждый раз, когда создается MVA (например, каждый спринт в Scrum), потому что они считают, что это займет слишком много времени. Мы считаем, что стоит задавать себе вопросы, отмеченные выше, после каждого выпуска MVP/MVA — если интересных ответов нет, то ретроспектива будет довольно короткой, и вы сможете двигаться дальше. Однако, если есть интересные ответы, стоит потратить некоторое время на анализ того, как вы принимаете архитектурные решения, прежде чем приступать к созданию следующего инкремента MVP/MVA. Это сэкономит вам время и избавит от проблем в долгосрочной перспективе.
Ретроспективы помогают командам улучшить их способ работы, а обзоры помогают командам улучшить продукт, над которым они работают. Обзоры не заменяют ретроспективы, так же как ретроспективы не заменяют обзоры.
Многие команды пропускают ретроспективы, потому что им не нравится сталкиваться со своими недостатками. Архитектурные ретроспективы еще более сложны, потому что они исследуют не только способ работы команды, но и способ принятия решений. Но архитектурные ретроспективы имеют большие преимущества: они могут выявить невысказанные предположения и скрытые предубеждения, которые мешают команде принимать лучшие решения. Если вы проводите ретроспективы по тому, как вы создаете свою архитектуру, вы станете лучше в проектировании архитектуры.
Улучшить тариф