Monthly Archives: juin 2008

Estimez-vous!

C’est le grand mal des projets informatiques ! Je connais peu de projets qui prennent vraiment au sérieux la phase d’estimation. C’est pourtant à partir de ces estimations que sont établis de beaux diagramme de gantt qui se révèlent faux dès la première semaine de développement. Or un projet mal estimé c’est un projet qui démarre mal dans la vie… il sortira certainement en retard ou bâclé.

Pourtant estimer est une tache difficile qui mérite qu’on s’y attarde un minimum. Voici un petit quizz inspiré de celui que vous pouvez lire dans Software Estimation de Steve McConnel. Essayez d’y répondre de telle sorte que vos estimations vous donne 90% chance d’avoir la bonne réponse. Si vous ne connaissez pas une réponse, n’allez pas voir sur Wikipedia mais faite plutôt une estimation suffisamment large pour englober la bonne réponse avec 90% de chance.

Faire le quizz

Quizz Estimation

Si vous avez 9 bonnes réponses ou plus, bravo !
Vous savez estimer avec une certitude de 90%.

Si vous avez 8 bonnes réponses ou moins, vous avez été un peu trop optimiste dans vos estimations. Vous avez essayé sur certaines questions de mettre une fourchette qui se rapproche au maximum de la bonne réponse. C’est tout à votre honneur mais mieux vaut toujours une estimation trop large qu’une estimation fausse !

Le developpeur est en effet une espèce (allez savoir pourquoi) de nature plutot optimiste. Quand on lui demande combien de temps ca lui prendra de rajouter la fonctionnalité n°245, il vous répondra qu’il suffit d’ajouter un bouton ici, un bout de code là et que le tour est joué. En bref: « En 2h c’est bouclé ! ».
Dans la réalité au bout de 3h de travail, c’est presque fini.. mais pas complètement: « Donnes-moi encore 15 minutes pour boucler l’affaire ». Au bout de 4h, ça y est ! C’est fini… sauf qu’il reste encore 2 ou 3 bugs à corriger pour que ça puisse être livré. Classiquement, il aura fallu 1 journée de travail pour implémenter la fonctionnalité alors que la tache avait été estimée à 2h.

Pourquoi se mettre dans une situation comme ça tout seul? Quand on vous demande d’estimer une tache, n’essayez pas de faire votre kéké pour impressionner la galerie (genre, moi je code plus vite que tout le monde) et essayez de faire l’estimation la plus juste.

