Achèteriez-vous un pont inachevé?
J’imagine que non.
Pourtant, dans le monde des technologies de l’information, on risque de vous vendre des projets non-terminés. Vous risquez même de vous laisser convaincre...
Les explications en vidéo.
#PME #TransformationNumerique #industrie40
Transcription du vidéo :
Bonjour, Il y a de nombreuses méthodologies de projets dans l’industrie des technologies de l’information. Pour simplifier, disons qu’il y en a 2 approches : Les méthodes dites en cascade, et les méthodes dites agiles.
Dans un modèle en cascade, toutes les activités du projet sont déroulées séquentiellement, chacune ayant pour intrant les livrables de la précédente.
Les spécifications du système doivent être écrites à l’avance, elles doivent être complètes, claires, et formellement validées.
Le projet est totalement planifié d’avance (fonctionnalités-cibles, budgets, calendrier, RH, etc.). Aucune flexibilité n’est possible.
Les demandes de changement en cours de projet sont mal acceptées car les changements demandés peuvent avoir des impacts importants à tous les niveaux (budgets, délais, architecture technique du logiciel).
Rigide, ce modèle est cependant très efficace car tout est balisé à l’avance.
C’est ce modèle qui est utilisé – par exemple – dans la construction d’un pont. On fait les études, on prépare les plans et devis, on planifie tout le projet, et alors seulement on débute la construction.
Dans le modèle agile, on dessine le plan au fur et à mesure qu’on avance dans la réalisation du projet. En fait on ne fait pas vraiment de plan puisque ces méthodes valorisent le fait de produire un logiciel opérationnel plutôt que de la documentation.
Ces méthodologies reposent sur une approche itérative cadencées en cycles de 2 à 4 semaines appelés sprints.
Au terme de chaque sprint, on déploie une nouvelle version du système afin de permettre aux utilisateurs de valider l’adéquation du logiciel avec leurs besoins. La présentation des nouvelles fonctionnalités est faite dans le cadre d’une rencontre appelée démo.
La grosse différence avec les modèles en cascade réside dans le fait qu’on accueille le changement plutôt que de coller à un plan défini à l’avance.
Donc si au cours de la démo, un utilisateur déclare que ce qui a été fait ne répond pas aux besoins, on va refaire cette partie-là.
Et on va la refaire autant de fois que nécessaire… jusqu’à ce qu’elle reçoive l’approbation des utilisateurs.
En somme, au lieu de faire des changements sur plan, on les fait « pour de vrai » dans le logiciel. Ça implique toutes sortes de professionnels de différentes spécialités, et évidemment, ça coûte cher.
De plus, comme en plus on ne définit pas de périmètre de projet, et qu’on de définit pas de date de fin, toutes les dérives sont possibles. La seule limite, c’est votre budget. Et lorsqu’il sera épuisé, on arrête le projet.
Là on vous dira que tout ce que vous aviez prévu en termes de fonctionnalités n’a pas été livré, mais que tout ce qui a été livré correspond parfaitement aux besoins des utilisateurs.
Je vous laisse imaginer la tête des ministres des transports fédéral et provincial devant un nouveau pont Champlain inachevé se faisant dire par l’entrepreneur : Le pont n’est pas terminé, mais tout ce que nous vous livrons aujourd’hui répond parfaitement à vos besoins. En plus on n’a pas dépassé votre budget!
De nos jours, cette approche est proposée presque systématiquement dans les projets informatiques, alors qu’elle est beaucoup plus coûteuse qu’une approche en cascade.
Et selon moi elle ne devrait être proposée que dans les projets qui vont être très longs à compléter (12 mois et plus) car il est possible, en cours de route, que les règles d’affaires changent.
Et là encore, je mets un bémol à ce que je viens de dire car un projet très long devrait être découpé en projets plus petits et avec un périmètre restreint. Ils seront plus faciles à réaliser et ils apporteront de la valeur plus rapidement.
De nos jours, l’agilité est comme une religion. D’ailleurs les différentes rencontres s’appellent des cérémonies. Il y a des dogmes. Il y a ceux qui détiennent la vérité, et il y a les hérétiques. Je fais partie de ceux-là. Si vous êtes un intégriste de l’agilité et que vous voulez me tirer des roches, c’est dans les commentaires que ça se passe.