Accueil / Blog / Métier / 2013 / Retours de l'Agile Tour 2013 à Toulouse

Retours de l'Agile Tour 2013 à Toulouse

Par Romain Garrigues — publié 16/10/2013
Résumé des conférences de l'Agile Tour auxquelles Makina Corpus a participé.

Makina Corpus était présent à l'Agile Tour 2013 qui s'est déroulé au centre de congrès Diagora Labège à Toulouse.

Voici un résumé succinct des différentes conférences auxquelles nous avons assisté.

La "horde agile"

par Pablo Pernot

La "horde agile" nous permettait de faire un lien très intéressant entre notre nature "profonde", remontant à des millénaires, et les méthodes de travail que nous essayons de mettre en place chaque jour. L'agilité est-elle contre-nature, ou l'a-t-on perdue au fil du temps ?

Entre parallèles avec le modèle de la pyramide de Maslow et le(s) nombre(s) de Dunbar, l'étude de cette mémoire permet d'adapter aujourd'hui nos méthodes de travail.

Nous dédierons un post de blog à ce sujet.

L’agilité au MiPih, 18 mois après...

par Loïc Chapron, Luc Auvray, Marianne Jullien, Mohammed Ouchani et Séverine Sabatier

Cette conférence consistait en un retour d'expérience de la mise en place de l'agilité au sein du MiPih, éditeur de progiciel leader dans le domaine des Systèmes d'Information Hospitaliers (400 agents sur 4 agences).

Elle s'est effectuée en 3 étapes (équipe de plus en plus expérimentée en agilité), et a vu ses différents acteurs évoluer au fil des projets.

Le détail de ces étapes, ainsi que les retours des principaux protagonistes (product owner, scrum master, testeurs, ...), vont faire l'objet d'un petit billet.

La culture du backlog

par Claude Aubry

Le but de cette conférence était de trouver des solutions à des problématiques récurrentes :

  • mieux connaître les stories en début de sprint ;
  • pouvoir injecter des changements pendant le sprint ;
  • avoir une meilleure idée de l'avancement ;
  • éviter les gros backlog de début.

La solution présentée consiste à rediviser les différentes étapes de vie des stories via un certain nombre de "bacs" (bac à sable, bac à features, bac de culture, bac de départ, ...), afin de pouvoir gérer au mieux l'évolution de ces stories avant d'être réalisées dans un sprint :

  • le "bac à sable" est la première étape de toute feature/epic/story. Toutes les idées peuvent être positionnées ici ;
  • le "bac à features" contient les features que l'on souhaite réaliser ;
  • le "bac de culture" contient les stories tirées des features que l'on va réaliser dans les sprints qui arrivent. Cette étape implique un échange avec le client afin d'étoffer les stories, les préciser, en discuter, les faire évoluer afin d'être parfaitement clair sur le travail à effectuer ;
  • le "bac à glace" contient les stories que l'on sait nécessaires, mais pas dans la release courante ;
  • le "bac de départ" contient les stories qui sont prêtes à être intégrées dans un sprint ;
  • le "bac de sprint" contient les stories à réaliser durant le sprint courant ;
  • le "bac de récolte" contient les stories réalisées.

Avoir plus d'étapes permet d'éviter de pâtir d'un énorme backlog en découpant les différentes phases de préparation des stories, et permet de mettre en avant les stories nécessaires, celle qui ont besoin d'être précisées, celles qui sont prêtes à être faites, etc.

Celebrity Prioritisation : jouez à prioriser

par Grégory Alexandre

Un paquebot où voyagent quelques célébrités commence à sombrer dans les eaux de l'Atlantique ; l'équipe a 7 minutes pour décider dans quel ordre elle va évacuer les célébrités. 

Un jeu très intéressant pour forcer un groupe qui ne se connaît pas à mettre en place un processus de "priorisation" :

  • la première équipe a mis en place des critères très objectifs (homme/femme, jeune/vieux, faible/fort) et a procédé à l'évacuation très rapidement en commençant par les extrêmes ;
  • la deuxième a mis en place un processus très simple (jeton) où chacun a pu choisir une célébrité et apporter des corrections jusqu'à la fin du temps imparti ;
  • la troisième a échoué : ses membres ont passé beaucoup trop de temps à définir des critères de nature subjective (universalité, éthique), et l'évacuation n'a pas pu se faire complètement.

Le consensus des critères est la clé de la satisfaction, mais il faut absolument limiter le temps pour aboutir.

La scierie à pratiques

par Pablo Pernot et Stéphane Langlois

Le but de cet atelier était de découper nos pratiques afin qu'il n'en reste qu'une, mettant ainsi en évidence la substantifique moelle de celles-ci : leurs fondements, leurs raisons d'être. 
Chaque équipe a fait le choix d'un contexte fictif (démarrage de projet, startup, projet mûr) et a disposé de dix minutes pour lister un maximum de pratiques agiles qu'elle souhaiterait mettre en place. On a procédé ensuite à une série de "rounds" pour prioriser les pratiques selon les critères et méthodes de l'équipe, pour à la fin n'en garder que deux.

