Archives par mot-clé : méthode agile

Demander l’avis du dev

Je déjeunais, tranquillement (Jardin du Palais Royal, il y a pire), assis sur un banc.

S’assoie juste derrière moi une jeune fille et un garçon.

La fille parle fort, donc je l’entends :

Bon tu vois, machin, je l’aime pas. Il est dev, il doit rester à sa place.

Nous on a passé des heures à définir une fonction, on va pas tout remettre en question parce qu’il se pose des questions.

On a défini le besoin, à lui de le développer, point.

Le “dev” n’a qu’à s’exécuter, et développer la magnifique fonction définie par les équipes marketing, ou métier, ou produit (suivant les organisations).

Quelle erreur !

Si vous faites ça, vous vous privez de beaucoup de choses :

  • Il est très démotivant d’être traité comme un simple exécutant. Vous risquez de faire partir les meilleurs, vous risquez des postures d’oppositions systématiques, vous risquez la montée de tensions entre les équipes, chacune positionnée en sniper vis à vis de l’autre ;
  • Vous perdez une bonne partie du “cerveau” de l’équipe technique. Vous ne lui demandez pas son avis ? Très bien, elle va développer en suivant les spécifications. Mais attention, j’espère que vous aurez bien pensé à tout…

Il faut bien comprendre que, certe, vous avez passé du temps à définir, analyser une fonction. Mais l’équipe technique va passer encore plus de temps à la développer.

Il est fondamental qu’elle s’approprie le besoin et la solution.

Les “devs” peuvent remettre en question les choix ? Et pourquoi  pas ? Si votre travail est très bien préparé, les fondamentaux doivent résister. Et si l’équipe technique propose des améliorations, c’est parfait ! Ils se sentiront complètement intégrés dans le processus, et seront bien plus motivés pour faire un “truc qui marche”, et la solution sera meilleure que ce qui était prévu au début.

C’est une des raisons qui font qu’on doit bosser en méthode agile. L’équipe métier n’est pas séparée de l’équipe technique. Les équipes bossent ensemble, de manière itérative.

Alors, ça se passe comment chez vous ?

 

Développement agile pour Target2sell

Pour le développement de Target2Sell, on est parti, dès le début, avec une organisation basée sur Scrum.

C’est une méthodologie agile, basée sur quelques idées simples.

A la base, les méthodes agiles se sont développées en alternative aux solutions “historiques” du type Merise et autre “cycle en V”.

Au début de Target2Sell, l’organisation agile nous a permis de sortir une nouvelle version tous les 15 jours.

Aujourd’hui, on est à un rythme bien plus rapide. On a gardé l’organisation en sprint de 15 jours, mais on fait des mises en productions bien plus rapides, 1 à 2 par semaine.

Accélérer les mises en production apporte un vrai confort : cela permet de pousser des évolutions par petites étapes. C’est bien plus facile que de pousser un “gros cailloux”, avec tous les risques que cela comporte.

Pour faire ça, il faut avoir quelques éléments en place :

JP notre “animateur agile” a commencé par mettre en place une infrastructure “dev-ops” parfaitement huilée :

  • Sources gérés sur sur git, hébergés sur github
  • Tests unitaires : pour que la version en cours puisse être poussée en production, il faut que le code passe au travers un grand nombre de programmes de tests. Actuellement : 550 tests unitaires, et 70 tests d’intégrations (basé sur JUnit)
  • Processus de build, géré par buildr, qui permet de construire et déployer automatiquement les différentes versions : intégration, pré production et production.

Tout vert :)

Concrètement, une mise en production, c’est quelques minutes de travail, c’est un “non évènement” comme dit JP.

Alors, pourquoi pas vous ? Pourquoi ne pas utiliser les méthodes agiles pour développer les sites e-commerces ?

 

Faire du logiciel, c’est une histoire de processus et de culture

Bon, je commence par expliquer que faire du logiciel, c’est de l’artisanat.

Et ensuite, je fait un billet ou je parle de processus ?

Oui, et les deux sont parfaitement compatibles !

Dans le billet précédent, j’explique, pour faire simple, que ce qui compte, avant tout, c’est la compétence des équipes. Chaque développeur doit être au top.

Après, il ne s’agit pas simplement de mettre X développeurs et d’attendre que le temps passe.

S’il est complètement fondamental de responsabiliser au maximum chaque développeur, il est également indispensable de mettre en place des méthodes, des processus très précis.

A ce titre, je vous conseille de regarder cette vidéo, qui explique les processus en place chez Facebook :

Facebook a un processus de mise à jour qui permet une mise en production tous les jours (!!!)

Donc, pour reprendre le titre :

La culture, c’est celle du dieu code.

Les processus, ce sont toutes ces méthodes et outils qui permettent d’automatiser au maximum la chaîne de production, tout en gardant le maximum de responsabilité entre les mains des développeurs.

Les méthodes à mettre en place sont bien sûr basées sur les méthodes agiles.

