"Storytelling" ou facilitation graphique?

Vous avez peut être déjà constaté qu'il est parfois plus facile de discuter autour d'un dessin, d'un diagramme. Napoléon Bonaparte, ne disait il pas :"Un bon croquis vaut mieux qu'un long discours"?

Ce que certains appellent le "Storytelling" (encore un terme anglais!), est l'illustration par le dessin des propos d'un conférencier. Je vous donne ici un bel exemple, que vous connaissez peut être déjà. Ça va vite (peut être un peu trop!), cela parle de l'éducation, de la pédagogie. C'est intéressant dans la forme et le fond: https://www.youtube.com/watch?v=zDZFcDGpL4U

Si ce format aide à la compréhension et à fixer les idées, cet exercice n'est évidemment pas à la portée de tout un chacun. Vous avez aussi remarqué que la vitesse du dessin était bien supérieure à ce qu'il est possible de faire en temps réel.

Heureusement il est possible d'utiliser un outil plus simple, plus accessible, que l'on appelle la facilitation graphique. Le principe est de dessiner au fur et à mesure, lors d'une réunion, en fonction de ce qui se dit, afin de donner une représentation graphique des propos, des idées. Celui qui dessine, le facilitateur, le fait évidemment sur un tableau visible de tous.

Le niveau de dessin requis n'est pas important, ce qui est rassurant, car la plupart d'entre nous ont arrêté de dessiner vers 10 ans. Il ne s'agit pas de dessiner bien, mais de dessiner de façon sommaire afin d'illustrer ce qui se dit. D'abord parce que la parole va très vite, mais aussi parce qu'un dessin schématique suffit pour donner suffisamment d'informations.

Cela demande au facilitateur une bonne capacité d'écoute, et un peu d’entraînement. Celui-ci peut aussi écrire si c'est plus simple, plus compréhensible, mais il vaut mieux qu'il se limite à quelques mots.

Il est très probable que ceux qui n'ont pas été présents à la réunion, trouverons difficile de savoir tout ce qui s'est dit en regardant simplement le dessin. Mais là n'est pas l'objectif. La facilitation graphique est intéressante pour la réunion, et ne dispense pas d'écrire un compte rendu. Elle permet d'aider à clarifier un propos, mais aussi de venir en aide aux personnes qui peinent à exprimer leurs idées, ou même à s'exprimer par timidité. Enfin elle peut donner une vision plus complète du sujet abordé, pour peu que la ou les pages de dessins soient toutes rendues visibles en même temps, au besoin en les fixant sur un mur côte à côte.


Un site intéressant pour en savoir plus sur les différentes formes de facilitation, mais là les dessins sont d'un autre niveau: http://www.fgcp.net/techniques-et-medias/

Quelle méthode de gestion de projet choisir ?

La situation

La méthode classique de gestion de projet utilisée en informatique est issue du bâtiment. Elle suit le cycle en V dans lequel on définit un cahier des charges, on rédige des spécifications, puis on définit l'architecture, on fait le développement, les tests, la validation, on fait la recette et le client dit ainsi  si cela lui convient ou pas. Il existe une variante, le cycle en Y qui dissocie le fonctionnel du technique, mais fondamentalement on reste sur un fonctionnement où une fois que le client et son fournisseur se sont mis d'accord sur le cahier des charges avec le coût et les délais correspondants, le projet est lancé et ces bases ne sont plus censées varier.

Le Standish group publie depuis plus de 20 ans une étude appelée « Chaos computer » qui indique le pourcentage de projets réussis, en échec ou en dérive. Un projet réussi est un projet où les fonctions et caractéristiques attendues, ainsi que les délais et le coût répondent aux attentes initiales du client et du fournisseur. On constate que la proportion de projets réussis oscille entre 25 et 33 % et que les projets stratégiques ont encore moins de chance d'être réussis car beaucoup sont interrompus avant la fin (http://rapportsalzman.blogspot.fr/2012/05/la-gestion-de-projet-peut-mieux-faire.html).

