Je vous ai déjà parlé de différentes méthodes de gestion de projet. Entre autre, j’ai déjà écrit des articles sur le cycle en V et le cycle itératif, ainsi que sur les méthodes agiles. Ces méthodes, et plus particulièrement les méthodes agiles, sont globalement axées sur la gestion des développements.…
Les spécifications à problème (3) Spécifications qui arrivent après le développement.
Ce billet est le dernier d’une série de trois articles consacrés aux spécifications et à leurs problèmes. Les deux précédents concernaient : l’absence de spécification les spécifications qui changent en cours de développement En image
Les spécifications à problème (2) Spécifications qui changent en cours de développement
Ce billet fait partie d’une série de trois articles consacrés aux spécifications et à leurs problèmes. Le précédent portait sur les développements réalisés sans spécification. Je vous invite à le lire rapidement pour comprendre le contexte. Le troisième article porte sur les spécifications qui arrivent après le développement. En image
Les spécifications à problème (1) Pas de spécification
Il existe 3 grands types de problèmes avec les spécifications. Il y a quelques mois, j’ai préparé une présentation pour expliquer notre nouvelle organisation dans mon entreprise. Dans cette présentation, j’abordais les spécifications, en tentant d’expliquer les conséquences négatives qu’il peut y avoir lorsqu’elles ne sont pas préparées correctement. Pour rendre…
À propos du refactoring
Je vous ai déjà parlé de refactorisation. Voici un retour d’expérience un peu atypique. Ces derniers mois, nous avons procédé dans mon entreprise à un gros chantier de réécriture de code. Ce chantier a été lancé durant l’été, et s’est déroulé de septembre à décembre, avec une mise en production…
Le cycle itératif
Si vous avez lu mon billet sur le Cycle en V, vous savez pourquoi ce type de méthode de travail n’est pas adapté à la plupart des projets informatiques, qui réclament une plus grande souplesse. En l’appliquant de manière rigide, on finit par obtenir des logiciels mal adaptés (fonctionnalités sans priorités), livrés en retard (chaque étape bloque les suivantes) et souvent buggués (la technique se plie au fonctionnel).
C’est ainsi qu’est née la méthode du cycle itératif (ou incrémental), qui tente de formaliser une approche plus pragmatique et maniable.
Définition
Cette méthode se décompose en 6 étapes, dont 4 qui en constituent le « coeur » :
- L’expression de besoin : Le client explique ce qu’il veut obtenir. On peut faire un parallèle avec l’étape de faisabilité du cycle en V, et dans une moindre mesure avec les spécifications fonctionnelles. L’idée reste que les informations en entrée peuvent être modifiées par la suite du processus.
- Le coeur du processus itératif :
- Spécification : C’est la traduction en langage technique des besoins fournis en entrée. C’est la réponse aux questions « qu’est-ce qu’on fait ? » et « comment on va le faire ? ».
- Développement : Il s’agit de la réalisation concrète de ce qui a été défini.
- Validation : C’est l’ensemble des tests qui permettent de s’assurer que le développement effectué correspond bien à ce qui était attendu.
- Évaluation : Cette étape sert à effectuer un retour sur les écueils rencontrés et les fonctionnalités abandonnées pendant les 3 étapes précédentes, et l’utiliser comme informations d’entrée pour un nouveau cycle.
- Déploiement : Les livrables qui ont été validés sont déployés pour que le client y ait accès.
Le cycle en V
Le cycle en V est une méthode d’organisation très connue dont l’origine remonte à l’industrie et qui a été adaptée à l’informatique dans les années 80. C’est l’une des premières méthodes qu’on apprend à l’école, et elle reste toujours d’actualité.
La grande force du cycle en V, c’est qu’il définit assez précisément la manière dont les choses devraient se passer.
On peut y distinguer 3 grandes parties : La phase de conception, la phase de réalisation (codage) et la phase de validation. Les phases de conception et de validation se découpent en plusieurs parties. Chaque étape ne peut être réalisée qu’une fois que l’étape précédente est terminée, ce qui diminue les prises de risque sur le projet.
Ce qui est bien visible sur le diagramme, c’est que chaque étape de conception possède son alter ego de validation. Il devient alors assez aisé de valider un projet, car le référentiel de test est connu très précisément.
Les différentes étapes
Le cycle en V est constitué de 9 étapes qui ont toutes leur importance.