dimanche 2 novembre 2014

Code à l'Ecole : heu, zêtes sûrs ?

Cela fait quelques temps maintenant que l'on parle d'enseigner le Code à l'Ecole... et à chaque fois cela me hérisse le poil.

Quoi ? On enseignerait le développement d'applications dans les écoles primaires et secondaires ?

Image courtesy of magerymajestic at FreeDigitalPhotos.net

Euh. "J'ai un doute", comme dirait l'autre.

Première chose qui me vient en tête : on va nous enlever, à nous développeurs, le pain de la bouche... Que va-t-il nous rester quand des milliers d'élèves formés pour pas chers débarqueront sur le marché du travail ?

Bon, soyons sérieux, je passe dessus rapidement parce que :
  1. Il s'agit de fierté mal placée (oui, je suis fier d'être développeur ; et pas le seul !)
  2. Le programme gouvernemental ne vise probablement pas à former des Ingénieurs d'Etude et Développement capables de produire des applications professionnelles.
Et c'est peut-être bien là que le bat blesse... Pourquoi, me direz-vous ?
Regardons de plus près le métier de développeur.

Je me prends pour exemple car c'est celui que je connais le mieux : de culture scientifique, j'obtiens un bac S avec mention bien et me dirige vers une école d'ingénieur, l'IG2I. 5 ans de formation intensive et poussée dans ce que je trouve, avec le recul, être un excellent lieu de formation pour notre métier. Je sors major de ma promotion (section Génie Informatique) et m'engage dans une SSII qui m'envoie chez un client où, très rapidement, je fais mes preuves, monte en grade, prends des responsabilités, guide d'autres développeurs (y compris des plus âgés), participe aux cellules d'architecture, aux ateliers de normalisation de développement, etc.

Bref, à ce moment là de ma carrière, je peux prétendre être un bon développeur (depuis j'ai mal tourné, je suis passé de l'autre côté de la barrière, dans le mal absolu : chef de projet. bouah).

Et vous savez quoi ? Même en disant tout cela, avec toute la prétention qui pourrait en ressortir, je n'ai pas les chevilles qui enflent. Car, malgré le fait que je me considérais (imparfait, car j'ai perdu la main) comme un très bon élément, je savais déjà à ce moment là que j'étais très loin de tout connaître ; que malgré la motivation, l'énergie, l'engagement que je mettais à rester formé, ouvert, à l'écoute des nouveaux outils et technologies ; à lire les très très très nombreuses normes qui gouvernent notre univers, je ne savais rien.

Et même aujourd'hui, les meilleurs des développeurs (ceux qui facturent leur journée de conseil à quelques centaines voire milliers d'euros) ne sont vraiment spécialisés que dans un domaine. Les vrais couteaux suisses sont rares...

Tout cela pour en venir où ?

Prenez conscience que malgré toute la formation que j'ai eu (5 ans en études supérieures !), malgré tous les bons points que l'on m'a donné, je peux vous jurer que je suis très loin de m'y connaître en sécurité, que je ne connais pas grand chose sur les développements spécifiques au mobile ou à la tablette, ou encore que les mondes des bases de données et systèmes d'exploitation ne sont pas ceux qui me réussissent le plus.

Attardons-nous sur l'aspect Sécurité, car c'est là que je voulais vous emmener. C'est ce point en particulier qui me fait peur dans l'enseignement du code à l'école. Si un développeur avec mon parcours ne prétend pas y connaître grand chose au domaine, comment un élève du tronc commun, même très sérieux, pourrait s'y retrouver ?

Dites-vous bien que nous faisons auditer nos applications par des agences spécialisées dans le domaine, car la Sécurité est bien un métier à part entière (l'une des très très nombreuses spécialités de l'informatique).

Oserons-nous donner à des adolescents dont la devise est "je m'en fous des risques, je veux du fun !" (oui, on est tous passés par là) un outil qui pourrait se retourner contre eux, et méchamment ?

Ce genre de cas (vol de photos) pourrait se multiplier et cela est uniquement dû au manque de formation. On le rencontre tout le temps dans nos métiers : un utilisateur qui en a marre d'attendre que les "feignants d'informaticiens" pondent l'outil dont ils ont besoin et hop! ils le font, le tableur Excel ou la routine VBA qui va bien pour envoyer un rapport par email. Vous savez, ce rapport, que vous recevez 3.000 fois par jour dans vos boites emails parce que le programme s'est emballé ? Vous savez, cette application qui fait planter le réseau de l'entreprise parce qu'elle ne ferme pas les connexions (ah, vous ne savez pas que l'on doit fermer une connexion ? dommaage...) ?

Le développement est un vrai métier et jouer avec peut faire mal très mal. Vous laisseriez vos enfants monter en haut d'une échelle de pompier sans être encordés ? ou un stagiaire seul dans une Tour de Contrôle ?

Alors que faire, me demanderez-vous ? Laisser nos enfants sans culture de l'informatique ?

Ah. Attendez, ce n'est plus la même chose, le Code et la Culture de l'Informatique.