Les raisons de ces échecs sont multiples : incompréhensions, retards, besoin du client qui évolue, changements de spécifications diverses, risques techniques et humains, manque d'outils de suivi adaptés, études amont insuffisantes... Certains projets connaissent le redouté effet tunnel:  des quantités importantes de développements restent à réaliser, et les échéances ne cessent d'être repoussées, jusque parfois à ne plus donner de date de sortie du tout.

Si l'on décide longtemps à l'avance les services, les fonctions que l'on veut offrir, il se peut bien qu'à la mise sur le marché, cela ne corresponde pas ou plus aux attentes des consommateurs / utilisateurs. Il se peut aussi que l'on n'ait pas une vision totalement claire de ce qui doit être fait dès le début. Souvent certains points ne seront affinés que durant le projet. Hors avec l'accélération de l'évolution des marchés, particulièrement depuis l'arrivée d'Internet, une grande réactivité et une bonne vitesse d'exécution des projets sont encore plus nécessaires.

Lorsqu'un changement, une décision qui en remet en cause d'autres, intervient tard dans le processus de développement d'un logiciel, son coût s'accroît de façon exponentielle. En effet, non seulement une partie du cycle devra être re-parcourue (architecture, développement, tests, validation,...), mais en plus le nombre de personnes impliquées sera d'autant plus grand que ce chemin sera long. Il en va de même pour tout bug trouvé.

Hors les méthodes de gestion de projet classiques sont peu ouvertes au changement et elles n'empêchent pas l'effet tunnel. Le Processus Unifié tente de résoudre le problème avec les itérations et les incréments. L'itération est la possibilité de reparcourir une partie du processus: par exemple en mettant à jour l'architecture alors que l'on était dans le développement proprement dit. De même, le projet peut être découpé en sous-projets qui conduisent à autant d'itérations exécutées les unes après les autres, et qui cette fois-ci parcourent chacune tout le cycle. On fait donc des livraisons successives incrémentales qui correspondent à l'ajout d'un sous-projet à chaque fois. Enfin le Processus Unifié, en se centrant sur l'architecture et la réutilisabilité, entend réduire les coûts.

Ces méthodes restent toutefois assez rigides et ne permettent pas de réduire les coûts de façon significative en particulier lors d'un changement de spécification qui intervient tard, ou de bug rencontré.

Quelques méthodes agiles

Face à ce constat, Kent Beck a créé une méthode appelée eXtreme Programming (XP) qu'il a appliquée dès 1996. L'idée est d'accueillir le changement, de permettre des prises de décision tardives, mais aussi, de reprendre toutes les bonnes pratiques du métier qui ont pu être expérimentées, et de les appliquer dans un développement informatique. Cela a donné en particulier:

• le jeu du planning pour évaluer et planifier les tâches à réaliser pour une itération.
• la recherche constante de la simplicité (analyse de la valeur).
• la programmation en binômes.
• le refactoring: afin de favoriser la simplicité, la maintenabilité et la fiabilité, on n'hésite pas à refaire une partie du logiciel, à revoir l'architecture, à supprimer le code mort ou redondant.
• l'automatisation des tests pour contrôler la qualité et maîtriser toute dérive.
• l'intégration continue pour éviter les intégrations qui n'en finissent plus mais aussi pour permettre le test régulier de la livraison complète, et ainsi contrôler toute régression.
• la mise en production le plus tôt possible pour valider le logiciel et avoir des retours.
• le stand-up meeting, qui est la réunion quotidienne d'avancement de l'équipe. Celle-ci se fait le matin et dure 15' maximum!

Une des grandes forces d'XP est que l'ensemble de ces pratiques se renforcent. Par exemple, une conception simple simplifie les tests, l'intégration, les livraisons, les retours. Le logiciel est décrit en scénarios (user stories) de petite taille plutôt qu'en fonctionnalités. Ainsi le parcours du cycle de développement est rapide, et on contrôle l'évolution du logiciel. Par conséquent le coût de tout changement de spécification est réduit.

