Архитектор программного обеспечения является ключевым человеком в программном проекте, который я объяснил в статье «Что делает архитектор программного обеспечения?». Пост несколько месяцев назад. Архитектор лично отвечает за техническое качество разрабатываемого нами продукта. Независимо от того, насколько хороша команда, насколько сложна технология, насколько запутанны требования или хаотична спонсор проекта, мы обвиняем архитектора и никого больше. Конечно, мы также вознаграждаем архитектора, если нам это удастся. Вот что я, как руководитель проекта, ожидаю от хорошего архитектора.
Во всех проектах, которые мы запускаем на Teamed.io, я ожидаю регулярных отчетов от архитекторов программного обеспечения несколько раз в неделю. Каждый отчет включает три обязательные части: 1) статус области, 2) вопросы и 3) риски.
Состояние области действия
Первым и наиболее важным типом информации, которую я ищу, является статус области, который должен быть представлен в формате структуры разбивки продукта (PBS). Независимо от того, насколько сложный или маленький продукт, хороший архитектор должен иметь возможность создавать PBS из четырех-восьми элементов. Например:
1. Постоянство MySQL [сделано]
2. Логин OAuth [завершен]
3. Разбор исходного текста в XML [75%]
4. Хранилище данных S3 [none]
5. Кроссплатформенное тестирование пользовательского интерфейса [none]
Вот размер отчета, который я ожидаю получить от хорошего архитектора каждые несколько дней. Главная задача архитектора здесь - убедиться, что ничего не упущено. Независимо от того, насколько велик проект, все его технические компоненты должны вписаться в этот PBS.
Архитектор несет личную ответственность за то, чтобы не пропустить информацию в PBS и сделать ее настолько точной, насколько это возможно. Если что-то упущено или отчет задерживается, это становится хорошей причиной для изменения архитектора.
Здесь также важны проценты прогресса. Несмотря на то что отдельные задачи управляются с использованием принципа «0/100 завершения», архитектор должен скомпилировать эти проценты и убедиться, что компиляция является точной. Опять же, здесь ошибка непростительна.
вопросы
Список текущих проблем
Архитектор несет личную ответственность за то, чтобы не пропустить информацию в PBS и сделать ее настолько точной, насколько это возможно. Если что-то упущено или отчет задерживается, это становится хорошей причиной для изменения архитектора.
Здесь также важны проценты прогресса. Несмотря на то что отдельные задачи управляются с использованием принципа «0/100 завершения», архитектор должен скомпилировать эти проценты и убедиться, что компиляция является точной. Опять же, здесь ошибка непростительна.
вопросы
Список текущих проблем
Вторая важная часть регулярного отчета от архитектора. Проблема - это то, что уже произошло, и мы страдаем от этого. Вот несколько практических примеров:
1. MySQL слишком медленный для наших требований к производительности
2. Java 1.6 не позволяет использовать библиотеку X
3. У нас нет замены для Ruby парня, который оставил нас
4. Интеграционные тесты не предсказуемы
Опять же, список должен включать от четырех до восьми пунктов (не больше и не меньше), и архитектор должен упомянуть о наиболее важных проблемах.
Риски
Теперь, риски. Риск - это то, чего еще не произошло, но может произойти в ближайшее время, и если это произойдет, у нас будут проблемы. Архитектор несет ответственность за слежение за всеми потенциальными рисками и регулярное сообщение наиболее важных из них руководителю проекта. Вот пример краткого отчета о рисках:
1. Платформа развертывания может не поддерживать Java 8 [3/8]
2. Библиотека X может занимать больше запланированных двух недель [7/3]
3. Мы скоро потеряем хорошего разработчика Ruby [5/6]
4. Интеграционные тесты могут быть недостаточно безопасными [7/2]
5. Возможно, мы не сможем найти библиотеку с открытым исходным кодом [3/8]
Менеджер проекта может потребовать дополнительную информацию о каждом риске, но это уже другая история. Самое главное - информировать менеджера проекта о вершине списка. Каждый риск связан с двумя числами: вероятность и воздействие - от 0 до 9. В приведенном выше списке первый риск имеет вероятность 3 и воздействие 8. Это означает, что архитектор считает, что, скорее всего, этого не произойдет, Но если это произойдет, у нас будут большие неприятности.
Обратите внимание, что ключевым словом в описании каждого риска может быть. Риск - это то, чего еще не было. Это самая большая разница между риском и проблемой. Проблемой является уже возникший риск.
PS. Вот как архитектор может обеспечить соблюдение принципов проектирования и архитектуры: два инструмента программного архитектора
Обратите внимание, что ключевым словом в описании каждого риска может быть. Риск - это то, чего еще не было. Это самая большая разница между риском и проблемой. Проблемой является уже возникший риск.
PS. Вот как архитектор может обеспечить соблюдение принципов проектирования и архитектуры: два инструмента программного архитектора
Комментариев нет:
Отправить комментарий