Rémi Favretto et Sofia Krari viendront nous donner les bonnes pratiques en matière d’ergonomie sur les interfaces d’application riche, mais aussi nous expliquer comment améliorer l’expérience utilisateur.

Venez donc nombreux Jeudi 12 Janvier à 19h participer à notre sixième événement.

Pour ne pas changer une équipe qui gagne, ce sera salle TD6 au premier étage de l’ENSEIRB-MATMECA.

Comme d’habitude c’est gratuit et ouvert à tous, alors inscrivez vous vite sur http://ttfx6.eventbrite.com/

Il y a des jours ou l’on se rend compte que des années d’expérience ne nous mettent pas forcément à l’abris des erreurs les plus basiques.
Explications : lundi nous avons fait une grosse séance de refactoring avec ma paire : renommage de toutes les méthodes d’une classe, extraction de comportement commun dans une classe mère …

Nous étions un peu grisés et franchement contents du rythme auquel nous avancions. A tel point que nous n’avons pas pu commité lundi soir car nous fumes victimes de demandes de support arrivées lundi soir.
Résultat ce matin, après un jour férié, nous pensions qu’il nous suffirait de tester rapidement nos modifications puis de les commiter. Las, nous avons découvert quelques bugs et avons passé plus d’une demi-journée pour rechercher où étaient les erreurs parmi nos nombreuses modifications.

Finalement, nous avons fait un revert sur la majeure partie de notre travail de refactoring. Grosse frustration …
J’en tire une conclusion qui sonne comme un rappel : commiter régulièrement nous aurait éviter ce genre de mésaventures !

Un lieu-commun

Il faut dire que l’argument est très souvent entendu dans la bouche de commerciaux qui, après avoir gagné un projet, souhaitent légitimement que celui-ci soit réalisé dans les coûts prévus initialement pour rassurer le client. Le problème pour le commercial, c’est qu’il ne peut modifier ni le périmètre, ni la taille de l’équipe, ni la date de livraison sur lesquels il croit s’être engagé. Il ne lui reste alors plus qu’à essayer de faire en sorte que la qualité devienne une variable d’ajustement du développement.

Un concept difficile à définir

Le concept même de sur-qualité nécessite d’être expliqué. En effet pour un commercial la sur-qualité peut être défini par le fait que l’équipe de développement passe trop de temps à améliorer la qualité de son code, à écrire des tests unitaires, ou à les ré-écrire, à refactorer. En un mot à passer du temps à écrire du code qui n’apporte pas de nouvelles fonctionnalités. Pour rassurer le commercial inquiet, il suffit de se tourner vers le client et de lui demander s’il est prêt a accepter d’avantage de bugs et de support pour une amélioration hypothétique de la productivité de l’équipe. Une expérience récente me fait dire que sur ce point nous pouvons faire confiance à la vision produit de nos clients. Lorsqu’ils recherchent des gains de productivité, ils raisonnent à qualité constante.
La deuxième possibilité, c’est de laisser l’agiliste définir ce concept. Il pourrait alors dire que la sur-qualité consiste à implémenter des fonctionnalités (utiles) mais non demandées. Ce risque est fortement limité par le fait que les processus agiles s’appuient sur un feed back régulier du client. Impossible donc de développer beaucoup de fonctionnalités non demandées.

Une vision de court terme

En conclusion, je crois que la sur-qualité est un mythe, une vue de l’esprit de personnes qui ne participent pas directement aux activités de développement. Il s’agit de plus d’une vision de court terme dans laquelle la qualité est vue comme un coût immédiat et non pas pour ce qu’elle est : un investissement qui permet de ne pas sacrifier la productivité future.

Sur le même sujet : l’Agilitateur

Uu ROI rapide