Parmi les pratiques retenues, on retrouve :

  • visual management ;
  • daily meeting ;
  • backlog ;
  • Clean Code ;
  • continuous Integration.
Le "dot voting" s'est avéré la méthode la plus efficace pour choisir : chaque personne disposait de 3 points à répartir entre les différentes pratiques, et celles qui ont récolté le plus de points ont été choisies.

(Accéder aux règles de cet atelier)

Introduire l'agilité en grande entreprise : 3 ans chez Orange TV

par Anne-Françoise Marie et Julien Cimetiere

Deux agilistes d'Orange présentaient les méthodes qu'ils ont réussi à pousser dans un environnement a priori hostile :

  • projets très complexes ;
  • culture de l'entreprise très ancrée dans le cycle en V ;
  • enjeux commerciaux colossaux ;
  • pression sur les équipes très forte ;
  • éclatement géographiquement des différents acteurs ;
  • plusieurs développeurs et chefs de projets novices en agilité;
  • socle logiciel commun, avec des déploiements dans divers pays, sur différentes plateformes, une certaine viscosité fonctionnelle et beaucoup d'incertitudes d'intégration.
L'équipe Orange TV (30 pers.) a réussi à mettre en place des sprints Scrum pour les développements et du Kanban pour les phases de bug fix.
Les sprints des différents projets ont été synchronisés sur un rythme de 4 semaines pour gérer notamment la fusion des évolutions et bug fixes de chaque pays dans le tronc commun.

En phase de maintenance, le passage à des livraisons quotidiennes a permis de fluidifier et décontracter les échanges entre la production et les développeurs.

Le mythe du framework agile

par Jean-Baptiste Dusseault

Les frameworks web se prétendent agiles mais le sont-ils réellement ?
Coder une application type blog axée sur un pattern CRUD va effectivement être très rapide. Mais qu'en est-il pour un métier plus complexe et un projet plus gros ?
Les framework imposent beaucoup de couplage, par exemple avec la base de donnée ou la présentation. Il n'est ainsi pas possible de tester la partie métier sans la partie persistance.

Une réflexion plus poussée sur le sujet est disponible.

Projets Agiles : si nous parlions de documentation ?

par Jean-Michel Inglebert

La méthodologie Scrum s'attache à minimiser la documentation. Ses préceptes sont les suivants:

  • on ne commence pas par de la documentation ;
  • seule la documentation utile est nécessaire ;
  • la documentation doit être ciblée.
En suivant ces principes, la documentation sera grandement facilitée par l'application de l'intégration continue et par la mise en place de tests automatiques. Ainsi, la documentation système sera réduite au script de déploiement qui doit être réalisé dans le cadre de l'intégration continue. Un administrateur système étant tout à fait capable de comprendre le langage d'un script, ce document sera suffisant.

Concernant la documentation développeur, lors de l'implémentation, les tests unitaires correctement commentés constitueront l'information utile et suffisante. Par ailleurs, un code bien commenté peut, à l'aide d'outils de génération de documentation, constituer une documentation suffisante pour comprendre l'architecture d'une application.

Concernant la documentation utilisateur, une part de rédaction devra être nécessaire. Cependant, certains outils peuvent aider dans l'élaboration de cette documentation. L'utilisation de la BDD avec des outils comme Fitnesse (rédaction d'exemples métier et tests d'acceptance) permettra d'avoir l'essentiel de la documentation. Par ailleurs, les tests automatiques d'IHM pourront permettre d'obtenir les captures d'écran nécessaires à l'illustration de la documentation.

Software Craftsmanship

par Antoine Vernois

Ce mouvement a pour objectif de produire du code de qualité, via un certain nombre de règles élémentaires auxquelles il ne faut pas se soustraire.

Le code propre, réutilisable, lisible ainsi que les tests associés font partie intégrante de ce processus, et ne peuvent pas être sacrifiés sur l'autel du "manque de temps". Antoine était venu nous présenter plusieurs points fondamentaux lors d'un BrownBagLunch dans nos locaux.

Si vous voulez en savoir plus sur les préceptes de cet esprit, nous consacrerons un billet dédié à ce sujet.

ABONNEZ-VOUS À LA NEWSLETTER !
Voir aussi
Agilité et bonheur au travail : retours sur l'Agile Tour de Toulouse Agilité et bonheur au travail : retours sur l'Agile Tour de Toulouse 10/12/2015

Makina Corpus nous raconte l'Agile Tour Toulouse #attls 2015.

Des jeux pour apprendre 20/10/2011

Agilité et télétravail 24/10/2011

Comment pratiquer l'agilité dans une équipe à distance ?

Bien démarrer avec Scrum Bien démarrer avec Scrum 17/12/2015

Pour rester agile, ne jamais se focaliser sur la méthode.

Les outils de gestion de projet : Taiga Les outils de gestion de projet : Taiga 16/12/2015

Testons Taiga, outil Open Source de gestion de projet en méthodologie scrum ou kanban