User Stories Applied

dans Lectures

Dans la série des “Signature Book” de chez Addison Wesley,“User Stories Applied” est mon troisième livre approuvé par Kent Beck après “ATDD, by example” et “Test-Driven Development, by example”. Il m’a été prêté par un ami, merci Damien pour le prêt longue durée ;)

Il a été écrit par Mike Cohn qui est l’un des membres foundateurs de Agile Alliance et un développeur reconnu par ses pairs. Il est notamment l’un des spécialistes de Scrum, mettant en place cette méthodologie depuis plus de 20 ans et ayant écrit plusieurs livres sur le déploiement de l’agilité dans les projets informatiques.

Comment recueillir efficacement les besoins utilisateurs ? Comment rester au plus proche de ces besoins sans passer des mois à écrire des documents ? Comment différer le recueil de ces besoins au moment le plus opportun ? Comment estimer le travail à faire pour développer ces besoins ?
C’est pour répondre à toutes ces questions et bien d’autres que Mike Cohn nous présente les Users Stories apparues tout d’abord en eXtreme Programming et ayant évoluées depuis pour s’imposer comme l’une des meilleures méthodes de recueil de besoins dans un projet agile.

J’ai apprécié ce livre, assez facile à lire grâce à un découpage en petits paragraphes. A chaque fin de chapitre, on trouve un résumé (ce qui est une bonne idée si l’on veut reparcourir rapidement le livre plus tard pour se rafraîchir les idées) ainsi que des questions, moyen amusant de savoir ce que l’on a retenu de notre lecture.

Le livre est découpé en cinq parties :
    1. Getting started : présentation générale de ce qu’est une User Story et de comment on travaille avec.
    2. Estimating and Plannig : comment estimer une User Story et comment planifier son développement
    3. Frequently Discussed Topics : bonnes pratiques et questions récurrentes sur les User Stories
   4. An Example : exemple avec mise en situation sur une boutique d’articles de pêche et de plongée souhaitant développer son e-commerce.
    5. Appendices : un premier appendice sur l’eXtreme Programming, méthodologie où sont apparues les User Stories et un deuxième contenant les réponses aux questions de fin de chapitre.
Continuer

Agile Playground Clermont-Ferrand #3

dans Événements

J’étais mardi soir au 3ème Agile Playground organisé par l’A-Cube. Le principe est simple : partager les valeurs de l’agilité grâce aux jeux. Les jeux ont une puissance insoupçonnée pour communiquer, échanger et faire partager des points de vue différents. Plusieurs activités peuvent être réalisées au cours d’une session : jouer à un jeu connu, découvrir un nouveau jeu ou bien même créer un jeu !

Nous étions une petite dizaine de participants et nous avons commencé la soirée par jouer. C’était mon premier playground et j’ai donc découvert le delegation poker. Le but du jeu est de faire prendre conscience aux participants du niveau de délégation dont doit faire preuve un manager et quel niveau de responsabilité peut accepter une équipe de travail auto-organisée que l’on retrouve dans beaucoup de méthodes agiles.
Pour cela, chaque joueur dispose de 7 cartes représentant chacune un niveau de délégation, de 1 (chef décidant seul sans consulter l’équipe) à 7 (équipe décidant seule sans présence du manager). L’animateur du jeu énonce un cas (ex: en tant que manager, je décide seul du recrutement d’un nouvel équipier) et chaque participant retourne la carte qui lui semble la plus appropriée.
S’en suit un échange pour connaître les avis de chacun et la raison de leur choix, puis un deuxième tour de jeu (comme au planning poker) pour voir si les avis peuvent converger.
J’ai bien aimé ce jeu qui permet selon les profils des participants (manager, responsable équipe, développeur, etc) de mettre en évidence les différences de jugement et surtout d’échanger autour de ces différences pour que chacun puisse relativiser un peu. Il me semble tout à fait approprié pour désamorcer les tensions qui peuvent apparaître dans un projet.

Après le delegation poker, place à la créativité. Nous avons essayé de créer un jeu en rapport avec des difficultés que l’on peut rencontrer dans notre quotidien professionnel. Un tour de table de chaque participant a permis de lister les idées de chacun et un vote a permis de choisir lequel serait le thème du jeu.
Puis brainstorming autour du thème pour trouver un support (dessin, cartes, organisation des personnes dans l’espace, …) et les règles. Je n’en dirais pas plus, rendez-vous au prochain agile playground en juillet pour découvrir peut-être ce jeu dans sa version finalisée !

J’ai passé une super soirée avec des personnes très sympas. Merci à l’A-Cube pour l’organisation de ces soirées et aux participants pour leur bonne humeur !

Vivement la prochaine !

Commenter et partager

Test-Driven Development, By Example

dans Lectures

Kent Beck est un développeur reconnu par ses pairs. Il fait parti des signataires du manifeste Agile et est le fondateur de l’eXtreme Programming qui met en avant des valeurs telles que le courage, le retour sur développement (feedback) et amène de nouvelles méthodes de travail telles que le pair-programming et le développement piloté par les tests (test-driven development).

C’est justement cette dernière technique qui est détaillée dans ce livre. Je l’ai trouvé très bien écrit; il se lit vite du fait de chapitres courts, voire très courts (2 pages pour le chapitre 7), et du style fluide de Kent Beck. L’enchaînement de chapitres courts donnent envie de ne pas s’arrêter, surtout quand ils décrivent une histoire comme c’est le cas pour la première partie qui est un exemple, avec code, du développement d’un système monétaire.
La deuxième partie m’a moins convaincu. Elle est plus difficile à lire et le développement d’un framework de test en Python ne m’a pas emballé.
Enfin la dernière partie est un vrai guide pour mettre en place un développement piloté par les tests. Il fournit beaucoup de trucs et astuces, explique la philosophie qui fait le succès de cette méthode et surtout Kent Beck nous dévoile un peu sa vision du développement logiciel.

Je ne vais pas m’attarder sur les deux premières parties qui sont des déroulements d’exemples concrets mais plutôt reprendre en détail la troisième partie : Patterns for Test-Driven Development.
Continuer
  • page sur

Pierre PIRONIN

J’ai créé ce blog pour parler de ce qui se passe autour de moi dans le domaine du génie logiciel.
J’exposerai mes devs, mes idées, mes lectures, les faits qui m’intéressent et les événements auxquels je participe.

Bonne lecture !


Artisan développeur


Auvergne, France