Si l’on prend un peu de recul par rapport à cette étude, que l’on prend en compte le fait que les cartes graphiques à deux connecteurs se sont généralisées et que les écrans, désormais tous plats, se sont agrandis à prix constant, l’investissement à réaliser est modeste. Le retour sur investissement est donc extrêmement rapide.
Et que les managers se rassurent, ces mêmes études montrent que le choix d’un écran de 26 pouces n’apporte aucun gain de productivité supplémentaire par rapport à un modèle 24 pouces. De même, le passage à trois écrans n’apporte rien. Ouf, les développeurs ne coûteront pas trop chers…

Peut-on vraiment faire confiance à ces études ?

Ces études vont probablement être reprises par quelques commerciaux en mal de chiffres -comme ils le font avec l’étude du Standish group sur le Pair Programming- sans qu’ils comprennent en quoi ces pratiques améliorent véritablement la productivité des équipes. Je vais donc essayer de le leur expliquer en donnant quelques exemples dans lesquels l’utilisation de dual screen me semble apporter un gain de temps incontestable :

• lors de la rédaction ou de la mise à jour de cas de tests, cela me permet d’avoir sous les yeux à la fois le document que je rédige  et l’exigence qui doit être développée, évitant ainsi de switché de l’un à l’autre
• lorsque je développe, je peux à la fois avoir sous les yeux une classe dont je souhaite m’inspire et la classe sur laquelle je travaille, ou encore ma page web et le fichier de ressources dans lequel j’ajoute les traductions nécessaires au fur et à mesure. Je pourrai même avoir sous les yeux l’exigence pendant que je développe et ainsi vérifier régulièrement que je n’en ai pas oublié une partie
• lorsque je lance les tests et qu’ils sont rouges, je peux à la fois voir la méthode de tests en cause et la cause de l’erreur
• lorsque je débug, je peux avoir d’un côté la classe parcourue et de l’autre les variables, points d’arrêt et autres espions
• lorsque je livre, je peux le faire en ayant sous les yeux le mode opératoire de livraison et ainsi éviter de trop nombreuses erreurs

Faisons confiance au feed-back

S’il fallait encore ajouter un argument, ce serait le feed-back de ceux qui ont essayé. La conclusion de Microsoft Research est simple : donnez un second écran à quelqu’un, laissez le l’utiliser quelque temps et essayer ensuite de le lui retirer. Cela n’arrivera pas. Personne ne voudra revenir à un seul écran.

Le principe est simple :  vérifier à chaque modification de code source que celui-ci ne contient pas d’erreurs.

Comme souvent cette simplicité apparente cache une forme de complexité : d’abord il faut que l’intégration continue soit rapide. Au delà de 5 minutes pour que l’intégration continue soit terminée et le risque est (très) grand qu’un développeur ne fasse pas l’effort d’attendre de connaître le résultat de l’intégration pour commencer une nouvelle tâche.
Ensuite, cela nécessite que chacun dans l’équipe s’approprie un principe simple : “Le serveur d’intégration continu est représentatif de l’état du code”. Ce principe a un corollaire : “Si la dernière intégration et rouge, l’équipe doit porter son effort sur la réparation du build, quitte à mettre entre parenthèse les développements en cours”. Ce corollaire ne peut pas avoir dans mon esprit d’exception, que ce soit à cause d’un serveur svn inaccessible, d’une base de données qui a été arrêtée ou d’une tâche de l’intégration continue qui ne rend pas la main comme elle le devrait ; un build rouge empêche toute l’équipe de continuer à travailler, puisque plus personne ne peut commiter ou updater un projet correct.

Enfin, cela nécessite que chaque membre de l’équipe se sente impliqué dans le processus et éventuellement dans la réparation d’un build rouge. Ceci signifie par exemple qu’il me semble inconcevable de commencer à commiter à la fin d’une -dure- journée de travail. Illustrons cela par un exemple :
- 18h30 : les tests passent enfin au vert sur mon poste. Génial, je vais pouvoir commiter ce soir !
- 18h35 : j’update mes sources et relance les tests
- 18h45 : les tests passent au vert sur mon poste. J’update, pas de nouvelles modifications. Ouff, j’aurais pu y passer la nuit. Je commit.
- 19h : le serveur d’intégration continue compile l’application et passe les tests. Pas de chance le build est rouge
- Je commence donc à chercher l’origine du problème. Il est tard, j’ai envie de rentrer chez moi.
-19h15 : J’ai de la chance, ce n’est pas grand chose. J’ai rapidement corrigé. Je re-commit.
- 19h30 : le build est réparé ! Ca y est, j’ai bien mérité le droit de rentrer chez moi

