vendredi 24 octobre 2014

Les exigences non fonctionnelles en agile

Un projet agile se pilote par la valeur apportée au métier. Spécifier agilement, c'est se focaliser sur l’expérience utilisateur, et décrire simplement les exigences qu'aura cet utilisateur dans l'usage du futur système, et ceci à différents niveaux de granularité (User Story).

Pour autant, l'intégration d'une application dans un SI, et plus généralement l'acceptation d'une application par un client passe aussi par le respect d'Exigences Non Fonctionnelles (ENF). Parmi celles-ci, on peut lister:
  • La Sécurité
  • La Performance
  • La Capacité
  • La Disponibilité
  • L'Intégrité
  • L'Évolutivité
  • La Maintenabilité
  • La Scalabilité
  • La Compatibilité

Il existe trois techniques simples permettant d’intégrer naturellement les ENF dans la réalisation d'un projet agile. Ces techniques ne sont pas mutuellement exclusives et peuvent parfaitement être combinées:
  1. Identifier les utilisateurs non métier et leur affecter des User Stories
  2. Insérer dans le Product Backlog des Spikes ou des Technical Stories
  3. Ajouter des critères d'acceptation non fonctionnels aux User Stories

Identifier les utilisateurs non métier et leur affecter des User Stories

Afin qu'un utilisateur métier puisse accomplir ses tâches au travers d'une application, il faut qu'un autre type d'utilisateur puisse lui en garantir la disponibilité: l'Exploitant.

L'Exploitant est un utilisateur de l'application comme n'importe quel autre. Il possède ses propres interfaces, qui peuvent être de simples lignes de commandes et des logs, mais qui peuvent aussi se matérialiser au travers d'écrans spécifiques.

Le fait de considérer ce type d'utilisateur non métier dès les premiers cadrages du périmètre et de lui identifier ses propres User Stories permet d'intégrer naturellement un certain nombre d'ENF. Par exemple:
  • En tant qu'Exploitant, je veux un script de bascule de nœud applicatif afin de pouvoir mettre à jour l’application sans interruption du service
  • En tant que RSSI*, je veux que l'application contrôle que chaque utilisateur se soit préalablement identifié au SSO


Insérer dans le Product Backlog des Spikes ou des Technical Stories

Le Product Backlog doit contenir TOUT ce que l'Equipe a la charge de réaliser. Il est donc important que le Product Owner soit sensibilisé au fait que certains des éléments du Product Backlog, bien que n'apportant pas de valeur directe aux utilisateurs, sont essentiels pour l'implémentation du produit. 

On peut donc construire un Product Backlog sur la base d'une typologie d'éléments:
  • Des User Story, qui représentent les fonctionnalités vues de l’utilisateur, et constituent la valeur intrinsèque du produit
  • Des Spike ou Investigation Story, qui représentent les besoins de travaux exploratoires lorsqu'il n’est pas possible d’estimer la complexité d’une User Story (manque d’entrant fonctionnel, hypothèse technique à prototyper, …)
  • Des Technical Story, qui représentent la mise en œuvre d’exigences techniques liées au produit,  à son environnement ou à la gestion de la dette technique

Exemples de Technical Stories:
  • Mise en place de l’environnement de gestion de configuration sous GIT, afin de se conformer aux outils en vigueur dans le SI 
  • Upgrade de la bibliothèques de composants graphique PrimeFaces, afin de bénéficier des dernières améliorations du fournisseur
  • Implémentation de la procédure de sauvegarde et de restauration, afin d'atteindre un RPO* de 30 minutes
  • Dénormalisaiton de la base de données afin d'optimiser les performances des requêtes

Ajouter des critères d'acceptation non fonctionnels aux User Stories

Enfin, lorsque des ENF s'appliquent plus spécifiquement à des fonctionnalités, on les ajoute simplement aux critères d'acceptation des User Stories.

Exemple de critères d'acceptation non fonctionnels pour une User Story:
  • Le tableau de résultat doit s'afficher en moins de 5 secondes
  • L'affichage doit être compatible IE9, IE10 et IE11
  • Seul le rôle Administrateur peut accéder à cette fonctionnalité


Normalement, ces trois techniques combinées permettent de ne rien oublier dans la réalisation, et d'estimer au plus juste la complexité réelle du périmètre à implémenter au sein d'une itération.


* RSSI : Responsable de la Sécurité des Systèmes d'Information
* RPO : Recovery Point Objective




lundi 15 septembre 2014

7 changements à intégrer pour un véritable projet agile!

Pour beaucoup de projets, d'organisations, voir d'individus, passer à l'agilité représente un changement majeur de paradigme et de culture. D'ailleurs, dans pas mal de cas, un projet n'a d'agile que le nom.

Mais quand l'agilité est parfaitement comprise par l'ensemble des parties prenantes et que la volonté d'être agile est réelle, les changements à intégrer ne sont pas à sous-estimer, tant nous avons tous été habitué à évoluer dans une même matrice: des projets découpés en séquences, des équipes travaillant en silo, un management focalisé sur le respect des plannings.

L'agile casse ce moule, et c'est parfois rock 'n' roll, car ça bouscule pas mal d'habitudes!

Voici 7 changements à intégrer dans la conduite des principales activités projets lorsque l'on veut véritablement parler d'agilité!


L'implication du métier

Dans une organisation projet classique, l'implication du métier ou de ses représentants est forte dans les premières phases du projet (recueil de besoin, spécification), puis dans les dernières phases (validation,  acceptation). Cela pose souvent des problèmes de disponibilité de la part des sachants et autres key people, tant ces phases peuvent être chronophages. En revanche, durant la plus grande partie du projet, c'est à dire la construction à proprement dite, il n'y a plus de son et plus d’image.