Car que souhaite-t-on faire au juste ? Leur inculquer les risques sur internet (vol d'identité) ? les protéger des arnaques (phishing) ? des pédophiles (qui se cache derrière un pseudo ?) ? voire tout simplement mieux maîtriser les outils formidables qui sont mis à leur disposition ?


Image courtesy of chanpipat at FreeDigitalPhotos.net

Quand je vois aujourd'hui les moyens fantastiques qui sont accessibles à tous et comment ils sont utilisés, j'ai parfois l'impression que l'on met dans les mains de n'importe qui une Formule 1 alors que le démarrage en côte n'est même pas maîtrisé.

Image courtesy of Feelart at FreeDigitalPhotos.net

Si l'on apprenait à nos enfants les bases de l'informatique (notez que je parle d'informatique, pas de développement), dès leur plus jeune âge, ce serait formidable :
  • qu'est-ce que ordinateur ? un disque dur ? un processeur ? ...
  • qu'est-ce qu'internet ? un serveur ? un routeur ?
  • qu'est-ce qu'un cookie ? une connexion SSO persistante ? les risques associés ?
  • comment choisir son ses mots de passe ? (ah bon, vous n'en avez qu'un ? doommaaaage...)
  • qu'est-ce que le protocole HTTPS ? comment l'utiliser ? comment vérifier qu'il est vraiment sécurisé ? (ah, vous envoyez toutes vos données en clair ou sur un certificat falsifié ? doommaaaage...)
  • ...
Bien sûr, énuméré comme cela, avec les termes techniques, c'est barbant. Mais je ne doute pas que nos enseignants, dont c'est le métier d'enseigner, trouveront les formes à y mettre.

Au fait, nos enseignants... Sont-ils, eux-mêmes, formés à donner ce genre de cours ? parce que c'est quand même un poil technique tout ça...

Je vous donne un indice : Non.
Je vous dis pourquoi je le sais : je suis conjoint et fils d'enseignants...

Et je peux vous dire que, des fois, le PC que je retrouve à la maison, c'est Bagdad !

Et puis, comment l'enseigneraient-ils ?

Parce que l'ordinateur sous Windows 3.1 que ma mère possède dans sa classe (véridique) risque de paraître un peu désuet en comparaison de ce que les enfants ont comme smartphone (dès 10 ans).

Parce que la salle de PCs à laquelle mon père aurait accès avec sa classe serait tellement plus efficace... si l'administrateur de la mairie (qui n'est pas informaticien) savait comment installer correctement un pare-feu et un proxy de manière à ne pas isoler la salle du reste du net.

Parce que ma conjointe serait plus crédible... si elle avait un PC tout court.


Comme je vous le disais en introduction, ce sujet me hérisse les poils pour les raisons que je viens d'évoquer. Mais je n'avais pas eu l'occasion de confronter mon point de vue à d'autres, alors j'hésitais à faire paraître cet article.

Et puis, j'ai eu la chance d'assister à la Blend Web Mix cette semaine, où une conférence était justement dédiée à l'apprentissage du Code... à tous les âges. L'occasion d'aller voir ce qui se dit et déconstruire certains de mes a priori...

Et bien, j'en suis globalement ressorti avec les mêmes idées !

La conférencière, Laurence Bricteux, possède un apparent solide bagage dans le domaine de l'Apprenti du Code puisqu'elle organise elle-même des Ateliers du Code.

Elle est contre l'apprentissage du Code à l'Ecole. Pourquoi ? Parce les enseignants ne sont pas formés à cette discipline exigeante (ah tiens, on se rejoint). Parce que si l'on souhaite ajouter une matière, il faut en enlever une autre : laquelle ? Excellente question ! L'anglais ? On en a besoin pour le Code justement. L'Histoire ? C'est un fondamental pour construire notre culture commune. Le Français ? Heu... pardon. Les Mathématiques ? La Physique ? ... Le Sport ?

Image courtesy of jscreationzs at FreeDigitalPhotos.net

En revanche, elle serait davantage pour l'apprentissage du Code en péri-scolaire. Ce qui a le mérite d'être une contre-proposition intéressante à étudier. Mon avis sur la question rejoint celui que j'ai sur la réforme qui s'est déroulée, il y a peu :

Pour rappel, les activités en péri-scolaire sont organisées et payées par les communes. Comment voulez-vous trouver suffisamment de personnel (qualifié dans le domaine) pour alimenter les écoles des 36.000 communes françaises ? Comment voulez-vous que les petites communes paient ces personnes ? Au final, nous allons assister à une Ecole à deux vitesses (si tant est que ce n'est pas déjà le cas aujourd'hui). Je rappelle également qu'il y a marqué Egalité sur le fronton de toutes nos mairies... Je refuse, idéologiquement, que nos élèves n'aient pas les mêmes chances et accès aux mêmes ressources (ce pourquoi, je suis d'ailleurs plus que réfractaire à la réforme des rythmes scolaires, au moins dans la façon dont elle est organisée...).

On m'a devancé sur une question que je voulais poser : qu'est-ce que les personnes viennent chercher dans les Ateliers de Code qu'organise la conférencière ? Je n'ai honnêtement pas très bien compris la réponse, si tant est qu'il y en ait eu une. J'ai plutôt ressenti que les "élèves" venaient découvrir une nouvelle discipline, comme l'on pourrait s'essayer à un nouveau sport, s'inscrire à la danse ou faire de l'astro-photographie. Ce serait davantage un passe-temps qu'autre chose. Si cela se confirme, on serait quand même loin d'une véritable envie de maîtriser la discipline... Mais on assisterait tout de même à un engouement croissant pour la chose, ce qui est prometteur !

Nous avons eu des chiffres sur les demandes de développeurs en France qui sont bien supérieures aux offres. Pourquoi alors ne pas former des développeurs pour créer ces emplois ? Là encore, la question est intéressante mais (peut-être suis-je pessimiste) j'ai un doute sur la capacité à la réaliser. Il faut au minimum 2 à 3 ans pour former un développeur apte à évoluer en entreprise (au minimum un DUT quoi). Les écoles d'Ingénieur, dont je viens, n'ont plus la côte depuis longtemps : les effectifs recrutés diminuent d'année en année. Ce genre de métier n'attire pas réellement : le développeur a encore l'image d'un geek boutonneux asocial (la Blend Web Mix prouve tout le contraire au passage !). Il faudrait commencer par changer l'image du développeur pour mieux recruter.

Mais je m'égare. Revenons au sujet.

Alors quoi faire ?

Pour moi : enseigner la culture informatique à l'Ecole. Commencer par les bases (cf. plus haut), les risques (comme le font déjà en partie des intervenants de la Gendarmerie Nationale).

Image courtesy of Ohmega1982 at FreeDigitalPhotos.net

L'informatique, le Web, les Réseaux Sociaux sont des outils absolument formidables. Mais ils ont leurs propres règles, leurs propres fonctionnements qu'il faut savoir comprendre, décrypter. Vous connaissez le concept de la Bulle Filtrante dans laquelle vous enferme Google ?

Il faut donner la chance à nos élèves de maîtriser ces outils pour évoluer socialement, personnellement et professionnellement dans un monde qui devient de plus en plus technique, compliqué et qu'il faudra connaître et maîtriser pour réussir.

Une fois que ces bases seront là, alors nous pourrons envisager d'enseigner le Code.

lundi 13 janvier 2014

Question sur l'Agilité : l'estimation doit-elle tenir compte de l'existant ?

Nous avons réalisé vendredi dernier nos premières estimations en points des User Stories que nous proposais notre PO (je dirais modestement : youhou !). Pour la grande majorité aucun souci, mais nous avons cependant été confronté à un petit problème qui nous a laissé plusieurs réponses possibles. Je souhaite vous l'exposer pour connaître votre avis et le partager avec tous.

Nous avons, sur notre application Front Office, une fonctionnalité en version 1 sur le canal desktop. Elle est déployée en production et constitue donc un existant pour notre équipe en charge de faire évoluer le périmètre fonctionnel d'une partie de cette application.

Notre PO nous a fournit 2 User Stories :

  • la première permettant de faire évoluer la fonctionnalité desktop en version 2 (l'ajout métier et les actions à mener sont relativement faibles),
  • la seconde permettant d'implémenter la fonctionnalité directement en version 2 pour le canal mobile.

Au final, la fonctionnalité sera présente à l'identique sur les deux canaux. Le coût (au sens nombre d'actions et charge horaire) pour amener la fonctionnalité au même niveau est cependant différent :
  • pour le desktop, c'est la réalisation du delta version 1 vs. version 2
  • pour le mobile, c'est l'intégralité de la version 1 + version 2

Dans le cadre de l'estimation en points de ces User Stories, nous avions donc plusieurs possibilités :
  1. Considérer que les deux User Stories permettent de livrer la même fonctionnalité au final et que l'estimation en points doit donc être la même pour les deux canaux. Ce sont les actions à mener qui permettront de les différencier. La charge horaire sera donc moindre sur le canal desktop que sur le canal mobile. L'inconvénient est que cela a un impact sur la vélocité en fin de sprint puisque nous aurons au final une différence de temps de réalisation. Si dans un Sprint suivant, nous avons deux User Stories totalement indépendantes et non corrélées mais avec le même nombre de points, nous pourrions ne pas être en mesure de les traiter dans le même intervalle de temps alors que nous avions la même estimation...
  2. Considérer que l'existant (provenant d'un projet non agile ; sans User Story existante) doit rentrer en compte dans l'estimation en points et donc que la livraison de la fonctionnalité sur le desktop doit être estimée plus faiblement que la livraison pour le mobile. Cela nécessite d'avoir une connaissance parfaite de l'existant au moment de l'estimation en points, ce qui n'est pas forcément évident pour une équipe qui se monte dans le cadre "d'un projet d'évolution".
Au-delà du cas particulier des deux User Stories jumelles au canal près, c'est la question de la prise en compte de l'existant qui se pose. Est-ce que l'existant doit nécessairement rentrer en ligne de compte ? ou est-ce la fonctionnalité proprement dite qui est estimée ?

Et y a-t-il une réponse unique ? ou comme dans de nombreux cas en Agilité, est-ce à l'équipe de définir son mode de fonctionnement et de s'y tenir ?

Merci par avance pour vos avis et vos conseils !

lundi 11 novembre 2013

Se concentrer sur les tâches courantes plutôt que sur un but à long terme


Je vous conseille la lecture de cet article publié par @James_Clear, en n'oubliant pas les commentaires qui modulent et éclairent la thèse principale ("no goals at all" est probablement trop fort...).

En résumé, il explique que se donner des buts est une Fausse Bonne Idée. Ces objectifs, dont le planning de réalisation prévu peut ne pas être tenu (le futur est-il prédictible ? non), ne sont que des étapes à l'issu desquelles la motivation disparaît puisque nous ne sommes pas préparés à l'Après (que ce soit un échec ou une réussite). Cela rappelle d'ailleurs la notion de phase dépressive des fins de projet, qui peut conduire certains à avoir peur de terminer un projet et donc ne jamais vraiment le finir (le mieux est l'ennemi du bien...).

