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

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
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 :

Comparaison des outils de méthodologie logicielle
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.

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.

KPI - indicateur de mesure de la qualité en Entreprise
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 :

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

Avec une page particulièrement qui nous concerne :


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.

CQFD !

Ce qui empêche le mise en place d'une transformation agile

Cela fait plusieurs fois que je trouve ce genre d'article sur les réticences à la mise en place de l'agilité, les coachs agiles, comme un peu frustrés, y donnent leur leçon d'agilité. Je pense que c'est le fait de la société actuelle de ne pas vouloir être agile. Oui car il y a une réelle volonté farouche de freiner l'agilité.

Mise en place de l'Agilité en entreprise

Avant même de lire l'article, je le ressens ainsi car l'agilité prône la liberté des acteurs de l'entreprise. Je peux constater que ce n'est pas le cas, ce n'est pas la volonté de certains que de donner de la liberté dans leurs entreprises. 

D'autre cadre de travail en agilité comme SAFe prône la dilution de la responsabilité vers les équipes. Là encore un "petit chef à l'ancienne", ce n'est pas du tout ce qu'il veut. Il veut des outils pour mieux contrôler, mieux cornaquer ses équipes et cela ce n'est pas tout Agile.

Alors regardons ensemble :
Siècle Digital - 5 caractéristiques empêchant la mise en place d'une transformation agile

L'agilité se définit comme une culture et des valeurs permettant d'être performant dans un environnement complexe. La direction doit s'impliquer dans le passage à l'agilité.

Les quatre verbes : livrer, communiquer, réfléchir, s'améliorer.

Et bien voilà, moi je ne n'ai pas besoin d'aller plus loin car je sais qu'il n'y a plus de culture d'entreprise, les entreprises ne cultivent plus, stressées par la mondialisation, elles ont totalement abandonné l'idée de la création d'une culture d'entreprise.

Voilà, nous venons de voir rapidement les freins à l'instauration de l'Agilité dans l'entreprise.

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é. C'est Florent Barbare avec lequel j'ai eu l'occasion de travailler, nous sommes contacts sur LinkedIn, c'est lui qui me fait part de cette vidéo sur l'agilité que voici :


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.

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 mangement 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 et celui qui construit une cathédrale

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 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 ;-)

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 Dev.

CQFD !

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

Je vais réaliser une série d'articles 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
Méthodologie Scrum en un seul Diagramme
Je vais citer un collègue Blogger le "Chef d'équipe"

Chef d'équipe - Origine de la méthodologie Scrum

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."
 
Le Guide Scrum
À la fin de chaque sprint, l’équipe doit fournir un livrable fonctionnel.

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

C'est quoi la conception DDD (Domain Driven Design) ?

Vous vous demandez ce que peut bien être la conception Domain Driven Design DDD ou la conception pilotée par le Domain en français ? Et bien je vais essayer de répondre à cette question.

Petit préambule intéressant : Vous vous souvenez de la bonne vieille méthode du cycle en V qui met en face à face dans un V les Spécifications d'une part et le Test et la Validation d'autre part,  la conception et les Tests d'intégration etc ... Et bien j'ai lu récemment des articles ayant pour sujet la réhabilitation de ces méthodologies face aux méthodologies agiles.

Comme quoi, il suffit d'attendre assez longtemps et tout fini par arriver.

Alors le DDD c'est quoi ? Encore un truc à la c(bip) pour dégager les vieux codeurs et leur faire croire qu'ils n'ont rien compris.

By Eric Evans - Domain Driven Design Pattern Summaries Word document dddcommunity.org, CC BY 2.5, https://commons.wikimedia.org/w/index.php?curid=9389541
Patterns in strategic domain-driven design and the relationships between them

D'après le Xebia blog la conception DDD lie le fonctionnel et le code (se serait dommage autrement).

Conception DDD

