Quels outils pour gérer l'agilité dans un projet logiciel

Il y a un outil dont on parle tout le temps en méthodologie agile pour gérer les projets de façon agile, c'est SAFe. Il y a un certain rejet de SAFe de la part de la communauté des agilistes et c'est normal puisque SAFe est un outil souvent trop contraignants pour conserver de l'agilité.

C'est quoi SAFe ? C'est un Framework Agile (Scaled Agile Framework® - SAFe®) permettant de gérer de très grands projets de plusieurs équipes. SAFe se veut être un outil global dans l'entreprise veillant à ce que toutes les "équipes" de l'entreprise travaillent sur ce qui compte à tous les niveaux.

Avec une petite comparaison Google Trend entre SAFe et Jira avec le terme Agile pour essayer de voir qui s'intéresse à quoi :


Trend SAFe Agile vs Jira agile

On vois l'engouement pour SAFe. Les gens qui se revendiquent de SAFe : Scaled Agile. Trop compliqué, peu clair, finalement il faut prendre un cours suivre une formation. Finalement ce n'est pas très Open Source.

Et puis un post bien fait sur les différents outils qui peuvent vous permettre de gérer vos projet en agilité :

Agilemouse - Quel outil pour gérer notre projet agile ?

Voilà mais faut-il un outil pour gérer vos projets en Agilité, l'agilité c'est une culture, une façon de penser. L'outil c'est un carcan !

Mise à jour de septembre 2020 : Dans mon milieu professionnel, on parle beaucoup de Jira-Confluence. Je refais une petite recherche sur google trend pour voir. Voici ce que je trouve aujourd'hui :

Trend SAFe vs Jira vs Genius

Et bien SAFEs n'est plus du tout la même place, je découvre GENIUS j'avais entendu parler de TRELLO et le méthode Kanban.

Capterra - Logiciels de gestion de projets
Un comparatif mais je trouve que le souci de ce genre de page c'est que tous les logiciels sont au même niveau quelques soit leur importance. Les critères de comparaison ne sont pas ceux qui vous intéressent.

ATLASSIAN - Agile Coach - Qu'est ce que SAFe ?
Pour décrire ce qu'est SAFe mais on y découvrira les freins, le carcan. Evidemment on a besoin de l'adhésion de la Direction, c'est toujours le souci numéro un, l'adhésion des dirigeants.

Scaled Agile - SAFe Lean-Agile Principles
Une somme sur le Lean/Agile tout ce qu'il faut savoir sur SAFe et donc peut être trop contraignant.

Tient cela me rappelle mes premiers cours de qualité logicielle car j'ai participé au sein de la SAGEM à l'élaboration de la Qualité dans les années 90. On a donc écrit des pages et des pages de référentiels de pratiques à adopter. Et je me disais qu'à chaque fois au début d'un projet, il faut définir, ce que l'on va, et ce que l'on ne pas, utiliser dans de la méthodologie logicielle. 

La première tâche sur un projet logiciel, c'est donc de contextualiser par rapport à la méthodologie qui peut être trop contraignante et dire, écrire ce que l'on ne va pas utiliser et pourquoi on ne va pas le faire. L'inconvénient majeur de toutes ces méthodologies, c'est qu'elles sont trop contraignantes. Un petit projet ne se gère pas de la même manière qu'un grand projet, une erreur c'est de vouloir appliquer l'ensemble des préconisations de SAFe à un petit projet.

Méfiez vous des ayatollahs de telle ou telle méthodologie qui voudront appliquer à la lettre tous les préceptes d'une façon dogmatique. Tous les projets sont différents et se gèrent différemment aucune  méthodologie ne peut gérer tous les types de projets.

Mon outil idéal pour gérer un projet avec agilité ... je cherche encore.

En savoir plus sur Jira

Indicateur KPI pour mesurer la performance d'une société en qualité logicielle

On se pose souvent la question de mesurer la qualité d'une entreprise qui développe du logiciel. Et je connais la difficulté qu'il peut y avoir à se lancer dans une telle évaluation. Alors comment savoir si le logiciel développé par une entreprise est de qualité ?

J'ai rencontrer des sociétés qui était obligées d'utiliser du code source sans savoir à quoi il pouvait bien servir mais quand le Responsable logiciel les enlève, le logiciel ne fonctionne plus !

Je me demande si mon indicateur est un bon indicateur. Evidemment plus cet indice KPI est élevé plus la société est mauvaise, l'objectif serait de faire tendre cet indicateur vers zéro.

Cet indicateur ne permet pas à priori de suivre l'évolution de la qualité dans une entreprise. Il ne me permet pas de mettre en place en processus d'amélioration continu. Je le mesure à un instant donné je peux le réduire mais il ne représente pas l'évolution de la Qualité ...

Il faut savoir que ces indicateurs KPI sont classés en trois catégories permettant :

KPI - indicateur de mesure de la qualité en Entreprise

• Équilibration
• Anticipation
• Alerte

