Partager du code JavaScript client/server

Update : Pour ceux ayant lu l’article avant le 15/05/2013, la solution n’était pas bonne. L’article est mis à jour avec une autre solution qui elle, fonctionne 😀
L’avantage d’utiliser le JavaScript (CoffeeScript dans mon cas) côté serveur  (avec nodejs) et côté client, est de pouvoir partager du code.

Seulement un petit problème se pose. En effet, côté client, afin de créer un système de module, la solution la plus connue est d’utiliser RequireJS. Celle-ci s’appuie sur l’AMD (Asynchronus Module Definition) alors que côté serveur, nodejs repose sur CommonJS qui a une structure différente.

La première solution est de créer deux fichiers ayant la même fonction métier mais avec une structure différente. Pas très avantageuse, on a de la redondance alors qu’on travaille avec le même langage…

La deuxième solution consiste à importer la librairie requirejs dans node puis de l’utiliser. Je ne m’étendrais pas plus sur celle-ci dans ce billet.

Une autre solution consiste à modifier un peu nos fichiers JavaScript(ou CoffeeScript) afin qu’il soit compatible CommonJS du côté serveur et AMD côté client. Alors comment procéder ? Voici l’exemple de deux fichiers ayant la même fonction métier. C’est une simple classe avec une dépendance.

serveur :


client :


Le premier problème que nous voyons est que la classe Dog n’est pas au même niveau(en terme de scope) dans les deux fichiers. Côté serveur elle se situe dans le scope du “fichier” tandis que côté client, elle se trouve dans le scope de la fonction define.

Donc dans un premier temps, nous allons changer la structure du fichier sous RequireJS afin de faire ressortir la classe Dog afin qu’elle soit dans le scope voulu.


Petite parenthèse, lorsque je dis que le scope sera au niveau du fichier, cela ne signifie pas que le scope est le fichier. En effet, si on regarde comment est compilé ce fichier en JavaScript, on voit que le tout est englobé dans une fonction dont le scope est this(passé en paramètre de la fonction call) :


Notre scope “au niveau du fichier” est ce qu’est this à la dernière ligne (window par exemple du côté client). Si vous ne comprenez pas bien la manière dont fonctionnent les scopes, revoyez les notions de this, de scopes et de closures, c’est indispensable de bien comprendre ces notions lorsqu’on fait du JavaScript 🙂

Passons maintenant à la deuxième étape qui est de fusionner nos deux fichiers en un seul. L’astuce consiste à tester quelque chose qui nous permettra de déterminer de quel côté nous sommes. Ici j’ai choisi de tester la variable window. En effet côté serveur, celle-ci n’existe pas. On aurait pu aussi tester la méthode define : si celle-ci n’existe pas, alors nous sommes côté serveur. Bref, voici au final ce que ça donne :


Notre fichier est maintenant compatible AMD et CommonJS 🙂 On voit qu’il y a trois parties : la première concerne la déclaration de Burd ainsi l’import des dépendances avec CommonJS, la seconde notre code métier et la troisième l’import/export d’AMD ainsi que l’export de CommonJS.

Je vous met également la version JavaScript(qui sera donc utilisée côté client) :

Retour d’expérience TypeScript

Screen Shot 2013-04-26 at 10.13.51 PM

Aujourd’hui, j’ai commencé un nouveau projet nodejs. Cette fois-ci, j’ai choisi d’utiliser TypeScript pour voir ce que ça donne.

Je classerais ce post comme un “fourre-tout”. J’y metterais plusieurs choses que je remarquerais, mais que je n’ai pas encore approfondi. Je rajouterais petit à petit des retours. J’essaierais ensuite, de creuser chaque retour pour en faire un “vrai” post.

L’importation de librairies javascript :

Point noir de ce côté. TypeScript a un compilateur qui vérifie que les méthodes utilisées dans nos fichiers js sont existantes. Jusque là, aucun souci. Seulement, lors de l’utilisation d’une librairie, le compilateur typescript nous renverra une erreur nous disant que la méthode(de la librairie) n’existe pas…

Quand on y réfléchit, c’est tout à fait logique. Comment TypeScript peut-il savoir quelles sont les méthodes existantes dans un fichier js?

