Coroid modélise un cycle de vie logiciel complet, et non seulement l'étape de compilation. La plupart du processus s'exécute automatiquement ; une partie correspond à un point de contrôle optionnel que vous activez lorsque le travail est suffisamment important pour justifier cette étape.
Le workflow SDLC optionnel
Sur le Nouveau travail formulaire, sous les paramètres avancés, se trouve une case à cocher :
Utiliser le workflow SDLC (optionnel) — examiner l'intention et les spécifications avant la planification. Désactivez cette option pour démarrer directement la planification à partir de votre cahier des charges.
Il est désactivé par défaut. Désactivé, votre cahier des charges est envoyé directement à la planification. Activé, deux artefacts sont d'abord produits et approuvés :
- Intention — l'objectif réel du travail, avec les décisions et hypothèses qui le sous-tendent consignées par écrit.
- Spécifications — périmètre, exclusions et critères d'acceptation.
Ce n'est qu'une fois ces éléments approuvés que la planification commence.
Quand l'activer ?
Activez-le lorsque le coût de construire quelque chose de incorrect est élevé, lorsque la demande provient d'une personne qui ne va pas examiner elle-même le plan, ou lorsque le cahier des charges contient une hypothèse que vous préféreriez voir consignée et approuvée par écrit.
Laissez-le désactivé si le cahier des charges est déjà clair. Un point de contrôle d'approbation supplémentaire sur un travail courant crée des frictions sans bénéfice — et l'étape d' approbation du plan s'applique quand même dans tous les cas.
Les cinq étapes
Le cycle de vie complet se déroule en cinq étapes, chacune produisant des preuves utilisées par l'étape suivante.
| Étape | Ce qui se passe | État |
|---|---|---|
| Définir | Une demande ambiguë devient une intention approuvée, avec les décisions, hypothèses et mesures de succès associées. | Bêta |
| Visualiser | Concepts d'interface utilisateur optionnels, affinés et approuvés comme directives de conception. | Bêta |
| Livrer | Le plan est décomposé et les agents l'exécutent. | Disponible |
| Prouver | Les exigences correspondent aux tâches, vérifications, résultats d'examen et modifications de demandes d'intégration. | Disponible |
| Améliorer | Les moniteurs, remédiations et évaluations transforment les régressions en travail pour le cycle suivant. | Disponible |
Définir et Visualiser sont les deux étapes en développement actif. Livrer, Prouver et Améliorer sont ce qui s'exécute sur chaque tâche aujourd'hui, que vous activiez ou non le point de contrôle.
Pourquoi les artefacts sont versionnés
Les approbations sont liées à une version exacte d'un artefact. Modifier un artefact approuvé crée un nouveau brouillon plutôt que de changer silencieusement ce qui avait été convenu.
C'est ce qui donne du sens à une approbation. Une approbation flottante — attachée à « la spécification » plutôt qu'à une version spécifique de celle-ci — approuve tout ce que le document dira plus tard, ce qui ne constitue pas du tout une approbation.
Rôles d'approbation
Les responsabilités liées au produit, à la conception, à la technique, à la sécurité et à la mise en production peuvent être attribuées indépendamment, de sorte que la personne approuvant les implications de sécurité n'est pas nécessairement celle approuvant le périmètre.
Lignée des preuves
Le but de produire des preuves à chaque étape est de permettre de retracer un pull request terminé : cette modification implémente cette tâche, qui provient de cette exigence, qui découle de cette intention approuvée.
Cette chaîne est ce qui rend la livraison autonome auditable. Sans elle, vous avez du code fonctionnel mais aucune trace de la raison pour laquelle c'est le code que vous aviez demandé.
Comment cela se rapporte-t-il aux plans ?
Le workflow SDLC et les plans constituent des points de contrôle différents :
- Le workflow SDLC approuve ce qui doit être construit, avant qu'une approche n'existe.
- Le plan approuve comment il sera construit, avant l'existence du code.
Vous pouvez en utiliser un, les deux, ou aucun. Leur utilisation combinée est moins coûteuse que de réviser un pull request déjà terminé et avec lequel vous n'êtes pas d'accord.