Comments 8
И если “учимся на ошибках” как часть grow mindset хотя бы попадает в необходимые условия для того, чтобы запустить эмпирический подход, то метрика в виде количества уровней декомпозиции — это сильно. Особенно если учесть что уровни сразу ограничивают команду только в сторону декомпозиции структурной, что сильно дернет их в сторону component team вместо feature team.
Я бы посоветовал начать с whitepaper о evidence-based management, у них прекрасный набор метрик, причем не на поведение, а на полученный результат. В конце концов мы имеем то, что мы измеряем. А у вас великий шанс “декомпозицию на три уровня и праздник от проблемы” и получить вместо реализации цикла разработка обоснованной гипотезы — планирование и проведение эффективного эксперимента — анализ результатов эксперимента — уточнение неверной гипотезы/формирование новой на основе верной.
В свою очередь, идея написания программы обусловлена бизнес задачами:
1. Рассмотреть готовность к трансформации
2. Создать общее видение
3. Сформировать набор метрик для оценки наличия атрибутов SCRUM
Соответственно, эмпиризм является важным атрибутом SCRUM со своими метриками. Но другой вопрос, как мы можем его измерить и оценить? Думая над этим вопросом, я выделил две понятные и простые метрики:
1. Декомпозиция — характеризует способность разбивать сложные проблемы на более простые.
2. Отношение к проблеме — характеризует мировоззрение (mindset), при котором сотрудник или команда не испытывает тревожность и раздражение при появлении новой проблемы.
Петля обратной связи есть и характеризуется набором следующих атрибутов:
1. Философия эмпиризма
2. События
3. Критерии завершенности
Монолитная архитектура — 0 баллов.
Микросервисный монолит — 1 балл.
Микросервисная архитектура — 3 балла.
С чего вы решили, что монолит — плохо, а микросервисы — хорошо?
Введите лучше метрику, оценивающую насколько сознательно и последовательно команды работают над архитектурой системы.
1. Горизонтальное масштабирование осуществляется с помощью дополнительного экземпляра. Что предъявляет требование к созданию новой команды для поддержки и развития;
2. Жесткая зависимость из-за единой кодовой базы в репозитории, что накладывает ограничения на релизный цикл и его зависимость, если мы захотим разбить монолит на логические блоки.
В общем, архитектура полностью повторяет принцип организации процессов.
Организации, проектирующие системы, …производят их, копируя структуры коммуникации, сложившиеся в этих организациях(Конвей, 1968)
в контексте масштабирования.
Монолитная система прекрасно масштабируется, в том числе и горизонтально. И в разы выгоднее с точки зрения сложности. Не всем же мнить себя Netflix'ом.
Вот вы Конвея привели. Ну так прочитайте внимательно приведенную цитату. "копируя структуры коммуникации," Подумайте какие в компании могут быть структуры коммуникации (кроме хаотических)? От чего эти структуры зависят. Какая структура управления выбрана, функциональная, проектная, матричная? Как происходит масштабирование, по георгафии или по продуктовой линейке? Насколько меняются внешние условия на рынках сбыта? Какой исторический контекст? Из всего этого получается определенная структура коммуникации, к которой подойдет или не подойдет микросервисная архитектура приложений.
Исходя из моего опыта могу сказать, что скорее не подходит. По причине высокой сложности. Особенно, когда у вас прямо по Конвею выстроился монолит, а вы в интернете прочитали, что монолит это зло и начали его в добрые и пушистые микросервисы переписывать.
Введите лучше метрику, оценивающую насколько сознательно и последовательно команды работают над архитектурой системы.
Есть такое понятие, как эмерджентная разработка программного обеспечения (emergent software development), характеризующее принцип, при котором нет необходимости разрабатывать детализированный дизайн архитектуры для того чтобы начать производство и отгрузку инкремента. Архитектура становится неотделимой частью существования продукта, изменение которой обусловлено дополнительной ценностью для стекйхолдеров.
Соответственно, я не считаю, что целесообразно вводить отдельную метрику для оценки команды в части работы над архитектурой, так как она находится полностью в их зоне компетенций и ответственности.
"Этот артефакт является единственным источником работы для команды."
Вообще вымыто понятие работы с business-пользователем. Гибкие методологии на то и гибкие, что в их основе лежат 4 простых принципа. Самый первый из них настаивает, чтобы разработчики при анализе требований отдавали предпочтение общению с пользователями и доменными экспертами.
Коэн в User Stories Applied напрямую пишет, что сторя — это только маленькая заметка. Все детали программист получает от прямого общения с пользователем или экспертом. Что кагбэ намекает, что для перехода к гибкой методологии у программиста должен быть доступ к этому пользователю/эксперту.
В вашем опроснике этому не уделено никакого внимания.
SCRUM: Понимание и применение фреймворка