L'article conseille donc de se focaliser sur une chose : les tâches courantes, qu'elles soient quotidiennes, hebdomadaires ou mensuelles ; le but étant de définir un process, un mode de fonctionnement qui permettent de tirer le meilleur de vous-même ou de votre équipe.

Toutes ces notions se rapprochent de ce que j'ai compris de celles de l'agilité, en se concentrant ici non pas sur la valeur du produit mais sur la valeur de l'équipe et de son fonctionnement. La thèse de l'article dit qu'il devient inutile d'essayer de forcer une équipe à réaliser un planning, mieux vaut l'organiser pour qu'elle produise le plus possible, donc pour que sa vélocité soit la meilleure. On transforme ainsi la notion de chemin critique (présente dans les plannings) par la notion de vélocité maximale. Plus positif non ?

Les tâches dont parle l'article peuvent être celles qui composent un Sprint : le Daily Meeting, le développement quotidien, la recette, la démonstration de fin de Sprint, ... Bref, tous les rituels Agile et ceux que votre équipe considérera comme améliorant son efficacité. Pourquoi ne pas ajouter du Visual Management, un afterwork au bar local une fois par semaine, la démonstration au client de chaque fonctionnalité par les développeurs eux-mêmes ? L'important est de se concentrer sur la façon dont le travail est fait, de créer et mettre à jour les métriques qui permettront soit de l'améliorer soit de se rendre compte d'un changement. Ce changement peut être positif ou négatif, peu importe. L'important est d'être en mesure de s'en rendre compte afin d'en identifier les causes pour les corriger voire pour les renforcer si elles bénéficient à l'équipe.

