Coroid моделирует полный жизненный цикл ПО, а не только этап сборки. Большая часть процессов выполняется автоматически; один из этапов представляет собой необязательный контрольный пункт, который включается, когда задача достаточно важна для такого подхода.
Необязательный рабочий процесс SDLC
В разделе Новая работа формы, в разделе дополнительных настроек, расположен флажок:
Использовать рабочий процесс SDLC (необязательно) — сначала нужно согласовать цель и спецификации перед началом планирования. Если этот параметр отключить, план будет создаваться сразу на основе вашего задания.
По умолчанию он отключен. При отключении задание сразу поступает в планирование. Если включить этот режим, сначала будут созданы и утверждены два артефакта:
- Цель — для чего предназначена работа, с записью принятых решений и предположений.
- Спецификации — объем работ, исключения и критерии приемки.
Только после их утверждения начинается планирование.
Когда стоит включить этот режим
Включайте его, если стоимость создания неверного продукта высока, если запрос поступил от человека, который сам не будет проверять план, или если в задании есть предположения, которые лучше закрепить в документе и согласовать.
Отключайте его, если задание уже однозначно сформулировано. Дополнительный этап согласования для рутинных задач создает лишние сложности без реальной пользы — при этом согласование плана все равно требуется в любом случае.
Пять этапов
Полный жизненный цикл состоит из пяти стадий; на каждой из них создаются данные, используемые на следующей стадии.
| Этап | Что происходит | Статус |
|---|---|---|
| Определение | Неоднозначный запрос превращается в утвержденную цель, решения, предположения и критерии успеха | Бета |
| Визуализация | Необязательные концепции интерфейса, доработанные и утвержденные в качестве рекомендаций по дизайну | Бета |
| Поставка | План разбивается на этапы, а агенты выполняют его. | Доступно |
| Подтвердить | Требования соответствуют задачам, проверкам, результатам рецензирования и изменениям в пулл-реквестах. | Доступно |
| Улучшить | Мониторинг, устранение проблем и оценки превращают регрессии в задачи следующего цикла. | Доступно |
Функционал «Определить» и «Визуализировать» находится в активной разработке. Функционалы «Реализовать», «Подтвердить» и «Улучшить» применяются к каждой задаче независимо от включения контрольной точки.
Почему артефакты версионируются
Согласования привязаны к конкретной версии артефакта. При редактировании согласованного артефакта создается новый черновик, а не происходит скрытое изменение уже утвержденного варианта.
Именно это делает согласование значимым. Если согласование привязано не к конкретной версии спецификации, а к самому документу, то оно распространяется на любые последующие изменения текста, что вообще не является настоящим согласованием.
Роли при согласовании
Обязанности по продукту, дизайну, технической части, безопасности и релизу можно назначать независимо друг от друга, поэтому человек, утверждающий аспекты безопасности, не обязательно тот же, кто утверждает объем работ.
Линия доказательств
Цель создания доказательств на каждом этапе — чтобы готовый pull request можно было отследить по цепочке: данное изменение реализует эту задачу, которая исходит из этого требования, а оно, в свою очередь, основано на утвержденном намерении.
Именно эта цепочка обеспечивает возможность аудита автономной разработки. Без нее у вас будет рабочий код, но не будет подтверждения того, что это именно тот код, который вы запрашивали.
Как это связано с планами
Рабочий процесс SDLC и планы — это разные этапы контроля:
- Рабочий процесс SDLC утверждает что необходимо разработать, еще до того, как появится конкретный подход.
- Планы Спланировать утверждает как будет реализовано до написания кода.
Вы можете использовать любой из вариантов, оба сразу или не использовать их вовсе. Оба варианта экономят средства по сравнению с проверкой готового pull request, с которым вы не согласны.