Notre KPI doit tendre vers zéro et le rester tout au long de la vie de l'entreprise. Ce KPI trop élevé peut entraîner la mort de l'entreprise. Les décisions à prendre sont alors trop lourdes de conséquences.

Je trouve que ce site est le meilleur et le plus complet pour présenter les KPI :

PILOTER.ORG - Qu'est-ce qu'un indicateur de performance ?

Site informatif et complet sur les indicateurs de performance et pas seulement pour les sites web.

Avec une page particulièrement qui nous concerne :

PILOTER.ORG - Le tableau de bord de la Direction du Système d'Information

Le métier de la Qualité logiciel est primordial au sein d'une entreprise qui développe et commercialise du logiciel (software).

Trouver un indicateur KPI pour un tel type d'entreprise n'est pas une chose aisée. Si vous avez pris soin de parcourir le site de PILOTER.org vous savez que ce n'est pas simple.

Je vous propose comme indicateur de performance KPI : 

Le nombre de lignes de code que la société est encore obligée d'utiliser alors que le développeur qui les a écrites est parti sans les documenter et sans montrer ce qu'il a fait au responsable du développement qui se demande à quoi elle servent ?

CQFD !

Agilité, principes de base par Pablo Pernot

Un fois n'est pas coutume, je vous fais part d'une vidéo sur l'agilité. Ce sont vraiment les bases fondamentales de d'agilité celles qu'il faut absolument connaitre :

Agile Grenoble 2017 - Keynote Pablo Pernot

Comment engager les gens derrière l'agilité ?
Les fondamentaux de l'agilité, agile on ne sait plus ce que cela veut dire réellement

Agile ça veut dire que l'on est dans un monde complexe. Etre agile veut dire évoluer dans ce monde complexe. Comment être performant dans un monde complexe ? On responsabilise.

Suis-je engagé, impliqué ? On responsabilise les gens mais il on le droit à l'erreur. Mais le droit à l'erreur doit être sécurisé donc il faut limiter le champ d'action (sprint). Faire de petites choses priorisées par valeur.

Pour savoir si on se plante ou pas, il faut un vrai regard, un vrai retour sur ce que l'on fait sur des choses finies. Pour ça il faut développer des éléments verticaux, depuis les données jusqu'à l'interface afin de pouvoir juger de l'utilité.

La bascule pour le management c'est le lâché prise. Pour l'équipe produit c'est de ne pas avoir tout, tout de suite.

Comprendre pourquoi il y a une forte implication des joueur dans les jeux vidéo :
Pourquoi mon ex-belle mère me demande une vie à Candy Cruch Saga alors que d'habitude elle ne me demande rien.

Les 4 points clefs de l'implication

