(пост о команде создателе и его принципиальной схеме)
Система-создатель, это команда из людей в ролях, назовем ее условным именем XE, вот роли (списком, не схема):
- Бэк-разработчик
- Груммер/Оценщик задач
- Декомпозитор задач
- Проектировщик софта
- Писатель кода
- Пропихиватель по пайплайну
- Фронт-разработчик
- Одабриватель MR-ов (коллега разработчика, который проверяет код напарника/ревьюит)
- Тестировщик
- Проджект-менеджер проекта
- Писатель спецификаций
- Договариватель внешних проектных ролей
- Исследователь проблемы/Аналитик
- Лид команды как планировщик ресурсов
- Системный архитектор (приходит, говорит как делать консистентно)
Самое интересное для меня то, что как и в примере с ракетой, не могу сказать, что здесь во всем потоке один предмет метода. Разработка начинается с запроса функциональной возможности/функции (не пишу проблема, слишком обо всем). Я бы сказал, что это описание, которое отсылает автора описания к желаемой будущей модели системы, а если быть точнее к воображаемому опыту, который он хочет получит, когда этой возможностью будет пользоваться. Этот запрос пользовательский и он проходит разные стадии.
Этот запрос, прошедший процесс уточнения, формализации, структурного описания принято называть требованиями. Где заканчивается одно и начинается другое ни кому неизвестно, но это разделение есть. Когда участники проекта считают что описание достаточно для того, чтобы начать разработку, его называют техническим заданием/спецификацией. По полноте содержания ТЗ от запроса может отличаться только шаблоном или чуть более подробными подробностями. Но когда разработчики готовы взять это в разработку, когда они считают написанное полным, это принято называть ТЗ. Так что основной критерий, отделяющий одно от другого, это субъективное восприятие исполнителем описания.
После написания ТЗ проходит декомпозиция на задачи/таски, и изначальный запрос теперь раскладывается на работы. Работы после выполнения становятся написанным кодом/инструкциями для машины и т.д.
Мои выводы, когда описывал эту схему:
- Здесь явно напрашивается как минимум два контура, условно управляющий (где проджет-менеджер, архитектор) и производственный (где разработчики). Для сложных проектов/проблем я бы еще выделял контур аналитики/проектирования решения.
- Задачи могут делать и делаются параллельно, системный аналитик пишет ТЗ, а разработчик уже и вместе с ним груммит, бэк и фронт делают свои задачи паралелльно (после утверждения контрактов).
- Почти после каждой роли (считай применения метода ролью/выполнения работы) может быть шаг назад на итерацию какой то другой работы. С одной точки зрения это можно считать частью метода работы (“писатель кода” возвращается в SA с вопросом уточнения “что сделать”, SA отвечает на вопрос и при этом правит документацию, а значит произошел возврат на шаг назад до работы “писать документацию”) и не делать “шлюза”/ромбика возврата назад, к тому же работа в таком случае не останавливается… да, пожалуй я и не буду описывать все эти возвраты и остановлюсь на последовательности.
Производственный контур:
- Исследователь проблемы
- Писатель технических заданий
- Груммер задач
- Декомпозитор задач
- Планировщик ресурсов
- Проектировщик софта
- Писатель кода
- Пропихиватель по пайплайну
- Одабриватель MR-ов
- Тестировщик
Управляющий
- Проджект-менеджер проекта
- Договариватель внешних проектных ролей
- Системный архитектор
- Продуктовый приемщик
Нашел или состаивл схему? Про разработчиков нашел (описана прямо в джире), это хорошо описанный и отработанный флоу, как только задача проходит грумминг, дальше идет “по накатанной”. Про все остальное составил.
P.S. Чем больше рисовал схемы, тем больше это было похоже на uml activity diagramm или BPMN.