Quelques conseils pour terminer:

  • Si vous manquez d’information pour faire votre estimation, prenez le temps de réunir les informations qu’il vous faut. Ça peut être de faire un mini prototype, d’aller regarder le temps effectivement pris pour faire une tache similaire, etc.
  • Si votre chef insiste pour vous faire baisser votre estimation, ne soyez pas politiquement correct. Dites-lui que vous pensez sincèrement que votre estimation est juste et qu’il peut consulter ses archives pour voir qu’une tache de ce genre prend effectivement le temps que vous avez estimé (et si votre chef ne garde pas un historique de chaque tache, avec l’estimation et le temps effectivement requis, demandez-lui de commencer à le faire.

Bouton ou hyperlien?

Quand on développe une application Internet riche en HTML/AJAX, Flex ou Silverlight, nous sommes à la croisée des chemins, entre pages Web et applications riches.

Et quand vient l’heure d’ajouter un bouton à l’application, je me pose toujours la question de savoir s’il vaut mieux mettre un bouton qui ressemble à un…bouton, ou bien un bouton qui ressemble à un hyperlien.

Cliquez moi

On peut considerer que les hyperliens ont pour unique fonction d’amener l’utilisateur sur une nouvelle page HTML dans le navigateur. C’est leur vocation première et devrait donc rester leur vocation unique. Mais les applications Internet riches ont de ceci de particulier qu’elles n’ont en fait qu’une seule page qui peut changer du tout au tout. Un clic sur un bouton dans une telle application peut donc – meme si l’adresse de la page ne change pas – amener sur une autre interface graphique que l’on pourrait considérer comme une nouvelle page.

On pourrait donc utiliser les hyperliens dans les applications Internet riches quand l’action qui se trouve derrière le bouton va le faire changer d’interface graphique.

Au niveau de l’ergonomie, on peut aussi remarquer que les boutons sont beaucoup plus voyant que les hyperliens. On pourrait donc réserver les boutons aux actions que l’on veut mettre en valeur, et mettre des hyperliens pour les actions que l’on ne veut pas mettre en avant.

Regardez l’interface de Google Analytics permettant de choisir une date et remarquez comme la commande Apply utilise un bouton et la commande Cancel, un hyperlien (Et pour mettre cette dernière encore moins en avant, notez que le mot cancel ne commence pas par une majuscule).

Bouton ou hyperlien? les deux!

Que pensez-vous de cette utilisation des hyperliens dans les applications Internet riches ? Est-ce intuitif ?

Commencez par une maquette

Lorsque je dois démarrer un nouveau logiciel, une nouvelle application Web ou une nouvelle fonctionnalité, et que les idées sont à peu près claires sur ce qu’on veut obtenir, je commence systématiquement par maquetter l’interface utilisateur.

Inutile de démarrer les développements si on ne sait pas exactement ce que l’on veut. Bizarrement, peu de développeurs ont le reflexe de prototyper correctement l’interface utilisateur avant de coder. Pourtant, pour se mettre d’accord avec les utilisateurs, ou même pour se rendre compte du résultat des développements, rien ne vaut un bon dessin.

Pour les premières maquettes de l’interface utilisateur, un dessin à main levé suffit. Soit je dessine sur une feuille blanche que je scanne ensuite, soit j’utilise ma palette graphique pour dessiner à la main. Dans tous les cas, la maquette ressemble à quelque chose comme ça:

Prototype à main levé

A ce stade on peut déjà avoir un feedback des utilisateurs et essayer de travailler sur l’ergonomie et le placement des différents éléments graphiques. Comme vous le voyez, c’est rapide à faire et ça permet de faire un premier round de discussions qui sont – je vous l’assure – toujours très pertinentes.

Une fois qu’un consensus se dégage, on peut maquetter plus finement en essayant d’avoir le résultat final tel qu’il sera à l’écran. On peut faire ce genre de maquette en HTML, sous forme d’image avec Photoshop ou Paint Shop Pro, ou encore avec le designer graphique qui va avec votre environnements de développement (Visual Studio, Flex Builder, etc.). Dans le cas de la page d’accueil de Google, on obtiendrait donc une image comme ça:

Google Prototype Avancé

Là on est prêt à développer… quoique. Il peut également être intéressant de maquetter ce qui se passe quand on clique sur les boutons, pour rendre la maquette plus interactive, et bien montrer à quoi sert tel ou tel bouton.
Jusqu’à présent, je n’utilisait que des outils RAD (Visual Studio, Flex Builder, etc.) ou des fichiers HTML pour faire ce genre de maquettes interactives. Mais j’ai récemment découvert que l’on pouvait utiliser PowerPoint pour créer de véritables maquettes interactives. Pour notre exemple avec Google, cela donne une maquette comme ça (cliquez sur les zones jaunes):

Maquette Interactive Google

Maquette Interactive Google (google.pss, lisible sous Powerpoint XP/2003/2007 et OpenOffice 2.x)

L’idée c’est de désactiver le passage automatique à la slide suivante quand on clique sur la souris, et pour naviguer de mettre des zones rectangulaires semi-transparentes qui sont des liens vers d’autres slides.

On peut également utiliser Powerpoint pour faire des « maquettes papier » interactives avec le Powerpoint Prototype Toolkit que je vous recommande chaudement.