Afin que le compilateur sache quelles sont les fonctions qui existent et dans quels “modules”; il va falloir créer un fichier qui les répertories. D’après ce que j’ai pu voir, le convention de nommage serait mylibray.d.js. Si ce fichier est déjà présent dans les sources de la librairie (comme nodejs,express ou jquery), l’effort n’est pas forcément énorme (il faut ajouter ///<reference path=’node.d.ts’/> au début du fichier ). Seulement, si votre librairie ne dispose pas de ce fichier…vous êtes bon pour l’écrire.

Apparemment, l’importation de fichier ts n’aurait pas ce problème. Je ne peux pas trop en dire plus, je n’en sais pas plus.

Je détaillerais ça dans un autre post avec des informations plus précises et plus exactes.

 

ScrumDay 2013

Logo-Scrum-Day-20131

Le 11 avril dernier s’est tenu à Paris dans les locaux d’IBM le ScrumDay. Grâce à Guillaume Collic, j’ai pu m’y rendre et découvrir cet évènement pour la première fois.

La keynote d’ouverture

La journée a commencé avec la keynote de Robert RICHMAN “Culture Hacking”, celle-ci était en anglais et je n’ai malheureusement pas pu comprendre tous les messages qu’a voulu nous faire passer Robert Richman. Ce qu’il y a, je pense, à retenir de cette keynote est, l’importance de l’aspect humain dans l’entreprise et de l’importance des rituels (comme fêter un anniversaire). Le message général que Robert a voulu nous faire passer est qu’il est important qu’un employé soit content de venir travailler. Un employé content de sa condition dans l’entreprise est beaucoup plus productif. L’agilité est bien entendu  en accord avec ce message.

Les sessions

La première session, présenté par Sébastien Delest, était un retour d’expérience  sur l’intégration continu. L’intégration continu permet en effet de réduire considérablement l’étape d’intégration d’un projet qui consiste à regrouper le code des différentes parties d’une application. L’intégration continu permet de le faire à chaque commit. Les tests de non-régression assurent toujours la stabilité de l’application.

La deuxième était un retour d’expérience sur la mise en œuvre d’un projet mobile en Scrum. Il était très intéressant de voir que l’agilité à permis de mieux appréhender ce projet surtout par le biais de la communication et de la visibilité entre les équipes.  Merci à Cyrille DERUEL ainsi qu’à Elise PEYRET.

La troisième session était, quant à elle, une session un peu plus détendu.  Christophe HERAL  nous a fait une analogie sur la manière de jouer des joueurs de starcraft  II à l’agilité. Et si ces joueurs faisaient de l’agilité sans le savoir? Un joueur de starcraft doit en effet avoir la capacité de s’adapter au changement (en fonction de ce que joue son adversaire). Pour cela, il a besoin de visibilité, d’indicateur. Il doit pouvoir priorisé ses actions, etc… Identifier, traiter les signaux et les comportements freinant l’adoption de l’Agilité est un sujet primordial pour toute entreprise décidant de se placer sous le parapluie de l’agilité. C’était justement le sujet de la quatrième session. Celle-ci était organisée en un échange entre les occupants de la salle, ayant pour support une fiche faisant état de plusieurs de ces signaux. La session a eu plus de succès que prévu, merci à Eric Siber !

Laurent Morisseau (auteur du livre “Kanban pour l’IT” présenté ici)  ) était le speaker de la session «#OMG, mon équipe fait son haka en Kanban Style », partisan de la méthode Kanban, Laurent nous a démontré comment Kanban pouvait s’inscrire dans un contexte Scrum pour y apporter des problèmes…  ou

La keynote de clôture

Enfin, la journée s’est terminée sur une Keynote de clôture  par Dominique DUPAGNE. Celle-ci avait pour but de nous démontrer que le corps humain était agile et qu’il était impossible de tout prévoir. Il est important pour une entreprise de pouvoir s’adapter face à une situation, comme le fait le corps humain contre une maladie.

Devcamp #7

slider-devcamp7

Le Mercredi 10 avril prochain à 18h30 se tiendra le devcamp n°7 à la CNR(cantine numérique rennaise). Celui-ci met à l’honneur le lancement de la communauté JavaScript de Rennes dont je ferais partis.

Pour ceux qui ne connaissent pas le principe du devcamp, celui-ci est un évènement regroupant les développeurs(mais pas que) issues de nombreuses technologies comme le  .net, cocoa,java, python, ruby, javaScript, web, etc… Le but étant de partager ensemble (connaissances, actualités et trolls :D). Les présentations peuvent être de différents formats bien que le plus pratique qu’on est trouvé est le lightning talk(ou LT : conférence d’une dizaine de minutes).

Lors de ce devcamp, j’animerais 2 LT :

1er : Découvrez CoffeeScript et TypeScript
2eme : WebStorm : (enfin) un IDE pour JavaScript/CoffeeScript/Dart

Il y aura également 2 autres LT animé par Nicolas Pennec et Florian Strzelecki qui porteront respectivement sur AngularJS et la maîtrise des events en JavaScript.

N’hésitez pas également à vous inscrire sur la mailing-list : devcamps@lacantine-rennes.net

Retrouvez plus d’information sur la cantine numérique rennaise :

Lecture de : Kanban pour l’IT

kanban

Kanban pour l’IT est un livre écrit par Laurent Morisseau. Il nous explique comment la méthode Kanban va nous permettre d’améliorer nos processus de développement. Dans une première partie, Laurent nous explique les concepts de Kanban. Dans la seconde partie du livre, Laurent met un place une équipe et une société fictive pour avoir un fil conducteur sur la mise en place de la méthode Kanban. On y voit les difficultés rencontrées ainsi que les bonnes pratiques a adopté. Cela permet également de rentrer dans le noyau de la méthode Kanban.

 

