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