Ils ont perdu ?? Et oui, durant des années ils ont perdu + de 70% des logiciels qui étaient produits dans le monde. Comment ça se fait ?
Commençons par le cycle en V
Déjà, V n'est qu'une construction théorique qui n'est pas applicable en tant que cycle de vie.
Les mécanismes du cycle en V sont fondés sur le contrôle et le suivi de projet, pas du produit.
les méthodes en
cascade avec le cycle en V ou le cycle en W sont des méthodes dites
prédictives dans lesquelles nous avons une hypothèse de base :
- Nous maîtrisons ce que nous voulons et nous nous engageons à le réaliser.
Un peu radical, non ?
Un cycle de vie est un ensemble ordonné de phases décrivant la vie d’un projet, la phase n ne pouvant commencer que si la phase n-1 est terminée. Dans la représentation graphique du V, les boites s'appellent Spécification, Conception, Codage, Test et Validation pour prendre la variante la plus simple. La signification du nom de ces différentes boites est à peu prés claire : Spécification on décrit le quoi, Conception le comment etc... Il s'agit des disciplines classiques du développement de logiciel.
Considérer que les boites du V correspondent aussi à des phases d'un cycle de vie revient à dire qu'elles se déroulent en séquence stricte : en premier toute la Spécification puis toute la Conception puis tout le Codage puis tout le Test... Évidemment aucun logiciel n'a jamais été développé de cette façon strictement séquentielle. La preuve la plus évidente concerne les travaux de Test. Quand on trouve un bug dans la "phase" de test, le minimum est de refaire des travaux de codage. Dans quelle phase ? Il y a deux possibilités qui débouchent sur une impasse :
- revenir en arrière dans une phase précédente, ce serait remonter dans le temps !
- considérer que pendant la "phase" de test on fait du codage, de la conception, de la spécification en plus du test alors que c'est le nom d'autres "phases" du V, ce serait utiliser le même terme avec 2 significations différente
En cycle en V, les exigences et les scénarios de tests sont gérés par deux processus bien séparés.
- Les exigences pour but de satisfaire le niveau supérieur.
- Les tests sont décrits pour contrôler ce niveau d’exigence. Il n’y a pas de lien, ni de vérification entre les différents niveaux de tests
Les exigences, majoritairement écrites sous forme documentaire, voir avec des outils de type Doors, ne peuvent que retranscrire le comportement statique du besoin. La spécification s’apparente la plus part du temps à un catalogue de règles de gestion, qui pense-t-on, mises bout à bout, vont produire un logiciel.
A l’inverse, les scénarios de tests décrivent l’aspect dynamique et cinématique du besoin : L’approche opérationnelle. Ce que l’utilisateur réel va vraiment pouvoir faire.
Encore une fois, les tests étant fournis après comme contrôle du travail fini, les équipes de développement n’ont donc que l’aspect statique et ne connaissent pas le mode opératoire du logiciel qu’ils sont en train de produire. Le développement est donc piloté par la seule information à caractère statique de se que sera le logiciel et sera sanctionné par un contrôle à postériori.
C’est le pilotage par le contrôle. Incohérent par nature !
Au tour de la hiérarchie MOA / MOE
En France, contrairement à d'autres pays, il y a une tradition qui est de diviser le rôle de Chef de Projet en deux: celui de Chef de Projet MOA (Maîtrise d'Ouvrage) et celui de Chef de Projet MOE (Maîtrise d'Oeuvre) du moins dans le contexte des Grands Comptes.
La MOA étant le client et la MOE étant le fournisseur, on retrouve les comportements typiques suivants: la MOA aura à tendance à en demander toujours plus, la MOE à en proposer toujours moins de peur d'être débordée. Ainsi, des conflits entre la MOA et la MOE surviennent.
Un DSI, dans un article de 01 Informatique, proposait comme solution de supprimer cette division en fusionnant les deux services car le modèle MOA/MOE représentait clairement un frein aujourd'hui dans le rapprochement voulu entre DSI et métiers. Un rapprochement de plus en plus forcé avec l'apparition des solutions SaaS.
Agilité: méthode dite empirique
Un partie de la solution, utiliser des méthodes
empiriques, où la règle est:
- Nous faisons l'hypothèse de base que ne nous ne maîtrisons pas ce que nous allons faire et nous allons essayer d'avancer avec l'incertitude. Pour réaliser cela, il y a 3 piliers fondamentaux (Les Valeurs de l'agilité : source Wikipedia( http://fr.wikipedia.org/wiki/Méthode_agile ):
- la transparence (avoir les informations).
- inspection (inspecter les indicateurs).
- Adaptation (améliorer, réorienter).
Pour les processus Agiles, un cycle de vie est composé d'itérations incrémentales (ou sprints) successives. Voici un schéma pour bien comprendre ?
La aussi, ce que l’on reproche aux méthodes Agiles est leur manque de visibilité à long terme. Et c’est heureusement là qu’elles pourraient bien au contraire vous surprendre.
La grande différence réside dans la construction du backlog. En agile, nous utilisons les user stories : Une définition succincte mais précise des possibilités offertes à l’utilisateur, leur moyen de vérification, ainsi que les critères d’acceptance. Dans ce cas, les scénarios de tests sont fournis comme (seuls ou en complément) des spécifications en entrée de sprint. Des exigences plus fines de type règles de gestion peuvent être définies au cours de la réunion de planification de sprint.
Le développeur est ainsi « formé » à l’utilisation de ce qu’il va produire. Il connaît les objectifs à atteindre. La chaîne de construction se répète tout au long du process jusqu’à l’écriture du code de test avant le code lui-même (TDD), qui participe au maintient de la qualité du logiciel (Intégration continue, tests automatisés).
L’approche est donc radicalement différente.
Agile propose un pilotage par les objectifs.
En bref
Un logiciel, c'est comme produire une voiture, à la différence que le client souhaite constamment customiser son Produit et non son Projet. Cela implique donc des procédés d'ingénieries industriels (PIC, TDD, BDD) pour une réactivité sans cesse accru.