Pour une fois, on ne parle pas de méthodologie, il s'agit bien d'une façon de concevoir le code.

Exemple de DDD : xblanc33/DDDvsJavaBean
Un tour rapide sur la mise en œuvre de la conception DDD c'est brillant d'une très grande clarté.
Je ne peux m'empêcher de citer ici les 3 concepts Utilisé par Xavier Blanc :

Trois concepts à manipuler

Le postulat est le suivant, certes tout est objet, mais tous les objets ne sont pas les mêmes. Il est important de distinguer certains types d'objet : Value Object, Service et Entity.

Un Value Object est un objet qui représente une valeur et même une constante. L’exemple le plus utilisé est celui du point GPS avec la latitude et la longitude. Chaque point GPS est défini par sa latitude et sa longitude. Du coup, aucun intérêt à changer les valeurs (pas de setter).
Un Service est un objet qui offre une ou plusieurs fonctions (stateless si possible). De fait on peut construire un Service, l’utiliser et le supprimer. Un service n’a pas réellement d’état, c’est juste un ensemble de fonctions.
Un Entity est un objet qui est identifiable et qui a un état propre qui va changer. L’Entity est l’objet « noble » de la programmation orienté objet. Par contre, plutôt que des setter, il offre des méthodes métiers qui vont permettre d’exécuter l’application (on choisira des noms explicites pour ces méthodes).

Une fois ces trois concepts connus, le DDD préconise l’utilisation de Value Object et de Service plutôt que d’Entity. En d’autres mots, il faut essayer de manipuler le plus possible de Value Object et de Service.

Encore une fois ces pages pourraient disparaître, je garde donc une trace minimum.

Méthodes Agiles

Pour vous montrer à quel point, côté Agilité c'est foisonnant, voici une page qui présente toutes les méthodes agiles et leurs concepts :

nut&cache - Les méthodes Agiles – La liste complète des méthodologies Agiles

C'est plutôt un ensemble lexicale, on y trouve le FDD : Feature Driven Development (FDD) Le Développement Dirigé par les Fonctionnalités, en français. On parle de modélisation du produit ...

Tout ça est bien joli mais il faut s'accaparer les termes et faire "à sa sauce" en fonction de son expérience (XP).

Qu'avons nous appris ? Pas grand chose que nous ne sachions déjà.

Le DDD et les microservices

Voilà donc deux sujets, fort intéressant du moment, évoqués dans cet article :

donetechno - Les microservices : une architecture Agile — Deuxième partie
Pour connaitre les questions principales sur les microservices, un vrai délire architectural. Plein de questions sur les microservices, l'agilité par rapport aux microservices et finalement pas grand chose sur le DDD (Domain Driven Development).

Un exemple de code sources en C#

Oui, il y en a qui sont allé jusqu'à l'implémentation en C# voici un article en anglais simple et efficace. Voici donc du code en C# réalisé avec une méthode de conception DDD (Domain Driven Development) :

C’était un exemple de code mais il a disparu du net ! Le projet s'appelais QuoteEngine : DoboTEK - Domain-driven design DDD practical implementation in C# .NET


Implémentation du DDD en C#
Visual Studio 2017 - Implémentation du DDD en C#

Peut être que l'on peut retrouver ce projet sur Gihub  à voir j'ai trouvé ça :

Il faudrait retrouver le DDD (Domaine Driven Development) dans ce projet.

Voilà, je ne sais pas vous mais moi je n'ai pas plus d'idée sur le DDD ... disons que c'est une méthode de conception.

Have fun!

Méthode Agile - Résumé

Quel est le meilleur résumé, le plus efficace sur la méthode agile, il y a tellement de littérature sur le sujet, on s'y perd très facilement.

Méthode Agile - Résumé
Alors pour simplifier, voici une page de présentation de la méthode agile :

https://www.agiliste.fr/exemple-dorganisation-projet-agile/

