Projet

Méthodes agiles : les clefs du succès

Sommaire

Méthodes agiles : les enjeux
Méthodes agiles : la démarche
Méthodes agiles : techniques de mise en œuvre
Méthodes agiles : les principales méthodes agiles
Méthodes agiles : les clefs du succès

Méthodes agiles : les clefs du succès

Voici une présentation synthétiques des clefs du succès des méthodes agiles.

Les méthodes agiles ont démontré à travers de nombreux exemples qu’elles offrent un cadre plus adapté à la réalisation réussie de projets informatiques. Elles doivent donc être appliquées à chaque fois que cela est possible.

De multiples facteurs contextuels peuvent être pris en considération pour valider ou invalider la possibilité d’application d’une méthode agile. Les principaux critères d’éligibilité pourraient être les suivants :

Besoin rapide de mise à disposition du produit
Imprévisibilité des besoins du client
Nécessité de changements fréquents
Besoin de visibilité du client sur l’avancement des développements
Présence de l’utilisateur assurant un feedback immédiat

A l’inverse, il faut savoir détecter les conditions qui peuvent rendre difficile la mise en œuvre d’une méthode agile :

Indisponibilité du client ou de l’utilisateur
Dispersion géographique des ressources humaines
Inertie des acteurs du projet ou refus des changements

Dans ces conditions, les méthodes traditionnelles pourront (peut-être) être une solution plus adaptée.

Catégories : Blog, Méthodologie, Projet

Méthodes agiles : les principales méthodes agiles

Sommaire

Les principales méthodes Agiles

On parle quelquefois de méthode agile (au singulier) ou de méthodes agiles (au pluriel). Si le premier terme désigne le concept qui a été décrit ci-dessus, il existe des déclinaisons en termes de plan de mise en œuvre, de vocabulaire et de préconisation. Ce sont les méthodes agiles (au pluriel) dont voici les principales méthodes agiles :

Scrum

Scrum (qui signifie mêlée au rugby) est aujourd’hui la méthode agile la plus populaire. Elle se caractérise par itérations (appelées sprints) assez courts (maximum 1 mois) et un formalisme réduit : rôles (Product Owner, ScrumMaster, équipe), timeboxes (planification de release, planification de sprint, scrum quotidien, revue de sprint, introspection) et artéfacts (backlog de produit, plan de produit, plan de sprint, burdown/burnup de release, burdown/burnup de sprint)

EXtreme Programming (XP)

L’objectif principal de cette méthode est de réduire les coûts du changement. Elle met l’accent sur la revue de code (faite en permanence par un binôme), sur les tests (ils sont faits systématiquement avant chaque développement), la conception continue (refactoring), la simplicité, la traduction des besoins en métaphores.

XP est souvent pratiqué conjointement avec Scrum.

Rational Unified Process (RUP)

Cette méthode qui peut être considérée comme la moins agile des méthodes présentées ici, est un mélange des pratiques issues des méthodes traditionnelles et des méthodes agiles. Le principe est de parcourir un cycle de vie (inspection, élaboration, construction, transition) durant une itération. Chaque phase du cycle de vie est très précisément détaillée.

Son approche assez lourde et le coût d’investissement de cette méthode la réserve à des projets de grande ou moyenne taille.

Feature Driven Development (FDD)

Moins connue que les 2 méthodes précédentes, FDD est essentiellement axé sur le design et le développement. Pour cela elle s’appuie sur une formalisation du modèle objet à l’aide de diagrammes UML, un découpage par fonctions qui seront développées par des petites équipes responsables d’une ou deux fonctions. Elle accorde un aspect très important à la qualité du produit fini, et s’aide d’outils pour suivre le déroulement du projet.

Rapid Application Development (RAD)

C’est la méthode agile la plus ancienne et celle qui a été la première à être en rupture avec les méthodes traditionnelles. Elle a introduit les notions d’itération et d’incrément. Elle vise à adopter la solution la plus stratégique (en termes de délais), la moins risquée, la plus fiable et la moins coûteuse. Son cycle de développement est simple : cadrage, design, construction et finalisation dans le respect absolu d’une durée comprise entre 90 et 120 jours.