Dans une organisation projet agile, l'implication du métier ou de ses représentants est constante durant toute la durée du projet. Cela peut paraître contraignant, mais en réalité, la charge est lissée, et le mode agile ne requiert pas de longues phases de travaux "en chambre". Tout au plus des workshops réguliers, d'une heure à une demi journée. On démarre plus vite, avec moins d'inputs, et on se voit souvent. Le dialogue métier/technique doit être constant, et la réactivité optimale, tant pour l'affinage de la compréhension de inputs fonctionnels que pour la prise en compte du feedback récolté sur les incréments livrés.

Les spécifications fonctionnelles

Dans une organisation projet classique, les spécifications détaillées du périmètre sont élaborées au début, et une une seule fois. Il n'est pas rare, pour un projet de plusieurs années, d'y passer plus de 6 mois. Il s'agit alors d'un labeur surhumain, tant il faut imaginer dans le moindre détail un vaste système et présupposer de son utilisation, alors que tout n'est encore que virtuel. A l'issue, de volumineux documents font l'objet de revues et de validations. A partir de ce moment, le projet devient comme figé et focalisé sur la réalisation de ces "tables de la loi".

Dans une organisation projet agile, les spécifications détaillées du périmètre sont élaborées au fil de l'eau, avec une approche "just in time". Une phase d'initialisation est toujours nécessaire pour le projet, mais n'a pas pour objectif de décrire tout le comportement du futur système dans ses moindres détails. On se concentre sur l'architecture générale (Vision), et sur le découpage du futur système en fonctionnalités, dont la granularité est inversement proportionnelle à la priorité (Product Backlog). On rentre alors rapidement dans la réalisation d'un premier incrément, en affinant préalablement la compréhension d'un premier sous-ensemble de fonctionnalités. On pourrait penser que la quantité limitée de détails formalisés est un problème pour les développeurs. En réalité, cette limite volontaire fait qu'il se produit un petit miracle: les développeurs parlent aux analystes, et cet échange est fondamental à la réussite du projet.

Les tests du système