L’exemple ci-dessus, dans lequel le problème a été résolu très rapidement m’inspire une règle générale : “ne pas commiter après 18h, à moins d’être prêt à ne pas sortir du travail avant 19h30″. Et comme cela ne me semble pas être un rythme soutenable, j’en resterais personnellement à “ne pas commiter après 18h“. Je préfère préparer le commit, arriver tôt le lendemain, pour que le build ait lieu pendant la mêlée.

L’Agile Tour 2011 Bordeaux aura lieu le 

vendredi 21 octobre 2011 à l’ENSEIRB-MATMECA.

Plus d’infos ici : http://agiletourbordeaux.okiwi.org/

Un but commun

C’est probablement le plus évident, mais pas nécessairement le plus simple des éléments qui caractérisent une équipe et en particulier une équipe agile. Elle doit -ou plutôt chacun de ses membres doit- avoir un idéal, celui de produire des applications de manière efficace en collaborant avec le client. Chacun croit en cette idée folle : il est possible de rendre les processus plus efficients et d’améliorer les conditions de travail de tous les acteurs.

Elle trouve un sens à son travail qui va bien au delà de l’écriture de quelques lignes de code.

Une approche empirique

L’approche d’une équipe agile ne peut pas être dogmatique. Mieux vaut bien souvent accepter une solution proposée par un client pour pouvoir lui démontrer l’inopérance de cette solution, plutôt que de refuser de mettre en place cette solution. L’équipe y trouvera un double avantage : d’abord elle s’économise des débats sans fin et les procès d’intention que les uns ne manqueront pas de faire aux autres, ensuite elle légitime d’autant plus les propositions qu’elle formulera qu’elle aura mis en évidence les problèmes concrets posés par la solution mise en œuvre.

Cela signifie donc que chacun est près à mettre en application des solutions auxquelles il ne croit pas nécessairement, à le faire le mieux possible et à en tirer ensuite les enseignements.

L’adaptation au changement

Pour intégrer une équipe agile, il faut accepter de quitter le monde du taylorisme dans lequel nous avons grandis : seule l’équipe est responsable de la réussite ou de l’échec des développements ! Cela constitue un changement majeur dont chaque membre de l’équipe doit prendre conscience et que chacun doit accepter.

S’adapter au changement, c’est aussi accepter de mettre en cause les décisions que l’on a soit même pu prendre par le passé, contribuant ainsi à un processus d’amélioration continue.

Je terminerais ce billet en rappelant que travailler dans une équipe agile ne va pas de soi, que cela constitue pour certains de nos collègues une véritable révolution dans la manière de concevoir notre métier. Il faut donc de l’accompagnement, de la patience et du travail pour que  l’agilité fasse de nouveaux convaincus.

Le Jeudi 26 Mai à 18h30 aura lieu notre quatrième rendez-vous.
Cette fois ci, les tontons ont fait appel à Max l’alchimiste, le spécialiste en préparation de mélange détonant.

L’idée est de voir comment mettre en place des développements dirigés par les tests avec la Flexeuse.

Venez donc nombreux à l’ENSEIRB-MATMECA, assister à la présentation de Flex et TDD.
Vous verrez ainsi comment tester unitairement votre application Flex, mais aussi des conseils, des astuces, des techniques, et un retour sur les quatre ateliers précédents.

Inscriptions ici : http://flex-tdd.eventbrite.com/

Comment mener un Serious Game ?