Coroid modela um ciclo de vida de software completo, não apenas a etapa de compilação. A maior parte dele é executada automaticamente; uma parte é um ponto de verificação opcional que pode ser ativado quando o trabalho for suficientemente importante para justificar isso.
O fluxo de trabalho SDLC opcional
No formulário de Novo trabalho , em configurações avançadas, há uma caixa de seleção:
Usar o fluxo de trabalho SDLC (opcional) — revise a intenção e as especificações antes do planejamento. Deixe desativado para iniciar o plano diretamente a partir do seu resumo.
Ele está desativado por padrão. Desativado, seu resumo vai direto para o planejamento. Ativado, dois artefatos são produzidos e aprovados primeiro:
- Intenção — o propósito real do trabalho, com as decisões e suposições por trás dele registradas.
- Especificação — escopo, exclusões e critérios de aceitação.
Só após a aprovação desses itens é que o planejamento começa.
Quando ativá-lo
Ative-o quando o custo de construir algo errado for alto, quando a solicitação vier de alguém que não irá revisar o plano pessoalmente ou quando o resumo contiver uma suposição que você prefere ver por escrito e acordada.
Deixe desativado quando o resumo já for claro. Uma etapa de aprovação extra em trabalhos rotineiros gera atrito sem benefícios — e a aprovação do plano ainda se aplica de qualquer forma.
As cinco etapas
O ciclo de vida completo ocorre em cinco fases, cada uma produzindo evidências usadas pela próxima.
| Etapa | O que acontece | Status |
|---|---|---|
| Definir | Uma solicitação ambígua se transforma em intenção aprovada, decisões, suposições e métricas de sucesso. | Versão beta |
| Visualizar | Conceitos de interface opcionais, refinados e aprovados como orientação de design. | Versão beta |
| Entregar | O plano é decomposto e os agentes o executam. | Disponível |
| Comprovar | Requisitos são mapeados para tarefas, verificações, resultados de revisão e alterações em pull requests. | Disponível |
| Melhorar | Monitoramentos, correções e avaliações transformam regressões em trabalho para o próximo ciclo. | Disponível |
Definir e Visualizar são as duas etapas em desenvolvimento ativo. Entregar, Comprovar e Melhorar são o que já roda em todas as tarefas hoje, independentemente de ativar ou não o ponto de verificação.
Por que os artefatos são versionados
As aprovações estão vinculadas a uma versão exata de um artefato. Editar um artefato aprovado cria um rascunho novo em vez de alterar silenciosamente o que foi acordado.
É isso que faz uma aprovação ter significado. Uma aprovação flutuante — ligada à "especificação" em vez de a uma versão específica dela — aprova o que quer que o documento diga mais tarde, o que na verdade não é uma aprovação.
Funções de aprovação
Responsabilidades de produto, design, técnica, segurança e release podem ser atribuídas independentemente, de modo que a pessoa que aprova as implicações de segurança não seja necessariamente a mesma que aprova o escopo.
Linhagem das evidências
O objetivo de produzir evidências em cada etapa é permitir que um pull request finalizado possa ser rastreado até suas origens: essa alteração implementa essa tarefa, que vem desse requisito, que vem dessa intenção aprovada.
Essa cadeia é o que torna a entrega autônoma auditável. Sem ela, você tem código funcionando, mas nenhum registro de por que esse é o código que você pediu.
Como isso se relaciona com os planos
O fluxo de trabalho SDLC e os planos são pontos de verificação diferentes:
- O fluxo de trabalho SDLC aprova o que deve ser construído, antes que exista uma abordagem definida.
- O plano aprova como ele será construído, antes que o código exista.
Você pode usar um, ambos ou nenhum. Ambos são mais baratos do que revisar um pull request finalizado com o qual você discorda.