Архитектор программного обеспечения — ключевой человек в программном проекте, который я объяснил в своей статье «Что делает архитектор программного обеспечения?». опубликовать несколько месяцев назад. Архитектор несет личную ответственность за техническое качество разрабатываемого нами продукта. Независимо от того, насколько хороша команда, насколько сложна технология, насколько сложны требования или насколько хаотичен спонсор проекта, мы обвиняем архитектора и больше никого. Конечно, мы также награждаем архитектора за успех. Вот что я, как руководитель проекта, ожидаю от хорошего архитектора.
Во всех проектах, которые мы выполняем на Teamed.io , я ожидаю регулярных отчетов от разработчиков программного обеспечения несколько раз в неделю. Каждый отчет состоит из трех обязательных частей: 1) состояние области, 2) проблемы и 3) риски.
Состояние области
Первым и наиболее важным типом информации, которую я ищу, является статус области, который должен быть представлен в формате Структура структуры продукта (PBS). Независимо от того, насколько сложный или малый продукт, хороший архитектор должен быть в состоянии создать PBS из четырех-восьми элементов . Например:
1. MySQL persistence [done]
2. OAuth login [done]
3. Input parsing in XML [75%]
4. S3 data storage [none]
5. UI cross-platform testing [none]Это размер отчета, который я ожидаю получать от хорошего архитектора каждые несколько дней. Главная цель для архитектора — убедиться, что ничего не пропущено. Независимо от того, насколько велик проект, все его технические компоненты должны вписываться в эту PBS.
Архитектор несет личную ответственность за то, чтобы не пропустить информацию в PBS и сделать ее максимально точной. Если что-то пропущено или отчет задерживается, это становится хорошей причиной для смены архитектора.
Проценты прогресса также важны здесь. Несмотря на то, что отдельные задачи управляются с учетом «принципа завершения 0/100», архитектор должен компилировать эти проценты и убедиться в точности компиляции. Опять же, ошибка здесь непростительна.
вопросы
Вторая важная часть регулярного отчета от архитектора — это список текущих проблем, с которыми сталкивается команда разработчиков. Проблема — это то, что уже произошло, и мы страдаем от этого. Вот несколько практических примеров:
1. MySQL is too slow for our performance requirements
2. Java 1.6 doesn't allow us to use library X
3. We don't have a replacement for a Ruby guy who left us
4. Integration tests are not predictableОпять же, список должен включать от четырех до восьми элементов (не больше и не меньше), и архитектор должен упомянуть наиболее важные проблемы.
риски
Теперь риски. Риск — это то, что еще не произошло, но может произойти в ближайшее время, и если это произойдет, у нас будут проблемы. Архитектор отвечает за отслеживание всех потенциальных рисков и регулярно сообщает о наиболее важных из них руководителю проекта. Вот пример краткого отчета о рисках:
1. Deployment platform may not support Java 8 [3/8]
2. Library X may take more than the two weeks planned [7/3]
3. We may lose a good Ruby developer soon [5/6]
4. Integration tests may not be safe enough [7/2]
5. We may fail to find an open source library [3/8]Менеджер проекта может потребовать дополнительную информацию о каждом риске, но это другая история. Что наиболее важно, так это информировать руководителя проекта о начале списка. У каждого риска есть два числа, связанных с ним: вероятность и влияние , от 0 до 9. В приведенном выше списке первый риск имеет вероятность 3 и влияние 8. Это означает, что архитектор считает, что, скорее всего, этого не произойдет, но если это случится, у нас будут большие неприятности.
Обратите внимание, так как ключевое слово в каждом описании риска может . Риск — это то, чего еще не было. Это самая большая разница между риском и проблемой. Проблема — это риск, который уже возник.
PS. Вот как архитектор может применять принципы дизайна и архитектуры: два инструмента архитектора программного обеспечения