Spiria logo.
Mélissa Guay
03 avril 2019.

Trois problèmes à anticiper dans tout projet de développement

Mélissa, qui a déjà une longue expérience dans la gestion de projets, vous propose des pistes de solutions pratiques aux trois problèmes les plus souvent rencontrés lors du développement d’une application ou d’un site :

Une période de démarrage trop furtive et sommaire

Lorsqu’un nouveau projet démarre, tout paraît possible ! C’est la lune de miel, la nouveauté est enivrante, les possibilités sont infinies, l’excitation bat son comble. Quant à eux, les risques ne sont pas toujours perceptibles au premier regard et leur analyse exige temps et effort. C’est pourtant à ce moment critique qu’il faut leur accorder la plus grande importance puisque la gestion du risque est aussi la capacité à anticiper et à s’adapter à un écueil potentiel. Cela ne veut cependant pas dire qu’il faut craindre les rebondissements et obligatoirement tout prévoir, il faut un juste milieu.

Des rebondissements : oui, mais pas à n’importe quel prix ! © iStock.

Souvent appelée « Sprint 0 », « analyse », « conception », « découverte », peu importe le nom qu’on lui donne, cette étape est cruciale pour le projet. Elle permet de mettre la table, d’établir de bonnes bases, de prendre le temps de réfléchir et de préparer le projet à venir. Parmi les activités couramment incluses, nous trouvons l’élaboration des besoins du client, le raffinement du « backlog » de tâches à exécuter, la définition des critères de succès des « stories », la réalisation de maquettes fonctionnelles ou « wireframes », l’écriture du plan de test, la création d’environnements, la réalisation d’une démonstration de faisabilité ou encore d’études sur l’expérience utilisateur, etc.

De ce fait, comme dans toute nouvelle initiative, il y a souvent cet empressement naturel qui nous porte à vouloir rapidement entrer dans le vif du sujet. De plus, cette hâte peut être accentuée par des contraintes telles qu’un échéancier serré ou un budget limité. C’est ainsi que les premières étapes pourtant cruciales d’un projet se retrouvent très souvent escamotées et dépriorisées. Un manque de vision s’en suit alors et les risques de réécriture deviennent alors proéminents.

C’est un peu comme construire une maison en n’ayant fait ni plan ni inventaire des matériaux nécessaires. Il se pourrait que vous deviez par la suite déplacer un mur ou encore retourner souvent à la quincaillerie ou chez d’autres fournisseurs pour vous procurer le matériel nécessaire.

Solution

Il nous a été démontré maintes et maintes fois au cours de notre pratique, qu’avant même le début de l’exécution du projet, un effort de 15 à 20 % du montant total du projet devrait être accordé aux étapes préparatoires. Cela peut paraître un gros investissement pour peu en retour, mais détrompez-vous ! Cette étape vous fera suffisamment gagner sur l’efficacité de réalisation et limitera les efforts de réécriture à un point tel que vous serez convaincu de sa valeur. Faites-en l’essai par vous-même et vous verrez !

Temps de réusinage de code non prévu dans le plan de projet initial

D'après John Cutler.

Quel que soit l’échéancier d’un projet, un imprévu technologique majeur nous fait l’effet d’un ciel qui nous tombe sur la tête à 10 110 011 km/h !

Le réusinage (« refactoring ») fait partie des processus nécessaires à chaque itération/période de développement. Il consiste à retravailler le code source de façon à le normaliser et améliorer sa structure interne, sans modification du comportement externe du code. Il exclut donc tout ajout de fonctionnalités ou correction de bogues. Il rend le logiciel plus aisé à comprendre et à maintenir, il aide à repérer les bogues et accélère la programmation.

C’est un peu comme faire du ménage dans ses placards et bien organiser le contenu de ses tiroirs afin d’accueillir du nouveau contenu et de faire en sorte qu’il sera simple d’y accéder par la suite.

Solutions

Lorsqu’un projet est construit sur des bases existantes, soit avec l’utilisation du code qui ne vous appartient pas, soit avec du code hérité d’une technologie qui n’est plus prise en charge, il faudra prévoir du temps pour le réusinage de code.

Toutefois, même si votre projet débute à partir d’une planche à dessin vierge et que vous en êtes l’instigateur, on ne s’en sort pas ! Il faudra tout de même prévoir du réusinage assez rapidement dans le projet et le besoin sera plus accru avec l’évolution du projet et l’ajout de nouvelles fonctionnalités. Il faudra donc planifier dans les sprints de mi-projet et les avant-derniers sprints une part plus importante de réusinage. Notre pratique nous a démontré que 10 % de réusinage était normalement suffisant pour que le logiciel demeure facile à comprendre, à déboguer et à entretenir, en plus d’accélérer la programmation par la suite.

Plusieurs ajouts et changements acceptés en cours de route sans signalement formel

© Spiria.

Bien que l’on pourrait croire qu’a priori un client sera nécessairement plus heureux si l’on fait plus que la demande originale et qu’on accepte tous les changements de dernière minute, il le sera moins s’il réalise que son projet est alors menacé par ces ajouts ou encore que ses contraintes budgétaires ne puissent plus être respectées. Il importe donc d’être transparent avec les clients, de documenter les changements et d’évaluer chaque demande pour ensuite prévenir le client des impacts financiers potentiels ou encore des conséquences que ceux-ci pourraient avoir sur l’échéancier du projet. Même lorsque l’impact vous paraît minime, il est important de le documenter et de le suivre, car un amoncellement de petits changements négligeables peut avoir un impact considérable sur votre projet si vous ne les suivez pas attentivement. Un océan est formé de nombreuses petites gouttes d’eau lui aussi !

Solution

Tenir un registre des changements, comme on tient un registre des risques, est une solution essentielle. On le met idéalement en ligne et on invite le client à le consulter chaque fois que l’on y ajoute du contenu. On priorise ensuite les demandes de façon à ne pas menacer l’objectif initial des sprints et du projet avec des éléments intéressants à avoir, mais non prioritaires. Pour certains gros projets, les demandes de changements sont si nombreuses qu’une rencontre hebdomadaire y est consacrée, possiblement jumelée avec celle du suivi de bogues et/ou des risques.

Pour conclure, c’est grâce à une solide expérience découlant d’un portefeuille de projets variés, une communication efficiente, une grande attention portée au transfert de connaissances, autant en développement qu’en gestion de projets, que l’on s’assure que les meilleures pratiques soient utilisées lors de croisades en terres numériques.

Je recommande fortement de tenir une liste de leçons apprises et l’historique des problèmes/solutions, puis d’assurer le partage des apprentissages à l’ensemble des communautés de pratique. Ceci permettra d’assurer une amélioration continue au sein des pratiques et de transformer le savoir individuel et collectif en apprentissage organisationnel. Dans le contexte concurrentiel que nous sommes aujourd’hui, une telle démarche pragmatique d’évolution est au cœur de ce que présente l’entreprise apprenante.

Partager l’article :