Lecture de : Gestion de Projet eXtreme Programming

 

Je viens de lire le livre “Gestion de projet, eXtreme Programming” qui décrit la méthode Agile du même nom. Ce livre se découpe en 3 parties.

Les pratiques de l’Extreme Programming

Les valeurs de bases d’eXtreme Programming

Pour que les pratiques de l’eXtreme Programming fonctionne, il est nécessaire de respecter 4 valeurs.

  • La communication pour une meilleure visibilité

La communication est en effet un point indispensable dans une équipe XP. Lorsqu’on parle de communication, il s’agit surtout de communication directe (orale). Elle favorise en effet le transfert de compétence, la détection de problème, l’entraide au sein de l’équipe et la confiance entre le client et l’entreprise.

  • La simplicité comme garantie de productivité

Côté client, c’est à lui de définir ce dont il a réellement besoin et d’y mettre des priorités. Côté développeur,  il est inutile de s’occuper de cas qui n’arriveront peut-être jamais. C’est en appliquant cette simplicité que la rapidité de développement et la possibilité de changement seront favorisées.

  • Le feedback comme outil de réduction du risque

Le feedback est au coeur de la méthode eXtreme Programming. En effet, elle est gage de qualité. On retrouve la notion de feedback à différentes échelles du projet : des tests unitaires au tests de recettes jusqu’à la structure itérative de la méthode.

  • Le courage de prendre les bonnes décisions

Le courage est une qualité qu’il faut pour pouvoir respecter les trois précédentes valeurs. Il faut du courage pour se focaliser uniquement sur ce dont on a besoin, de maintenir une transparence en communiquant sur nos difficultés(et nos atouts) et admettre les différents feedbacks comme par exemple devoir jeter une partie de code qu’on aurait créé et qui ne conviendrait pas.

Les règles d’eXtreme Programming

Il existe 13 régles si on veut respecter l’eXtreme Programming. Celles-ci se découpe en 3 catégories :

Les pratiques de programmation

  • Une conception simple (simple design) : inutile d’inventer des mécanismes génériques, le “péché mignon” du développeur, si ce n’est pas nécessaire. Il faut toujours implémenter la solution la plus simple.
  • Le remaniement (refactoring) : Il est important que les développeurs reviennent  sur leur code pour le rendre plus simple, enlever les parties inutilisées.
  • Développement piloté par les tests unitaires(Test Driven Developpement) : Le développeur écrit des tests unitaires avant d’écrire le code. Cette pratique lui permet de bien structurer dans son esprit ce qu’il veut faire ainsi que d’éviter le phénomène de régression.
  • Test de recette (acceptance test) : Ces tests sont créés par le client. Il lui permet de définir les objectifs que les développeurs doivent atteindre. Si le test passe, alors la fonctionnalité est validée tel que le client la veut.