Tout cela est facile à dire, mais plus compliqué à défendre lorsqu'un client (qu'il soit interne ou non) nous demande quand son produit sera livré... Mais pour faciliter la transition, comme pour l'Agile, il faut associer le client à la démarche, car il fait partie de cette démarche...

vendredi 8 novembre 2013

Rétrospective de l'Agile Tour Lille 2013

Cet article fait la rétrospective de "mon" Agile Tour Lille 2013, notamment des conférences "Table Ronde des acteurs locaux" et de la keynote de @gojkoadzic.

En introduction d'article, je vous conseille fortement d'aller lire la discussion sur le hashtag  #ATLille sur Twitter. Les propos qui y sont remontés sont particulièrement intéressants.

Contrairement à d'autres conférences sur divers outils, méthodologies ou organisation (je pense au Responsive Design ou au Big Data par exemple), l'Agile Tour Lille 2013 est la seule où aucun acteur ne s'est plaint d'avoir appliqué le cœur du sujet, à savoir les méthodologies Agile. Cela ne veut bien entendu pas dire que l'Agile marche sur tous les projets et dans toutes les conditions :

Cette "approbation" unanime est cependant un signe clair de ce qu'apportent, comme efficacité et comme confort, ces méthodologies aux équipes qui ont fait l'effort de modifier leur façon de penser. Car, à mon sens, ce qui ressort des conférences de cet Agile Tour, c'est que l'Agilité n'est pas une solution, ce n'est pas un ensemble d'outils, ce n'est même pas vraiment une organisation d'équipe, c'est une façon de penser : le produit passe au centre des préoccupations de son équipe. C'est probablement ce que vous pensez faire tous les jours dans votre travail, mais il faut pousser la compréhension de ce concept plus loin.

Puisque le produit passe au centre de vos préoccupations, puisque ce qui vous importe c'est la valeur que ce produit aura pour votre client et pour vous, vous en retirez tout ce qui n'apporte pas une valeur ajoutée pour vous concentrer uniquement sur le cœur de métier de ce produit. Vous économisez ainsi un ensemble d'actions inutilement consommatrices en temps. Exit les réunions inutiles, out les reportings qui ne sont pas demandés... Certains poussent jusqu'à ne produire aucune documentation, puisqu'elle n'apporte rien pour l'utilisateur et puisqu'elle ne sera pas lue... Cela fait peur mais quel est le coût gagné pour la perte subie ?

Et c'est là que la culture de l'entreprise, ou en tout cas la culture des équipes qui interviennent sur le produit, prend toute son importance : si seule l'équipe réalisatrice s'organise pour suivre ces principes, il y a fort à parier qu'elle sera perturbée par des demandes de l'extérieur qui ne tiennent pas compte de la priorisation des actions productrices de valeur.