Dynamic systems development method (DSDM)

DSDM est méthode agile développée en Angleterre au milieu des années 90. Elle reprend les principes déjà vus dans les autres méthodes (implication des utilisateurs, autonomie de l’équipe, visibilité et adéquation du résultat, développement itératif et incrémental, réversibilité des modifications, tests continus, coopération des acteurs).

Elle est aujourd’hui moins utilisée que les méthodes précédemment décrites.

Voir aussi l’article expliquant la démarche agile.

Catégories : Blog, Méthodologie, Projet

Méthodes agiles : techniques de mise en œuvre

Sommaire

Pour atteindre les objectifs, les méthodes agiles partagent pour la plupart un ensemble de techniques de mise en œuvre dont voici un aperçu ci-dessous.

Fonctionnement par itérations

Pour intégrer les changements qui peuvent survenir, pour obtenir un retour de la part des utilisateurs ou du client et pour vérifier le bon fonctionnement des modules développés, les méthodes agiles fonctionnent par itérations.

Une itération est un cycle court ou très court durant lequel une partie de l’application doit être développée. Elle doit aboutir à la fourniture d’un livrable applicatif qui permet de constater les travaux réalisés.

Une itération permet également de procéder à des ajustements suite aux retours des précédentes itérations, et d’intégrer des nouveautés pouvant survenir au cours du projet.

Processus incrémental

Chaque itération est bâti selon un processus incrémental qui permet d’enrichir l’application en lui ajoutant des nouvelles fonctionnalités, en affinant les scénarios de tests, et en vérifiant sa bonne intégration dans l’environnement cible.

Un incrément est donc le résultat de la production d’un sous-ensemble de fonctions répondant aux exigences fixées au démarrage de l’itération.

Collaboratif

L’une des particularités des méthodes agiles est de considérer le groupe projet comme une équipe plus qu’une somme de personnes. Les notions de rôles et de hiérarchie sont réduites à leur strict minimum et c’est l’esprit de groupe qui est favorisé. Ce groupe doit partager un but commun : celui de réussir le projet dans l’intérêt de tous.

Ainsi si les notions de MOA, MOE, utilisateur et équipe développement existent toujours, elles travaillent ensemble et de préférence sur un même site.

La composante essentielle de cet aspect collaboratif est la confiance accordée à chaque membre de l’équipe. Les apports de chacun doivent avoir comme unique objectif celui de faire progresser le projet.

Prototypage

L’approche itérative et incrémentale favorise la réalisation d’essais, aussi appelés prototypes, qui permettent de valider une solution ou une approche (en terme d’interface utilisateur) avant son intégration dans l’application.

En effet, la recherche de l’excellence technique pousse à tester des solutions innovantes qui vont répondre aux besoins des utilisateurs.

Pour autant, elles ne pourront être acceptées que si elles ne présentent aucun risque et si leur mise en œuvre ne conduit pas à la réalisation d’une « usine à gaz » (recherche de la simplicité).

Processus d’intégration continue

L’intégration continue est un processus qui vise à intégrer au plus tôt tous les développements réalisés dans la version en cours afin de vérifier sa bonne intégration.

Ainsi, dès qu’une fonction est jugée « finie » (c’est-à-dire développée et testée), elle est mise à disposition dans la version courante.

Ce processus d’intégration continue contient également toute une mécanique visant à tester la version dans son ensemble, et ce de manière automatique et à chaque nouvelle intégration. Les tests doivent donc être automatisée et reproductibles. Ils sont donc définis et développés conjointement aux modules de code.

L’intégration continue est généralement réalisée à l’aide d’outils permettant l’intégration du code, sa compilation automatique pour génération d’une version, et le lancement de tous les tests déjà définis sur la nouvelle version produite. L’automatisation du lancement des tests permet de vérifier le bon fonctionnement de l’application dans l’intégralité de sa version actuelle et l’absence de régressions.

Culture différente

Les méthodes agiles demandent à ceux qui les adoptent de changer leur approche et d’oublier certaines des habitudes acquises avec les méthodes précédentes (accepter le changement, privilégier l’application à la documentation, raisonner uniquement dans l’intérêt du projet, préférer le bon sens aux règles et usages).