La présence du client est requise au sein de l'équipe ! Ainsi il peut répondre à toutes les questions, clarifier ses demandes. Le client pilote davantage le projet, car on lui fait clarifier au fur à mesure ce qui doit être développé, on le fait choisir ce qui est prioritaire pour lui, ce qui donne le plus de valeur au produit à ses yeux. Le client voit ce qui est réalisable et réalisé par l'équipe à chaque itération. Tout cela contribue à construire une véritable relation de confiance avec lui.

Scrum est une méthode née officiellement en 2001. Cette méthode est faite pour tout projet technologique et donc pas seulement logiciel. 3 rôles principaux sont décrits: le Product Owner qui dit ce qu'il souhaite voir implémenter, l'équipe de développement, et le ScrumMaster qui agit pour améliorer le processus, le produit, le fonctionnement et le niveau de l'équipe.

Comme dans XP, on travaille à optimiser la prise en compte de tout changement afin d'en réduire le coût et de maximiser la valeur du produit. Les livraisons se font régulièrement à l'issue de chaque itération appelée sprint, ce qui contribue à éviter l'effet tunnel. Scrum intègre des pratiques du Lean et d'XP. Par exemple:

• La mêlée quotidienne correspond au "stand-up meeting" d'XP.
• Le tableau kanban qui permet de visualiser l'étape dans laquelle se trouve un scénario utilisateur où user story (A faire/En cours/Terminé), vient du Lean. 

De plus, en informatique, il est recommandé de reprendre des pratiques d'XP comme l'automatisation des tests et l'intégration continue.

Kanban est une méthode qui date des années 50, qui fait partie des pratiques du Lean. Si elle a été utilisée en premier lieu dans l'industrie automobile, elle est aujourd'hui mise en œuvre dans l'informatique. Cette méthode se concentre sur la gestion du système de production, afin d'en optimiser la capacité et de livrer en continu des éléments de travail (fonction, bug fix,...). Cela commence par formaliser le processus de production. Kanban utilise le management visuel notamment en mettant en place dans la salle de l'équipe, le tableau kanban visible de tous, qui indique ce qui est planifié, en cours et réalisé.

Un des changements les plus radicaux est le passage au flux tiré : désormais l'équipe ne prendra une nouvelle tâche que si elle en a la capacité, le but étant de faire des livraisons régulières et d'optimiser l'efficacité de l'équipe. Il n'y a pas d'itération planifiée comme avec Scrum. Kanban s'adapte bien aux projets en maintenance ou aux longs projets de développement. On peut envisager son utilisation pour une activité de support.

Enfin Scrumban est une combinaison de Scrum et de Kanban : on utilise Kanban pour la gestion des user stories et pour fluidifier la production. On garde la gestion par itérations/sprints, mais on détaille les différentes étapes par lesquelles chaque user story passera. On dessine donc un tableau, avec une colonne par étape, par exemple avec les colonnes: A faire, Développement, Intégration, Validation, Fait. Cela permet de détailler le processus de production, parfois même de le formaliser! C'est aussi très utile pour détecter et prévenir des situations de famines ou de surcharge dans une étape.

Scrumban est recommandé par rapport à Scrum, si l'équipe contient des personnes spécialisées dans des domaines particuliers (3D, tests, par exemple). Le logiciel peut aussi imposer que certaines étapes soient gérées par un nombre très restreint de personnes à la fois, comme pour l'intégration par exemple.

Conclusion

De plus en plus d'entreprises optent pour une méthode agile pour éviter l'effet tunnel, et améliorer les chances de rentabiliser leurs projets. Cela nécessite des compétences: les équipes doivent être formées, et les rôles définis par la méthode choisie, doivent être respectés. En effet les rôles et les processus diffèrent de ceux auxquels on est habitué.

Les méthodes agiles sont adaptées dans un contexte changeant où certaines décisions peuvent être prises tardivement et peuvent éventuellement en contredire d'autres. La méthode choisie peut ne pas être adaptée, par exemple à cause de la taille de l'équipe: avec XP l'équipe de développement ne dépasse pas les 10 personnes.

Il s'agit de rester pragmatique avant tout. Certaines pratiques peuvent être mises en place très rapidement. Mais il y a un réel changement culturel à opérer, et la migration vers une méthode agile n'est pas instantanée, ni semée d'embûches, aussi il vaut mieux être accompagné dans cette démarche.