Introduction

Avant de parler des concepts de la méthode Kanban, je vais, comme Laurent l’a fait dans son livre, définir les mots de vocabulaire que je vais utilisé.

  • Kanban : Avec un K majuscule est utilisé pour désigner la méthode Kanban.
  • kanban : Avec un k minuscule désigne les outils de visualisation utilisé de la méthode Kanban.

Les concepts de Kanban

Objectif du Kanban

L’objectif de Kanban de réduire voir éliminer les situations de surcharge de travail et de gérer les flux de demandes variables. C’est donc un moyen d’équilibrer notre chaîne de processus pour l’accomplissement d’un projet. En d’autres mots, Kanban à pour objectif de trouver un équilibre entre la demande et la capacité d’un système kanban.

Capacité d’un système Kanban

La capacité d’un système Kanban est constitué de 3 indicateurs:

  1. Le débit du système : c’est le nombre moyen d’éléments produits par unité de temps(exemple : 10 éléments par semaine).
  2. le temps de traversé : c’est le temps moyen d’un élément passe dans le processus de réalisation(de la demande à la livraison).
  3. la performance à la date d’échéance : c’est le pourcentage d’éléments livrés à la date d’échéance par rapport au nombre total d’éléments.

Les fondations

Kanban repose sur trois piliers :

  1. Commencer par ce que vous faîtes maintenant
  2. Respecter le processus actuel, les rôles et responsabilités
  3. S’engager à changer de manière incrémentale et évolutive

Le premier pilier s’explique par le fait qu’un changement trop rapide entraîne de la résistance de la part  des membres de l’équipe. En contrepartie, Kanban peut ne pas donner des résultats immédiats. Le deuxième pilier signifie que Kanban s’applique dans un processus déjà existant(cycle en V, Scrum…). Enfin, le troisième pilier préconise l’évolution par petit pas, l’objectif étant de s’approprier une culture d’amélioration continue.

Les 5 pratiques

  1. Visualiser : La visualisation est une pratique simple mais essentielle. Elle se met en oeuvre par différents outils comme le tableau kanban ou les cartes kanban. Elle permet à tout l’équipe de visualiser l’état du projet.
  2. Limiter le travail en cours : Pour chaque activité de réalisation du projet, on va limiter le nombre d’éléments de travail. Ces limites doivent être équilibrée afin d’avoir un flux de travail fluide. Dans la pratique , on passera d’un système de réalisation à flux poussé à un système de réalisation à flux tiré.
  3. Gérer le flux de travail : Il faut être en capacité de pouvoir gérer les éléments en manipulant les indicateurs de capacité du système.
  4. Rendre explicites les règles de gestion du processus : Nos différentes activités sont soumis à un ensemble de règles et de caractéristiques. Il faut rendre explicites ces règles afin que toute l’équipe les visualise, les comprenne et les améliore.
  5. S’améliorer de manière collaborative : Les blocages mise en évidence par les différentes pratiques Kanban permettent d’augmenter les discussions entre les membres de l’équipe. Cela contribue au commencement de la démarche d’amélioration. Cette démarche d’amélioration s’appuie alors sur des modèles externes(Lean, théorie des contraintes, théorie des files d’attente, etc..) visant à comprendre et résoudre ces blocages.

 

Un développement en flux tiré

Afin d’appliquer la méthode Kanban, il faut pour cela mettre en place un flux de travail. Laurent suit les deux axiomes suivant définis par Corey Ladas pour définir le développement en flux :

  1. Il est possible de diviser le travail en petits incréments apportant de la valeur et pouvant être planifiés indépendamment les uns des autres.
  2. Il est possible de développer n’importe quel incrément apportant de la valeur dans un flux continu, des exigences au déploiement en production. Autrement dit, toutes les activités liées à un incrément peuvent être réalisées et s’enchaîner les unes après les autres.

Une fois  cette étape effectué, la seconde consiste en avoir un flux tiré. Contrairement à un flux poussé qui consiste à produire un travail sur la base de prédictions, le flux tiré consiste à ne travailler que sur le remplacement de ce qui a été consommé.

Le modèle PDSA

Kanban s’appuie également sur le modèle PDSA(Plan, Do, Study, Act) qui est une variante du modèle PDCA(Plan, Do, Check, Act).

  • La phase plan(Concevoir) sert à définir le modèle et les hypothèses que l’on souhaite mettre en place.
  • La phase do(Mettre en oeuvre) est la réalisation du modèle.
  • La phase Study(Etudier) est la phase d’étude du système, on s’appuie sur les résultats obtenus ainsi que sur différents modèles de pensée : théorie des files d’attentes, théorie des contraintes, maîtrise des statistiques et gaspillage du Lean.
  • La phase Act(Améliorer) utilise la phase d’étude pour améliorer son système. Puis repars sur un nouveau cycle PDSA.

Schéma : 

Kanban

Conclusion