Product Owner est assuré par un membre de l’équipe métier (MOA)
- Alimente et maintient le Product Backlog, et pré priorise les éléments de ce dernier.
- Ajuste les fonctionnalités prioritaires du Product Backlog (candidates au périmètre du prochain sprint) et s’assure que les pré-requis aux développements associés seront disponibles en temps voulu (exemples : décisions métier, jeux de données du SI amont,…).
- Rédige les User Stories associées aux fonctionnalités prioritaires et dessine au besoin des maquettes d’écran.
- Répond aux questions soulevées par l’équipe de développement en cours de Sprint et complète au besoin les User Stories associées.
- Vérifie en cours de Sprint la bonne couverture du besoin des fonctionnalités terminées en collaboration avec l’équipe de développement.
- Rédige les plans de tests.
- Participe à la réunion de revue de sprint au cours de laquelle, elle aide le Product Owner à accepter ou rejeter les fonctionnalités présentées.
- Teste avant mise en production la conformité du produit dans son ensemble.

Scrum Master appartient à l’équipe de développement (MOE)
- S’assure que l’équipe est pleinement opérationnelle et productive.
- Établit une collaboration étroite entre l’ensemble des rôles et fonctions.
- Supprime les obstacles rencontrés par l’équipe de développement.
- Protège l’équipe des interférences extérieures.
- Assure le suivi du processus.

Voilà on arrive à la substance ...

Le DevOps c'est quoi ?

DevOps est LE terme à la mode en ce moment, il faut absolument faire du DevOps alors le DevOps c'est quoi ? Et bien c'est un terme un peu comme ITIL, un ensemble de bonnes pratiques quand on a dit ça on ne peut pas s'arrêter là. Il faut entrer dans les détails, dans tous les détails. Car le DevOps intervient à toutes les étapes du développement logiciel.

Microsoft - Parts Unlimited MRP
Microsoft - Parts Unlimited MRP

Voici le site de Microsoft qui présente chacune des étapes du développement logiciel "à la façon DevOps" dans une simulation complète d'une entreprise de développement logiciel, c'est vraiment top ! C'est vraiment une partie à étudier en profondeur, ce sont les équipes de Microsoft qui ont fait un effort particulièrement important pour nous présenter cet aspect de leur métier, de notre métier, le DevOps.

La simulation est vraiment complète avec un Github. Malheureusement des liens sont cassés ! Avec des cours sur par exemple "Infrastructure as Code" ; Il faut pouvoir coder scripter votre infrastructure pour en conserver une description complète et une trace reproductible et pouvoir la faire évoluer dans le temps plus facilement. Dans ce cas la définition de l'infrastructure devient le script qui devient donc comme une empreinte complète et fidèle de l'infrastructure nécessaire à l'exécution de votre application.

Inutile de vous dire que tout est codé dans le Cloud.

Lors d'un meetup sur le DevOps, j'ai noté également d'autres termes :

Terraform 
Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently.

Meteor

Prometheus
Power your metrics and alerting with a leading open-source monitoring solution.

Value Stream Mapping

Il y a une multitude d'outils à chaque étape du développement qui vous permettent d'assurer le Test & l'Automatisation de chacune de ces étapes quelque soit la chaîne de développement avec laquelle vous travaillez. Il y des passerelles.

Le terme DevOps vient de la volonté de rassembler deux types de ressources de l'entreprise. Les Développeurs et les Opérationnels car les problèmes de l'entreprise qui développe du logiciel ont été identifiés à la frontière des ceux deux services. 

Les Développeurs font des trucs que les Opérationnels ne peuvent pas se permettre devant le client et de l'autre côté des Opérationnels trouvent des astuces pour palier aux problèmes du système qu'ils ne rétrofitent pas aux développeurs.

Bien des problèmes viennent d'une mauvaise communication entre les opérationnels et les développeurs.

Le DevOps c'est une culture, une culture qui doit se répandre dans toute l'entreprise.