En suivant ce principe, on améliore une chose qui parle généralement au client : c'est le Time To Market, c'est-à-dire le temps de délivrance en production d'une idée. Sur le Web, il est important que le Time To Market soit le plus court possible, tout en conservant la qualité et la pertinence des fonctionnalités. En priorisant, on élague ce qui gène l'équipe pour avancer rapidement.

Et cela engendre un effet de bord intéressant et, surtout, souhaité : il devient inutile d'écrire des spécifications pour les x mois à venir. On ne sait d'abord pas ce que sera le besoin dans 6 mois (qui a vu un besoin maintenu exactement comme il a été exprimé 6 mois avant ?). La priorisation des prochaines étapes pourra donc avoir changé. Le Cycle en V, qui est une méthode prédictive, ne peut donc marcher intégralement. En exprimant le besoin au fur et à mesure (toujours en ayant un peu d'avance), le produit n'en devient que plus malléable aux besoins du moment. Si une fonctionnalité est systématiquement repoussée, c'est qu'elle ne présente pas un intérêt suffisant et qu'elle peut être abandonnée.

Il est donc important que ce ne soit pas seulement l'équipe IT qui adhère à ces valeurs, mais bien tous ceux qui interviennent dans le projet voire, si possible (mais les transitions sont parfois compliquées voire impossibles structurellement), toute l'entreprise. Une fois que l'on a accepté cela, la mise en place des outils, des rituels agiles n'en est que plus facilité. Et si l'on considère notre façon de travailler, il ne faut parfois pas grand chose pour y passer : nous priorisons tous déjà aujourd'hui :-) Il faut assumer de ne pas seulement repousser mais parfais d'annuler...

Encore une fois, il faut remettre dans le contexte toutes ces notions. Prioriser, c'est prendre en compte la capacité à produire d'une équipe. Si cette équipe est composée d'une personne, il est certain que des fonctionnalités importantes ne seront pas disponibles rapidement. Il faut donc ajuster la taille de l'équipe (ou des équipes ?) en conséquence, tout en se rappelant que 9 femmes ne font pas un bébé en 1 mois ! De manière générale, il ressort que la taille d'équipe idéale est comprise entre 5 et 10 personnes ; c'est la Team Pizza : ceux qui ne peuvent manger à leur faim sur une seule pizza sont de trop !

En conclusion, l'Agile Tour Lille 2013 est un excellent cru, bien meilleur que le dernier que j'avais effectué. Mais peut-être savais-je quoi y chercher ? J'ai également l'impression que ces dernières années ont été un tournant pour le monde Agile : nous sommes passés de projets précurseurs, d'une utilisation de l'Agile parce que c'est "hype" à une utilisation de l'Agile pour ses vraies valeurs et pour ce qu'elle apporte vraiment. Cela devient une façon de faire "pro" dans la tête de beaucoup et cela joue sur son expansion...

jeudi 7 novembre 2013

Spécifications et Tests en utilisant Cucumber et Calabash

Cet article fait la rétrospective de la conférence "Automatisation des Tests sur un projet Mobile iOS / Android à Air France avec Cucumber" présentée par @laurentmeurisse dans le cadre de l'Agile Tour Lille 2013. La présentation elle-même devrait être publiée d'ici peu sur le compte twitter du speaker.

Le projet sur lequel les outils Cucumber et Calabash ont été mis en place est un projet mobile d' @airfrance permettant, entre autres, d'effectuer des réservations de vol. 

Le projet et la mise en place du BDD

Les premières... La première user story du projet donne des sueurs froides à l'équipe : à la fois rédigée en français et anglais, utilisant des termes métier non connus de l'équipe IT, elle fournit un début de schéma algorithmique écrit sous Excel qui cache en réalité des cas complexes. Il est alors décidé de faire la transition vers le Behavior Driven Design (BDD) à l'aide des outils :
  • cucumber (cukes.info), outil actuellement référent dans le BDD, permettant la rédaction par le Product Owner des tests d'acceptance,
  • calabash (calaba.sh), qui permet d'implémenter les tests cucumber sur des interfaces mobile iOS et Android. Il s'agit du standard actuel mais bientôt un plugin (?) Selenium va arriver sur le marché et pourrait devenir un concurrent sérieux.



