Au-delà des chiffres: Comprendre les Story Points comme un contrat tacite dans Azure DevOps: Adopter l'observabilité
& SecDevOps
Introduction: Mise en contexte
Soyons honnêtes: l'idée des "story points" peut sembler un peu… eh bien, absurde au premier abord. C'est
comme essayer de mesurer le ressenti d'une bonne tasse de café avec une règle. Mais les story
points ne visent pas une mesure précise. Ils sont un outil de communication, de collaboration et,
surtout, de compréhension de la complexité relative des tâches. Mais, si on les fait correctement, il ne s'agit pas
de mesurer le temps ; il s'agit de tenir une promesse. Une promesse tacite, en fait, celle qu'on fait d'un coup
d'œil complice et d'un haussement d'épaules un peu embarrassé. Il s'agit d'estimer l'effort, pas le
temps. Utiliser les story points nous permet de prioriser efficacement et de suivre notre vélocité: en
gros, à quelle vitesse nous avançons. C'est une approche étonnamment utile et c'est une pierre angulaire du
DevSecOps.
L'écosystème interconnecté: Observabilité & SecDevOps
Imaginez un orchestre chaotique: où chacun joue un instrument différent, à n'importe quel cadence et où personne ne sait ce que font les
autres. C'est à ça que ressemble le développement d'application sans un bon système. Azure DevOps, en revanche, ressemble à une
symphonie magnifiquement orchestrée. Azure Boards (pour la
planification), Azure Repos (pour le code), Azure
Pipelines (pour les compilations et les déploiements) et Azure
Artifacts (pour la gestion des packages): ils communiquent tous ensemble. Les changements dans le
plan sont immédiatement reflétés dans le code, les compilations et les déploiements. Cela crée une boucle de
rétroaction: un élément essentiel pour l'observabilité.
Voyez les choses de cette façon: un petit bug introduit pendant une compilation est immédiatement signalé, et
l'équipe peut rapidement annuler les modifications. C'est un principe fondamental du SecDevOps: la
sécurité proactive, la surveillance continue et la réponse rapide. Sans cette intégration, vous êtes essentiellement
à l'aveugle. C'est comme essayer de réparer une fuite de canalisation, mais cette fois-ci avec une lampe de poche.
La visibilité en temps réel est essentielle !
Observabilité et SecDevOps: Maintenir le contrat vivant
Sans observabilité, la capacité à comprendre ce qui se passe à l'intérieur de votre système, ce contrat
tacite est fragile. Vous devez savoir pourquoi les choses se produisent. La surveillance, la
journalisation et le traçage sont vos alliés. Les pratiques SecDevOps ne consistent pas seulement à ajouter de la
sécurité ; elles visent à construire la résilience et la compréhension. C'est autant
une question de manière de travailler que de ce que nous livrons !
Alors, qu'est-ce qu'une User Story ? (Et pourquoi c'est un accord secret)
Une user story, au fond, est un petit extrait de conversation. Ce n'est pas un document de spécification détaillé.
Ce n'est pas un plan. C'est un point de départ. Une bonne user story ressemble à ceci: "En tant que [rôle
utilisateur], je veux [objectif] afin que [bénéfice]." Exemple: "En tant que client, je veux pouvoir réinitialiser
mon mot de passe afin de pouvoir accéder à mon compte si je l'oublie." Simple, non ?
Mais voilà le truc: ce ne sont pas seulement les mots. C'est l'accord implicite qui suit. C'est là que le côté
"tacite" entre en jeu. C'est comme accepter de se voir pour un café: vous n'écrivez pas l'itinéraire exact, la
température ou la marque de café préférée. Vous acceptez simplement de vous retrouver. Puis, vous vous débrouillez.
Une user story bien rédigée est la base de cet accord.
L'art de moins de stress, plus de promesses
La documentation agile, et je ne parle pas d'un dossier de 100 pages, je parle de tout ce que l'on place simplement
dans nos tableaux de travail, vise en réalité à réduire la pression sur l'équipe. Soyons réalistes, courir sans
cesse après cette "spécification parfaite" ne fait qu'engendrer de l'anxiété. C'est un jeu de raffinement sans fin,
et honnêtement, c'est épuisant. En adoptant une approche légère, on déplace l'accent de la documentation méticuleuse
de chaque détail vers la simple capture d'assez d'informations pour que tout le monde reste aligné. Il s'agit d'une
compréhension partagée, pas d'un contrat rigide.
Les éléments qui "verrouillent" la spécification (et pourquoi vous ne devriez pas les ignorer)
Décomposons ce qui fait réellement qu'une user story "tient". C'est plus que le format de base. Voici ce qui doit
être présent pour que tout le monde soit sur la même longueur d'onde et pour créer cet accord puissant et silencieux
:
-
Critères d'acceptation: Ce sont les règles de l'accord. Ce sont les éléments qui
doivent être vrais pour que la story soit considérée comme "terminée". Ils ne sont pas optionnels. Exemple:
"Étant donné que j'ai saisi une adresse e-mail valide, lorsque je clique sur ‘Réinitialiser le mot de passe',
alors je devrais recevoir un e-mail avec un lien pour réinitialiser mon mot de passe."
-
Définition de Terminé (DoD): C'est la liste de contrôle plus large: scans de sécurité,
revues de code, tests d'intégration, etc. C'est ce qui assure que la story est véritablement complète
et fiable.
-
Valeur d'affaires": C'est la partie "… afin que …". C'est pourquoi nous faisons
cela. C'est le lien avec l'objectif "business". Sans cela, vous construisez seulement des belles choses creuses sans
but.
-
Considérations techniques: Parfois, l'équipe doit discuter des implications techniques. Ce
n'est pas nécessairement une partie de la user story, mais il est important de le reconnaître.
Story Points: Engagements, pas échéances
Oubliez l'idée de mapper les story points aux heures. C'est une recette pour la frustration. Les story points sont
des estimations relatives: parlons-nous d'une "petite modification" ou d'une "refonte majeure" ? Considérez-les
comme un moyen de communiquer la complexité relative et le risque. Encore une fois, nous n'essayons pas de
quantifier l'effort (c'est un piège !). Nous essayons d'établir une mesure relative de complexité et de
risque. Une story estimée à environ 8 points est à peu près aussi complexe qu'une story à 13 points.
L'important n'est pas le chiffre lui-même, mais la compréhension partagée qu'il représente.
La règle des 13 points: Quand décomposer
Voici un petit secret: tout ce qui est estimé à 13 ou plus devrait probablement être décomposé. Sérieusement. C'est
un signal d'alarme rouge flamboyant qui vous dit que vous vous apprêtez à vous lancer dans quelque chose de
potentiellement épineux. Les stories volumineuses sont souvent le symptôme d'un glissement de périmètre ou d'un
manque de clarté.
Voyez les choses ainsi: si vous estimez une story à 13 points, vous dites essentiellement "Je ne suis pas tout à
fait sûr de ce dans quoi je m'embarque." Et c'est tout à fait correct ! Mais cela doit être traité. Ne vous
contentez pas de la confier à un développeur et d'espérer le meilleur.
La séquence de Fibonacci: Pourquoi une échelle relative ?
Vous avez probablement entendu l'histoire de Ron Jeffries et de la séquence de Fibonacci. Il essayait d'estimer
l'effort sur un projet, et il s'est rendu compte que les tâches se répartissent souvent en catégories distinctes:
certaines sont minuscules, d'autres énormes. La séquence (1, 2, 3, 5, 8, 13…) est une façon naturelle de représenter
cela. C'est comme dire "D'accord, cette tâche est à peu près de la taille d'un petit chien, celle-ci est de la
taille d'un Labrador…"
La valeur d'un point: Échelle, pas absolus
Ne tombez pas dans le piège de penser qu'un "3" signifie toujours la même chose. Lors du Sprint 1, un "3" peut être
une entreprise énorme: réécrire une partie conséquente de l'application. Mais au Sprint 5, c'est probablement une
tâche standard. La valeur d'un point se solidifie avec le temps à mesure que l'équipe acquiert de
l'expérience et une compréhension partagée. Il s'agit de suivre la vélocité: la tendance de la
rapidité avec laquelle vous avancez, pas d'un objectif rigide. Considérez cela ainsi: un marathonien expérimenté
connaît mieux son rythme qu'un débutant.
Rigueur et flexibilité: Trouver l'équilibre
Bien qu'il soit important d'être réfléchi dans nos estimations, ne vous enfoncez pas dans les détails. La
rigueur et la flexibilité doivent être équilibrées. Utilisez des techniques comme les rétrospectives de
sprint et le planning poker pour affiner vos estimations au fil du temps. Adoptez l'auto-organisation et
l'adaptation. N'oubliez pas que l'objectif est de communiquer efficacement et de délivrer de la valeur.
Azure Boards, Repos, Pipelines, Artifacts: Construire les "dents"
C'est là que la magie opère. Lorsque vous connectez vos Azure Boards, vos Git Repos, vos Pipelines et vos Artifacts,
vous intégrez les dents dans ce contrat tacite.
-
Azure Boards: Fournit le cadre pour la story, le backlog et la planification du sprint.
-
Repos: La source de vérité pour le code.
-
Pipelines: Automatisent le processus de compilation, de test et de déploiement,
garantissant une livraison cohérente.
-
Artifacts: Le livrable empaqueté, prêt à être déployé.
Cet écosystème intégré transforme une promesse vague en un résultat concret et vérifiable. Les pratiques de sécurité
et DevOps (SecDevOps) sont cruciales ici. Pensez aux scans de sécurité automatisés dans vos pipelines, aux
évaluations de vulnérabilité et à la surveillance continue.
Conclusion
En résumé: Les story points ne servent pas à mesurer le temps. Ils visent à instaurer la confiance, à favoriser
la collaboration et à transformer des intentions vagues en résultats concrets. En connectant vos outils et en
adoptant SecDevOps, vous pouvez transformer votre processus agile d'une série de suppositions en un pipeline de
livraison fiable et reproductible.
Et en fin de compte, les story points sont un outil de communication et de collaboration, pas un système de mesure
rigide. Adoptez l'approche du "contrat tacite": mettez l'accent sur la compréhension partagée et laissez les
chiffres vous guider. Ne vous focalisez pas sur les chiffres ; concentrez-vous sur la livraison de la valeur.
Prêt à transformer vos pratiques DevSecOps ? Laissez-nous un commentaire ci-dessous pour planifier une
consultation et découvrir comment nous pouvons vous aider à construire une équipe plus efficace et
collaborative.
Prochainement: SecDevOps et Ingénierie de Plateforme.