Dans une organisation projet classique, les tests sont élaborés après les spécifications, et en parallèle des développements. Ils sont exécutés à la sortie de la phase de développement, dans une étape qui (normalement) est planifiée en début de projet, et qui est souvent largement amputée avec les retards de développement (n'est-ce pas?). Durant cette étape, l'équipe de développement est sous pression car il faut corriger une montagne d'anomalie qui arrive chaque jour, tout en finalisant les développements (souvent en retard,  donc!).

Dans une organisation projet agile, les tests font partie des spécifications. Voir, ils les remplacent totalement avec l'approche de "test spécifiant", basée sur la création d'exemples d'usage valorisés venant enrichir chaque élément du Product Backlog. Ces tests doivent pouvoir être facilement automatisés et devenir des spécifications exécutables, même si ce n'est pas une obligation absolue. Automatisé ou pas, un cas de test est élaboré avant le développement de l'élément fonctionnel qu'il complète. Les tests fonctionnels alimentent donc l'activité de développement et contribuent à un meilleur alignement du développement avec le métier.

La validation du produit

Dans une organisation projet classique, la recette (UAT, VABF, ...) est véritablement le couperet final du projet. Dans le pire des cas, le nombre et/ou la criticité des anomalies remontées sont tellement importants que la mise en production est tout simplement repoussée. Et je ne parle pas des utilisateurs...on va dire "interpellés" par l’ergonomie qu'ils découvrent! A ce moment précis, la confiance accordée à l'équipe de réalisation se réduit comme peau de chagrin...

Dans une organisation projet agile, le cycle de validation se cale sur le cycle de développement, c'est à dire itératif et incrémentale. Chaque incrément réceptionné à l'issue chaque itération fait l'objet d'une acceptation partielle de la part du client. Ceci nécessite le respect d'une règle fondamentale d'un projet agile: chaque élément fonctionnel alimentant une itération doit pouvoir être complètement terminé dans une et une seule itération. Ensuite, les anomalies d'une recette N alimentent les travaux des itérations suivantes. On maintien généralement une phase de recette chapeau à la fin du projet, mais comme la plupart des anomalies ont déjà été levées et corrigées, il s'agit alors surtout de vérifier la bonne intégration du produit dans le SI et formaliser l'acceptation finale pour passer en production.

Les estimations

Dans une organisation projet classique, on estime des tâches en jour/homme, et ceci de manière prédictive. Le manager demande à chaque membre de son équipe (généralement individuellement) d'estimer son effort pour accomplir une certaine tâche. Dans le cas où la tâche est en avance, les délais sont généralement maintenus et on perd en productivité. Dans le cas où la tâche est en retard, la pression s'accentue et on perd généralement en qualité. Les tensions peuvent alors s'exacerber car il n'est pas rare de voir fuser les réprimandes pour ne pas savoir respecter ses engagements.

Dans une organisation projet agile, on estime des fonctionnalités en complexité relative, et ceci de manière empirique. Le terme fonctionnalité est à comprendre ici comme une valeur apportée au client, et non comme une simple caractéristique du système. Les estimations sont obtenues collectivement, via des ateliers de travail dédiés. Quelque soit l'unité d'estimation, cette unité représente toujours une taille, jamais un délais. Chaque élément est estimé comparativement aux autres. Plus le projet avance, plus la connaissance grandie, et plus les estimations sont fiables. L'apprentissage constant est une donnée du projet agile.

La planification et le suivi

Dans une organisation projet classique, on planifie des phases et des activités (architecture, spécification, développement, test) et ceci en début de projet. On suit ensuite la progression de chaque phase. Les indicateurs majeurs du projet sont l'état de chaque activité et la tendance de la trajectoire vers la date de fin prévue. On s'intéresse généralement peu à l'adéquation de ce qui est en construction avec à ce qui est réellement attendu, en tout cas pas avant la recette finale.

Dans une organisation projet agile, on planifie de la valeur métier (c'est à dire des éléments fonctionnels de différentes granularités apportant un intérêt tangible pour les utilisateurs), et ceci tout le temps. On suit la quantité de valeur déjà délivrée et acceptée par les utilisateurs, et la quantité de valeur restant à délivrer. Un indicateur important est la vélocité de l'équipe de réalisation, c'est à dire sa capacité à produire une certaine quantité de valeur dans un laps de temps donné, ce qui permet de planifier en permanence l’atterrissage du projet avec toujours plus de précision. Mais l'indicateur majeur reste le feedback obtenu à la livraison de chaque itération.

Le management du projet

Dans une organisation projet classique, un chef de projet définit le cadre d'organisation, affecte les tâches et contrôle leur progression. Son action s'inscrit généralement dans une organisation où la frontière entre ceux qui réalisent le produit (MOE) et ceux qui veulent le produit (MOA et/ou DSI) est forte. Généralement seul à porter l'engagement, le CP utilise le traditionnel point projet hebdomadaire pour relever les compteurs individuels (consommé / reste à faire), consolider le tout afin d'actualiser les indicateurs, et donner les directives pour la suite. Parfois, c'est le respect du processus qui compte plus que l’objet même de ce dernier: la réalisation d'une vraie application pour de vrais utilisateurs!

Dans une organisation projet agile, la notion même de chef de projet n'a plus vraiment de sens. Un manager agile est un facilitateur, qui travaille à maintenir en permanence un bon niveau de collaboration et de transparence entre toutes les parties prenantes, quotidiennement. Il entraîne l'équipe vers plus d'autonomie dans ses décisions et de confiance dans ses engagements. Il incite chacun à prendre part à l'amélioration continue, du projet comme du produit. Le "contrat agile", explicite ou non, nécessite aussi que l’engagement soit mieux réparti entre ceux qui réalisent et ceux qui veulent. Le rôle du "chef de projet agile" peut finalement se résumer à ça: détruire les obstacles qui peuvent freiner la bonne marche de l'équipe dans son engagement à produire de la valeur et de la qualité pour un client.




jeudi 8 mai 2014

Agilité et seconde guerre mondiale !

En ce 8 mai 2014 (jour célébrant la victoire des alliés en 1945, pour les plus mauvais en histoire d'entre nous), quoi de plus naturel que de parler de la seconde guerre mondiale. OK, mais en parler sur un blog agile !!??


J'aime les citations. Certaines, bien que n'ayant rien à voir avec l'agilité, renvoient tout de même à certaines de ses valeurs. Parmi celles-ci, celles du général Patton.

Célèbre chef de guerre américain, ce militaire nous a laisser quelques citations sur sa vision du "management" d'une unité de combat. Certaines font pour moi référence à certains principes agiles. Vous l'aurez compris, il ne s'agit pas de se prendre au sérieux ici, quoique.... Voici ces citations :


 "A pint of sweat, saves a gallon of blood.“

Le courage. De dire ou d'agir tout de suite, même si ça coûte, plutôt que de laisser sous le tapie. C'est le cas pour le refactoring, et aussi pour les tests fonctionnels automatisés. Oui, il faut "suer une pinte" pour les obtenir. Mais combien économise-t-on lorsque les fonctions sous tests évoluent ? C'est tout simplement énorme. Par le passé, j'ai trop souffert de l'introduction de régressions par différentes équipes de dev et tellement dépensé à faire passer et repasser des procédures manuelles pour ne pas aujourd'hui investir systématiquement en amont de chaque projet sur de l'automatisation.  

"A good plan violently executed now is better than a perfect plan executed next week.“

Échouer vite, apprendre rapidement. Il est toujours préférable de passer à l'action tout de suite, de confronter ses hypothèses à la réalité, et d'apprendre de l'expérience et du feedback plutôt que de dépenser des jours et des semaines à élaborer, planifier, peaufiner avant de démarrer. Quoi de plus agile ?

"A piece of spaghetti or a military unit can only be led from the front end.“

Manager par l'exemple. Un leader ne dit pas "go", mais "let's go". Il est devant, et il supprime les obstacles. Cela fait aussi référence au concept Lean du "Go and Sea". Le manager est présent sur le terrain, avec l'équipe, pour comprendre ce qu'il se passe.

"Don't tell people how to do things, tell them what to do and let them surprise you with their results.“

L'autonomie. Sûrement ma citation préférée,qui se réfère à l'idée de ce qu'est (ou devrait être, dans pas mal de cas) l'équipe Scrum. Celle-ci doit être guidée par la vision du produit et par l'objectif de chaque Sprint, mais elle doit rester libre de ses choix d’implémentation, d'outillage, et d'amélioration des processus projet (c'est pas toujours ça, hein ?).

"Prepare for the unknown by studying how others in the past have coped with the unforeseeable and the unpredictable.“

Inspection et adaptation. Planifier, c'est bien tenter de prévoir l'inconnu. Pour se faire, l'approche agile est résolument et clairement empirique. On apprend du passé pour mieux prévoir l'avenir. On le retrouve concrètement dans le pilotage et la planification agile, avec la mise à jour continue des estimations des Baklogs en fonction des Sprints passés. 

"There is only one sort of discipline, perfect discipline."

L'excellence technique. L'amour du travail bien fait, un des principes du manifeste agile, que l'on retrouve aussi dans le software craftsmanship. Et c'est aussi l'un de mes chevaux de bataille : l'agilité requière une réelle discipline, et un maintien de celle-ci dans l'application des valeurs, des principes et des framework agiles tout au long du projet. 

Bon 8 mai à ceux qui liront ce post aujourd'hui...et spéciale dédicace à Amaury ;-)








mardi 15 avril 2014

L'oiseau agile a fait son nid

Parfois il est bon de revenir aux sources. Feedback sur la keynote d'ouverture du ScrumDay.fr 2014.

L'excellent speech d'Alistair Cockburn, co-auteur du Manifeste Agile, en introduction du ScrumDay 2014 à Disneyland Paris, fut l'occasion de dresser un état des lieux de l'agilité en 2014, tout en revenant aux sources de celle-ci.

Deux points abordés par Alistair m'ont en effet interpellé, car ils mettent en perspective le cœur de l'agilité tel que l'ont conceptualisé les pionniers à la fin des années 90, et son application à grande échelle aujourd'hui.
  • Core Scrum : back to the basics
  • L'agilité en 2014 : on a changé d'échelle

Core Scrum : back to the basics 

Tout d'abord, il est utile de rappeler que l'agilité, ce n'est pas une méthode, mais des valeurs. Scrum lui, est un Framework pour construire un produit de manière agile, c'est à dire basé sur les valeurs de l'agilité.

Premier point donc abordé par Alistair, un recadrage sur ce qu'est Scrum dans sa plus pure définition. En effet, beaucoup de pratiques et de techniques se sont greffés (avantageusement) à Scrum, et le tout forme aujourd'hui une sorte de boite à outils qu'il faut savoir utiliser à dessein, mais pas de manière systématique.

Alistair résume Scrum en 3 principes de base et 2 principes corollaires :

3 principes de base
  1. livrer (plutôt que démontrer) à chaque Sprint
  2. laisser l'équipe libre de ses choix (sur les pratiques, sur les outils, sur son organisation)
  3. examiner la situation et s'adapter en permanence, chaque jour et chaque Sprint
2 principes corollaires
  1. une personne possède la capacité de supprimer les obstacles (ScrumMaster)
  2. une personne possède la capacité de représenter le produit ou le métier (Product Owner) et est disponible



Puis vient ensuite ce qu'Alistair appelle des "barnacles", que l'on peut traduire par..."bernaches" ou "bernacles" (c'est à dire des petits crustacés qui viennent se coller sur la peau des mammifères marins - je l'avoue, je ne connaissais pas ce mot, ma culture animalière est visiblement limitée...).

L'image est parlante. En effet, le Kanban Board, les graphes de combustion, les fameuses trois questions quotidiennes, ...tout cela est tellement "accroché" à Scrum désormais que ça fait presque partie du package de base.


Enfin, tout le reste, c'est en dehors de Scrum. Dire que c'est du Scrum relève de la "rumeur". Le planning poker, les User Stories, ...un projet Scrum peut très bien vivre sans. En tout cas, cela ne doit pas être imposé à l'équipe.

L'agilité en 2014 : on a changé d'échelle

Cette vision root de l'agilité, elle est désormais déployée à grande échelle. Dans certains cas aujourd'hui, on est bien loin de la petite équipe de "guerriers" qui a décidé de faire de l'agile pour un petit projet web interne. L'agilité a changé de braquet, et adresse désormais des sujets complexes, des enjeux majeurs, voir transforme totalement les organisations.

Alistair a repris ici l'exemple de Spotify (http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify). Bon ok, le coté "geek" de leur cœur métier doit simplifier l'application de ce genre de matrice, mais aujourd'hui, de plus en plus de DSI opèrent ce type de transformation (y compris certaines du CAC40 !).



Spotify, c'est une centaine de développeurs, 30 Scrum Team, trois sites distants.

Comment garder l'esprit agile avec la nécessaire organisation industrielle indispensable à ce niveau d'échelle ? 

Sur le schéma ci-contre, l'équipe Scrum telle que nous la connaissons, c'est "l'escouade". Elle dispose des moyens et de l'autonomie nécessaire pour choisir son propre mode de fonctionnement. Son travail est orienté par un Product Owner.

Le degré de maturité de chaque escouade étant différent, elles ont accès à des coach, chargés de les assister dans le déblocage des problèmes et l'amélioration continue.

Si une escouade est une mini start-up, la "tribu" en est l'incubateur. Chaque tribu adresse un sous-domaine complet du périmètre général. Il y a donc un chef de tribu, qui maintien la cohérence entre les travaux de ses escouades et gère leurs dépendances.

Afin d'éviter les silos, harmoniser l'organisation et disons-le, la piloter, des "groupes" (chapter ?!) inter-escouades s'organisent autour de compétences spécifiques au sein d'une tribu. Ces groupes se réunissent régulièrement sous la tutelle d'un manager (3.0, évidemment).

Enfin, afin d'harmoniser les pratiques et partager l'expérience, des "guildes"  s'organisent autour de thèmes spécifiques (UX, testing, coaching, ...). Chaque guilde possède un coordinateur, ici à temps plein dans ce rôle.


En résumé, cette keynote d'ouverture présumait d'un très bon cru 2014 du ScrumDay. Et effectivement, on s'est régalé...en prenant un grand bol d'air pur agile. Vivement l'année prochaine !

dimanche 30 mars 2014

7 idées reçues sur l'agilité !

Aujourd'hui, tout le monde parle d'agilité. Mais comprend-t-on toujours de quoi il s'agit...hum. J'ai entendu beaucoup d'idées reçues sur le sujet, et j'ai trouvé amusant d'en rassembler un certain nombre, en tentant d'y apporter une réponse.

Vu ou entendu dans la vraie vie ! Est-ce que vous en avez d'autres ?


L'agilité, c'est que pour les développeurs !

Oh que non !!!

L'agilité, c'est un écosystème qui impacte tous les acteurs concernés par la matérialisation d'un besoin. C'est une chaîne de valeur complète, dynamique, collaborative, qui part du besoin (l'utilisateur), jusqu'à son maintien en condition opérationnelle (l'exploitant). Et accessoirement, c'est vrai, cette chaine passe par les développeurs...

Et de même que pour la chaîne de production horizontale, l'agilité impacte aussi la verticalité de l'organisation : le management et ses différentes strates. Le contrôle sans confiance, l'autocratie, les décisions top-down, tout cela est incompatible avec l'agilité. Le management doit donc se positionner aussi sur ces questions, et évoluer vers plus de facilitation, d'écoute, de libération des énergies.  

Et pour ceux (comme moi) qui l'ont vécu, je peux vous garantir qu'une équipe de dev agile dans un environnement non agile, c'est le meilleur moyen de se planter !

L'agilité, c'est freestyle, y a pas de process !

Facile celle-là, car c'est tout l'inverse !

Des rôles (PO, SCM, ...), des activités (Story Mapping, Sprint planning,...), des livrables (incréments du produit), des outils de pilotage (backlogs, burndowns, ...), des check-list (DoR, DoD, ...). Tout cela ne ressemble-t-il pas à un process ?

En réalité, l'agilité est une vraie discipline, tant sur le plan de l'organisation que de l'ingénierie. Cette discipline, bien menée, permet au fil des itérations une réelle maîtrise du projet et de la qualité de ce qu'il produit. A l'inverse, baisser la garde et le niveau d'exigence sur ces pratiques, et c'est un risque d'échec.

En fait, plutôt que de "discipline", il faudrait plutôt parler de compréhension et d'appropriation. Car le projet devient vraiment agile quand chacun comprend l'objectif et s'en approprie les moyens. L'agilité est avant tout une histoire de culture. Le process, lui, est à adapter à chaque contexte.

C'est pas freestyle, c'est juste fun !

En agile, y a pas de specs !

Hum, plus dure celle-là, car certains sont vraiment réfractaire à l'idée de parler de spec en agile. Mais pour moi, clairement, ce n'est pas un gros mot !

Je dirais plutôt, en agile, y a pas de gaspillage. Ce qui est certain, c'est que passer 6 mois à pondre une spec détaillée qui sera de toute façon incomplète et surtout probablement déjà obsolète au moment de sa validation, c'est du gaspillage.
En agile, on spécifie au moment où on en a besoin (JIT - Just In time). Et pour spécifier, on privilégie le dialogue constant, productif et respectueux entre ceux qui veulent (utilisateurs, MOA, DSI) et ceux qui font (analystes, développeurs, testeurs). Spécifier en vase clos et "balancer" la spec aux développeurs, c'est assurément soumettre le besoin à interprétation. Et ça, c'est si la spec est lue!

L'essentiel, c'est donc pas la spec, c'est la compréhension de ce qu'il y a à produire par ceux qui produisent. Et ça passe par le dialogue. Le niveau de documentation associé est en réalité fonction de chaque contexte et de chaque besoin. Et surtout fonction de la valeur réelle apportée par le document. Les approches de test spécifiant (ou de spesc exécutable) sont extrêmement puissantes, et reviennent à spécifier avec des exemples concrets, vivants et surtout qui ne sont pas soumis à interprétation.

Un projet agile ? OK, on code tout de suite !

Essayez pour voir !

Démarrer la réalisation d'une application sans poser la vision fonctionnelle et technique de la cible est une aventure hasardeuse à laquelle je ne participerai pour rien au monde. (En fait, c'est possible, mais ça ne s'appelle pas une application, ça s'appelle un POC).

Pour réellement démarrer un processus de construction itératif et incrémental, l'architecture doit être stabilisée. Le contexte, les acteurs, les domaines fonctionnels, les contraintes techniques, l'ergonomie générale, les modules logiciels, l’élaboration d'un premier Product Backlog...Certains appellent cela le Sprint zéro, mais soyons clair, ce n'est pas un Sprint au sens Scrum, c'est une phase d'initialisation et d'analyse. 
En revanche, la conception détaillée doit émerger et s'améliorer au fil du développement. Mais cela doit se restreindre à la manière d'organiser le code et ses classes (refactoring, design pattern) et pas aux principes structurants de l'architecture (sinon, ça peut faire mal...).

Un forfait agile ? Faire rentrer des ronds dans des carrés !

Sujet sensible...mais clairement, ça marche (sinon je serai au chômage !).

Forfait et agilité, ce n'est pas du tout incompatible, mais (car il y a un mais), ça doit influer sur la manière de contractualiser. Dans un forfait agile, l'un des éléments du triptyque CCC (Coût/Contenu/Calendrier) est forcément variable. Généralement, c'est le Contenu. On s'engage sur une complexité globale, et on fait varier le détail. Tant qu'on est dans la même complexité globale, l'engagement est maintenu (ici le Coût et le Calendrier). 
Pour que cela fonctionne, il est fondamental que client et fournisseur partagent les métriques qui servent à établir la complexité. La vraie difficulté, c'est donc l'étalonnage de cette complexité, qui est forcément empirique. Ce qui veut dire que sans expérience préalable sur le contexte, il faut adresser le risque de s'engager avec une vision erronée de la complexité globale (mais là, ça ne change pas des forfaits classiques). L'idéal est donc de procéder à cet étalonnage avant de s'engager forfaitairement.
Le second point important du forfait agile, c'est l'abandon de la vision "donneur d'ordre/exécutant" du contrat classique, au profit d'une approche plus "gagnant/gagnant". Sur ce point, pas mail d'éléments de contractualisation agile existent et sont de plus en plus matures. Mais quand on veut contractualiser en agile, on rencontre plus souvent des problèmes de culture et d’organisation que des problèmes juridique.

De l'agilité en offshore ? OK, t'as rien compris à l'agile alors...!

"...et les interactions entre individus du Manisfeste  ?!" Ok, ok, mais pourtant, ça tourne !

Et non seulement ça tourne, mais en réalité, je me demande comment mener un projet offshore sans agilité ! Mais on va pas se le cacher, un projet avec une équipe à distance rencontre toujours la même difficulté : la distorsion de l'information échangée. C'est toujours incroyable pour moi de constater comment l'absence de discutions informelles type "machine à café" influe sur la compréhension des inputs et sur la qualités des outputs. Or l'agilité possède deux armes pour contrer les effets pervers d'une équipe distante : des cycles courts et des cérémonies collaboratives régulières.

Les cycles courts permettent tout simplement ici de limiter le risque d'un livrable inadapté. En mode offshore, je réduis au maximum la durée des Sprints (une semaine). Les cérémonies qui encadrent les Sprints et qui permettent la compréhension, la démonstration, l'ajustement et l'amélioration  (plannings, revues, rétrospectives) sont donc aussi plus rapprochées et génèrent rapidement du feedback et des actions.

Et puis il faut savoir innover. Le ScrumMaster (forcément en Back, avec l'équipe) envoie au Front un "Daily Mail" à l'issue de chaque Daily Scrum. Un "Architecture Owner" (côté Front) assure l'intégration et la validation avant la démonstration au Product Owner (côté Front également, cela va sans dire). Un Proxy PO (coté Back) peut aussi faire son petit effet (à condition qu'il puisse rencontrer régulièrement le vrai PO). Et puis les réunions de planification et de rétrospective se font en Visio Conf.

Bref, l'agilité appliquée à elle-même !

Agilité et CMMI, ç'est pas compatible !

En théorie, c'est possible ! Mais en pratique ?

En pratique...c'est vrai qu'il peut y avoir une différence d'appréciation, voir de méthodes. Ce qui est certain, c'est que l'agilité ne se substitue pas aux fondamentaux de l'industrie logicielle et de ce qui fait qu'un projet est un succès ou un échec : bon niveau d'expertise, de coordination, de collaboration et de pilotage.

Si l'on considère que l'assurance qualité, c'est se conformer à un plan, produire des documents uniquement pour alimenter les revues, mesurer la productivité individuelle ou encore présenter des indicateurs "pastèques" en comité de pilotage (vert à l'extérieur, rouge à l'intérieur), alors oui, il y a problème de compatibilité avec l'agilité. En revanche, si les procédures d'assurance qualité se focalisent sur les moyens donnés aux équipes et sur le suivi de l'apport de valeur réelle au client final, alors rien ne doit empêcher d'intégrer de l'agile dans un processus CMMI.

Pour ma part, je ne l'ai pas encore vu, mais je ne désespère pas ;-)


A lire également : 7 changements à intégrer pour un véritable projet agile


dimanche 9 février 2014

Kanban en 4 étapes

La méthode Kanban est une méthode simple, visuelle et compréhensible par tous les acteurs d’un processus. Elle est également faiblement intrusive dans l’organisation, contrairement à Scrum qui définit de nouveaux rôles (Product Owner, ScrumMaster), de nouveaux artéfacts (Product et Sprint Backlogs), une cadence figée (Sprints) et des cérémonies dédiées (Planning meeting, Sprint Review, etc…).

Kanban est simple, mais sa mise en œuvre nécessite un peu de méthode et beaucoup d'accompagnement. Je vous propose dans cet article de décrire la démarche que j'ai implémentée sur l'un de mes projets. J'ai volontairement essayer d'en faire ici une démarche générique et non spécifique.

Kanban en 4 étapes


Pour démarrer avec Kanban, pas besoin de big bang. On part du processus existant, et on itère sur la mise en oeuvre, de manière progressive. On se focalise d’abord sur un flux simple ou un sous-flux, en limitant le nombre de nouveaux concepts à implémenter et appréhender. La montée en puissance de Kanban se fera alors par l’enrichissement progressif des concepts mis en oeuvre et par l’élargissement des acteurs impliqués.

Les pré requis

Afin d’impliquer l’ensemble des parties prenantes concernées par le processus global, la mise en œuvre de Kanban est conditionnée par l’identification
  • D’un facilitateur (pilote opérationnel du processus à "kanbaniser", qui peut être externe à l’organisation)
  • D’un sponsor (obligatoirement interne à l’organisation et avec le bon niveau de décision et d’entrainement de l’ensemble des parties prenantes)

Etape 1 : Modéliser le flux existant

La première étape part de la situation réelle. Elle consiste à modéliser le flux existant, en identifiant la typologie des éléments de fabrication (ou classes de services), les étapes du processus au travers desquelles voyage chaque instance d’élément de fabrication, et les acteurs associés à chaque étape.

Il s’agit d’un découpage à la fois horizontal et vertical :
  • horizontal : la typologie des éléments de fabrication ou des services à fournir (évolution fonctionnelle, travaux techniques, correction d'anomalie, …) ainsi que leur complexité, qui doit être réduite à un nombre limité de taille (XS, S, M, L, XL)
  • vertical : les séquences d’activités (ou étapes) nécessaires à la fabrication des éléments ou à la fourniture du service (analyse, spécification, conception, développement, acceptation, production) et les acteurs associés à chaque étape.

Une fois le modèle existant identifié, il est retranscrit sur le tableau Kanban, visible de tous, et permettant de mettre en œuvre le management « visuel » du processus.

Etape 2 : Implémenter ou tuner les concepts

Les concepts associés à Kanban sont en nombre limité et assez simple à appréhender. Il s’agit de :
  • La visualisation du workflow (une étape est représentée par une colonne sur le tableau Kanban)
  • Le transit des éléments de fabrication (représenté sous forme de cartes Kanban avançant de colonne en colonne, et dont la couleur reflète la typologie)
  • Le travail en cours (WIP - Work In Progress), type de colonne regroupant les éléments réellement en cours de fabrication par une équipe dédiée (TEC : travail en cours)
  • Les files d’attente, représentant un stock de travail pour une équipe dédiée, qui vient « tirer » son activité de la finalisation de l’étape amont (TAF : travail à faire)
  • Pour chaque colonne, la détermination des limites (hautes et basses) à ne pas dépasser, c’est-à-dire un nombre maximum ou minimum d’éléments de fabrication transitant au même moment par une même colonne (travail en cours ou files d’attente)


Si le workflow et la typologie d’élément de fabrication varie généralement peu, les limites elles peuvent varier en fonction de l’apprentissage de chaque équipe, de l’amélioration continue ou d’un changement capacitaire.

Chaque limite doit être tunées en permanence :
  • Pour les files d'attente, afin d’éviter de travailler de manière trop anticipée, lisser la charge et limiter le stress d’une pile de tâche qui s’accumule. La limite doit être suffisamment grande pour garder l'équipe occupée, mais suffisamment petite pour éviter que des éléments stagnent trop longtemps avant d'être traités.
  • Pour le travail en cours, principalement pour empêcher le multitâche. En effet, le multitâche est générateur de perte en ligne car passer d’une tâche à une autre implique obligatoirement une certaine inertie et ralentie le débit global. De plus, il est plus bénéfique pour l’équipe de garder le focus et l’attention sur un nombre limité de travaux, et améliorer ainsi les échanges, le travail d'équipe et la diffusion de la connaissance.

Etape 3 : Faire couler le flux

Il est important de noter que les éléments qui transitent au travers des colonnes WIP et files d’attente sont toujours des notions liées au besoin du consommateur final du processus (flux tiré). La granularité des éléments n’est donc pas la tâche (work), mais la fonctionnalité (feature). La feature est bien la finalité et la valeur intrinsèque du processus lui-même.

Pour démarrer le flux, il faut donc instancier les éléments qui vont couler le long des étapes.
  • Pour le BUILD (réalisation d’une application ou d’une évolution majeure), on découpe le périmètre en petit bout (Feature Breakdown Structure OU Story Mapping -> Product Backlog) et on le priorise,
  • Pour le RUN (activité récurrente type correctif ou incident), le flux démarre de manière événementielle, ou avec un stock priorisé (P1, P2, P3).
Le flux coule naturellement grâce aux limites. Une équipe à droite tire son travail à faire de l’équipe à gauche dès que sa limite le lui permet. La priorisation peut être issue de règles de gestion associées à la typologie des éléments de fabrication, où décidées par qui de droit. En effet, bien que Kanban n’implique pas la définition de rôles précis, il est souvent nécessaire de déterminer un « propriétaire du produit » ou un « responsable opérationnel du flux  » qui est à même de décider de la priorisation de l’activité.

Etape 4 : Collaborer et s’améliorer

Cette dernière étape permet de mettre en place quelques pratiques supplémentaires pour faciliter la collaboration et l’amélioration continue, et de reboucler sur l’introduction ou l’adaptation des concepts Kanban au contexte.

Les pratiques complémentaires à Kanban ne sont pas limitées. En voici quelques exemples:
  • Le stand-up meeting
  • La rétrospective
  • Les DoD et DoR
  • L’Emergency Line

Stand-up meeting
Le pilotage est dans le rythme (et vise-versa). Chaque jour, un stand-up est organisé autour du tableau Kanban et réunit les intervenants concernés par les différentes activités du flux. Ce stand-up a pour objectif de piloter le Kabnan, et mettre à jour « l’instantané » de l'état du processus que constitue son tableau.

L’implication de chacun est un élément fondamental de la réussite d’un projet, et le facilitateur Kanban doit s’assurer du bon degré de collaboration et du bon niveau de connaissance de chacun. C’est lui qui s’assure du bon déroulement de la réunion, qui doit être time-boxée.
Durant ce stand-up, on passe en revue l’activité de chaque équipe (via son représentant présent). On débute en partant de la droite du tableau – le besoin final. Pour chaque activité, trois points sont abordés (équivalent des trois questions du Daily Scrum) :
  • L’activité en cours pour chaque équipe
  • L’activité à venir pour chaque équipe, et la priorisation de l’activité
  • Les obstacles à venir, et les actions de prévention
Dans ce processus collaboratif, la notion de limite spécifiée pour chaque colonne est primordiale. Et il est important de considérer que les limites sont des règles de gestion du processus pour lesquelles on ne transige pas.

En effet, les limites constituent le moyen d’identifier très rapidement les problèmes du système, qu’ils soient récurrents ou exceptionnels (blocage, engorgement, sous-activité). 
Lorsqu’une limite est atteinte, la première conséquence est qu’aucun nouvel élément de fabrication ne peut entrer dans la colonne en question. Il y a donc urgence à « désengorger » l'activité, au risque de bloquer l’ensemble du système.
L’atteinte d’une limite doit donc déclencher immédiatement deux choses :
  • La focalisation sur l’activité en risque de surcharge
  • L’affectation prioritaire des ressources sur le déblocage de l’activité

Dans ce cadre, et si cela est possible en fonction des connaissances de chacun ou du mode de contractualisation entre les équipes, les ressources des autres équipes doivent venir en renfort de l’équipe où la limite est atteinte.

Rétrospectives
Pour améliorer le processus et/ou le produit, il est plus bénéfique de « décrocher » de l’activité opérationnelle et prendre un peu de recul. C’est la raison pour laquelle il est préférable d’aborder l’optimisation et l’amélioration continue lors d’ateliers dédiés plutôt que de mixer des réflexions d’amélioration au suivi quotidien de l’activité.
L'outil ici, c'est la rétrospective. Tout comme le stand-up meeting, un maximum de parties prenantes doit participer aux sessions de rétrospective. Typiquement, deux questions y sont évoquées:
  • Qu’est-ce qui fonctionne bien et qu’il faut capitaliser ?
  • Qu’est-ce qui fonctionne moins bien et qu’il faut améliorer ?
Pour être efficace, des décisions concrètes et partagées doivent émerger de chaque rétrospective. Les plans d'actions doivent être réellement menés. 

DoR / DoD : Definition of Ready & Definition of Done
L’entrée d’un élément dans le processus de fabrication, comme le passage d’un élément de fabrication d’une colonne WIP à une colonne de file d’attente doit correspondre à un contrat passé entre l’équipe qui fournit (à gauche) et l’équipe qui consomme (à droite). L’équipe qui fournit doit se focaliser sur la satisfaction de son client (l’équipe que consomme) et livrer son travail conformément à ce qui est attendu.

Les DoR et DoD définissent ces contrats. Ils stipulent que si un élément est présent dans une colonne de type « file d’attente », c’est que cet élément est dans un état correspondant à l’accomplissement par l’équipe amont d’un certain nombre de tâche sur cet élément. 

Une bonne pratique est d’afficher les DoR et DoD en-dessous de chaque colonne « file d’attente ». Ces définitions ne sont pas figées, et peuvent évoluer avec le temps, en augmentant progressivement le niveau d’exigence.

Emergency Line
Le processus doit pouvoir gérer les urgences. Une équipe doit pouvoir travailler sur une urgence, même si sa limite est atteinte.

On peut dès lors insérer une ligne spéciale (emergency line) dans laquelle ne peut circuler qu’un élément en parallèle. Un élément présent dans cette colonne indique à l’équipe que c’est sa priorité du moment.

Attention toutefois bien définir collectivement ce qu’est une urgence, car beaucoup voudront alors considérer que « tout » est urgent afin de voir leur besoin propre avancer plus vite.


mardi 4 février 2014

Agile Mind Map - l'agilité dans un slide

J'ai été confronté récemment à une question existentielle dans l'animation d'une formation sur l'agilité. Comment résumer l'agilité dans un seul slide ?

(voici un bon sujet pour ce tout premier article de mon nouveau blog!).

Partant du principe que seule une image pourrait synthétiser tout ce qu'il y a à dire sur l'agilité, et ayant récemment participé à un Agile Dojo sur les cartes heuristiques (merci AgilBee et Clément Boye), je me suis donc mis à créer mon Mind Map de l'agilité.



J'ai d'abord restreint la figure à 4 branches principales. Ces 4 domaines sont selon moi indissociables pour parler d'agilité :
  • l'ingénierie et les techniques agiles
  • la culture agile
  • l'individu et l'équipe
  • l'organisation et son management
Chaque branche a fait éclore 4 feuilles. L'ensemble me permet d'aborder en un slide tous les points clés de ce passionnant domaine de connaissance. Voici en substance le discours :

1 - L'ingénierie et les techniques agiles
L'agilité, c'est d'abord des pratiques et des outils pour spécifier, valider, piloter, déployer.

User Stories
Le produit vu de l'utilisateur. Construire une application, ce n'est pas livrer du code en enchaînant des tâches, mais produire de la valeur pour un client.  

Test Driven xxx (Development, Requirement)
Par expérience, c'est un pré requis pour un projet agile. Le métier du développeur ne se résume pas à développer. Il doit aussi comprendre en amont et valider en aval. Associer le test à la démarche de spécification et de développement permet cela.

Backlogs, Burdowns & Cie
Pas de projet sans outils d'estimation, de planification et de suivi. L'agilité, c'est pas free style. Les outils associés à l'agilité permettent de piloter finement et...empiriquement les projets.

Continuous Delivery
L'avenir. Un pipeline continu et automatisé depuis le commit du code jusqu'au déploiement en prod.

2 - La culture agile
Sans culture, la technique n'est rien. Intégrer la culture agile est crucial pour que les pratiques soient réellement efficaces.
Collaboration
Elément essentiel du succès pour tout projet (agile ou non). La collaboration doit être optimale au sein de l'équipe, et avec le client. Le rôle du ScrumMaster ou du facilitateur est ici prépondérant.

Flexibilité
Le changement n'est pas une menace. C'est un bienfait, car il rapproche la flèche (le projet) de sa cible (la satisfaction client).

Transparence
Ne rien laisser sous le tapis. Faire émerger les bonnes idées. C'est aussi le domaine du management visuel, du radiateur d'information. L'information affichée en temps réel, pour tout le monde et tout le temps.

Co-création
Comprendre que la relation client/fournisseur de type donneur d'ordres/exécutant est contre productive. Un projet est une entreprise commune. Un logiciel est une co-création.

3 - L'individu et l'équipe
Un responsable qualité d'une grande banque m'a dit un jour : "l'intelligence est dans le processus, pas dans l'individu." Et bien l'agilité, c'est le contraire.

Bienveillance
Il est indispensable que tout le monde puisse se respecter et s'exprimer, notamment lors des rétrospectives. Là encore, la présence d'un facilitateur (ScrumMaster par exemple) est essentiel pour faire passer le message et créer les conditions de l'émergence des idées.

Autonomie
Le chef de projet qui affecte les tâches et relève les compteurs n'est plus (essayer avec une équipe génération Y !). L'objectif est ici le maintien sur le long terme d'une équipe soudée, qui progresse en maturité et prend des décisions pour elle-même.

Courage
Courage pour exprimer ses difficultés. Courage pour remanier le code. Courage pour admettre qu'on a pris une mauvaise direction.

Engagement
Un projet est une entreprise. Une équipe doit s'engager pour son succès, facilitée en cela par le ScrumMaster. Conscience professionnelle et amour du travail bien fait.


4 - L'organisation et son management
Principal levier. Principal frein aussi à l'agilité. Pour être réellement agile, les organisations doivent se transformer, avec de nouveaux processus, de nouveaux rôles, une nouvelle culture, un nouveau management tourné vers l'innovation et la participation.
Cycles courts et flux continus
Produire plus vite de la valeur en limitant gaspillage. Ne pas stocker (BRUF : Big Requirement Up Front), mais spécifier et faire au moment où le besoin émerge (JIT : Just In Time).  

Amélioration continue
Accepter que l'on ne peut pas tout prévoir, qu'il faudra s'adapter, essayer et apprendre pour s'améliorer. Pas de statu quo. 

Facilitation et coaching
Sans support et accompagnement, difficile de lâcher une équipe dans la nature en leur disant "soyez agile". L'agilité doit être accompagnée, sponsorisée. L'organisation, l'équipe et l'individu doivent être écoutés, aidés. L'agilité n'est pas un Big Bang, c'est une roue vertueuse et progressive.

Management 3.0
Créer les conditions de la réussite individuelle et collective. Etre présent. Impliquer et motiver. Donner.


Voilà ma vision à 360 de l'agilité, comme j'essaie de la pratiquer et de la partager au quotidien. Merci d'avance pour votre feedback, pour partager et s'améliorer...