Donc si vous êtes un DevOps vous devez pouvoir tout reconstruire à partir de scripts faciles à mettre en oeuvre.

Il y a trop de trucs installé sur la machine du Développeur lors du déploiement de l'application cela va poser des problèmes aux Opérationnels dont l'installation du produit ne va pas fonctionner. Ils devront chercher ce qui manque !

Voilà le DevOps c'est tout cela. Si vous débutez retenez surtout que DevOps c'est un état d'esprit qui vous permet de vous sortir des pièges dans lesquels tombent toutes les équipes de développement qui ne possèdent pas cette culture cet état d'esprit.

Comment devenir un ingénieur DevOps

C'est quoi une Matrice de traçabilité des exigences ?

Voilà mon sujet sur l'amélioration de la qualité ce matin, trouver à quoi peut bien servir une matrice de gtraçabilité des exgigences. Je vais recadrer légèrement en abordant ce sujet du point de vu de la norme : 

EN 62304 Medical device software.

Defines the life cycle requirements for medical device software. Dit comme cela c'est un peu court mais c'est surtout payant :

https://www.en-standard.eu/csn-en-62304-medical-device-software-software-life-cycle-processes/
European Standards - CSN EN 62304 - Medical device software - Software life-cycle processes

Wikipédia nous parle de la La gestion des exigences avec une définition de la traçabilité des exigences.

Définition de la traçabilité des exigences :

S'il on veut être conforme à cette norme, il doit être possible de retracer jusqu'à leur origine chacune des exigences et chacun des changements les affectant ; les exigences doivent donc être documentées pour achever la traçabilité.

Définition de l'exigence :

Les exigences sont l'expression d'un besoin documenté. Facile à dire mais vous verrez combien de clients formuler leurs exigences par orale sans prendre de note et sans documenter. Donc écrire documenter est un point essentiel de la traçabilité.

Matrice de traçabilité :

Il s'agit donc de regarder pour chacune des exigences exprimées s'il on a bien la possibilité de la tracer jusqu'à l'origine.


Pour le reste il faut payer ... c'est un sujet à creuser.

Approche Agile plutôt que méthode Agile

Malgré l'utilisation et l'application stricte de méthodes traditionnelles, on découvre que bien des projets informatiques sont des échecs voir de véritables fiascos. L'apport de l'approche Agile est considérable dans la réussite d'un projet et elle garantie la satisfaction du client.


Méthode Agile
Les causes de l'échec des projets informatique avec l'utilisation des méthodes classiques :
  • Cahier des charges de la taille d'une encyclopédie
  • Pas de place pour l’improvisation, réfractaire au changement
  • Effet tunnel de la méthodologie du cycle en V
A la fin du projet, le client s'étonne de la non conformité aux attentes.


La méthode Agile se concentre sur la satisfaction du client et de l'utilisateur final. Elle favorise le travail collaboratif de l'ensemble de l'équipe de développement.

Cadre méthodologique Scrum

Scrum c'est un package avec le product owner et le scrum master.

Product Backlog : liste des fonctionnalités du produit triées par importance de Valeur Ajoutée ROI

Planning Poker : estimation collaborative des sprints et de leurs difficultés

Sprint Backlog : le comment ?

Stand-up meeting : réunion journalière de 15 minutes, debout pour éviter de s'éterniser

Burndown Chart : courbe d'avancement

Revue de sprint : à la fin de chaque sprint
Rétrospective de Sprint

Assistance à la Maîtrise d'Ouvrage (AMOA)

C'est quoi l'Assistance à la Maîtrise d'Ouvrage ou AMOA ? Pour y répondre je me promène sur le site d'une SSII et je trouve les définitions suivantes :


Description de l'AMOA - Assistance à la Maîtrise d'Ouvrage 
Cette description de l'AMOA est un peu en forme de cycle en V. Avec une descente jusqu'à la phase 3, spécifications, conception, développement et une remonté jusqu'à la phase 6 : Validation puis Support technique et fonctionnel ...