L’article ne résume que les concepts de Kanban, c’est à dire la première partie du livre. Dans la suite de celui-ci, Laurent Morisseau nous décrit le noyau de la méthode Kanban au travers du suivis d’une équipe dans la mise en place de la méthode. On aborde plus profondément les concepts en effectuant un cycle PDSA. Il y a plusieurs choses à retenir :

  • Le Kanban a pour but d’améliorer notre processus en se fixant un objectif sur un des indicateurs du système. Faire du Kanban sans objectif n’est pas la bonne approche.
  • Le Kanban ne résout pas les problèmes rencontrés, il se charge simplement de les mettre en évidence
  • Le Kanban n’est pas une méthode agile, elle peut très bien s’appliquer dans un contexte de cycle en V. Cependant, il est vrai qu’elle amène dans sa pratique à plus d’agilité. L’utilisation du Kanban dans un contexte Scrum est appelé ScrumBan.

CoffeeScript

coffeescript-logo

Présentation

CoffeeScript est un langage qui, une fois compilé, donne du JavaScript. La règle d’or de CoffeeScript est d’ailleurs “it’s just JavaScript”. Créé par Jeremy Ashkenas, CoffeeScript a pour but d’écrire moins de code tout en étant plus lisible, plus compréhensible et plus facile à maintenir. Sa syntaxe s’inspire du Ruby.  Il est bien sûr possible d’utiliser des librairies JavaScript. Attention toutefois, il n’est pas possible d’écrire du JavaScript dans du CoffeeScript directement (contrairement à TypeScript). En effet afin d’écrire du JavaScript en CoffeeScript, il faut le délimiter par l’accent grave : ` .

Celui-ci est disponible ici  ou à installer avec le gestionnaire de packet node :

npm  install -g coffee-script

Pour écrire du coffeeScript, il suffit d’écrire un fichier en .coffee et de le compiler avec le compilateur coffeescript.

coffee -c fichier.coffee

Variables

Parce qu’un exemple est toujours plus parlant :


Que pouvons nous remarquer? CoffeeScript n’a pas besoin de déclarer une variable avec le mot clé “var”. De plus,nous n’avons pas besoin d’utiliser de point-virgule à la fin de la ligne.

Les commentaires en CoffeeScript sont définis par un “#”

Il est possible de placer une variable dans une chaine de caractère sans concaténation. Il suffit pour cela d’utiliser la syntaxe #{maVariable} :


 

Opérateurs

Voici un tableau comparatif des différents opérateurs existant en CoffeeScript.

CoffeeScriptJavaScript
==
is
===
!=
isnt
!==
not!
and&&
or||
true
yes
on
true
false
no
off
false

Comme on peut le voir dans ce tableau, certains opérateurs en JavaScript disparaissent tel que l’opérateur == ou !=. Pour expliquer ceci, il est important de revenir au JavaScript et d’expliquer  la différence entre == et ===. Avec l’opérateur ==, on vérifie uniquement la valeur de la variable tandis qu’avec l’opérateur ===, on vérifie également le type de la variable. Ainsi si on a deux variables : a = “2” et b=2. Le résultat a==b renverra true tandis que a===b renverra false. Les bonnes pratiques JavaScript veulent qu’on utilise l’opérateur ===. C’est pourquoi l’opérateur == n’existe pas en CoffeeScript.

D’autres on été rajouté tel que yes, on, off, no. Ces valeurs ont pour but de simplifier la lecture du code.

Conditions


Comme on peut le remarquer, en CoffeeScript on s’affranchit des parenthèses et des accolades. De plus, lorsque l’on veut tester qu’un nombre est situé dans un intervalle, inutile d’utiliser l’opérateur &&. Enfin, si il n’y a qu’une instruction, il est possible de l’écrire sur une seule ligne comment montrer ligne 13.

Une chose qui peut être troublante est l’absence d’accolades. Comment faire alors pour effectuer plusieurs opérations? En CoffeeScript, c’est l’indentation qui va déterminer ceci. Une indentation est représenté par une tabulation ou bien 2 espaces. C’est cette indentation qui va signifier un bloc d’instruction :


Il n’existe pas d’écriture ternaire en CoffeeScript, nous le remplaçons à la place par le mot clé then :


En CoffeeScript il est aussi plus facile de savoir si une variable est définis grâce au mot clé “?”:


Enfin voici la méthode pour créé un switch en CoffeeScript  :


 

Fonctions

Il existe 2 moyens de créer des fonctions en JavaScript mais qu’une en CoffeeScript :


Pour créer une fonction en CoffeeScript, nous utilisons “->”. Etant donné que nous avons qu’une seul instruction(la valeur de retour), il est possible de mettre tout sur la même ligne.

Voyons comment cela se passe lorsque la méthode reçoit un argument :


Comment nous le voyons ici, l’indentation est ce qui détermine le bloc concernant la fonction. La dernière instruction du bloc est sa valeur de retour(une fonction coffeeScript renvoie donc toujours quelque chose). Les argument de place entre parenthèses lors de la définition avant le ->. Cependant lors de l’appel de la fonction, si il y a des arguments, les parenthèses sont optionnelles. Il est également possible de rajouter des paramètres optionnelles comme le montre le deuxième argument.

Attention!

Regardons cet exemple :


On s’attend, à la fin du code, que a vaut toujours 3 et i vaut 10 car le sentiment qu’on a est qu’a la compilation, il y ait ce code JavaScript :


Et bien non, la compilation donnera ceci :


Je ne m’attarderais pas sur l’explication de ce fonctionnement dans ce billet, on est ici pour découvrir les bases de CoffeeScript. Cependant il me semblait important de souligner ce comportement. Je l’expliquerais dans un autre billet.

Nombre d’arguments variables

Il est possible d’avoir un nombre d’arguments grâce à l’emploi de “…” 


 

Tableaux

En ce qui concerne les tableaux, CoffeeScript suit toujours son leit motiv : écrire moins de code pour faire la même chose. Voici quelques exemples de création d’un tableau :


Chacune de ces façons d’écrire fournira un tableau contenant les chiffres 1, 2, 3, 4.  Reprenons chacune de ces lignes :

ligne 2 : C’est la même façon que la création de tableau en JavaScript
ligne 4 : les .. signifie de 1 jusqu’à 4 inclus
ligne 6 : les … signifie de 1 jusqu’à 5 exclus
ligne 8,9 et 10 : il est possible de créer un tableau à partir de variable. Si on inversait les variables a et b nous aurions un tableau égale à [4,3,2,1]

Afin de rendre plus lisible la création de tableau il est possible de le faire sur plusieurs ligne comme ceci :


De cette manière, c’est un peu plus lisible. Attention à l’indentation : si le premier élément n’est pas indenté correctement sur la ligne du dessous, le compilateur renverra une erreur.

CoffeeScript nous permet également de pouvoir de récupérer un tableau de valeurs à partir d’un autre tableau :


Simple non? 🙂

Passons à un comportement plus spécifique, regardons l’exemple ci-dessous :


Ici, nous nous attendons à ce que le compilateur nous renvoie une erreur. Et pourtant, la compilation se déroule bien et tableau2 contient [2,3,4,5]. En fait, le -1 va être traduit en tableau.length par le compilateur. C’est une sorte d’alias.


Il existe deux façons de parcourir un tableau en coffeeScript : avec une boucle foreach ou bien avec une boule for in :


 

Objets

Pour créer un objet en CoffeeScript, rien de plus simple :


Comme toujours en CoffeeScript, c’est l’indentation qui définit les “limites” de notre objet.

Il est possible de parcourir un objet grâce au mot clé “for of”  :

Les itérations

Arrêtons nous un peu sur les itérations. Tout comme en JavaScript, CoffeeScript utilise la boucle while :


Cependant, la boucle for n’existe plus et est remplacé par le parcours d’un élément appelé “compréhension”. Nous avons donc for in pour parcourir un tableau et for of pour parcourir un objet. Pour faire une boucle for classique, nous feront comme ceci en CoffeeScript :


Il est vrai que la “compréhension” d’un élément n’aurait pas grand intérêt si elle s’arrêtait là. Pour ceux venant de .net et utilisant linq, vous retrouverez quelques similitudes.En effet nous pouvons faire ceci par exemple :


Littéralement : lorsque le fruit contenu dans le tableau [“pomme”, “banane”, “poire”] n’est pas égale à “banane”, faire un alert de fruit. Etant donné que l’on ne fais qu’une opération, il est même possible d’écrire tout sur une seule ligne de cette manière :


La “compréhension” a également la possibilité de nous retourner une liste :


Cette ligne signifie :  sélectionne fruit pour fruit contenu dans [“banane”, “pomme”, “poire”] lorqu’il est différent de banane. Attention à ne pas oublier les parenthèses. Sans celles-ci, maListe contiendra uniquement le dernier résultat (poire).

CoffeeScript Orienté Objet

CoffeeScript simplifie beaucoup la partie Orienté Objet de JavaScript. Ainsi pour créer une classe il nous suffit d’utiliser le mot clé class :


Remplissons notre classe en lui fournissant des attributs, des fonctions et un constructeur :


Comme le montre l’exemple, afin de créer un attribut, il suffit de placer le sigle @ devant. Les méthodes sont comme de simples variables. Enfin le mot clé constructor indique la fonction qui sera exécuté lors de l’instanciation de la classe. Si un des arguments possède un @, le compilateur comprendra qu’il s’agit d’initialiser un attribut. A la compilation cela donne :


 

Il est également possible de mettre en place l’héritage grâce au mot clé extends :


Le mot clé super invoquera la méthode de la classe mère ayant le même nom que la méthode courante.

 

Voilà, ce billet touche à sa fin. Je n’ai pas tout expliqué sur CoffeeScript, il reste encore beaucoup de notions. Pour en apprendre plus, n’hésitez pas à vous rendre sur le tutoriel officiel . Celui-ci est très complet et très bien fait. 🙂

 

Lecture de : Scrum

scrum

Je viens de lire le livre Scrum: Le guide pratique de la méthode agile la plus populaire. Ecrit par Claude Aubry, celui-ci nous explique les rouages de la méthode Scrum. Le livre se découpe en 3 parties : les pratiques de Scrum, les pratiques complémentaires et la mise en place de Scrum.

Introduction

Un peu d’histoire

Jeff Sutherland a créé le processus Scrum en 1993. Il a tiré le terme « Scrum » d’une analogie mise en avant dans une étude réalisée en 1986 par Takeuchi et Nonaka, publiée dans le Harvard Business Review. Dans cette étude, Takeuchi et Nonaka comparaient les équipes à haut rendement et inter-fonctionnelles à la mêlée utilisés par les équipes de rugby. Ken Schwaber formalisa ce processus pour l’industrie du logiciel du monde entier dans le premier document publié sur Scrum au OOPSLA de 1995. Depuis lors, Scrum est devenu l’une des principales méthodes de développement agile, utilisé par les 500 plus grandes entreprises mondiales. source

Une méthode Agile

Scrum s’inscrit dans les méthodes agiles parce qu’elle respecte le manifeste Agile suivant  :

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 pratiques de Scrum

Les rôles

Le Product Owner

Le product Owner est responsable du produit.

  • Il donne la vision du produit, c’est à dire l’objectif du produit, la position du produit ainsi que la liste des fonctionnalités essentielles. Il doit s’assurer que tout les membres du projets partagent cette vision.
  • Il définit le contenu du produit :  il est responsable du backlog de produit et définit les priorités de développement. Il s’implique donc dans les tests d’acceptations.
  • Il planifie la vie du produit : il constitue les objectifs d’une release et prend les décisions sur son contenu ainsi que sur la date de mise en production.

L’objectif du Product Owner (PO) est de s’assurer que le produit apporte de la valeur aux utilisateurs.

 

Le ScrumMaster

Le ScrumMaster est responsable du déroulement de la méthode Scrum.

  • Il veille à la mise en application de Scrum(en animant les différents cérémonials par exemple).
  • Il encourage l’équipe à apprendre et à progresser dans les pratiques d’ingénierie.
  • Il aide à éliminer les obstacles freinant l’avancement du sprint.
  • Il incite l’équipe à être autonome et responsable.

L’objectif du ScrumMaster est que l’équipe arrive à un état où elle n’est plus besoin de lui.

 

L’équipe auto-organisée

L’équipe est responsable de la réalisation du produit. Le PO et le ScrumMaster font partis de cette équipe.

  • Elle définit la façon dont elle organise ses travaux sans autorité de la part du ScrumMaster ou du ProductOwner.
  • Chaque membre apporte son expertise, partage sa connaissance afin de créer une équipe multifonctionnelle.
  • Elle veille à posséder toutes les compétences nécessaires.

L’objectif de l’équipe est de réaliser un produit de qualité dans l’environnement de travail qu’elle a défini.

 

Les artefacts

Les artefacts sont les éléments physiques dont l’équipe se sert pour développer le produit.

Backlog de produit  : Il contient la liste des fonctionnalités des produits détaillées en stories. Ces fonctionnalités sont priorisées.

Plan de release : Il présente les sprints à venir ainsi que leurs contenus.Il est orienté vers le client(ils doivent pouvoir le comprendre) et est mise à jour régulièrement.

Plan de sprint : Il présente la liste des tâches à effectuer. Ces tâches sont définis, associé à une story et estimé (en heures ou en “point”, c’est optionnel).

Burndown chart de sprint : C’est un graphique représentant ce qu’il reste à faire dans le sprint. Il sert à montrer l’avancement réel du sprint et permet l’ajustement du plan de sprint.

Burndown char de release : C’est un graphique représentant ce qu’il reste à faire dans la release. Il sert à montrer l’avancement réel et apporte une aide à l’estimation de l’état du produit à la fin de la release. Il permet d’ajuster le plan de release.

Les cérémonials

Scrum est une méthode Agile itérative. Certaines étapes du produit reviennent donc régulièrement :

Release : C’est une version du produit réalisée par une série de 3-4 sprint.

Sprint : C’est une itération d’une durée de 2 à 4 semaines dans laquelle sont réalisées des tâches.

Planification de release : Processus permettant de définir le contenu d’une release (ou version). Elle est composée de plusieurs réunions étalées sur la réalisation de la release. Toute l’équipe y participe. Le PO doit au préalable établir et priorisé les différentes fonctionnalités.

Planification de sprint : Processsus permettant de définir les tâches(liées à des stories) prise dans le backlog qui vont être effectué pendant le sprint. Toute l’équipe y participe.

Scrum quotidien : C’est une réunion quotidienne(appelé scrum), elle appartient à l’équipe et doit lui permettre de s’auto-organiser. Ce n’est pas un compte rendu fait au ScrumMaster ou au ProductOwner. Lors de cette réunion, chaque membre de l’équipe doit répondre à ces trois questions :

  1. Qu’ai je fais depuis le dernier scrum ?
  2. Que vais-je faire jusqu’au prochain scrum?
  3. Quels sont les obstacles qui me freinent dans mon travail?

Ces trois questions ont pour objectif de présenter ce qui a été fait, prévoir ce qui va être fait et identifier les obstacles afin d’actualiser le plan de sprint ainsi que le burndown chart de sprint. Il ne s’agit en aucun cas d’évaluer les membres de l’équipe!

Revue de sprint : C’est une démonstration du produit en cours de développement faite à toutes les personnes concernées ou intéressées par le produit. Elle a lieu le dernier jour du sprint. La démonstration ne contient que les fonctionnalités finis du produit. Son objectif est de collecter un feedback sur le produit, d’actualiser le backlog de produit(par des évolutions ou des corrections) et d’ajuster le plan de release.

Rétrospective : C’est la réunion qui clôture le sprint. C’est un moment de réflexion collective qui a pour but :

  • de capitaliser sur les pratiques qui ont marché.
  • d’éviter de refaire les mêmes erreurs.
  • partager différents points de vue.
  • permettre au processus de s’adapter aux nouvelles avancées dans la technologie utilisée pour développer.

Le résultat de cette rétrospective est un regroupement d’actions divisé en 4 catégories :

  1. celles dirigées vers les personnes.
  2. celles sur leur façon d’appliquer les pratiques Scrum.
  3. celles orientées outils à installer ou à adapter.
  4. celles axées sur l’amélioration de la qualité.

Signification de fini : La définition de fini doit être définis au départ du projet (et actualisé si besoin). Elle permet de motiver l’équipe, diminuer les ambiguïtés et obtenir plus de performance et de transparence. Il y a trois définitions de fini : Une pour une story, une autre pour un sprint et une dernière pour une release.

 

Schéma globale de Scrum :

VueGlobaleScrum

Les pratiques complémentaires

Claude Aubry nous explique dans cette partie des pratiques complémentaires à Scrum permettant de faciliter son utilisation comme par exemple la création du backlog ou bien la mise en place d’indicateurs. Ces pratiques concerne le PO, le ScrumMaster et l’équipe.

De la vision aux stories

Avant de devenir une série de stories, le produit est avant tout une vision. Celle-ci possède un but, c’est à dire l’objectif du produit. Elle prend en compte les besoins des utilisateurs et développe une présentation de la solution à ces besoins tout en prenant compte des contraintes imposées au développement. Il est bien sûr possible d’avoir plusieurs visions selon la dimension du projet. On peut avoir une vision globale du produit puis des visions par release(ou version).

On découpe cette vision en une liste de fonctionnalités (ou features). Ces fonctionnalités sont des services fourni par le produit, observable de l’extérieur, qui répondent à un besoin et dont la description se situe à un niveau tel que toutes les parties prenantes du projet comprennent facilement ce dont il s’agit.

Une fois cette liste de fonctionnalités obtenu, elle est décomposée en “stories”. Ces stories possèdent un nom, une description, un identifiant(la fonctionnalité à laquelle elle appartienne). Il existe 3 type de stories :

  • User story : Elle définit un comportement visible pour les utilisateurs et leur apporte de la valeur ou de l’utilité.
  • Story technique : Elle définit un comportement invisible pour les utilisateurs mais visible par l’équipe de développement. Elle est nécessaire au développement de certaines user stories.
  • Défaut : Elle définit un comportement  qui enlève de la valeur au produit. Elles sont souvent créées lors des feedbacks.

De la story aux tests d’acceptation

Une fois une story définis, il est important de lui définir des tests d’acceptations. Ces tests permettent de savoir précisément lorsque la story est finis et d’être sûr de n’avoir rien oublié. Le Product Owner participe donc grandement à la création de ces tests. Le nombre de ces tests doit être inférieur à 8. Dans le cas contraire, la story est sans doute trop grosse et le Product Owner doit avoir la possibilité de la décomposer.

Lorsque plusieurs stories sont liées, on met alors un scénario en place qui permet d’effectuer les tests dans un certains ordre.

L’équipe doit être capable de refuser une story lors de la plannification de sprint lorsque celle-ci ne possède pas les conditions requises pour déterminer son état de finition.

Estimations, mesures et indicateurs

L’indicateur principal de la méthode Scrum est le burndown Chart. Celui-ci est représenté grâce à la récupération de mesure et permet de faire des estimations. Dans cette partie, Claude Aubry nous liste des mesures qu’ils séparent en 4 catégories :

  1. Les mesures quotidiennes
    • Le nombre d’heures restant pour finir les  tâches du sprint
    • Le nombre de tâches restant à finir
    • etc…
  2. Les mesures à chaque sprint
    • La capacité estimé au début du sprint
    • La vélocité réelle du sprint
    • L’utilité ajoutée pendant le sprint
    • etc…
  3. Les mesures à chaque release
    • identique à celle du sprint mais à l’échelle d’une release
  4. Autres
    • Nombre d’obstacles rencontrés et non éliminés
    • Ressource consommé
    • etc…

Ces mesures  permettent de créer des indicateurs(sous forme graphique par exemple) et ainsi pouvoir estimer la suite du projet. Ces estimations ne sont pas des engagements et peuvent être actualisées!

Scrum dans l’ingénierie du logiciel : Pratiques d’eXtreme Programming

Scrum est une méthode Agile pouvant s’adapter à différents domaines. Dans le cas de l’ingénierie du logiciel, Claude Aubry se tourne vers des pratiques de la méthode agile eXtreme Programming. Je vous invite à lire ce billet pour plus d’information : lien

Mise en place de Scrum

Dans cette dernière partie, Claude Aubry sort de l’aspect pratique de Scrum et s’attarde sur sa mise en place.

Adapter Scrum au contexte

Scrum n’est pas une méthode qu’il faut appliquer bêtement. Il faut la voir comme un cadre. A ce cadre vient s’appliquer des pratiques liées à l’ingénierie(pratiques d’eXtreme Programming pour l’ingénierie lié au développement du logiciel par exemple).

Claude Aubry nous explique également qu’il faut savoir adapter Scrum et revenir dessus à chaque rétrospective. Afin de bien cerner ce contexte, Il faut répondre à ces questions :

  • A quel niveau d’innovation se situe l’entreprise
  • Dans quel culture? N’oubliez pas le côté humain d’un projet!
  • Quel est le domaine métier?
  • Quel niveau de maturité? A-t-on beaucoup d’expérience dans le domaine?

Le contexte peut être partager en 4 catégories :

  1. La nature du produit
  2. L’état du logiciel
  3. L’équipe
  4. L’organisation de développement

Pour résumé, Scrum possède deux axes sur lesquelles repose son application : la sélection des pratiques liées au domaine métier et le contexte.

La transition à Scrum

La transition à Scrum ne doit pas être brutale, elle doit être réfléchis. Cette transition constitue en lui même un projet dans lequel sera exécuté un projet pilote. L’équipe du projet pilote peut être différente de l’équipe du projet de transition. L’équipe du projet de transition doit être un support pour l’équipe du projet pilote.

Claude Aubry définit un cycle de 5 étapes :

  1. Evaluer le contexte : Il s’agit d’avoir d’avoir un vision claire de la raison du changement.
  2. Préparer l’application de Scrum : Choisir le projet pilote, adapter les pratiques. Créer l’équipe pilote et la former à Scrum (il existe plusieurs méthodes).
  3. Exécuter Scrum sur un projet pilote : Le projet de transition et le projet pilote se déroule simultanément. Les phases de rétrospective sont nombreuses et importantes.
  4. Diffuser dans l’organisation : L’objectif du projet de transition et de faire passer toute l’organisation de l’entreprise à Scrum.
  5. Evaluer le niveau atteint : A chaque fin de projet, on évalue le niveau atteint et on ajuste.

Scrum avec un outil

Dans cette partie, Claude Aubry nous présente différents outils utilisés pour Scrum. Il nous présente également iceScrum dont il est Product Owner.

Scrum à grande échelle

Scrum s’applique à des équipes constituées de 5 à 10 personnes. Dans le cas de la création d’une très grosse application, il est possible d’avoir plusieurs équipes. Il est important alors de bien constituer le backlog. Pour cela, il est possible de constituer des scrums de scrum. C’est à dire que chaque équipe scrum possèdera son backlog. Un représentant de chaque équipe est choisi pour créer une autre équipe Scrum. Cette équipe a pour but d’avoir une vision globale du projet. Elle possède son propre backlog. En décomposant celui-ci, les features obtenues alimentent les backlogs des équipes “normales”.

Il faut cependant bien garder à l’esprit que la communication est la clé de la réussite d’un projet. Par conséquent, plus l’équipe sera grosse et éparpillé géographiquement, plus il sera difficile de maintenir le projet dans un environnement stable. Il est alors possible d’utiliser la méthode Kanban pour améliorer sa chaîne de processus.

Scrum en France

Dans cette dernière partie, Claude Aubry fais un état de lieu de la méthode Scrum en France.

 

Conclusion 

Ce qu’il faut retenir est que la méthode Scrum est un cadre qui repose sur un contexte et un domaine métier. Ce cadre possède des pratiques à respecter qu’il faut enrichir par des pratiques lié au domaine métier. Ce billet n’est qu’un résumé de ces pratiques. Pour plus d’information je vous conseille vivement la lecture de ce livre qui vous expliquera ces pratiques en détails ainsi que toute la dimension humaine lié à un projet Scrum. Cette dimension est malheureusement difficile à exprimé en un simple article de blog :  Scrum n’est en aucun cas une méthode permettant d’évaluer les membres d’une organisation.

 

 

 

 

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