Développer sur plusieurs plateformes mobiles

Les OS nomades

Si dans le marché de la mobilité les terminaux Android et iOS (iPod, iPhone, iPad) restent les vedettes incontestées, dans le domaine des smartphones, Windows phone de Microsoft n'est pas forcément à écarter, ni Blackberry même si on peut s'interroger sur la pérennité de ce dernier.

On retrouve à peu près les mêmes OS dans les tablettes tactiles et les smartphones, même si Microsoft propose deux OS différents : Windows 8 pour les tablettes et Windows phone pour les smartphones. Pourtant la frontière entre ces deux mondes est de plus en plus floue en particulier depuis l'arrivée des fablets (ou phablets), qui sont des smartphones avec une taille d'écran entre 5 et 7 pouces.

Certains OS sont dérivés d'Android, comme Amazon Fire OS, qui est une adaptation par Amazon pour ses tablettes et son smart phone (http://en.wikipedia.org/wiki/Fire_Phone). Sans aller aussi loin, les constructeurs qui utilisent Android ont aussi des spécificités qui peuvent aller  au delà de la taille et de la résolution de l'écran. Aussi, lorsque l'on envisage le test d'une application, on ne peut pas se contenter de faire les tests uniquement sur la plateforme de développement.

Selon l'OS retenu, la plateforme de développement n'est pas la même et les coûts non plus (licence développeur, matériel). Par exemple:

• Apple fournit X-Code qui ne fonctionne que sous MacOS. Il faut donc posséder un Mac et s'acquitter d'une licence d'au moins 99$ par an pour pouvoir tester sur iPod, iPhone ou iPad, et publier sur l'App store.
• Pour Android, Google fournit ADT qui est un environnement basé sur eclipse. Celui-ci n'est pas lié à un OS spécifique (Windows, Linux, ...). La licence est de 25$, pour pouvoir publier les applications sur Google Play.

Chaque plateforme a son ou ses langages de prédilection, par exemple Objective C pour iOS, Java pour Android, Java pour Blackberry, et pour Windows Phone VB.NET, C#,...

Notez qu'Android possède l'avantage de permettre à une même application d'adapter automatiquement son affichage au terminal avec la technologie des fragments. Avec iOS, il faut développer une interface spécifique pour chaque type de terminal ce qui a un coût supplémentaire.

Que choisir ?

Selon le marché ciblé, on peut être amené à choisir un OS particulier. Souvent on développe une application pour un OS, puis on développe l'équivalent pour un autre OS. Néanmoins, il est possible de faire un développement qui s'adaptera en grande partie aux différents OS et aux différents types de terminaux. C'est ce que permet notamment Apache Cordova (http://cordova.apache.org/).

Le principe est que l'on développe l'application cliente comme une application WEB, en utilisant les technologies similaires : HTML5, JavaScript, CSS3, le tout en intégrant vos librairies JavaScript favorites (jQuery, Mojo, ...). Puis on génère l'application pour l'OS cible. Il est même possible de faire du « responsive design » autrement dit d'avoir une application qui s'adapte à l'écran du terminal en termes de surface et de résolution.

Possibilités et limitations

Si utiliser Apache Cordova peut permettre de gagner du temps, il vaut mieux regarder de plus près les restrictions.

Tout d'abord on ne peut accéder à toutes les fonctionnalités de chaque OS. Par exemple la gestion de système de fichiers étant totalement différente sous Android et iOS, il ne sera pas possible de gérer des fichiers dans l'application à moins de faire des développements spécifiques ou d'opter pour un contournement, comme l'utilisation d'une base de donnée (SQLite dans les deux cas) pour stocker les données.

L'accès aux APIs spécifiques de chaque OS, se fait via des plugins. Néanmoins, il n'existe pas forcément un plugin pour chaque API dont on a besoin. Les applications doivent donc être assez simples.

Apache Cordova permet de développer des applications avec une interface de type WEB, donc assez passe-partout non spécifique à l'OS. Si vous voulez respecter l'ergonomie propre à chaque OS, il faudra faire des développements spécifiques.

