Это план — это упорядоченный набор задач, сгруппированных по этапам. Вы утверждаете его перед тем, как начать написание кода.
Используйте его, когда для выполнения работы требуется несколько последовательных изменений или когда вы хотите увидеть весь подход до того, как приступить к реализации.
Жизненный цикл
Планирование — это самостоятельный этап, а не мгновенное преобразование.
- Начинается планирование. Архитектор анализирует кодовую базу и составляет этапы и задачи.
- Вы проверяете черновик. Это самая экономичная точка вмешательства во всей системе.
- Утвердить, скорректировать или сбросить. Утверждение запускает процесс выполнения; корректировка отправляет план обратно с вашими замечаниями; сброс означает начало планирования заново.
- Выполнение. Задачи выполняются по порядку, соблюдая границы этапов.
Вы можете утвердить и запустить выполнение одним шагом, либо утвердить и начать позже.
Корректировать, а не сбрасывать
Если план почти готов, его корректировка сохраняет знания архитектора о вашей кодовой базе и учитывает ваши замечания. Сброс уничтожает эти данные и начинает процесс заново.
Сбрасывайте план, если весь подход ошибочен. Корректируйте, если подход верный, но детали не соответствуют ожиданиям. Корректировка обходится дешевле, а содержимое отклонённого плана не теряется — оно становится исходным материалом для следующей попытки.
Управление запущенным планом
Запущенный план можно приостановить, возобновить или отменить, а также отслеживать прогресс по его этапам. Планы также можно клонировать — это удобный способ повторить уже проверенную структуру, например, для миграции на другой сервис.
Завершённые планы можно архивировать, чтобы сохранить актуальность основного представления.
Один pull request, а не один на каждую задачу
Задачи плана не создают отдельный pull request для каждой из них. Они работают в собственных ветках и объединяются в общую ветку конвейера; эта ветка преобразуется в единый запрос на объединение с вашей базовой веткой после завершения работы.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘Таким образом, вы проверяете готовую функциональность за один раз, видя все изменения целиком, а не утверждая незавершённые этапы по отдельности.
Исключением являются планы между проектами: задача, относящаяся к другому проекту, чем ветка конвейера, объединяется отдельно, поэтому на каждый репозиторий приходится один pull request. Один pull request не может охватывать два репозитория.
Этапы и параллелизм
Этапы определяют порядок, а не одновременность выполнения. Задачи в рамках одного этапа могут выполняться параллельно при наличии свободных ресурсов; следующий этап начнётся только после завершения текущего.
План с десятью задачами, допускающими параллельное выполнение, при наличии одной слот-позиции агента всё равно будет обрабатывать их по очереди. Структура не создаёт ресурсы — см. Ресурсы и слот-позиции агентов.
План или задача?
Вы решаете это, выбирая Поэтапный рабочий план или Одна исполняемая задача на этапе маршрутизации. Никакой автоматический алгоритм не анализирует ваше задание и не принимает решение за вас.
Критерием служит возможность проверки: один pull request, который коллега может прочитать за один присест, — это задача; всё, что требует нескольких последовательных изменений, — это план.
Ошибка при классификации действительно крупной работы как задачи более рискованна — задача может исчерпать доступное пространство посреди выполнения, что приведёт к пустой трате ресурсов. Ошибка при классификации как плана обойдётся лишь в дополнительный этап утверждения, который был не совсем необходим.
Этапы доставки
План может включать этап доставки, определяющий условия, при которых результат работы может быть передан дальше. Подробнее — в разделе Критерии качества.