Un logiciel n’a pas besoin d’être rapide… il doit juste ne pas être lent!

Pour cela il suffit juste que le logiciel effectue les taches demandées dans un temps jugé acceptable par l’utilisateur. Et autant l’utilisateur attendra facilement d’attendre quelques secondes pour obtenir le résultat d’un traitement couteux, autant il ne comprendra pas si le logiciel mouline ne serait-ce qu’une seconde a chaque copier/coller.

Le temps qu’un utilisateur est prêt à attendre dépend de ce qu’il considère comme normal. Et cette norme évolue… Prenez la recherche d’un email. Il y a 5 ans, un utilisateur de Microsoft Outlook acceptait d’attendre quelques minutes pour obtenir le résultat d’une recherche visant à retrouver un ancien mail. Aujourd’hui ce n’est plus le cas. Des logiciels comme Lookout ou bien Gmail rendent leur verdict en quelques secondes et ont donc fait évoluer l’attente des utilisateurs.
Donc lorsque vous développez votre logiciel, ayez les mêmes attentes que les utilisateurs en termes de performance. Inutile pour autant d’optimiser toutes les parties du logiciel….

Voici quelques conseils pour vous aider à développer un logiciel suffisamment rapide pour vos utilisateurs :

• Lors de la phase de conception, écartez les architectures qui ne vous permettront pas d’atteindre des performances suffisantes. Dans le cadre d’un logiciel de gestion d’email, par exemple, écartez toutes les architectures qui nécessitent plusieurs minutes pour effectuer une recherche.
• Lors du développement quotidien du logiciel, ne vous focalisez pas sur la performance. Mais:
  • Procédez à une phase d’optimisation régulièrement (à chaque fois que vous finissez une itération, une fonctionnalité, …). Lors de cette phase d’optimisation, utilisez un profiler pour déterminer ce qu’il faut optimiser.
  • Testez régulièrement votre logiciel avec de gros volumes de données.
• Si votre logiciel effectue des taches potentiellement longue, affichez une barre de progression ou un indicateur d’activité ainsi qu’un bouton « Annuler » pour stopper immédiatement l’opération. Cela permet à vos utilisateurs d’abandonner une tache si ils la jugent trop lente.
  Et ne faites pas comme certains logiciels qui mettent un bouton « Annuler » mais qui est tellement mal programmé que lorsqu’on appuie dessus, non seulement l’opération ne s’arrete pas et se poursuit jusqu’à son terme, mais en plus embraye ensuite sur une interminable phase d’annulation des modifications effectuées.

Voilà une question que je pose actuellement alors que je travaille sur un nouveau logiciel chez mon employeur actuel

Interrogez des utilisateurs et demandez-leur de vous citer un logiciel qu’ils aiment. Demandez-leur ensuite quelles sont les raisons qui les poussent à aimer ce logiciel. Voici quelques-unes des réponses que vous risquez d’avoir (dans le désordre):

• Il répond à mon besoin.
• Il fait ce que je lui demande.
• Quand je lui demande quelque chose, il réagit rapidement
• Il est facile à utiliser.
• Il est beau / cool / à la mode / etc.
• Je me sent à l’aise avec ce logiciel.
• Il ne plante jamais.
• Il est rapide à charger.
• D’autres gens de mon entourage l’utilisent.

Notez que vos utilisateurs ne vous feront aucune de ces réponses:

• Il est bien architecturé
• Le code est bien écrit / bien documenté
• Il est écrit en C# / Java / Ruby / Flex  / Eiffel / [Ajoutez ici votre langage favori]

Je vous propose de voir, tout au long de ces prochaines semaines, comment toutes ses réponses peuvent nous aider à construire de meilleurs logiciels.

Pour gérer un projet, on a plusieurs solutions: On peut le faire à la-rache sans utiliser de logiciels, en partageant le code source via une clef USB, en notant les demandes utilisateurs dans un coin de la tête du chef de projet, et les bugs bloquants sur une feuille volante. On peut aussi le faire à l’ancienne, avec Visual Source Safe, Microsoft Project et un outil de gestion de bugs fait maison. On peut également se la jouer grosse boite qui a de l’argent en utilisant ClearQuest pour gérer les bugs et les demandes d’évolution et Primavera pour gérer les plannings. Indépendamment de leurs qualités intrinsèques, ces logiciels ont tous un point commun: ils ne correspondent pas à ce dont à besoin une équipe qui utilise une méthodologie de développement agile.

De quoi à besoin une équipe de développement agile ?

