Coaching Agile

Agile, Scrum et autres pensées
Laurent Carbonnaux

SigmaT 16 : Antisocial, tu perds ton sang froid!

Voici l'annonce du prochain SigmaT


La commission Séminaires de l'association s'est réunie pour définir le programme du 10 décembre.
Un consensus s'est dégagé pour faire de ce SigmaT16 un événement différent, avec le retour de Laurent Bossavit qui était là pour le premier SigmaT il y a 4 ans, et avec une orientation vers le "social".
Cela donne le programme suivant :
  • Quarante ans de crise, dix ans d'agilité (Laurent Bossavit) : de 16h15 à 17h15
  • Agilité et risques psycho-sociaux (Florent Bonnel, Grégory Salvan) : de 17h15 à 18h
  • Le laboratoire social (Nicolas Séné) : de 18h à 18h45


Et toujours, pour s'inscrire ou plus d'info : le site www.sigmat.fr

Burndown et Burnup

Le burndwon est un excellent outil de suivi du reste à faire.
La vision graphique simple qu’il propose est très appréciée tant des équipes que des clients.



Considérant 100% du scope à produire en 14 itérations.
La courbe rouge montre la production idéale. La courbe descend de 100% à 0% de reste à faire considérant une production constante.
La courbe bleue le reste à faire réel.

Dans cette vue, on peut voir que le projet en fin de 5ème itération, comment dire, …, est un peu en retard d’environ 20% sur le scope prévu.
J’utilise aussi deux modes de projection :
  • Sur dernière vélocité
  • Sur vélocité moyenne
Sur dernière vélocité (courbe bleu clair), la projection montre un fin au sprint 14,5.
Sur vélocité moyenne (courbe violette), la projection montre un scope réduit à date de fin à 50%, ou un fin à sprint 30 au moins (non représenté sur la courbe)
Dans ce cas, l’erreur de projection est de fois 2. Pas très acceptable, n’est-ce pas.

Un autre mode de projection peut être effectué sur une vélocité moyenne glissante. Il faut choisir la bonne période, l’équipe est la mieux placée pour définir cette période en fonction de son ressenti et son engagement.

Le burnup pour sa part représente la progression de l’estimation du produit (surface grise) ainsi que de la production (surface orange).


Autre projection de la vélocité, le Lead Time.
Le burnup permet de montrer le Lead Time, ainsi que les changements de scope.


Le LeadTime correspond au temps de production d’une version fonctionnelle cohérente. Même si ce n’est pas exactement la notion provenant du Lean, mais une adaptation à Scrum. Il correspond en fait au temps de production d’une release. Cela peut aider à réadapter son plan de release, réorganiser les priorités, éviter les augmentations de scope dans une release, pour lisser la charge par release, réduire le délai de production d’une release et donc éviter de retomber dans l’effet tunel.
Faire des sprints sans jamais livrer, même avec des démos, ce n’est pas suffisant.


Intégration continue

L’objectif de l’intégration continue est de :

 
Fabriquer un état stable du produit à partir d’incréments fonctionnels à une fréquence élevée.

 
Pour atteindre cet objectif, plusieurs conditions sont nécessaires :
  • Chaque personne (ou équipe au niveau système) doit être responsable de l’intégration de sa partie
  • Le contrôle de l’état stable doit être défini communément
  • Le contrôle de l’état stable doit être passé avant intégration et revérifié après intégration
  • La fabrication et le contrôle de l’état stable doivent être automatisés
  • La fabrication et le contrôle de l’état stable doivent être effectués en moins d’un cycle d’intégration
  • La gestion de configuration doit être adaptée à ce processus (et non l’inverse)
  • Toute action apportant un état instable doit être corrigée en priorité avant toute autre action

 

 

Chaque personne (ou équipe au niveau système) doit être responsable de l’intégration de sa partie


 
Dans un contexte d’intégration continue, il est de la responsabilité de celui qui produit de vérifier que son apport ne casse rien. Et il lui faut aussi fournir les éléments de contrôle qui serviront aux autres pour vérifier que sa production reste stable.
  • Vérifier avant soumission que rien n’est cassé
  • Fournir les éléments de contrôle de la partie à soumettre
 

Le contrôle de l’état stable doit être défini communément

Il s’agit des tests de non régression. Qu’ils soient de niveau tests unitaires, tests d’intégration ou tests fonctionnels.

 
Ces tests doivent être définis au niveau global et non pas au choix par personne ou équipe.
Cela permet de garantir que les vérifications effectuées avant soumission soient cohérentes d’une personne (ou équipe) à l’autre.

 
Plusieurs niveaux de contrôles peuvent être définis en fonction du temps d’exécution de ceux-ci et la fréquence de passage adaptée.
Par exemple, les tests unitaires peuvent être passés tous les jours, les tests fonctionnels complets toutes les semaines, un sous-ensemble des tests fonctionnels minimum peut être défini pour passé tous les jours, c’est ce que j’appelle les tests de maturité. Ils ne couvrent pas la totalité des fonctionnalités, mais servent à vérifier le plus rapidement possible (1 à 2 heures), que le produit ne plante pas sur les cas nominaux.

 

Le contrôle de l’état stable doit être passé avant intégration et revérifié après intégration