Le BDD implique que les user stories écrites par le Product Owner restent ainsi les spécifications, comme cela est le cas dans les principes Agiles, mais contiennent en plus les scenarii de tests à implémenter pour valider la fonctionnalité, ainsi que les exemples de scenarii. Cette spécification par l'exemple et ces tests d'acceptance fournissent un avantage certain car ils sont écrits en langue maternelle (français ou anglais au choix de l'équipe) et sont donc compréhensibles par tous sans traduction...

Le BDD fait ressortir les principes suivants :
  • les tests deviennent une responsabilité collective. Exprimés par le Product Owner, ils sont implémentés par l'équipe de développeurs qui doivent s'approprier les scenarii pour les réaliser avant de commencer la fonctionnalité proprement dite.
  • les tests sont les spécifications,
  • les tests sont automatisés et en intégration continue,
  • chaque modification est facilement testable : on fait des petits gaps de tests de façon à éviter de gros refactoring.

En Agilité, et d'autant plus dans les BDD et TDD, la notion de refactoring permanent est très fort. Il faut donc être en mesure de tout retester depuis le début. Les tests d'acceptance implémentés sont ainsi systématiquement rejoués entièrement à chaque exécution (cela rejoins ainsi le principe des tests unitaires et de non régression).

Les outils proprement dits

Cucumber permet l'écriture de tests d'acceptance avec la logique suivante :
  • Chaque feature (fonctionnalité) est testée par un ensemble de scenarii,
  • Chaque scenario est composé d'un ensemble d'étapes du type Given / When / Then,
  • Chaque étape est écrite en langue maternelle et une fonction technique lui est associée (donc implémentée par l'équipe de réalisation).
Les tests d'acceptance doivent pouvoir être compris voire écrits par le Product Owner sans souci et surtout avant même la réalisation de l'application (le BDD est une variante du TDD, où les tests guident donc la réalisation...). Les étapes qu'ils contiennent représentent donc les gestes fonctionnels de l'utilisateur et non pas les actions proprement dites sur l'interface (d'autant plus que cette dernière peut être différente en fonction du support iOS ou Android). Cela permet notamment de réutiliser les tests pour tous les canaux Desktop et Mobile pour peu que les scenarii soient identiques.

Il est cependant nécessaire, pour des raisons à la fois techniques et fonctionnelles, que les scenarii soient indépendant les uns des autres. Il vaut mieux donc éviter de faire appel au scenario "connexion à votre compte" dans le scenario "modification de vos données".

Calabash, quant à lui, permet d'intéragir avec une interface mobile en simulant le support proprement dit. Il est d'ailleurs possible d'afficher une simulation de l'écran mobile sur le poste du développeur (particulièrement pratique pour implémenter puis vérifier les tests).

Calabash fournit ainsi un vocabulaire lié à la gestuelle de l'utilisateur qui permet de donner des ordres à l'application. Exemple : "When I touch button 1" qui ira activer le bouton dont on passera l'identifiant en paramètres.

Comme les interfaces mobiles peuvent être différentes tant fonctionnellement que techniquement, l'implémentation des tests est différente. Ils sont donc à implémenter une fois par canal ciblé.

Dans le cadre du projet présenté lors de la conférence, l'implémentation des tests est faite en ruby, qui est le langage natif de cucumber. Si, malgré sa simplicité de prise en main, le Ruby vous rebute, il est possible de le remplacer par d'autres langages. C'est ainsi Ruby qui ira piloter les ordres passés à Calabash.


Le projet Air France a choisi d'utiliser Jira et Jira Agile pour écrire les user stories, en ajoutant un plugin permettant l'édition en direct des tests d'acceptance. Ces tests sont ensuite automatiquement injectés dans la solution d'intégration continue (Bamboo en l'occurence) qui se charge de lancer cucumber, lui-même faisant appel à Calabash.

Ce que je retiens de la conférence

J'avais commencé à regarder Cucumber et JBehave il y a quelques temps, mais l'expérience n'avait pas été concluante pour plusieurs raisons :
  • le métier n'était pas avec nous, ce qui retire tout l'intérêt. Et oui, nous n'étions pas agiles à l'époque...
  • les tests son arrivés en cours de route et non pas dès le début du projet,
  • le choix des outils n'était pas le plus pertinent, surtout avec notre historique.
Nous ne faisions que du Web Service et n'avions donc pas d'interaction avec les IHM. Nous nous étions cependant posé la question de la façon dont nous aurions procédé. Faute de temps, nous avions abandonné ce point de l'étude. La conférence d'aujourd'hui m'a clairement réconcilié avec ces outils dont la démonstration a mis en avant leur pertinence dans le cadre des méthodologies agiles.

Dixit le speaker, après un petit temps d'adaptation, le Product Owner a été en parfaite mesure d'écrire directement des user stories complètes, comprenant tous les éléments nécessaires à l'équipe réalisatrice. Cela n'a fait que renforcer la proximité, la cohésion et l'efficacité de l'équipe.

Il faut cependant prendre en compte le temps de développement des tests d'acceptance qui n'est pas négligeable : cette méthodologie n'a pas pour objectif de faire gagner du temps mais bien de faciliter la production de fonctionnalités qualitative et surtout de permettre de les faire évoluer tout au long du projet.

Une très belle conférence donc, mené par un speaker investi et convaincant. La solution complète mérite réflexion pour vos projets !

Mission to Mars, ou comment s'initier à l'Agile en s'amusant

Cet article fait la rétrospective de l'atelier "Mission to Mars - Sprint Planning" organisé dans le cadre de l'Agile Tour Lille 2013 et animé par Alexandre Jacob.

Ce premier atelier de la journée nous proposait de jouer sérieusement en participant au jeu "Mission to Mars" qui engage une équipe de 5 personnes dans la construction et le lancement de sa fusée en direction de la planète rouge. L'objectif avoué est de faire découvrir les grandes notions de l'Agile à travers les différentes étapes qui composent les sprints à réaliser.



A noter que d'autres jeux de ce type sont disponibles sur le site www.agileplayground.org.

La mise en place du jeu...

Notre équipe Gravity (ainsi nommée en espérant déjouer les pièges de l'espace) se lance donc dans la construction de sa fusée en groupant 5 participants qui se voient chacun attribuer une fiche de personnage. Nous avons ainsi :
  • 1 architecte
  • 1 expert développeur
  • 1 développeur confirmé qui manipule également un peu l'électronique
  • 1 électronicien très confirmé
  • 1 testeur
Chaque personnage est un réalisateur qui peut, chaque jour, soit :
  • réaliser une tâche dans son domaine de prédilection (architecture, développement, électronique et tests donc) sur la user story en cours,
  • se former pour monter en compétence dans un domaine de son choix, 
  • analyser les user stories à venir,
  • résorber la dette technique qui se crée au fur et à mesure de la réalisation.
Les user stories, qui sont l'expression du besoin du "client" (ou Product Owner), sont déjà écrites mais ne sont dévoilées qu'au fur et à mesure des sprints. L'objectif du jeu est ainsi de réaliser le maximum de user stories :
  • dans un maximum de 6 sprints de 8 jours,
  • dans un maximum d'1h30 (dans le cadre de notre atelier). C'est d'ailleurs bien trop court puisque la notice du jeu conseille davantage 2h / 2h30 que je monterais allègrement à 3h ; délai qui prend en compte les explications et le temps d'approfondir chaque événement pour tirer pleinement profit des enseignements du jeu.
Tout l'intérêt de ce jeu réside donc dans la planification que l'équipe, en totale collaboration et coordination, effectue dans les différents rituels de la méthodologie Agile :
  • Le Sprint Planning s'effectue en début de sprint. Il permet à l'équipe de prendre connaissance des user stories priorisées par le Product Owner et de définir lesquelles composeront le sprint à venir en fonction de l'estimation de charge fournie avec. L'objectif est ici de planifier suffisamment de user stories pour occuper toute l'équipe pendant tout le sprint sans pour autant la surcharger car, rappelons-le, à l'issu du sprint le projet est systématiquement déployé en production. Ce qui ne fonctionne pas est donc un danger, d'autant plus dans le vide spatial !
  • Le Daily Meeting qui permet de se répartir les tâches de la journée en fonction de la user story en cours.
  • La Rétrospective qui permet de faire le bilan du Sprint écoulé, calculer la vélocité de l'équipe (i.e. ce qu'elle a été en mesure de réaliser en ajustant les estimations faites), discuter de ce qui s'est bien et mal passé, etc.
Ce que nous avons fait

Notre stratégie a été de miser sur la formation dès le début du projet. Mon personnage qui avait une double compétence développement / électronique a donc passé tout le premier sprint à accroître ses compétences en électronique pour devenir la variable d'ajustement à venir entre ces deux types de tâches. Nous disposions en effet de deux personnages expérimentés dans ces domaines, mais une deuxième personne en mesure de les seconder tous les deux nous a permis d'accélérer fortement par la suite.

Nous avons également très régulièrement résorbé notre dette technique pour qu'elle soit quasi-nulle à la fin de chaque sprint. Cela nous a permis de ne pas trop subir les embûches que le jeu nous pose aléatoirement.

En 1h30, notre stratégie nous a donc permis de réaliser 3 sprints et 8 des 25 user stories avec une excellente qualité (aucune dette technique) et presque personne en chômage technique (nous avons alors compensé par de la formation).

Ce que le jeu m'a enseigné
  • Au cours de chaque rituel, il est extrêmement important que chacun s'exprime sur les décisions prises par l'équipe. En prenant le temps de discuter des choix, c'est toute l'équipe qui s'engage dans des actions qui prennent en compte l'avis de chacun et permettent de lever les écueils. Il est dommage que nous n'ayons pas eu le temps d'approfondir en détail les rétrospectives et les sprint plannings. Ils sont riches d'enseignement...
  • Quand l'ensemble de l'équipe fait régulièrement l'effort de résorber tour à tour la dette technique, c'est l'ensemble de la qualité du projet, la charge de chacun et la vélocité qui s'en trouve améliorés. L'appel aux experts en tant que bouée de sauvetage se fait ainsi rare et soulage tout le monde.
  • Le premier sprint permet clairement à l'équipe de se découvrir. Le deuxième nous a permis d'accélérer notre capacité à réaliser tandis que le troisième confirmait notre envolée. Notre vélocité n'a donc cessé de progresser tout au long de ses 3 sprints. Dommage que nous n'ayons pas pu mener au bout le jeu car j'étais bien curieux de savoir jusqu'où nous étions capables d'aller...
  • Étonnamment, la formation en début est bien plus bénéfique qu'en fin de projet. Je vous l'apprends ? Oups. Mais surtout cibler la bonne compétence pour la bonne personne est un atout réel, même si cette personne n'est pas experte. Là encore, prendre le temps de poser les choses est un gain pour la suite.
Ce qu'il faut pondérer
  • Le jeu n'est pas une représentation fidèle de la réalité : le Product Owner n'est par exemple pas présent et ne vient donc pas modifier ses user stories en cours de route ; ou encore chacun peut s'occuper de la dette technique alors qu'en réalité le domaine de compétence joue un rôle. Les enseignements que l'on peut tirer de ce jeu sont donc à remettre dans votre contexte. Il vous permet cependant de découvrir et surtout mettre en oeuvre très facilement les principes de l'Agile et de prendre la mesure de son potentiel.
  • Si vous avez peu de temps devant vous, avoir les notions, mêmes basiques, des principes Agiles vous permettra de bien mieux profiter pleinement du jeu. Un facilitateur dédié à l'équipe est ainsi un point... facilitant.

En conclusion, je dirais que ce jeu est une véritable introduction à l'Agilité et qu'une équipe non formée à ces principes peut bien perdre 3 heures à s'y amuser, elles seront rentabilisées ensuite... Un excellent exercice que je vous engage donc à faire... si vous pensez à prendre du recul après mais aussi pendant le jeu !

mardi 27 août 2013

Tracer son propre chemin

L'autonomie ; que ce soit dans la vie privée ou professionnelle, je suis convaincu que c'est l'une des valeurs reines. Je parle ici non seulement d'être capable d'agir de manière autonome mais également de raisonner, concevoir, anticiper, organiser seul.

Je ne dis pas qu'il faut systématiquement opérer tout seul dans son coin (voire même qu'il vaut mieux éviter, l'humain peut et doit être social), mais il faut être en mesure de le faire, non seulement en ayant la capacité manuelle et/ou intellectuelle de le faire, mais également en ayant le recul nécessaire pour se dire que dans une situation donnée nous ne devons rien attendre d'un groupe et en ayant le courage de se lancer seul, parfois contre vents et marées.

Car oui, l'autonomie est risquée. Elle implique de se mettre en danger en tirant des conclusions, en prenant des initiatives... en ayant des idées tout simplement, mais surtout en les assumant et en les partageant. Parfois ces idées ne se révèlent pas judicieuses. Pour certains, seule une minorité d'entre elles sera pertinente ; pour d'autres une majorité. C'est probablement ce qui fait les génies. Les appliquer, c'est ce qui fait les entrepreneurs. Thomas Edison disait :
Vision without execution is hallucination.
Beaucoup attendent de voire comment la majorité d'un groupe oriente ses idées voire les expose, pour ensuite les suivre, les appliquer voire les prendre à leur compte. Un tel comportement revient à se cacher derrière le groupe, derrière ceux qui ont eu le courage d'exposer leurs idées et de les soumettre à la critique de tous. Car être autonome, c'est accepter de se mettre en danger, de se soumettre au regard des autres. Et cela fait peur à beaucoup, en particulier dans un monde où l'apparence compte, chaque jour, de plus en plus.

Mais si chacun suivait continuellement l'avis du groupe, ne proposait rien de nouveau ou de différent, sous prétexte que l'idée risquerait d'être rejetée, alors le groupe n'évoluerait plus, se scléroserait et finirait par disparaître. Il faut donc des personnes qui osent, qui tentent. Non pas des personnes pour qui l'avis d'autrui ne compte pas, non pas des personnes pour qui l'avis d'autrui filtre les idées mais pour qui l'avis d'autrui donne une idée sur la qualité d'une proposition. Car si la majorité a souvent raison, il lui arrive également d'avoir tort et il faut être capable de soutenir, de défendre une idée dans laquelle l'on croit, quitte parfois à devoir secouer le cocotier...

L'humilité doit nécessairement accompagner celui qui ose. Elle lui permettra d'accepter plus facilement le risque d'émettre une idée à d'autres, de prendre en compte leurs avis et d'avoir le courage d'abandonner en reconnaissant son erreur. Car la peur de soumettre une idée n'est rien d'autre que la peur de se tromper, la peur de reconnaître une hypothétique faiblesse. Manquer de courage n'est-il pas cependant une faiblesse plus importante que manquer de discernement ou de jugement ? Se tromper peut être passager et corrigé en comprenant la raison de l'erreur ; se cacher devient en revanche vite une habitude.

L'humain est par nature grégaire. Il se regroupe avec d'autres individus du même genre et imite le comportement, parfois inconsciemment. Il faut que chacun dépasse cette condition pour influencer, positivement, le groupe, son comportement et donc son mouvement.

Apprendre à tracer son propre chemin, en fonction de sa propre personnalité, de ses envies, de ses valeurs ; c'est être apprendre à être libre. Libre de la peur des autres, de la peur de l'inconnu. C'est utiliser pleinement ce pour quoi des Hommes se sont battus : la liberté de conscience, la liberté de parole, la liberté d'entreprendre ; toujours dans le Respect d'autrui bien sûr, la première des valeurs selon moi.

Tracez votre propre chemin. Exposez vos idées. Parlez aussi avec vos tripes.

Vous mènerez peut-être ainsi un projet, une équipe, une entreprise dans votre vie professionnelle. Vous mènerez surtout votre vie. Ne laissez par le groupe décider pour vous et laissez encore moins votre peur vous empêcher d'être vous !