Ce changement de culture n’est pas simple à accepter car il entraîne une modification de la position de chaque acteur, une perte de repères et donc une certaine insécurité.

L’adoption d’une méthode agile doit donc être un acte volontaire, accepté dans un état d’esprit positif. C’est l’une des clefs de la réussite du projet qui est à réaliser.

Catégories : Blog, Méthodologie, Projet

Méthodes agiles : les enjeux

Sommaire

Cible et Problématique

Bon nombre de projets informatiques « s’achèvent » avec un bilan peu satisfaisant, pour cause de retard, de dépassement de budget ou de non-satisfaction des utilisateurs. Malgré une expérience forte de plusieurs décennies, ce constat reste malheureusement d’actualité. Pourquoi ?

L’analyse du bilan des projets qui ont connu un échec fait apparaître quelques causes qui sont presque toujours les mêmes :

La confusion entre les besoins estimés et les besoins réels
La forte pression d’un contexte économique ou d’un planning très tendu
Les modalités de forfaits qui figent dans le marbre les spécifications fonctionnelles
La volonté de respecter un ensemble de clauses contractuelles qui font oublier l’objectif initial
Des rapports parfois difficiles entre la maîtrise d’ouvrage et la maîtrise d’œuvre
L’utilisation de méthodes non adaptées ou mal utilisées
Le manque de communication à tout niveau

En réponse à cette analyse, de nouvelles méthodes de conduite de projets informatiques ont vu le jour il y a quelques années. Ce sont les méthodes agiles.

Enjeux

L’importance de la qualité

La définition de la qualité en sens ISO 9000 est la suivante : » Aptitude d’un produit ou d’un service à satisfaire, au moindre coût et dans les moindres délais les besoins des utilisateurs. « .

C’est donc le point le plus important d’un projet et celui doit guider toutes les décisions d’un projet informatique.

La qualité est au cœur des concepts des méthodes agiles.

La maîtrise des risques

L’identification et l’élimination des risques (à défaut leur réduction) sont des tâches qui doivent être traitées en permanence sur un projet informatique. C’est ce qui s’appelle un pilotage par les risques.

Une fois les risques maîtrisés, les facteurs d’échec se trouvent grandement diminués.

Les méthodes agiles consacrent une grande importance à cet aspect comme cela est présenté plus loin.

Renvois bibliographiques :

Scrum – Le guide pratique de la méthode agile la plus populaire (Claude Aubry – DUNOD)

Gestion de projet : EXtreme Programming (Jean-Louis Bénard, Laurent Bossavit, Régis Médina, Dominic Williams- Eyrolles)

UML 2 en action (Pascal Roques et Franck Vallée – Eyrolles)