Enfin les applications conçues avec Cordova seront moins rapides qu'un développement natif, qui lui, sera bien plus optimisé. Donc pas question de faire d'animation trop évoluée, de faire des jeux, ou d'utiliser intensivement les capteurs du terminal. Un accès simple à un CMS, par exemple, est plus adapté.
 

Le test des applications

Le test sur chaque plateforme cible est fortement conseillé car une même application ne se comporte pas totalement de la même façon selon l'OS mobile mais aussi selon la marque du mobile. Par exemple sous Android, les constructeurs peuvent ajoutent ou implémentent des couches qui leurs sont propres. Il peut donc y avoir des bugs et des comportements spécifiques à la version d'Android mais aussi au constructeur.

Si on automatise les tests, ce qui est aussi conseillé, il faut noter que les frameworks de tests proposent en général le support d'Android et d'iOS. Attention toutefois, car certains ne s'exécutent que dans le simulateur de terminal qui s’exécute sur la plateforme de développement... Hors ces tests qui tournent sur un PC ou un Mac même s'ils sont utiles, ne garantissent pas à 100% la bonne exécution et le bon rendu, sur les appareils cibles.

Conclusion

Un framework comme Apache Cordova qui permet de développer « une fois » pour plusieurs plateformes, peut s'avérer être un choix judicieux pour une application avec une interface de type WEB. Il convient de tenir compte du contenu fonctionnel de l'application à développer, des performances requises, et de l'ergonomie souhaitée.

Des développements spécifiques peuvent être nécessaires pour s'adapter correctement à chaque OS cible. Dès lors, si on gagne du temps en faisant des développements communs aux OS, il faudra quand même avoir des sous projets spécifiques à chacun et faire les tests correspondants.

La problématique se pose aussi en termes de compétences. Car Apache Cordova nécessite des compétences WEB et mobile. Hors en cas de développements spécifiques selon la plateforme, il faudra que les développeurs connaissent suffisamment chacun des OS et langages associés.

Une évaluation préalable est donc nécessaire pour déterminer l'intérêt d'un tel type de framework par rapport au projet de développement ainsi qu'à l'entreprise. On pourra ainsi choisir en connaissance de cause soit de faire autant de développements entièrement spécifiques à chaque OS cible, soit d'utiliser un framework comme Apache Cordova.

Quelques liens pour aller plus loin:

http://www.nextinpact.com/news/89231-android-ecrase-marche-smartphones-tire-par-succes-forks.htm

Les parts de marché des OS
http://www.zdnet.fr/actualites/chiffres-cles-les-os-pour-smartphones-39790245.htm

Responsive design / Responsiveness
http://www.wired.com/2013/11/responsive-html5-apps-write-once-run-anywhere-where-is-anywhere/
http://fr.wikipedia.org/wiki/Site_web_adaptatif

98% des applications Android tournent sur Blackberry:
http://www.blackberry-fr.com/blackberry-10-98-applications-android-compatibles/

2) Réécrire un logiciel de A à Z ou ne rien faire, où comment sortir du statu quo

Qui va le faire et comment ?

Est-ce le manager qui va décider de tout ? Comment va t-il obtenir les mesures attendues ? Qui est le plus pertinent pour indiquer une amélioration et son ROI ? Comment trouver le temps et l'argent pour mettre en place des améliorations ? Comment s'assurer qu'une amélioration a produit le bénéfice attendu ?

Pour avoir la liste des améliorations et mesures, appliquons un des principes du Lean : impliquons les personnes de l'entreprise qui subissent en premier lieu les conséquences de la non qualité. Ceci peut concerner toute la chaîne de production jusqu'au support et à l'exploitation.

On procédera ainsi par une phase d'initialisation pour dégager des axes d'améliorations avec une évaluation des ROIs. Pour réussir notre démarche, et obtenir une bonne adhésion des personnes, il est important de s'inscrire dans le temps. Une possibilité intéressante est de mettre en place des cercles de qualité.

