[Devoxx 2013] How To Do Kick-Ass Software Development

devoxx 2013Sven Peters était déjà présent l’année dernière à Devoxx pour prodiguer les bonnes méthodes utilisées chez Atlassian : 7 things to make good team greats – un ensemble d’astuces pour que votre équipe passe d’une équipe compétente à excellente. Cette fois ci, c’est pour faire des logiciels qui « déboîtent » que Sven prend la parole dans le Kinepolis d’Anvers : How To Do Kick-Ass Software Development !

Dave Lizewski, dans le film Kick-Ass, est une personne ordinaire, un peu geek sur les bords, mais tout de même ordinaire. Pourtant, des choses l’embêtent : il n’aime pas le crime ! Cela l’embête, cela le dérange. Pour résoudre son problème, il se transforme en super héros, sans pouvoir peut-être, mais super héros tout de même. En tant que développeur, quand quelque chose nous bloque, nous dérange, on se doit de devenir comme Dave : un super héros et résoudre ce grain de sable dans nos rouages.

En résolvant nos problèmes, que voulons-nous atteindre? Généralement, ce que l’on veut, c’est de meilleurs logiciels, moins de choses superflues, développer plus rapidement, que nos clients soient contents, et que les développeurs soient aussi contents. La solution souvent énoncée? Il faut être…Agile ! L’agilité résout des problèmes, ou du moins les expose plus clairement, mais ce n’est pas la solution à tous les problèmes.

IMG_20131113_115958

Maintenant, qu’est-ce qu’on fait? On attend une nouvelle certification ou une nouvelle méthode qui résoudra nos problèmes? Non, on fait comme Dave, on enfile notre costume de super héros et on va résoudre nos problèmes.

Attention, avec les équipes un peu trop enracinées, résoudre les problèmes n’est pas si simple : ces équipes pensent qu’il suffit d’ajouter un process pour résoudre un problème. Changer quelque chose ? C’est probablement trop compliqué…et la décision qui a été prise il y a 3 ans et qui ne sert plus à rien est forcément…toujours d’actualité. Avec ce genre d’équipe, changer les choses peut être un petit peu plus ardu qu’avec une équipe ayant un esprit d’ouverture, mais pas impossible non plus.

// Par quelles étapes devons-nous passer pour faire des produits qui « déboîtent » ?

Deliver Kick Ass Software

Le client doit être content de ce qu’il utilise. C’est normal après tout : c’est lui le client, non? Les clients sont contents quand ils utilisent un produit dont ils avaient besoin. Mais comment savoir si l’on est en train de créer le bon produit?

Microsoft a produit un téléphone : le Kin. Une sorte de smartphone « cool », ayant nécessité deux ans de développement mais, surtout, ayant fait un flop complet ! Comment éviter ce genre de déconvenue? Chez Atlassian, ils font ce qu’ils appellent : Fake It Until You Make It, qui consiste à réaliser un prototype en simulant un maximum de composants, exercice bien connu de ceux qui pratiquent le Lean.

Un exemple connu est comment IBM a testé la reconnaissance vocale : pour cela, ils ont demandé à quelqu’un d’utiliser un logiciel de reconnaissance vocale, et ils ont observé comment la personne utilisait le logiciel. Ce que l’utilisateur ne savait pas : aucun algorithme n’était utilisé dans ce prototype. Une personne cachée écoutait la conversation et retranscrivait le tout, le plus rapidement possible. Ce test a permis de lever quelques problèmes d’utilisation (comment effacer du texte?). Le concept peut être poussé plus loin : avez-vous déjà pensé à utiliser des interfaces en papier pour simuler un logiciel ?

Ce qu’il est possible de faire, également, c’est de récolter le feedback utilisateur. Cela se fait dans des gares d’une façon assez simple et rapide : une borne avec 2/3 boutons représentant son humeur. C’est voyant, rapide, et facile à remplir. Pourquoi ne pas faire pareil sur son logiciel ? Un gros bouton feedback dans l’en-tête de votre site, avec un formulaire simple à remplir ?

One Kick Ass Team

Sven a constaté que la mise à l’échelle du département QA (Quality Assurance) n’est pas simple à faire. Cela peut devenir un goulot d’étranglement. Le problème est que la qualité devrait être l’affaire de tous. Du coup, pour favoriser cela, il n’y a pas que le département QA qui teste, mais également les développeurs. Ils testent les fonctionnalités d’autres développeurs. Ils peuvent être assistés par le département QA, plutôt renommé en Quality Assistance pour l’aide apportée aux testeurs.

Pour dire vrai, chez Atlassian, tout le monde peut être mis à contribution pour tester de nouvelles fonctionnalités (ce qu’ils appellent les blitz test) : oui, même un commercial. Ils vont même jusqu’à faire des tests lors de sessions séparées, sur les mêmes fonctionnalités pour comparer comment deux groupes d’utilisateurs différents utilisent la même fonctionnalité. La pratique la plus extrême étant peut-être de dédier une personne à trouver des bugs en utilisant une fonctionnalité dans tous les sens, et uniquement pour essayer de la casser et y trouver des problèmes.

Kick Ass Collaboration

Lonesome Cowboy…qui n’a jamais pensé une fois être le Lucky Luke du code? Codeur plus rapide que son ombre, mais seul… Lonesome Coder… Dans une équipe, la communication doit être fluide et, parfois, les règles cassent cette fluidité. C’est un petit peu comme la différence entre un carrefour occidental et indien.

L’idée est d’utiliser le moins de process possible pour ne pas « alourdir » l’équipe et utiliser des process simples et légers, comme mettre en place une revue de code entre pairs, et non la mise en place d’un système de patch qui doit passer par 6 personnes différentes, n’ayant jamais le temps de valider votre modification.

Pour avoir une collaboration accrue, la communication est importante. L’e-mail est un support intéressant…mais pas toujours. On peut rapidement se retrouver sous 6 tonnes de mails inutiles. Il peut être intéressant d’utiliser des moyens de communication alternatif, comme les tchats et leurs systèmes de salon, comme IRC ou le produit d’Atlasian : HipChat.

Kick Ass Automation

C’est bien de rajouter de la collaboration, etc. Mais encore faut-il livrer quelque chose. Pour livrer facilement, il faut automatiser le process de livraison. Un build avec tous ses tests unitaires, ses tests fonctionnels, de performance, etc. peut être long, très long, trop long. C’est un problème.

Il y a des stratégies pour accélérer son build comme utiliser le même artefact tout au long de son flow de construction, au lieu de le reconstruire. Il est également possible d’accélérer sa suite de tests ou filtrer les tests à lancer, pour lancer les tests unitaires à chaque commit, mais ne lancer les tests de performance qu’une fois par jour.

Si le sujet des tests trop lents vous intéresse, David Gageot a également fait une présentation à ce propos au Paris Jug.

Pensez à « monitorer » vos builds pour détecter plus rapidement, et facilement, les parties qui font que votre build est lent : Measure, don’t guess !

Kick ass software development

Il ne reste plus qu’à convaincre vos managers pour mettre en place tout ça. Il est vrai que certains sont plus faciles à convaincre que d’autre. Mais il est important, pour mettre au monde un kick-ass software, de mettre en place une culture dans cet esprit ! Mais avec tous ces tips, plus rien ne devrait vous arrêter de faire des logiciels qui « déboîtent » !

Une dernière question : Did You Kick Ass Today ?

Pour (re)voir la présentation :

http://svenpet.com/talks/how-to-do-kick-ass-software-development/

Nombre de vue : 27