1. Un logiciel de gestion des sources qui ne verrouille pas les fichiers (plusieurs développeurs doivent pouvoir travailler en même temps sur le même fichier) et qui gère les branches. Subversion me semble indiscutablement le choix qui s’impose, mais CVS - son ancêtre - marche également. Enfin Perforce est également une solution pour les plus fortuné d’entre vous.
2. Un logiciel de build et d’intégration continue. Son rôle est de compiler le projet, d’exécuter les tests unitaires et de générer le distribuable, ceci de manière régulière. Pour un projet Java ou Flex, on utilisera typiquement Ant ou Maven pour la build. Pour l’intégration continue CruiseControl, Continuum et Hudson sont des candidats de choix. Pour un projet .NET, on passera par MsBuild et Team System si on arrive à négocier les licences avec son supérieur, ou bien Nant et CruiseControl.NET.
3. Un logiciel de tests unitaires. Pas la peine d’aller chercher bien loin, JUnit et ses différents portages (NUnit pour .NET et AsUnit pour ActionScript) feront parfaitement l’affaire. Pour .NET on regardera également du coté de Team System si on a le budget.
4. Un logiciel de rapport de couverture des tests unitaires. Du coté .NET, Team System fait ça très bien, sinon on peut essayer NCover (payant, contrairement à ce que son nom laisse présager). Pour Java on utilisera Cobertura si on veut du gratuit, ou le très bon Clover si on est prêt à payer pour avoir mieux (le plug-in Eclipse est très pratique). Pour ActionScript, il n’existe malheureusement pas encore d’outil à ce jour, il faut attendre encore un peu.
5. Un logiciel de gestion de projets (gestion de taches, bugs, spécifications, etc.). C’est le logiciel sur lequel il ne faut pas hésiter à investir, et à passer du temps à trouver celui qui vous convient le mieux. Néanmoins je vous recommanderais, dans l’ordre du plus simple au plus complet : FogBugz, Gemini, JIRA et AtTask. Ils sont tous payant (sauf JIRA si vous développez un projet open source) mais la qualité est à ce prix. S’il ne fallait en retenir qu’un seul, je dirais JIRA avec le plug-in GreenHopper. Jetez également un œil sur Basecamp et Unfuddle qui sont des solutions en ligne. Unfuddle allant jusqu’à héberger vos sources sur leur serveur SVN.

Et vous, utilisez-vous des logiciels plus complet ou performant que ceux-ci ?

Nous avons vu qu’il était utile de mettre des fonctionnalités de basse priorité dans la prochaine version pour servir de fusible, mais on peut aller encore plus loin… Et si on choisissait de ne pas inclure les fonctionnalités les plus demandées par nos utilisateurs?

Faites des affaires

Je vous échange votre baril de lessive Skip contre 4 barils de lessive Ariel. Ça vous intéresse?

Moi carrément, mais tous les chefs de projet n’ont pas l’air d’être de cet avis. Ils préfèrent ajouter au planning une fonctionnalité très demandées par les utilisateurs mais difficile à implementer plutôt que plusieurs fonctionnalités moins demandées mais beaucoup plus faciles à implementer. Je pense au contraire qu’il faut chasser les bonnes affaires! Mettez dans votre prochaine version les fonctionnalités qui présentent le meilleur rapport “qualité/prix” ! Vos utilisateurs seront certainement aussi satisfait (sinon plus) de trouver 4 nouvelles fonctionnalités dans votre prochaine version plutôt qu’une seule grosse nouveauté.

Conclusion: Classez vos fonctionnalités en fonction de leur ROI (retour sur investissement) pour choisir celles que vous mettrez dans la prochaine release.

C’est la question numéro 1 qui se pose lors de la planification d’une nouvelle version d’un logiciel.

Le processus consiste normalement à:

1. Lister les fonctionnalités demandées par les utilisateurs
2. Attribuer une priorité à chaque fonctionnalité
3. Prendre toutes les fonctionnalités de priorité maximale, estimer leur charge respective et les ajouter au planning
4. Si le planning n’est pas plein, faire de même avec les fonctionnalités de priorités inférieures

Tout le monde a l’air de se satisfaire de cette facon de proceder, mais c’est à mon sens une des raisons pour lesquelles la plupart de ces projets informatiques sont livrés en retard et ne satisfont pas leurs utilisateurs…

Ne promettez pas ce que vous ne pouvez tenir

C’est toujours la même histoire… le coût de chaque nouvelle fonctionnalité est sous-évaluée ou bien le département marketing veut mettre trop de fonctionnalités dans la nouvelle version. Bref, on promet qu’avec la nouvelle version PaintTruc 2007 on pourra lire les images au format JPEG2000, tracer des courbes au clavier et corriger automatiquement les photos floues.

6 à 12 mois plus tard, la nouvelle version sort et fait étalage de son habileté a lire le format JPEG2000 et de ses raccourcis clavier de folie pour dessiner des courbes sans souris mais c’est un fiasco. Mais où est donc passée la fonctionnalité qui permet de corriger les photos floues? OK - d’accord - cette fonctionnalité est finalement beaucoup plus compliqué à implementer que prévu, elle sera donc incluse dans la version PaintTruc 2008 mais le mal est fait! La fonctionnalité tant attendue de PaintTruc 2007 n’est pas là.

Moralité de l’affaire, mettez des fonctionnalités comme jugées moins importantes dans la roadmap de votre prochaine version. Elles serviront éventuellement de fusibles en cas de dérapage du planning.