• objectif clair (avec du sens)
• règles claires
• feed back (des mesures)
• invitation (pas d'obligation)

Sentiment de contrôle de son outil de travail.
Sentiment de Progresser
Sentir que l'on appartient à une communauté
Les tailleurs de pierre avoir l'impression de construire une cathédrale, ensemble

Se préoccuper en premier du temps et de l'argent, ce sont toujours de faux départs.

Voilà, il est cool Pablo, parfois son discours est un peu trop rodé à mon goût. Il lance des mots pour nous éblouir de sa science sur l'agilité et c'est normal mais cet éblouissement peut nous faire croire qu'il cache quelque chose. En tous cas, on le sens proche de nous avec les mêmes préoccupations du coup on se sent vraiment bien avec lui à côté.

Et à la fin, on a tout compris sur l'Agilité ;-)

C'est quoi le Story Mapping dans le cadre de la méthodoloogie Agile ?

En effet, je vois bien la méthodologie agile, les "users stories" mais précisément le Story Mapping c'est quoi ? Le "backlog de produit" est un ensemble de récits utilisateurs (users stories) que l'on classe par valeur d'affaire (apport de la valeur ajoutée pour le projet).

Le risque de cette organisation en users stories, c'est de perdre les Devs dans des "petites user storie" afin d'éviter cela Jeff Patton - USer Story Mapping a écrit un livre. Il faut retourner au Telling c'est à dire au récit. Il faut faire réciter à l'utilisateur ce qu'il fera lorsque qu'il utilisera le produit afin que chaque dev comprenne bien l'enchainement des "users stories".

ATOMIC OBJECT - Design Thinking Toolkit, Activity 2 – Story Mapping
Ici c'est en anglais mais on sent bien que la maitrise du Story Mapping est là :
But premier du Story Mapping : obtenir les détails qui vont permettre de comprendre "l'expérience utilisateur".

Au passage, on nous donne un outil de création de Backlog : Pivotal Tracker

Référence : Encore User Story Mapping by Jeff Patton and Peter Economy (2015)
Là c'est vraiment un de ces sites qui vous perdent totalement. L'objectif est de vous faire acheter le livre et sinon il y a un tas de vidéo.

MyAgile PARTNER - Story Mapping, bien comprendre sa création
Un bel exemple : un site e-commerce
Il faut bien sûr commencer par rassembler des post-it et un grand espace mural ou tableau de 3 ou 4 mètres de long minimum.

Le Story Mapping c'est

Le Story Mapping c'est donc agencer les "users stories" pour un faire un product backlog c'est à dire une feature réalisable par l'équipe de Développement dans le temps imparti du Sprint.

CQFD !

Qu'est ce que c'est la méthodologie Scrum ?

Je souhaite écrire un article pour faire le tour de la méthodologie Scrum car jusque là, j'y suis allé par de petites touches décrivant ici et là les principes les outils mais il me faut une vision complète de ce qu'est la méthodologie Scrum.

Je ne peux plus faire d'approximation, il me faut faire le tour complet du Sujet.

Méthodologie Scrum en un seul Diagramme

Je trouve la publication du manifeste Agile :

Agile Manifesto

Manifeste pour le développement Agile de logiciels

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Agile Manifesto ou Manifest Agile

Principes sous-jacents au manifeste agile

Nous suivons ces principes

1- Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

2 - Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

3- Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

4 - Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

5 - Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

6 - La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

7 - Un logiciel opérationnel est la principale mesure d’avancement.

8 - Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

9 - Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.

10 - La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

11 - Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.

12 - À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Il s'agit là des douze principes de la méthode Agile.

1 - Travailler en cycles courts ne suffit pas, l'implication exige que le Product Owner pour valider les livraisons soit le client ou l’utilisateur final, sinon cela ne fonctionnera pas.

2 - C'est le principe même de l'agilité, il faut alléger les phases de spécifications et de conceptions en amont car elle évolueront au cours du projet. L'acceptation du changement nécessite une organisation spécifique.

L'organisation en Scrum

Définition :

"Cadre de travail permettant de répondre à des problèmes complexes et changeants, tout en livrant de manière productive et créative des produits de la plus grande valeur possible."

Donc Scrum n'est pas une méthodologie ... Scrum c'est un cadre avec une description des rôles.

Scrum Master : coordinateur des équipes (le guide de l'avancement du projet, gourou ...)

Product Owner : collabore avec le client (le fondateur ou le boss ...)

Delivery Team : les développeurs

Etape 1 : Product Backlog : Analyse des besoins, identification de toutes les fonctionnalités afin de composer les "user stories".

Etape 2 : Le Sprint : répartition des tâches, tier les fonctionnalités sur une durée de deux semaines.

Pour la répartition des tâches on peut utiliser le jeu de cartes avec les points de difficultés, chacun estime la difficulté qu'il aurait à développer la user storie (la tâches ou le use case) c'est le Planning Poker.

Avant chaque sprint : une réunion de sprint planning meeting, c'est une négociation entre le PO et l'équipe pour sélectionner les exigences prioritaires pour le client.

En suite, chaque jour la mêlée (ou stand-up meeting), on fait évoluer le tableau en trois colonnes en racontant :

• ce que l'on a fait hier 
• les problèmes rencontrés la veille
• ce que l'on va faire aujourd'hui

Etape 3 : Sprint Review : chaque semaine ou fin de sprint, avec le Product Owner pour faire une démonstration de ce qui a été créé. Puis le client confirme si la fonctionnalité se comporte comme il le souhaite.

Le Guide Scrum de l'agiliste

Le Product Owner, ou le chef de produit porte la vision du produit c'est un expert du domaine métier

Le Scrum Master doit renoncer au style de management commander contrôler et doit adopter un management participatif.

L'Equipe de développement est pluridisciplinaire et globe tous les rôles

À la fin de chaque sprint, l’équipe doit fournir un livrable fonctionnel.

La mêlée doit faire naitre un esprit d'équipe il ne faut pas qu'elle soit simplement un reporting vers le Scrum master, il doit donc être déjà au courtant de l'avancement car c'est son rôle.

Graph d'avancement ou Burndown Chart : ce que l'on a déjà grillé, bruler comme travail/effort permet de tracer le graphique d'avancement du projet.

La Rétrospective de Sprint : consiste à dire/trouver ce qui aurait pu être amélioré lors du sprint précédent cette réunion participe à l'effort pour l'amélioration continue.

Le Kit Gratuit de l'Agiliste

Conclusion sur le cadre Scrum et l'Agilité

Le cadre de travail Scrum permet/incite à une interaction permanente entre les acteurs du projets, entre le Product Owner et le Client pour valider les nouvelles fonctionnalités, entre le Scrum Master et l'équipe dans un dialogue permanent et journalier et même entre les éléments de l'équipe qui s'expriment les uns devant les autres pour faire part de leur avancement, de leurs difficulté, on est donc dans l'agilité avec une adaptation possible et rapide aux changements éventuels.

Je n'ai pas encore fait le tour, je reviendrai...

Vous souhaitez poursuivre vos lectures :

Claude Aubry - Scrum, Agilité & Rock'N Roll

Vous avez un commentaire, merci de votre participation.