Dans un second temps, les cercles mettrons en place des améliorations conformément aux objectifs fixés, en procédant pas à pas et en mesurant l'efficacité des mesures prises. Ceci contribuera à sécuriser les investissements, à rassurer le management en donnant de la visibilité, ... et à initier une culture de l'amélioration continue.  

Le cercle de qualité

Un cercle de qualité est un petit groupe de 3 à 10 employés, qui se réunit régulièrement afin de chercher et de trouver les moyens d'améliorer qualitativement et quantitativement la production, ainsi que les conditions de travail. Ces personnes peuvent appartenir à une même équipe, au même service ou simplement avoir des préoccupations professionnelles commune.

Voici quelques caractéristiques du cercle de qualité:

• Le cercle est constitué sur la base du volontariat!
• Le cercle a un responsable et animateur comme dans toute réunion. C'est lui qui fixe les objectifs.
• La réunion est limitée dans le temps et se fait de façon périodique, par exemple, une heure tous les 15 jours.
• Le cercle travaille sur des problèmes rencontrés par ses membres ou par d'autres acteurs ou équipes.

Les problèmes doivent être circonscrits et concrets. On essaye un nombre très restreint d'améliorations à la fois. Cela permet d'en mesurer les bénéfices isolément avec le minimum de perturbations.
Afin de valider les améliorations, plusieurs méthodes sont possibles, dont:

• Le PDCA (où roue de Deming) : Chaque fois que l'on décide d'une amélioration (Plan), on la met en place (Do), on mesure si celle-ci apporte le bénéfice attendu (Check) et on valide l'amélioration ou au besoin on décide d'actions correctrices (Adjust / Act).
• Le PDSA: quasi identique au PDCA à ceci prêt qu'il est adapté aux cas où il est difficile de prévoir les effets de l'amélioration. Ici le « S » correspond au terme Study : on étudie l'impact de l'amélioration sur la chaîne de production.

Il y a donc une réelle autonomie de fonctionnement qui ne doit pas faire oublier de donner de la visibilité sur les actions menées, en particulier si on pratique le PDSA.

Les bénéfices sur le plan humain sont nombreux : meilleure communication, satisfaction de contribuer à l'amélioration et d'en constater les fruits, amélioration des compétences, cohésion des équipes, motivation... Ceci ne peut que rejaillir positivement sur l'efficacité de l'équipe.

La mesure du gain

En même temps que le choix de l'amélioration est fait, on définit les caractéristiques de l'échantillon, c'est à dire l'unité de mesure, la façon dont on va mesurer, et l'endroit où on va mesurer. On peut définir aussi la façon dont on va convertir la mesure en coût si on souhaite en avoir un.

Il est important d'envisager les outils à utiliser pour fiabiliser et faciliter la mesure. Cette tâche peut être rébarbative ou astreignante. Par exemple, mesurer le temps que prends une tâche peut être difficile en soi, parce que d'habitude on ne le fait pas. Les oublis, les mauvaises mesures peuvent être courants. Dans ce cas, il vaut mieux disposer d'un décompte automatique du temps passé voire d'une sauvegarde de ces résultats.

D'autres mesures sont plus complexes: si on supprime des documentations obsolètes, et qu'on centralise les documentations d'un même produit alors qu'elles étaient jusqu'ici dispersées à de nombreux endroits, on devine qu'il va y avoir un bénéfice, mais comment le mesurer ? On peut lister les cas où du temps a été perdu parce que la documentation était obsolète ou qu'elle était difficile à trouver et tenter de l'évaluer. La mesure en tout état de cause risque d'être imprécise car liée à la mémoire des personnes. La récurrence du problème sera un critère important.

Conclusion

Refaire entièrement un produit ou ne rien faire? Souvent le choix ne semble se limiter qu'à cette alternative. Pourtant il est possible de sortir de cette logique par la mise en place d'une véritable stratégie d'amélioration continue qui tient compte du contexte du projet et des objectifs de l'entreprise. Cela suppose que l'on a évalué les enjeux humains, techniques, commerciaux,... et que l'on est prêt à faire un minimum d'investissements en cohérence avec ces enjeux.