Les pratiques de collaboration

  • Programmation en binôme (pair programming) : Les développeurs doivent développer en binôme (deux par ordinateur). Cela permet une relecture en temps réel du code. Les binômes sont changés régulièrement
  • Responsabilité collective du code (collective code ownership : Les développeurs travaillent en binôme et changent régulièrement, ainsi, chacun travaille sur chaque partie de l’application. Chacun à le devoir d’améliorer le code même s’il n’en est pas l’auteur.
  • Règle de codage (coding standards) : Des règles de codage sont décidées au début du projet. Chacun doit s’y tenir afin de garantir la cohérence du code et ainsi faciliter la modification de celui-ci par n’importe quel développeur.
  • Métaphore : Le système ainsi que les sous-systèmes doivent être décrit par des métaphores ceci dans le but de faciliter la communication.
  • Intégration continue (continuous integrated) : Les développeurs doivent synchroniser le plus souvent possible leur travail afin de faciliter le processus d’intégration.

Les pratiques de gestion de projet

  • Livraisons fréquentes (fréquent releases) : Le logiciel doit être livré régulièrement. Cela permet au client ainsi qu’aux développeurs de s’assurer que le produit correspond bien aux attentes.
  • Planification itérative (planning game) : Lors d’une réunion dédiée, le planning décrivant l’itération en cours est décidé par le client et l’équipe de développement.
  • Client sur site (on-site customer) : Le client doit être intégré à l’équipe, la communication est ainsi optimale. Le client au sens eXtreme Programming n’est pas forcément le client au sens commun. Le client, au sens XP, est celui qui prend les décisions et qui est capable de répondre aux questions des développeurs.
  • Rythme durable (sustainable pace) : L’équipe de développement doit avoir un rythme qui peut être conserver tout le long du projet. Ce rythme doit favoriser le travail de qualité. Les périodes de “rush” sont à éviter.

Les rôles eXtreme Programming

EXtreme Programming définit six rôles principaux dans un projet IT :

  • Le programmeur : c’est le développeur. Dans son rôle XP, il est responsabilisé. En effet, sa proximité avec le client ainsi que le respect des différentes règles(dont la responsabilité collective du code) responsabilise et revalorise le métier de développeur.
  • Le client : Le client au sens XP est celui qui est présent au sein de l’équipe de développement, qui répond aux questions des développeurs et définit la priorité dans laquelle doit être implémenter les fonctionnalités. Il a le devoir de fournir un feedback aux développeurs ainsi que des tests de recette.
  • Le testeur :  le testeur est le bras droit du client. C’est à lui que revient la tâche d’installer les outils nécessaires à l’intégration continus, des tests de recettes et unitaires. Il est également là pour aider le client à créer les test de recette.
  • Le tracker :  Le tracker est là pour suivre l’avancement des tâches au sein d’une itération. Son rôle est donc de détecter au plus vite les éventuelles difficultés qui surviennent afin de les résoudre le plus vite possible. Ce rôle doit être évité d’être tenu par un membre hiérarchique supérieur afin d’empêcher un sentiment de surveillance.
  • Le manager : C’est le supérieur hiérarchique des développeurs. Il est là pour demander des comptes(à son équipe XP comme au client) et fournir les moyens humains et matériels pour l’avancement du projet. Il ne participe qu’aux réunions de planification et doit donc faire confiance à son équipe XP pour la réalisation du projet.
  • Le coach : Le coach est le garant du respect des règles eXtreme Programming. C’est à lui que revient le rôle de mettre en place la méthode. Son objectif est que l’équipe puisse fonctionner sans lui. Il doit donc s’armer de courage pour dire les choses telles qu’elles sont.
Un des objectifs de toutes ces règles est de pouvoir faire face aux changements réguliers d’un projet IT. Voici une évolution que l’on retrouve souvent dans les projets IT :
Et voici la courbe du coût du changement revue par les auteurs d’eXtreme Programming :

Facteur de compétitivité des entreprises

Dans la deuxième partie du livre, les auteurs d’eXtreme Programming nous explique la mise en place d’eXtreme Programming et ce que cela lui apporte.

Par où commence-t-on?

Dans une première partie, on nous explique la façon d’amener la méthode eXtreme Programming. En effet, certaines pratiques d’eXtreme Programming peuvent être vues par l’entreprise comme une perte de rentabilité(la programmation en binôme) ou alors comme du “flicage” pour les développeurs(le rôle de tracker par exemple).

La formation de toute l’équipe à l’eXtreme Programming est indispensable. Il est d’ailleurs important de souligner que la philosophie d’eXtreme Programming insiste dans le fait que toute l’équipe doit participer aux diverses formations. 3 différentes méthodes sont communiquées dans le livre :

  • Le coaching : un consultant eXtreme Programming est présent dans l’entreprise et joue le rôle de coach.
  • L’immersion XP : L’équipe se rend à une formation sur plusieurs jours et est encadrée par une entreprise de formation dans la création d’un projet fictif en utilisant les pratiques eXtreme Programming.
  • L’Heure Extreme : Ce sont des ateliers d’environ une heure mettant en pratique une notion d’eXtreme Programming.
Toutes les pratiques eXtreme Programming peuvent être dures à mettre en place dans une équipe. Il est donc recommandé de commencer par certaines pratiques comme la planification itérative et l’élaboration des tests unitaires avant le code.

Coûts et retours sur investissement

Cette partie du livre décrit les conséquences et la manipulation des variables clés qui font d’un projet XP une réussite.

Les variables clés

Les auteurs d’eXtreme Programming identifie 4 variables clés dans le déroulement d’un projet :

  1. Les coûts directs et indirects
  2. La qualité livrée
  3. La durée des projets
  4. Le périmètre fonctionnel des projets

Le livre nous explique les mécanismes de ces 4 variables ainsi que de leur inter-dépendance. Suite à cette analyse, la seule variable qui ressort manipulable est le périmètre fonctionnel des projets. En effet, il est impensable de diminuer la qualité du produit. Il est possible de modifier les coûts et le temps de développement mais le client ne sera pas satisfait. Par contre, réduire le nombre de fonctionnalités d’une version pour conserver la qualité, le coût et la durée de développement sera plus envisageable par le client.

Les auteurs listent ensuite les coût directs (exemples : la main-d’oeuvre, logiciels) ainsi que les coût indirects (exemples : les coûts du turn-over, défauts de qualité). Puis, on nous montre comment la méthode eXtrem Programming influe sur ces coûts, parfois en les augmentant comme pour la présence du client sur site, mais souvent en les diminuant. Les diminutions sont surtout visible sur les coûts indirects. En effet, les pratiques d’eXtreme Programming décrivent un environnement de travail serein au sein de l’équipe diminuant fortement le turn-over et le travail en binôme ainsi que les tests favorisent un travail de qualité.

Les aspects contractuelles

L’eXtreme Programming pose une certaine problématique lors de l’aspect contractuelle. En effet, la méthode n’est pas applicable suivant le type de contrat. En France, il existe 3 types de contrats:

  1. Les contrats forfaitaires : Le client définit un cahier des charges précis et contactera une société de service pour le mettre en oeuvre.
  2. Les contrats d’assistance technique : Le client définit et met en oeuvre le cahier des charges en faisant appel à du personnel compétent chez un fournisseur.
  3. Les contrats d’assistance forfaitée : Le client contacte un fournisseur qui lui fournira une équipe entière chargé de la réalisation du projet.

Seul le dernier contrat est véritablement adapté à la méthode XP (bien qu’il est possible de l’appliquer au second). En effet, le fait que ce soit une équipe en charge de la réalisation et d’être chez le client, le déploiement de la méthode est favorisé. Cependant, les auteurs du livre souligne le fait qu’il va falloir adapter les termes du contrat pour pouvoir spécifier les principes d’XP tels que le travail en binôme et le rythme durable par exemple. Le droit d’arrêt du projet est également donné au client, la méthode XP, grâce à sa structure itérative ainsi qu’aux livraisons d’un logiciel fonctionnel favorise la facture de ce qui est déjà fait.

Qualité et processus

Les auteurs du livre nous rappelle ce qu’est la norme iso:9000 ainsi que ces 8 principes.

  1. L’orientation client
  2. Leadership
  3. Implication du personnel
  4. Approche processus
  5. Management par approche système
  6. Amélioration continue
  7. Approche factuelle pour la prise de décision
  8. Relations mutuellement bénéfiques avec les fournisseurs

On nous explique alors les convergences entre l’eXtreme Programming et cette norme ainsi que les différents processus tel que les indicateurs de qualité(tests unitaires, recette) qui inscrivent XP dans la norme ISO:9001.

Méthodologie

Les auteurs nous expliquent que la méthode eXtreme Programming s’inscrit dans un mouvement plus vaste : celui de l’Agilité. Pour qu’une méthode soit validée comme étant agile, elle doit respecter le manifeste Agile :

L’importance est donnée:

  • aux individus et aux interactions plus qu’aux processus et aux outils
  • à des logiciels immédiatement disponibles plus qu’à une documentation exhaustive
  • à la collaboration avec le client plus qu’à la négociation contractuelle
  • à la réactivité face au changement plus qu’au respect d’un plan


Les méthodes Agiles s’appuient sur ces 4 valeurs clés et se différencient par la suite par leurs principes et leurs pratiques. Le livre nous décrit en quelques lignes d’autres méthode tel que Crystal, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development Model(DSDM) ou encore Scrum.

Etudes de cas

Dans cette dernière partie, 2 études de cas nous sont décrites. La première relate la réalisation d’un projet Web dans une équipe qui met en place pour la première fois eXtreme Programming. L’étude est analysée au rythme des itérations. La seconde étude de cas relate quant à elle un projet industriel. On nous explique alors la mise en place de la méthode XP avec les succès et les échecs à travers les points de vue des différents rôles.

Conclusion

La lecture de ce livre m’a appris énormément sur la méthode XP. J’ai cherché à travers ce billet de transmettre certaines valeurs de cette méthode. Seulement, ne vous contentez pas de ce billet pour la mettre en place. Je vous invite en effet à lire le livre pour comprendre les fondements de ces valeurs ainsi que l’importance qu’y attache eXtreme Programming. Le livre met également l’accent sur le fait que mettre en place eXtreme Programming n’est pas un objectif mais une base. On nous invite, une fois mise en place, à la modifier pour qu’elle s’adapte parfaitement à notre environnement de travail.

Devcamp #2 Rennes

Ce 14 novembre 2012 s’est déroulé le deuxième Devcamp à la Cantine Numérique Rennaise. Le thème de cette soirée était le déploiement d’application sur des serveurs. 5 intervenants nous ont fait découvrir leurs solutions dans des lightning Talk de 10min.

Fabric ton déploiement

Florian STRZELECKI nous fait découvrir Fabric, un logiciel python qui nous permet de déployer nos applications sur plusieurs serveurs. Fabric nous permet de définir des rôles pour chaque serveur afin de personnaliser ses déploiements. Fabric se configure à l’aide d’une fichier de configuration en python. Il ne nous reste plus qu’à utiliser les commandes Fabric pour lancer nos déploiements! Et tout ceci côté client, inutile d’installer Fabric sur chaque serveur.

Capistrano

Capistrano est présenté par Thierry HENRIO. Cette outils fait sensiblement la même chose que Fabric mise à part que celui-ci est développé en Ruby. Il utilise un système de plugin(ou Recipes) permettant de pouvoir utiliser des scripts déjà existant. Tout comme Fabric, Capistrano ne nécessite pas son installation sur nos différents serveurs.

GitHub Pages et IWantMyName

Guillaume COLLIC via un retour d’expérience sur la création de codeouest.org nous fait découvrir 2 services : IWantMyName et GithubPages

IWantMyName est un site web nous permettant de créer uniquement notre nom de domaine. Il possède ensuite un market (ou store) dans lequel différents services sont présentés. On peut alors lié un service voulu à notre nom domaine. Si la démarche ne peut pas se faire automatiquement, une explication précise sur la démarche est donné.

Guillaume nous présente ensuite Github Pages, un service qui nous permet d’héberger des pages web statiques sur un dépôt git. On peut utiliser ce service avec IWantMyName pour le lié à notre nom de domaine.

Puppet

Puppet est un outil également développer en ruby nous permettant le déploiement d’application sur les serveurs. Il nécessite son installation sur chaque serveur.

From scratch to deploy

Nicolas Ledez nous présente, à travers une démo en direct, la façon dont un administrateur système, un développeur et un intégrateur web travaille avec les outils découvert plus haut.

Conclusion

Ce deuxième Devcamp a été riche en échange et en découverte. Le regroupement de développeur passionné multi-techno donne une ambiance chaleureuse. Vivement le 12 décembre pour assister à la troisième édition! 🙂

Les gestionnaires de versions

Lors de la conception d’une application ou d’un logiciel, il est indispensable de suivre  son évolution à travers des versions. Cela nous permet de revenir au besoin à une version antérieur ou bien de sauvegarder une version 1.0, de développer une version 2.0 ajoutant de nouvelles fonctionnalités tout en corrigeant les bugs qui pourrait survenir dans la version 1.0 en sortant des patch 1.1, 1.2, etc…

Il y a trois types de sauvegarde :

  • Complète : Ce type de sauvegarde est le plus fiable mais aussi le plus gourmand en mémoire. Il sauvegarde à chaque nouvelle version l’intégralité des fichiers modifiés ou non.
  • Incrémentielle (ou incrémental) : Chaque sauvegarde enregistre les modifications effectuées par rapport à la précédente sauvegarde(incrémental ou complète).  Cette méthode de sauvegarde est la plus rapide mais pas la plus fiable. En effet, afin de restaurer une version, il nous faudra la dernière sauvegarde complète ainsi que toutes les sauvegardes incrémentales jusqu’à la version voulu. En cas de perte d’une de ces versions, il est impossible de restaurer la version voulu.
  • Différentielle : Chaque sauvegarde enregistre les modifications effectuées par rapport à la dernière sauvegarde complète. Cette méthode est moins rapide que la sauvegarde incrémentielle mais plus fiable. En effet, afin de restaurer une version, il nous suffit d’avoir la version complète et uniquement la sauvegarde différentielle de la version voulu.
Sans appui logiciel, cette tâche s’avère très fastidieuse voir impossible. Une des méthodes consistait en effet à créer une copie des fichiers dans un autre répertoire. Il était donc courant d’oublier de faire une copie, de supprimer un de ses répertoires, d’oublier de faire les mise à jour 1.1 et 1.2 dans la version 2.0, etc…

Ainsi il existe différents logiciels qui s’occupent de gérer ces versions.Ils sont divisés en trois catégories :

  • LVCS : Local Version Control System
  • CVCS : Centralized Version Control System
  • DVCS : Distributed Version Control System

LVCS

LVCS (Local Version Control System ) est le système le plus simple pour gérer ses versions. En effet, les LVCSs possèdent une base de données local afin de sauvegarder les versions. Cette méthode est aussi la moins fiable. En effet, si l’on perd le disque dur, la version du logiciel sur laquelle nous travaillons ainsi que les autres sont perdues. De plus, un LVCS est inadapté pour un projet en équipe.

RCS est un des LVCS les plus connus.

Schéma d’un LVCS :

 

CVCS

CVCS (Centralized Version Control System) est un système ayant un dépôt référent situé sur un serveur. Il apporte une solution aux développeurs travaillant en équipe. C’est le serveur qui se charge de sauvegarder l’historique des versions et qui sert de référent. Il est possible pour l’administrateur du serveur de gérer les droits des développeurs. Ce système est le standard pour  les gestionnaires de version bien que les DVCS apparaissent de plus en plus. En effet, les CVCSs ont trois principaux inconvénients. Premièrement, le travail hors-connexion est impossible, le développeur ayant besoin d’être synchroniser avec le serveur. Deuxièmement, en cas de perte du serveur(et de non backup), toute les anciennes versions sont perdus. Enfin, le système CVCS empêche l’utilisateur de travailler en mode “brouillon”. En effet, chaque version est forcément placer sur le serveur principal, il est donc impossible de pouvoir travailler sur des versions d’essais en local pour ensuite faire un commit sur le serveur principal.

Subversion(SVN) et CVS sont les CVCSs plus connus.

Schéma d’un CVCS :

DVCS

 Les DVCS (Distributed Version Control System) est un système où le dépôt(le regroupement des différentes sauvegardes des versions) situé sur le serveur est dupliquée sur l’ensemble des développeurs. Ce système offre plusieurs avantage : Il permet aux développeurs de pouvoir continuer à travailler hors-connexion. De plus, le développeur peut ainsi utiliser son dépôt local pour réaliser des brouillons et ainsi éviter de gêner les autres développeurs avec des versions “inutiles”. En cas de perte sur le serveur principal, il suffit de le restaurer en prenant une copie situé sur l’ordinateur d’un des développeurs. L’inconvénient principal de ce système réside dans le fait que l’administrateur du serveur possède moins de contrôle sur les fichiers. Par exemple, il ne pourra pas empêcher la mise à jour de fichier sur le dépôt local d’un développeur. Le second est que ce système consomme plus de mémoire(étant donné qu’on copie le dépôt du serveur sur sa machine local).
Git est le plus connu des DVCSs.
Schéma d’un DVCS :

Vocabulaire

Quelque soit le système de gestion de version que l’on utilise, on rencontre plus au moins le même vocabulaire. Voici les mots que l’on rencontre le plus :
  • Working copy : C’est les fichiers locales sur lesquelles on travaille.
  • Repository : C’est le répertoire de votre projet contenant la version du projet du côté du gestionnaire de versions.
  • Commit : C’est la version que l’on envoie sur votre gestionnaire de versions.
  • Branche : C’est l’axe de développement de votre application, il peut y avoir un axe développement et un axe production par exemple.
  • Merge : c’est l’action de fusionner de deux branches.
  • Flag/Tags : c’est un tag que l’on place sur un commit précis. Par exemple : Version 1.0

 

Agile Tour Nantes 2012

L’Agile Tour Nantes 2012 s’est déroulé hier(le 15 Novembre), c’était pour moi l’occasion de découvrir le milieu de l’Agilité. N’ayant très peu voir aucune notion d’agilité, celle-ci ne me paraissait juste qu’un ensemble de méthodes que l’on appliquaient à la gestion de projet. Cette journée m’aura cependant fait découvrir que l’Agilité, c’est bien plus que ça.

La Keynote : On est Agile!

La journée commence donc par une Keynote, et c’est Tremeur BALBOUS, coach agiliste, qui s’en charge. Tout d’abord il va nous parler de constats personnels qu’il a constaté lorsque les entreprises veulent se mettre à l’Agilité. Il nous dit que les bénéfices attendus ne sont pas la réalité. L’Agilité a pourtant fait ses preuves. Pourquoi donc les objectifs ne sont-il pas atteints?

Tremeur nous explique alors que l’Agilité ne sont pas de simples méthodes qu’il faut appliquer mais une philosophie. Vouloir employer l’Agilité au sein d’une équipe, c’est changer sa façon de d’être, de travailler. Nous sommes, explique-t-il habitué dès notre plus jeune âge a exécuter les tâches que l’on nous assigne (parents/enfants-professeur/étudiant-patron/employé). Il va falloir donc changer nos habitudes et c’est sur ce point là que se base le leit motiv de la keynote de Tremeur : le changement.

Tremeur nous fait part de son expérience et nous explique que c’est le manque de compréhension de l’Agilité qui a fait que les entreprises n’ont pas obtenu les résultats souhaités. L’Agilité est une philosophie qui doit d’abord être appliquer à soi-même. Or c’est ce point primordiale qui n’est pas respecter. Cependant, Tremeur va plus loin que de simplement mettre la faute sur ce point là. Il nous amène à nous interroger sur la cause de cette faute. Ce n’est pas un manque de volonté de notre part. Pour lui, cela vient du fait que l’Homme possède un système immunitaire contre le changement afin de se protéger. Ce système immunitaire est si efficace qu’il nous protège même des changements que l’on veut appliquer. Bien sûr, ce n’est pas une fatalité. Grâce à un travail sur soi, il est possible de “dompter” ce système immunitaire. Tremeur finis la keynote en nous invitant à suivre cette voie, il nous invite à changer nous même. C’est en faisant ce travail que nous comprendront la philosophie de l’Agilité qui est de favoriser le changement et donc à l’appliquer correctement.

 

Introduction à l’Agilité

Cécilia BOSSARD et Cécile ESPECEL nous font découvrir l’Agilité au cours de cette session d’une petite heure. Pour jouer le jeu jusqu’au bout, un tableau est mise dans la salle, ayant trois colonnes : A faire, en cours, Terminé. Au début de la session, une dizaine de post-it sont affichés dans la colonne à faire. Progressivement, ceux-ci passeront dans la colonne “en cours” puis “Terminé”.

Au cours de cette session, Cécilia et Cécile. Elle nous interrogeront sur les causes qui ont amené à un projet réussi. Les principales causes étaient la souplesse dans le projet, l’environnement dans lequel  travaille l’équipe, le proximité du client, etc… Elle nous expliquent alors comment l’Agilité va tenter de favoriser ces causes. Tout d’abord, elles nous présentent les concepts et les principes de l’Agilité pour ensuite s’attarder sur deux méthodes : Scrum et Kanban.

 

Immunothérapie pour le changement

Toujours sur le même leit motiv que sa keynote, Tremeur BALBOUS nous explique les blocages qui nous freine dans le changement et comment y faire face. Ce n’est pas un manque de motivation mais notre cerveau qui fait trop bien son travail. Cette session ne peut être résumé avec mes simples mots, cela revient à tenter de résumer un cours de philosophie ce dont je suis particulièrement mauvais. Sachez seulement que cette session était intéressante et qu’y participer une seconde fois ne serait pas de trop. Je remercie Tremeur pour cette excellente initiation à l’immunothérapie.

 

1986 : Pourquoi Scrum

Dans ce ligthning talk de 15-20 minutes, Fabrice AIMETTI nous raconte l’histoire de la méthode Scrum. Il nous explique que l’étude faite par 2 japonais sur des équipes travaillant sur des produis innovants (donc en proie au changement) ont relevé 6 caractéristiques expliquant les résultats positifs de celles-ci:

  1. L’instabilité intrinsèque
  2. L’auto-organisation
  3. Le recouvrement des différentes phases de cycle de développement
  4. L’apprentissage globale et multiple
  5. Le contrôle subtile
  6. Le transfert de la connaissance dans l’organisation

Par la suite, 2 américain (Ken Scwaber et Jeff Sutherland) utiliseront cette étude pour créer une méthode de travail favorisant ces 6 caractériques qu’il vont nommé Scrum.

Dans un deuxième temps, Fabrice nous fera découvrir les diverses mutations que cette méthode à subit pour arriver à celle qu’elle est actuellement.

Agilité dans la mobilité

Dans ce second Ligthning Talk, Alvin Berthelot nous explique en quoi l’Agilité est particulièrement adapté au développement mobile. En effet, qui dit mobile, dit changement. Alvin relève plusieurs constats dans le développement mobile :

  • L’Interface Utilisateur est différents en fonction des terminaux.
  • De nouvelles fonctionnalité arrivent chaque année voir tout les 6 mois et nous contraint à changer nos projets.
  • La mobilité regorge d’opportunité qu’il faut saisir rapidement.
  • Il faut offrir les fonctionnalités dans un espace visuel réduit de 80% à l’espace habituel
  • Il faut affronté des écosystèmes parfois obscur (la validation des market par exemple)
Alvin nous explique comment l’Agilité tente de faire face à ces constats.

Le paradigme de l’ingénieur dans un imaginaire ubiquitaire

C’est par une Keynote un peu particulière que démarre l’après midi. Celle-ci est dispensée par Aurélien JEANJEAN et  Florent LAROCHE et nous présente l’association “La machine”. Cette association créait des proto-industriel qui devront prendre vie. A travers de témoignage, Aurélien et Florent nous montre que la science, la technique et l’humanité sont l’essence du métier d’ingénieur. Il nous feront découvrir la structure interne atypique de cette association.

 

Les agilistes anonymes, pourvu qu’il ne nous arrive rien!

Au travers un retour d’expérience, Guillaume CRASSARD nous fait part des difficultés qu’il a rencontré lors de la mise en place d’Agilité au sein d’une équipe. Il compare avec humour la différence de la mise en place d’agilité  entre les livres et la réalité plus particulièrement autour de la méthode Scrum. En effet sur le terrain, rien ne se passe comme prévu.

Au cours de cette session, Guillaume nous a donc fait part des obstacles rencontrés et comment il les a géré. Il nous explique par exemple comment l’enthousiasme de l’utilisation de Scrum a progressivement fait place à un certain essoufflement et comment il a redynamisé son équipe. Il nous à fait part également des réussites de l’application de Scrum comme l’auto-organisation ou bien de la flexibilité du nombre de personnes dans l’équipe.

Enfin, il nous expliquera pourquoi de la méthode Scrum, il est passé à la méthode Kanban.

Outils pour un développement agile

Ce Ligthning Talk présenté par Florian KLEIN nous présente quelques outils pour un développement agile. Il nous parlera alors de BDD (Behavior Driven Developpement), c’est à dire utiliser un langage compréhensible entre le client et le développeur au travers de tests fonctionnel de l’application.

Kanban Game

C’est avec un serious game encadré par Laurent MORISSEAU et Patrice BOISIEAU que je finis cette journée. Ce jeu nous permet de comprendre comment Kanban permet de mettre en évidence certains problèmes que l’on rencontre lors de la création d’un produit et comment il va nous aider à améliorer notre processus de développement.

Conclusion

Si je devais retenir une notion de cette journée, ce serait d’accepter le changement. Au cours de cette journée, j’ai découvert l’univers de l’Agilité et surtout ce que ce mot signifie. Je remercie tout les organisateurs et les speakers pour cette journée qui m’aura fait découvrir une nouvelle approche de la gestion de projet.

Les slides des sessions seront bientôt disponible.

Lien : http://at2012.agiletour.org/fr/nantes.html

Twitter : @atnantes, @agilenantes

Enfin le planning complet:

Dart

Présentation

Dart est un langage développé par Google et dévoilé en octobre 2011. Il a pour objectif de remplacer JavaScript en apportant un langage plus structuré pour développer des applications web. Le SDK comprends :

  • Le langage Dart
  • Les librairies Dart
  • Le compilateur Dart-to-JavaScript
  • Pub : le gestionnaire de paquets pour Dart
  • La VM Dart

Deux outils viennent compléter le SDK : L’éditeur Dart et Dartium (un navigateur).

Le langage Dart

Dart est un langage client et serveur qui s’inspire de nombreux langages :

source

On retrouve donc tous les concepts de l’orienté objet de C# avec les classes et l’héritage. Le langage est mono-thread mais utilise le concept d’Isolates de l’Erlang (programmation concurrente). La syntaxe est proche du JavaScript. Les développeurs Java, C# et JavaScript n’auront  pas de mal à développer avec Dart. L’extension d’un fichier dart est « .dart ».

Pour plus d’info sur le langage : dart

Un exemple de code Dart :

Les librairies Dart

Le SDK Dart fournit de nombreuses librairies pour nous aider à développer des applications web. Voici  3 exemples de librairies. Pour plus d’info : Librairies

Dart : core

La librairie dart : core est automatiquement intégré à tous les programmes Dart, elle fournit des éléments essentiels comme l’objet Number, String, les collections ou encore les expressions régulières.

Dart : io

La librairie dart :io n’est pas utilisable par les applications basées dans le navigateur. Elle fournit des API afin de gérer les fichiers, les dossiers, les processus, les sockets et les ressources HTTP. Par exemple, on utilisera cette librairie pour créer un serveur HTTP.

Dart : html

Dart : html n’est utilisable que pour les applications web. Elle fournit des APIs pour manipuler le DOM et accéder aux APIs  HTML5 (Storage et WebSocket par exemple).

Pub

Pub est le gestionnaire de paquets pour Dart. Il permet de récupérer du code,  des bundles ou des librairies que la communauté Dart a partagées. Le gestionnaire fait partie du SDK et a été installé au même moment. Il faudra ajouter une variable d’environnement pointant vers le dossier bin de Dart.

Insérer un paquet dans un projet :

Il faut définir créer/modifier  le fichier pubspec.yaml. C’est ce fichier qui va servir à renseigner les paquets qui seront utilisés dans l’application. Voici un exemple de ficher pubspec.yaml :


Pour installer un paquet, on utilisera la commande « pub install ». Pub installe dans le projet les paquets renseignés par le fichier pubspec.yaml.


Il ne reste plus qu’à importer le paquet dans notre fichier à l’aide de la ligne suivante :


Pour plus d’info : http://pub.dartlang.org/

VM dart

Le langage Dart a besoin de la VM Dart pour être interprété. Celle-ci a fournis par le SDK. La VM peut alors exécuter le programme Dart en deux modes : checked et production.

En mode checked, le compilateur prend en compte les déclarations « assert » et lancera des exceptions si celles-ci sont égales à « false ».

En mode production, ces déclarations sont ignorées.

Pour lancer la VM Dart, autrement dit compiler un fichier Dart, la ligne de commande est la suivante :


Cette méthode n’est utilisable que pour les applications en ligne de commande.

Dartium

Afin de lancer une application web écrite en Dart, Google a modifié son navigateur Chromium (version de développement de Chrome) afin d’y installer une VM Dart donnant ainsi naissance au navigateur Dartium. Celui-ci peut donc nativement exécuter les fichiers Dart.

Attention, Dartium est une preview et n’est donc pas à utiliser en navigateur principale.

Le compilateur Dart-to-JavaScript

Etant donné que la VM Dart n’est pas installé sur les navigateurs. Google fournit un compilateur afin de transformer le code Dart en code JavaScript.  Le compilateur est fourni par le SDK actuel mais il est également possible de le télécharger séparément. Pour lancer le compilateur, il suffit d’utiliser la ligne de commande ci-dessous :


Le compilateur nous donnera alors un fichier .js.

Dart Editor

Afin de faciliter le développement, Google a mis en place un éditeur spécifique pour Dart : Dart Editor. Celui intègre tous les outils énoncés plus haut : le langage, l’auto-complétion,  le gestionnaire de paquets « Pub », Dartium, le compilateur Dart-To-JavaScript, etc…

Synthèse

Points positifs

  • Dart est un langage structuré dont le but est de créer des applications web.
  • Dart est un langage client et serveur. Il est ainsi nécessaire de connaître qu’un seul langage pour développer coté serveur et côté client (bien qu’il faut tout de même connaître le langage HTML et CSS).
  • Dart  possède son propre éditeur rendant plus facile le développement et le  débogage.
  • Dart possède un gestionnaire de paquets rendant plus facile le partage de code.
  • Dart est open source.

Points négatifs

  • Dart nécessite une VM pour pouvoir être exécuté. Or celle-ci est indisponible pour les navigateurs principaux. Il nous faut donc convertir nos fichiers Dart en fichier js avec le compilateur Dart-to-JavaScript.
  • Dart est un langage très jeune (1 an) est n’est pour l’instant pas destiné à la production.

Conclusion

Bien que toujours en développement et donc inexploitable aujourd’hui pour de la production, Dart est un langage qui possède de réelles capacités à devenir un concurrent à JavaScript.