Processus à respecter absolument.
  1. Je pars d’un état stable (nouveau branchement ou mise à jour)
  2. Je développe mon code (et tests). Partie techniquement cohérente, doit correspondre à une tâche du backlog de sprint pour ceux qui ont la chance d’être en mode Agile
  3. Je passe mes tests
  4. Je me remets à jour du dernier état stable.
  5. Je repasse mes tests et passe les tests de contrôle d’état stable
  6. Si ok, je soumets mon développement
 Si non, je corrige et reproduit le cycle depuis étape 2

 
Entre étape 4 et 6, il ne faut pas qu’il y ait d’autres soumissions. N’importe quel mécanisme de sémaphore peut être utilisé, de la peluche gizmo au blocage de l’outil de gestion de conf. (Je préfère de loin la peluche)

 

La fabrication et le contrôle de l’état stable doivent être automatisés

Dans un processus où il n’y a qu’une livraison de temps en temps (cycle en V ou en cascade), le coût d’automatisation est élevé par rapport au nombre de fois où il est exécuté.
Dans le cas de l’intégration continue, avec un passage au moins quotidien, le rapport du coût d’automatisation sur le nombre d’exécution est réduit.

 
De plus l’approche Test Driven réduit encore ce coût par la mise en commun des charges de spécifications et de tests.

 
D’autre part, il y a maintenant une multitude d’outils d’excellente qualité répondant à tous les niveaux d’automatisation des builds et des tests et ce dans la plupart des langages de programmation actuels.

 

La fabrication et le contrôle de l’état stable doivent être effectués en moins d’un cycle d’intégration

Comme évoqué plus haut, lors d’une phase d’intégration, il ne doit pas y avoir d’autres soumissions en parallèle. Pour ne pas bloquer le processus d’intégration continue, cette contrainte impose que les temps d’intégration soit très raccourcis.
Tant la fabrication du produit (build) que les tests de non régression (contrôle de l’état stable).
Un effort important est à consacrer à cette diminution du temps de cycle.

 
Des cycles différents peuvent être effectués, par exemple :
  • Cycle rapide (daily build) : build incrémental et tests de régression minimum
  • Cycle moyen (Weekly build) : build total et tests de non régression normal
  • Cycle long avant livraison (Release build) : build complet et tests complets

 
L’intérêt aussi d’un cycle court est qu’il limite le volume produit, les risques d’impact et de conflit et donc la charge d’intégration.

 

La gestion de configuration doit être adaptée à ce processus (et non l’inverse)

La gestion des projets (VOB ClearCase, repository Subversion,…), des composants, des branches doivent être adaptés pour faciliter ce processus.
Eviter l’organisation par composant, mais bien par projet incluant les composants.
Limiter le nombre de branches :
  • Un tronc commun
  •  Une branche par version ou feature pour les gros projets (organisation Feature team)
  •  Seulement deux versions : 
    • celle représentant la dernière version en production
    • celle pour le développement en cours
  •  Eventuellement une branche spécifique dans le cadre des prototypages, pour lesquels la totalité du code produit ne sera peut être pas réintégré, voire pas du tout.

 

 

Toute action apportant un état instable doit être corrigée en priorité avant toute autre action

Respecter le « Stop the line »
Rien de ne sert de produire plus, si la sortie est fermée.

 
Les outils d’intégration continue doivent alerter tout le monde.
Soit par mail, soit par un écran visible de tous, soit par add-on i-buddy
L’alerte doit être simple
  • Etat du build : ok ou en erreur, vert ou rouge
  • et/ou
  • Etat des tests : ok ou anomalie détectée, vert ou rouge
Toute personne de l’équipe doit se sentir responsable de la remise en état du produit.

 

And the Scrumers is...



Petits nouveaux dans le monde de l'outillage Agile, les Scrumers viennent de lancer leur service en ligne de gestion de backlog.


Business model au format RallyDev ou VersionOne, avec une version gratuite pour projets publiques et payante pour les autres.
Utilisabilité et ergonomie plus proche d'IceScrum.

Premiers tests effectués concluants, excellente réaction de l'équipe, française qui plus est.
Souhaitons leur bon courage.

Atteindre la cible

Comme le disait Claude Aubry, le backlog n’est pas une TODO liste. Une liste des choses à faire.


Je le vois comme une liste des objectifs à atteindre. Backlog de produit ou de sprint, objectifs fonctionnels ou non, mais objectifs.

Un objectif est selon la définition du dictionnaire (Larousse) :

« Un but, résultat vers lequel tend l’action de quelqu’un, d’un groupe ».

Une cible à atteindre. Et pour l’atteindre, il faut la définir.

Simple métaphore, un archer ne pourra se servir de son arc sans qu’une cible ne soit disponible.

Ces objectifs eux-mêmes sont un moyen de répondre à un besoin du client, du commanditaire.
Quelques soient ces objectifs, métiers, commerciaux, techniques, ils doivent être définis clairement.
Sinon Scrum ne devient qu’un enchainement de semaines avec point d’avancement régulier, ce n’est qu’un découpage temporel.

Et Scrum et l’agilité, ce n’est pas ça.
  • Une entreprise a des objectifs.
  • Un produit a des objectifs.
  • Une release a des objectifs.
  • Un sprint a des objectifs.
  • Même une tâche a un objectif.
Une fois définis, l’équipe sait au moins où elle doit aller.

Ça contribue à construire l’équipe. Un peu comme un dans un bateau : Sans cap, tout le monde rame, … mais pas forcément dans le même sens.