Les bénéfices seront d'autant plus grands que l'on considérera non pas une équipe isolée mais l'ensemble de la chaîne de production. Les améliorations toucheront à l'humain, à l'organisation, à la technique et par ricochet d'autres projets. Le tout se fera avec des investissements raisonnables, étalés dans le temps. Le calcul du ROI permet de justifier les améliorations envisagées en vue de  déclencher les investissements. Son usage à posteriori sert à en faire le bilan.

Il est indispensable de disposer d'un outil adéquat afin de conduire cette démarche. L'utilisation des cercles de qualités en est un, excellent. Toutefois cela demande un changement de mentalité, car on passe à un management participatif.

Ainsi en partant des seuls enjeux d'un produit, on peut arriver à sortir du statu quo, et progressivement à s'inscrire dans un cercle vertueux dont les bénéfices dépasseront largement le cadre initial.

1) Réécrire un logiciel de A à Z ou ne rien faire, où comment sortir du statu quo

Introduction

Vous avez peut être déjà été confrontés au choix de ré-implémenter un logiciel de taille conséquente soit de zéro, soit de le faire évoluer. La facilité ou la difficulté de faire évoluer un logiciel dépend de plusieurs critères :

• l'architecture plus ou moins pertinente et sa complexité,
• la façon dont le code est écrit, documenté,
• les librairies utilisées qui peuvent être obsolètes et plus supportées,
• la couverture de tests (idéalement automatisés),
• les diverses documentations du logiciel (installation, exploitation, guide utilisateur...).

Une évolution sur un logiciel ancien peut s'apparenter à un jeu de mikado, où régressions et instabilités peuvent surgir parfois assez facilement. 

Quels sont les enjeux ?

Si le produit est vraiment en fin de vie, et que l'on prépare son successeur dans une autre équipe pourquoi ne pas le laisser tel quel ? Cela peut se justifier si les technologies sont très différentes (passage de .NET à Java par exemple), mais attention toutefois à la phase de transition et de migration pour les clients, qui risque d'être longue, voire de ne jamais se faire pour certains !

Si le produit logiciel est sur un marché à potentiel intéressant, le ré-implémenter de A à Z peut conduire à une perte de marché. En effet, pendant une période significative, le nouveau produit ne sera pas disponible. L'ajout de nouvelles fonctionnalités augmentera d'autant les délais. Hors plus la sortie du produit sera tardive, et plus il est probable qu'il y ait des pressions pour intégrer des évolutions retardant encore la sortie du produit. Le risque est donc sérieux pour l'entreprise.

Pour chaque équipe, le coût de la non qualité se traduit par une moindre capacité à produire. Opter pour le statu quo c'est laisser le projet aller à la dérive. Qui plus est, faire travailler des personnes sur un vieux projet avec des technologies anciennes, et sans possibilité pour elles de contribuer à l'amélioration de la situation peut être démotivant et source de turnover.

Il y a donc 3 enjeux assez interdépendants:

1. Avoir les moyens de développer l'activité, et pour cela retrouver / maintenir un avantage concurrentiel,
2. Réduire les coûts et les délais pour améliorer la rentabilité du projet,
3. Avoir des équipes motivées, impliquées.

Que décider ?

Dans certaines entreprises, on peut rester pendant des mois voire des années sans prise de décision sur un produit. J'y vois plusieurs raison possibles :

• On a peur des conséquences pour l'entreprise (et pour soi!) si on prend une décision audacieuse et donc risquée. 
• On préfère opter pour des améliorations générales non spécifiques au produit.
• On se sent coincé et donc on se montre fataliste en reportant la responsabilité sur le produit ou sur les objectifs à court terme.
• Les objectifs mêmes de l'entreprise peuvent contribuer à ne pas prendre de décision, par exemple si le focus est mis sur d'autres produits.

Pourtant, entre tout réécrire et ne rien faire, il y a une troisième possibilité qui peut permettre d'aller vers un mieux en limitant les risques, mais cela nécessite un minimum d'investissements, et de courage. Nous allons voir dans la suite de cet article, qu'il est possible :

• d'agir sur l'environnement,
• d'agir sur le produit lui même,
• et de gérer le risque humain.