Wikipédia : Méthode Agile (http://fr.wikipedia.org/wiki/Méthode_agile)

Catégories : Blog, Méthodologie, Projet

Réussir une reprise de données

La reprise de données

La reprise de données constitue une des étapes les plus délicates au sein d’un projet d’implémentation d’un logiciel de gestion. En effet, elle doit souvent être réalisée très rapidement juste avant le démarrage d’un projet. De plus, elle est susceptible de reporter ce démarrage, en cas de problèmes bloquants, ce qui entraîne des coûts supplémentaires.

Or, il arrive très souvent que cette phase pose des problèmes, soit :

bloquants, du fait de données impossibles à reprendre,
consommateurs de charges supplémentaires non prévues (chez le prestataire en charge de la reprise et chez l’entreprise elle-même), en raison de la complexité de la reprise de données, qui a été identifiée trop tard par les acteurs en charge de cette dernière.

Ces problèmes sont principalement dus à l’analyse, qui n’est pas toujours réalisée de façon exhaustive. En effet, il est nécessaire lors de cette phase de mettre en parallèle tous les champs de données du logiciel source avec les mêmes champs au sein du logiciel de destination. Bien entendu, cela nécessite au préalable d’avoir identifié ces champs au sein du nouveau logiciel, soit via l’utilisation de champs existants, soit via la création de nouveaux champs. Or, pour cela, la compréhension du mode de fonctionnement du logiciel source est indispensable.

Jeux de tests

A partir du moment où cette analyse a été réalisée, il s’agit de réaliser en premier lieu un test avec un volume de données peu important (par exemple, 10 % des données à reprendre).

Cela permet d’identifier les principales anomalies, et de les corriger rapidement. Ce test doit avoir lieu au moins 1 à 2 mois avant la reprise complète des données. La date du test est déterminée en fonction du volume des données, ainsi que du délai prévisionnel de correction des anomalies rencontrées.

Ensuite, en fonction de l’importance de ces dernières, un second test peut être programmé.

Ces tests permettent notamment :

de s’assurer que la reprise des données se déroulera dans les meilleures conditions,
de prévoir précisément la durée de la reprise des données.

Dans le cas où des statistiques sont générées dans le logiciel source, il s’agit de procéder aux éditions correspondantes, puis de contrôler dans le logiciel de destination que les données restituées au sein des nouveaux états sont identiques.

Catégories : Blog, Consulting, Méthodologie, Projet

Intégration de progiciels

Un progiciel est un outil de travail au service des utilisateurs et de l’entreprise. Les principaux objectifs de la mise en place d’un progiciel sont les suivants :

optimisation de la productivité de vos utilisateurs,
pilotage de votre activité.

De manière générale, l’implémentation d’un progiciel ne se réduit pas à des phases d’installation et de formation. En effet, il s’agit d’un projet complet comprenant des étapes qu’il convient de respecter, afin d’en assurer la réussite.

Choisir et mettre en place un progiciel

Dans ce cadre, AMJ peut vous assister lors des différentes phases de la mise en place de vos progiciels, en se basant sur une méthodologie éprouvée :

recueil de vos besoins,
rédaction de cahiers des charges,
sélection du progiciel adapté à vos demandes,
maquettage de vos besoins,
établissement d’un planning de mise en œuvre, incluant les charges des différents intervenants,
validation des spécifications fonctionnelles et techniques,
accompagnement du changement,
communication auprès des utilisateurs finaux,
pilotage du projet,
coordination des intervenants au sein du projet,
accompagnement à la reprise des données,
élaboration de plans de recette,
recette de la solution mise en place.

En ce qui concerne le planning, AMJ prévoit aussi bien les charges des intervenants au sein du fournisseur du progiciel que celles de vos chefs de projet et utilisateurs, afin que le planning établi tienne compte des disponibilités de vos équipes.

Le planning doit également comporter des phases distinctes ainsi que des jalons, associés à des indicateurs d’alerte.

La définition du planning permet de maîtriser les étapes du projet, ainsi que les coûts et délais associés.

Par ailleurs, la validation des livrables par vos soins est capitale. Elle permet de s’assurer de la conformité face au projet initial et de s’adapter aux nouvelles contraintes. Cela conduit notamment à optimiser le coût du projet.

Catégories : Blog, Consulting, Méthodologie, Progiciels

Un planning, mais pour quoi faire ?

Le planning !

Qui dit planning dit tenue du planning. Voilà une charge de travail que je vois souvent supprimée ou trop fortement réduite dans bon nombre de projets. Mais au fait, à quoi ça sert un planning ?

Bien souvent le chef de projet (expérimenté) sur des projets de taille moyenne a en tête les tâches à mener et le besoin d’un planning ne se fait pas nécessairement ressentir.

Il est donc bien entendu possible de mener à bien un projet sans pour autant faire un planning.

Cela est principalement lié à la taille du projet et aux risques que l’on accepte de prendre sur le projet.

Dans la catégorie casse-cou (du genre saut du grand canyon à moto), il y a ceux qui réussissent et ceux qui y laissent leur peau. L’expérience montre que ceux qui réussissent sont justement ceux qui vont le mieux préparer et planifier leur action afin d’anticiper les risques et de les prévenir. Et bien dans les projets informatiques, c’est un peu pareil.

Les bonnes questions à se poser

En effet, l’élaboration d’un planning oblige à se projeter dans le futur, à réfléchir aux tâches à mener ce qui amène naturellement des questions :

untel a-t-il bien été prévenu des tâches qu’il va devoir réaliser ?
les ressources disponibles sont-elles suffisantes ?
les ressources sont-elles sous occupées, sur occupées ?
avons-nous bien l’ensemble du budget associé aux tâches ?
l’absence de X sur telle période a-t-elle été intégrée ?
pour mener telle tâche je vais avoir besoin de telle autre tâche qui n’était pas prévue ?
les délais impartis sont-ils réalistes ?
manque-t-il des tâches ?
etc…

Rien que l’exercice de création d’un planning est déjà riche d’enseignement en matière de gestion prévisionnelle d’un certain nombre de risques.

Un outil de communication

Le planning est aussi , il permet de partager la vision des travaux à réaliser avec l’ensemble des intervenants. Il permet à chacun de visualiser ce qu’il doit faire, de vérifier si des tâches n’ont pas été oubliées et si tout le monde a confiance dans le fait de mener à bien les tâches dans les délais prévus.

Avec le planning vient la gestion prévisionnelle des ressources et charges associées. Il est essentiel de pouvoir suivre régulièrement le taux d’occupation prévisionnel des ressources. Le problème ici est qu’il est souvent tentant pour bon nombre de personnes de ne pas vouloir connaître l’occupation prévisionnelle des ressources. A court terme, il est bien plus facile de ne pas se poser de questions sur les problèmes potentiels plutôt que de faire face à la réalité. Dans le meilleur des cas, les ressources concernées vont alerter. Bien souvent, il n’y a pas d’alerte par rapport aux surcharges de travail et ça dégénère car il est trop tard.

L’autre avantage du planning est qu’il permet de suivre l’avancement des tâches. En effet, tout dérapage est susceptible de remettre en cause la date de fin.

Le suivi du planning sera d’autant plus fréquent que l’on va approcher des phases critiques du projet telles que la mise en production par exemple. Plus on approche de la mise en production, plus chaque intervenant doit être en phase avec ses tâche et plus les dérapages potentiels doivent être rapidement détectés pour être corrigés. C’est un peu comme un avion qui s’apprête à atterrir et qui intensifie son échange avec la tour de contrôle à l’approche de la piste.

Enfin, il permet de visualiser immédiatement les impacts d’un dérapage (ou d’une avance) de tâche et de prévenir les personnes concernées.

Bien sûr cette gestion de planning à un coût qui est directement proportionnel au nombre de tâche, de ressources et à la fréquence de mise à jour.

Le planning est donc un instrument de pilotage essentiel et indispensable à partir d’une certaine taille de projets. Inutile de préciser que cet instrument n’est certainement pas Excel.

Catégories : Blog, Consulting, Projet

Comment réussir un cahier des charges fonctionnel ?

Du recueil des besoins au cahier des charges

De notre point de vue, il est essentiel de bien identifier les acteurs qui vont participer à la rédaction du cahier des charges et auprès desquels il sera nécessaire de recueillir les besoins. Ces personnes seront choisies en fonction de leur capacité à identifier et à définir des besoins, ainsi qu’à se projeter dans l’avenir. Il s’agit de personnes qui ont une vue constructive des améliorations qu’il serait souhaitable d’apporter par rapport au fonctionnement actuel.

Bien entendu, ces utilisateurs représentatifs de leurs métiers devront pouvoir dégager le temps nécessaire pour non seulement exprimer des besoins mais également relire des comptes rendus de réunion, lire le cahier des charges et le valider.

Le recueil des besoins est pratiquement un métier en soi. En effet, les utilisateurs ont souvent besoin d’être guidés et la compréhension de leurs besoins doit être constamment vérifiée. Pour cela, diverses techniques peuvent être utilisées comme par exemple :

comparaisons par rapport à ce qui se fait chez des confrères,
workflow,
schémas,
maquettes d’écrans,
Etc.

Dans le cadre de l’expression des besoins, il arrive parfois que certains besoins exprimés soient contradictoires. Il est dans ce cas très utile de pouvoir disposer d’un représentant des utilisateurs qui dispose du pouvoir de décision en cas de désaccord entre les utilisateurs.

« Fonctionnel… »

Pour le démarquer des cahiers des charges techniques, le cahier des charges qui décrit les besoins est parfois également appelé « Cahier des charges fonctionnel ». Cette caractérisation ne doit cependant pas faire oublier tous les autres types de besoins.

En ce qui concerne les besoins, il ne s’agit pas bien entendu que des besoins fonctionnels. Il est essentiel de traiter également de nombreux autres besoins tels que par exemple les besoins en matière de performances, d’ergonomie ou de sécurité.

La qualité des écrits est bien entendu fondamentale dans le cadre de la rédaction du cahier des charges. Le cahier des charges se doit d’être limpide et sans ambigüité. Pour ce faire, il sera agrémenté d’exemples à chaque fois que possible. A ce sujet, AMJ recommande d’établir notamment une charte rédactionnelle qui servira de guide tout au long de la rédaction du cahier des charges.

La présentation générale est aussi importante, elle doit être jolie et agréable et donner envie au lecteur de lire le document. En aucun cas elle doit rebuter le lecteur.

Il ne faut pas non plus confondre le quoi et le comment. En effet, le cahier des charges tout en étant très structuré doit refléter le besoin métier de l’utilisateur (le quoi). Il ne doit pas exposer des solutions informatiques (le comment) mais des besoins fonctionnels ou métiers.

Les pièges à éviter

Certains pièges sont aussi à éviter, il est essentiel de ne pas non plus tomber dans le syndrome de la recherche de la cible fonctionnelle parfaite qui conduit souvent à définir une usine à gaz. Il convient donc de savoir procéder à des arbitrages lorsque nécessaire afin de ne pas trop complexifier les besoins.

Même s’il est important qu’il soit précis et relativement complet, le cahier des charges n’est pas non plus une spécification fonctionnelle détaillée et il convient de savoir s’arrêter au bon moment pour passer à sa validation.

La validation du cahier des charges est un acte très délicat mais particulièrement important. En effet, les cahiers des charges sont souvent des documents volumineux et peu agréables à lire. L’expérience montre qu’ils sont souvent validés sans être réellement lus ce qui peut s’avérer catastrophique pour le projet. Pour que les cahiers des charges soient lus les utilisateurs doivent disposer d’un temps de validation et la clarté du document contribue aussi largement à sa lisibilité. Le fait de solliciter les utilisateurs pour une signature manuscrite constitue un acte d’engagement fort qui contribue à une réelle validation.

Enfin, il ne faut toutefois pas confondre la réussite du cahier des charges avec la réussite d’un projet qui sont deux éléments liés mais très différents.

Catégories : Blog, Consulting, Projet

Pourquoi est-il nécessaire de rédiger un cahier des charges ?

Telle est la question

La question pourrait être la même lorsqu’il s’agit de construire un immeuble, une voiture ou n’importe quel autre objet : pourquoi faut-il faire des plans ? Il faut faire des plans parce que cela permettra déjà de savoir quel est le produit fini attendu et surtout, cela permettra de faire une estimation de coûts et de délais.

En d’autres termes, si votre budget et vos délais sont très extensibles (ce qui est plutôt rare), il est possible de ne pas réaliser de cahier des charges. Cela signifie que vous avez les moyens de payer pour demander aux réalisateurs de

casser tout ou partie de ce qui a été élaboré pour le refaire d’une autre façon. Réaliser un cahier des charges nécessite du temps et de la réflexion. Cela requiert donc un effort et il est en effet très séduisant de penser que par miracle, il serait possible de s’affranchir de formaliser ses besoins. Personnellement, je ne connais aucun métier dans lequel il est possible d’obtenir quelque chose pour un délai et un coût donné sans l’avoir préalablement décrit avec un minimum de précisions.

Si les besoins ne sont pas précisément décrits, le risque est bien évidemment d’obtenir un service qui ne répond pas aux besoins ou qui y répond mais de façon partielle. Comment expliquer et démontrer alors que les besoins attendus ne sont pas pris en compte si aucun cahier des charges n’a été rédigé. Ainsi à la question « Pourquoi est-il nécessaire de faire un cahier des charges ?», il est possible de répondre avec une autre question « Comment puis-je faire pour vérifier que mes besoins ont bien été pris en compte et comment démontrer qu’il existe des manques le cas échéant ?».

Les bonnes pratiques

Ne pas réaliser de cahier des charges va à l’encontre des bonnes pratiques reconnues au plan international. Cf ITIL service design : Identifying service requirements : “The need for accurate and representative information from the business is paramount”.

Il ne faut cependant pas confondre cahier des charges et carcan. Si certains considèrent parfois le cahier des charges comme un carcan trop rigide, ce n’est pas le cahier des charges en lui-même qui est trop rigide mais bien souvent le budget du projet et le délai associé.

En effet, tant que le cahier des charges n’est pas validé, il est toujours possible de modifier les besoins qui le composent (en réajustant le délai de livraison associé). Après validation du cahier des charges, il doit toujours être possible d’apporter des modifications au projet pour autant que cela ait été prévu dans le projet. Ces modifications seront alors à traiter en tant qu’évolutions. Cependant, pour que tout cela soit possible, encore faut-il l’avoir prévu en amont. Ainsi, dès le début du projet, en plus du coût du projet lui-même, il convient de prévoir un coût d’évolutions.

Prévoir que le projet évoluera

Deux grandes erreurs sont souvent commises : le refus des évolutions en cours de projet (après rédaction du cahier des charges) et le refus des évolutions à l’issue de la mise en production. Cela provient essentiellement du fait que l’on pense que les personnes qui rédigent le cahier des charges disposent d’une boule de cristal qui leur permettra de préciser 100% des besoins. Dans la pratique, ce n’est jamais le cas. En 20 ans d’expérience, je n’ai jamais vu un projet aboutir sans un minimum d’évolutions.

Lorsque les enveloppes de budget d’évolutions ne sont pas prévues au début du projet, cela génère systématiquement des tensions entre maîtrise d’œuvre et maîtrise d’ouvrage avec des personnes qui finissent parfois par travailler les unes contre les autres. Or, comment est-il possible de réussir un projet lorsque les parties prenantes travaillent les unes contre les autres au lieu de travailler ensemble ? Bien entendu, toute nouvelle application induit un changement et il existe toujours des utilisateurs réfractaires. Si les évolutions ne sont pas possibles ou trop limitées, ils vont alors trouver là une aubaine formidable pour enterrer définitivement le projet.

Le fonctionnement basé sur la prévision des évolutions s’apparente un peu au fonctionnement des méthodes agiles avec 3 itérations. Une première qui couvre 80% des besoins et qui découle du cahier des charges initial.

Une seconde qui devrait couvrir environ 10% de besoins supplémentaires découverts après la rédaction du cahier des charges. Une troisième qui doit permettre de mettre en œuvre les 10% restants. Ainsi, dans ce type de démarche, le nombre d’itérations est connu et fixé d’avance, ce qui permet un bon cadrage du budget global.

Gérer le risque

Il existe également un risque très important lié au fait de ne pas (ou mal) faire de cahier des charges : il se peut tout simplement qu’une fonction fondamentale ne soit tout simplement pas réalisable avec l’outil de développement retenu. Si cette fonction est identifiée par les utilisateurs alors que 80% du projet est déjà réalisé, tout peut alors être mis à la poubelle… Si le choix d’un outil est généralement fait en amont du cahier des charges, dans le cadre d’une étude d’opportunité par exemple, c’est pendant ou à l’issue du cahier des charges (tant que rien n’a été construit) qu’il est encore temps de changer d’outil de construction si nécessaire. En l’absence de cahier des charges, cette nécessité de changement risque fort d’intervenir trop tard.

Enfin, le cahier des charges permet aussi de détecter si le besoin est suffisamment mûr ou non. En effet, le simple fait de mettre les besoins par écrit permet parfois de détecter des avis divergents ou des changements d’avis intempestifs. Il est bien entendu nettement préférable de traiter ces divergences et incertitudes dans le cadre de la rédaction d’un cahier des charges plutôt que de construire directement pour tout casser ensuite.

Catégories : Blog, Consulting, Projet

Comment décrire un besoin ou comment rédiger un cahier des charges ?

Le cahier des charges

Bien entendu, les utilisateurs peuvent exprimer leurs besoins comme ils le souhaitent. Cependant le document qui servira de référence en la matière correspondra au cahier des charges.

La phase de rédaction du cahier des charges correspond en quelques sortes à la phase dans laquelle sont posées les fondations du projet.

Les phases qui suivent le cahier des charges visent à construire le projet à partir des éléments qui ont été définis dans le cahier des charges. Le contenu du cahier des charges est en ce sens tout particulièrement important.

En effet, l’expérience montre que plus les erreurs produites dans le cahier des charges sont détectées tardivement dans les phases qui suivent, plus leur correction à un coût élevé.

Il est clair que dans la construction d’un pont ou d’un immeuble, il coûte très cher de corriger un défaut dans les fondations lorsque les ouvriers sont en train de faire les finitions ou la toiture.

L’expérience montre également que les descriptions de fonctions souffrent facilement de très nombreux maux lorsqu’elles ne sont pas écrites de façon professionnelle et structurée comme par exemple :

manque de clarté,
ambiguïtés,
absence de traçabilité,
manque de cohérence,
oublis,
etc..

Le cahier des charges se doit également d’être précis. Lorsqu’il existe des imprécisions qui subsistent à l’issue du cahier des charges et des spécifications (ce qui arrive parfois), cela se transforme souvent en source de litige.

La maîtrise d’ouvrage aura tendance à dire « C’était évident ». L’expérience montre cependant que rien n’est évident.

Exemple :

Dans un projet de base documentaire, nous avions demandé un moteur de recherche avancée qui selon le cahier des charges devait permettre des recherches sur mot clés.

Dans la première livraison, le moteur permettait des recherches sur mots clés à condition de tous les saisir dans l’ordre où ils avaient été saisis lors du dépôt du document dans la base. Inutile de préciser que c’était inutilisable.

Dans la seconde livraison, il n’était possible de saisir qu’un seul mot clé dans la zone de mots clés du moteur de recherche avancée. Cette version était déjà mieux mais plutôt très limitée pour un moteur de recherche dit « avancé ».

Enfin, la troisième version fut la bonne.

Le bon équilibre

Bien entendu, le cahier des charges ne doit pas tout préciser. Il ne faut pas non plus tomber dans le syndrome de l’excès de précisions qui risque d’être trop consommateur de temps et de budget. En effet, dans les projets, la hiérarchie attend des résultats concrets et de façon « rapide ». Passer trop de temps sur la phase de cahier des charges agace souvent assez vite les managers, ce qui peut conduire dans certains cas à l’abandon du projet avec pertes et fracas.

La rédaction d’un cahier des charges repose de plus sur un savoir faire qui couvre plusieurs domaines :

savoir cadrer le besoin (objectifs, périmètre,…),
savoir le recueillir,
savoir le comprendre,
savoir trouver le bon niveau de détail,
savoir le formaliser.

Qualité

Enfin, étant donné que le cahier des charges va devoir servir de référence (lors de la phase de recette) pour vérifier si les besoins ont bien été pris en compte et si la qualité est assurée, il doit prendre en compte les grands critères de qualité des logiciels décrits dans la norme ISO 9126 (maintenant intégrée dans la famille des normes ISO 25000).

Autant dire que les risques de défauts dans les fondations des projets sont nombreux si le cahier des charges ne tient pas compte des éléments qui précèdent. Dans la pratique, il est considéré que 80% des problèmes rencontrés dans les applications trouvent leur origine dans la phase de rédaction du cahier des charges (ITIL).

De plus, tous les référentiels de qualité s’accordent pour dire que la qualité se forge le plus en amont possible des projets.

Bien entendu, pour permettre de produire un cahier des charges de qualité qui soit en mesure de servir de fondations aux projets, AMJ a produit un référentiel méthodologique complet qui détaille chacun de ces aspects. De la même façon qu’il existe des techniques pour construire les fondations d’une maison, il existe aussi des techniques pour élaborer les fondations d’un projet.

Catégories : Blog, Consulting, Méthodologie, Projet