Etude pour améliorer un site et méthode agile

Ce billet fait suite à la conférence organisée par Adobe.

J’ai trouvé le débat intéressant, et j’espère ne pas avoir été le seul de cet avis ;).

Un des sujets dont on a parlé : comment faire cohabiter intelligemment l’analyse ergonomique, les tests utilisateurs, avec la vie du site, la road map ?

Une option, qui me semble particulièrement intéressante, est de mettre en oeuvre une approche agile.

On pilote le projet en le faisant évoluer par petites itérations, au lieu du “big bang” de 18 mois.

Et bien, on peut doit tout à fait travailler en parallèle une approche orienté utilisateur, qui sera synchronisée avec les itérations mise en oeuvres avec la méthode agile.

C’est une très bonne pratique.

Par contre, on ne peut mettre en oeuvre une telle méthode que si l’entreprise qui héberge le projet est convaincu de l’intérêt d’une telle méthode, au niveau des décideurs.

Autre retour d’expérience qui m’a semblé fondamental : quand on accompagne une refonte, ou un projet e-commerce, il est très important d’accompagner le client sur l’ensemble de la durée de vie du projet.

Il arrive malheureusement souvent que les résultats des études utilisateurs ne soient pas bien mises en oeuvre : elles restent dans un tiroir…

Grandeur et décadences de l’objet

L’objet, c’est un élément fondateur de l’informatique moderne.

On programme objet, on peut analyser avec une approche objet…

Mais d’abord, c’est quoi ce truc ?

L’approche objet est à la base une évolution “naturelle” des techniques de programmation.

Un peu d’histoire :

L’informatique a commencé avec des langages “barbares”, ou en tout cas de bas niveau : assembleur, cobol…

Puis sont venus les langages fonctionnels et structurés.

Fini les GOTO, et bienvenue aux variables locales !

Cela a constitué une avancée fondamentale :

Le programme est 1000 fois plus lisible, 1000 fois plus réutilisable.

Il y a eu d’autres pistes explorées : les langages de type Intelligence Artificielle (Prolog), les langages purement fonctionnels (Camel & co), …

Et puis il y a eu l’objet.

Derrière l’objet, il y a plusieurs idées fondatrices :

L’une des idées est de se dire que les structures de données sont clées, et finalement plus centrales, plus stables que les fonctions.

Bref, le truc objet a bien pris, et la plupart des langages modernes sont objets : C#, Java, PHP…

ça, c’est la grandeur des objets.

Mais les objets auraient pu aller à pleins d’autres endroits.

Il y a eu ainsi de magnifiques projets de bases de données objets (O2 mon amour 😉 ).

J’en parlais ce soir avec mon amis Hubert, qui de son côté a travaillé sur un projet d’OS objet.

A ce propos, Microsoft devait intégrer une base de données objet à la place du file system de Vista… Projet abandonné.

Tout ça, c’est la décadence de l’objet !

Il n’y a pas de base de données objet sérieuse sur le marché.

Les OS ne sont pas objets.

Le file system est très loin d’être remplacé par une base objet…

Pourquoi “tant de haine” ?

C’est une histoire qui me fascine d’autant plus qu’elle me ramène à ma propre histoire : dans les années 90, j’avais monté un projet de bases de données objet, persuadé que c’était l’avenir.

On peut dire que pour les bases de données, cela n’a pas pris parce que ce que les gens attendent d’une base de données, c’est de stocker des données, et pas tellement de savoir comment elles sont structurées.

Je n’adhère pas à l’argument, parce que cet argument aurait très bien pu jouer contre les langages de programmation…

Je pense qu’en fait, il y a sûrement une part de hazard là dedans… Et si ça se trouve, on aura bel et bien de belles bases de données objets dans les années à venir ! N’oublions pas que cette histoire est en cours d’écriture !

Méthode agile ou road map : contradiction ?

Soirée sympa hier soir, invité par Adobe, avec Michael, Yann & Olivier.

Avec Yann, on a toujours des discussions passionnantes sur le logiciel, et son avenir.

Il faut dire qu’on a une culture assez proche : NeXT, UML, …

Donc, on a parlé développement, et j’ai évoqué l’intérêt de méthodes agiles, comme Scrum.

Puis, un peu plus tard, j’ai parlé d’un aspect important de mon métier : “l’évangélisation” sur les métiers du logiciel, et en particulier l’importance de se projeter dans la durée, de travailler sur une road map.

Contradiction ?

D’un côté, les méthodes agiles. On avance par petites étapes (15 jours par exemple). A chaque étape, on doit avoir un système qui tourne.

C’est donc une méthode très itérative.

De l’autre côté, l’idée de road map, c’est la planification dans la durée du projet.

Les deux approches sont complémentaires !

La road map permet de définir les grandes étapes du projet.

La méthode agile est le processus pour avancer, le long de la road map donc.

Donc non, à mon sens, Yann, il n’y a pas de contradiction entre les méthodes agiles et le fait de définir une road map produit !