The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Архитектор программного обеспечения является ключевым лицом в программном проекте, что я объяснил в своем посте What Does a Software Architect Do? несколько месяцев назад. Архитектор лично отвечает за техническое качество продукта, над которым мы работаем. Независимо от того, насколько хороша команда, насколько сложна технология, насколько запутаны требования или насколько хаотичен спонсор проекта, мы винимаем именно архитектора и никого другого. Конечно, если мы добиваемся успеха, мы также вознаграждаем архитектора. Вот что я, в качестве менеджера проекта, ожидаю от хорошего архитектора.
Во всех проектах, которые мы ведем в Zerocracy, я ожидаю регулярных отчетов от архитекторов программного обеспечения несколько раз в неделю. Каждый отчет включает три обязательные части: 1) статус объема работ, 2) проблемы и 3) риски.
Первый и самый важный тип информации, который я ищу, - это статус объема, который должен быть представлен в формате Структуры разбиения продукта (PBS). Независимо от сложности или размера продукта, хороший архитектор должен быть способен создать структуру разбиения продукта из четырех до восьми элементов. Например:
Это размер отчета, который я ожидаю получить от хорошего архитектора каждые несколько дней. Основная цель архитектора здесь - убедиться, что ничего не упущено. Независимо от размера проекта, все его технические компоненты должны вписываться в это PBS.
Архитектор лично несет ответственность за то, чтобы не пропустить информацию в PBS и сделать ее максимально точной. Если что-то упущено или отчет задерживается, это становится хорошим поводом для смены архитектора.
Проценты выполнения также важны здесь. Несмотря на то, что отдельные задачи управляются с учетом принципа “0/100 выполнение”, архитектор должен собирать эти проценты и убедиться, что компиляция точна. Опять же, здесь ошибка непростительна.
Вторая важная часть обычного отчета от архитектора - это список текущих проблем, с которыми сталкивается команда разработчиков. Проблема - это то, что уже произошло, и от которого мы страдаем. Вот несколько практических примеров:
Опять же, список должен включать отчеты от четырех до восьми пунктов (не больше и не меньше), и архитектор должен упомянуть наиболее критические вопросы.
Теперь о рисках. Риск - это то, что еще не произошло, но может произойти скоро, и если это произойдет, у нас будут проблемы. Архитектор отвечает за контроль за всеми потенциальными рисками и регулярно сообщает наиболее критические из них руководителю проекта. Вот пример краткого отчета о рисках:
Менеджер проекта может потребовать дополнительную информацию о каждом риске, но это уже другая история. Самое важное - информировать менеджера проекта о самых приоритетных рисках из списка. Каждому риску приписаны два числа: вероятность и влияние, от 0 до 9. В списке выше у первого риска вероятность 3, а влияние 8. Это означает, что архитектор считает, что скорее всего этого не произойдет, но если произойдет, нас ждут большие проблемы.
Обратите внимание, что ключевым словом в описании каждого риска является может. Риск - это то, что еще не произошло. Это самая большая разница между риском и проблемой. Проблема - это риск, который уже произошел.
P.S. Вот как архитектор может соблюдать принципы дизайна и архитектуры: Два инструмента программного архитектора
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:52