Bref, bien peu d'agilité. Alors peut-on allier cycle en V et agilité ? C'est bien la question.

Littérature :

http://www.eqlhenix.fr/le-metier-damoa
une distinction est faite entre AMOA et AMOE
AMOE : choisie une solution technique et à fabrique/développe les logiciels correspondant au besoin des utilisateurs.
AMOA : décide du lancement d'un projet et qui confie la réalisation à la MOE. Elle est responsable du résultat du projet, assume l'usage du produit et finance sa réalisation.

C'est quoi ITIL ?

Vous vous demandez ce que c'est ITIL par rapport à d'autres méthodologies ? Je vais essayer de trouver les éléments de réponse à cette question.

ITIL c'est un ensemble de bonnes pratiques (best practices) pour la gestion d’un système d’information, édictées par l’Office public britannique du Commerce.
On observe une augmentation continuelle de la demande de services informatiques. Fin 1980 début 1990, le gouvernement britannique (OGC) demande une étude sur les bonnes pratiques de la gestion des services.

ITIL : Informations Technologie Infrastructure Library, ensemble de livres sur les bonnes pratiques de la gestion des services informatiques.

L'activité de mise en oeuvre d'ITIL concerne principalement l'amélioration des processus existants.

Pour se faire :
  • évaluer la maturité des processus existants,
  • s'assurer de l'implication du management pour engager la démarche,
  • s'assurer que les conditions du changement culturel sont satisfaites pour modifier ou améliorer la fourniture des services.
La prise en compte des demandes clients est primordiale.
Il faut assurer la fiabilité des projets dès la conception.

Cycle de vie des projets

Principaux points visés par la méthodologie :
  • Comment organiser une production informatique ?
  • Comment améliorer l’efficacité du système d’information ?
  • Comment réduire les risques ?
  • Comment augmenter la qualité des services informatiques ?
Processus : tâche pendant laquelle des participants produisent des livrables.

ITIL V2 entre 1990 et 2004 produit deux livres :

Service Delivery :
Concerne la planification et l'amélioration à long terme de la fourniture des services liés aux technologies de l'information.

Service Support :
Se concentre sur les opérations au jour le jour et le support aux services.

Fourniture des services (Service Delivery)

Gestion des niveaux de service (SLM Service Level Management)
du financement des services
de la capacité
de la disponibilité
de la continuité
de la sécurité

Pour chacune de ces discipline on observe les points suivants :
les objectifs
le périmètre
les concepts
les bénéfices et les difficultés
la mise en place
les activité
les indicateurs
certains autres points dépendants de la discipline traitée

Service Support

Fonction Service Desk

détection des incidents 
prise des appels 
coordination des actions

Gestion des incidents 

enregistrement des incidents
processus de gestion des incidents
classification escalade et remonté

Gestion des problèmes

traitement des erreurs connues
interrelation entre les processus

Gestion de la configuration

modélisation de l'infrastructure IT
maitrise des éléments de configuration
base de données de gestion de la configuration

Gestion des changements

préparer et valider un changement
traitement des demandes de changement

Gestion de mise en production

cycle de vie et processus de distribution

Ce qui fait le succès d'ITIL

C'est non propriétaire
Non dogmatique

ITIL représente l'expérience et les pratiques cumulées des meilleurs sociétés fournisseurs de services.
Toutes les pratiques citées dans ITIL ne sont a prendre systématiquement comme étant les meilleurs pratiques.

Liens vers ITIL

https://itil.fr/
Le portail des meilleurs pratique ITIL
Il faut s'abonner : https://itil.fr/sabonner

mise à jour 2017
ITIL France

mise à jour en 2020 : www.itil.fr le nom de domaine est réservé mais pas de site correspondant on dirait bien que tout ceci ... est à l'abandon.