Laissez l'équipe faire ses choix techniques !

Introduction

Ce que j'aime bien dans l'agilité, c'est le côté "bons sens" et pragmatique. Et ce que j'aime particulièrement dans Scrum, c'est le nombre limité de rôles, et la précision du périmètre de responsabilité pour chacun de ces rôles. Voir mon précédent article "Scrum : quel est le rôle le plus important ?".

Pour un projet de développement logiciel, les équipiers sont essentiellement des développeurs. Tout comme le Product Owner a la responsabilité de la partie fonctionnelle (quelles fonctionnalités et pour quand ?), les équipiers ont la responsabilité de tout ce qui est technique : choix des technologies, choix de l'architecture de l'application, règles communes de codage, qualités, innovation, etc ...

Scrum : quel est le rôle le plus important ?

Introduction

Pour l'organisation agile d’un projet de développement logiciel, Scrum propose un cadre simple et précis, avec notamment 3 rôles, ni plus ni moins :

• Scrum Master
• Product Owner
• Equipier

Ces derniers mois, à plusieurs reprises, je me suis posé la question de savoir lequel de ces rôles était le plus important, voici mes éléments de reflexion.

Calendrier niko-niko : l’équipe surveille son moral !

C’est quoi ? Quel est l’objectif ?

Le "niko-niko" est un calendrier, mis en œuvre par l’équipe et pour l’équipe, sur lequel chaque membre de l’équipe reporte à la fin de chaque journée son ressenti avec une pastille de couleur.

Par "équipe", j’entends bien entendu l’ensemble des équipiers, le Product Owner s’il est bien impliqué au quotidien, et le Scrum Master (sauf peut-être s’il est uniquement un animateur ou facilitateur). En fait, il me semble intéressant que toutes les personnes participant tous les jours au stand-up, contribuent à cet indicateur !

On parle de TDD autour d’une bière …

Il y a quelques temps, j’ai eu des échanges très intéressants avec un copain qui m’interrogeait sur ma vision et ma pratique du TDD. Voici une retranscription un peu arrangée de nos échanges ...

Lui : Récemment, je me suis intéressé à des librairies Open Source Java, accompagnées de plus ou moins de tests. Le TDD permet-il de garantir que le code est bien testé ?

Moi : Il faut bien distinguer le TDD et les tests unitaires. Le TDD est une “pratique”,

Mon retour sur Devoxx France 2014

Cette année, pour la première fois, je me suis payé Devoxx France. Voici mon retour sur ces 2 journées intenses et riches.

Scrum Tower Game

Le "Jeu de la tour Scrum", ou comment découvrir les concepts de base de l'agilité et de Scrum en s'amusant ...

Introduction

Il y a quelques années, sollicité par une entreprise pour sa transition vers l'agilité (merci à eux), j'ai mis au point un jeu permettant de découvrir quelques aspects de l'agilité, et les concepts de base de Scrum. Baptisé depuis "Scrum Tower Game", j'ai déjà déroulé plusieurs fois cet atelier, qui tient ses objectifs à chaque fois.

Après en avoir parlé au détour d'une bière, je l'ai fait jouer lors d'une soirée agile du CARA à Grenoble, avec des retours intéressants des personnes présentes. 

Lors de la dernière session de Agile Game France, je n'ai pas osé l'amener dans mes valises, mais certaines personnes me l'ont fait regretter, et m'ont motivé à diffuser cet article pour le présenter (1).

Un bon titre pour une bonne session TDD et coding-dojo

Introduction

Je me permets de solliciter la(les) communauté(s) pour recueillir des avis et propositions pour un titre de session.

La session

A l'automne, j'ai animé une session "L'apprentissage du TDD en Coding-dojo" lors des conférences agiles de Marseille, Montpellier et Grenoble. Cet atelier d'environ 2h me permet de présenter un peu de théorie sur les tests unitaires et le TDD, puis de faire une rapide démo live avant d’enchaîner sur un coding-dojo de type randori (donc sur un seul poste vidéo-projeté) pour permettre à une partie des participants de s'essayer, en pair-programming, au TDD pendant 5-6', sur un sujet simple, avec mes conseils, mes remarques et le soutien de l'assistance.

Développeur : un métier de passion !

Pour faire suite à mon article Développeur : une passion et un métier, sinon rien !, et conforme à ma motivation du moment pour diffuser ce point de vue, mardi dernier (10 décembre), j'ai proposé d'aborder ce sujet lors des Human Talks Grenoble.

Ma session de 10' a été filmée, vous pouvez donc la consulter ici (la qualité d'image n'est pas géniale, mais le son et les slides y sont, c'est l'essentiel) :

Agile Grenoble et Agile Innovation cuvée 2013

Les 21 et 22 novembre dernier, j'ai assisté à Agile Grenoble 2013 et Agile Innovation 2013. En voici quelques éléments de retour.

Qualité :

• Il n'y aurait pas "la" qualité mais "les" qualités ?
• Du moins, il y a plusieurs éléments de qualité, selon qu'on regarde le code, la stabilité de l'application, sa réponse au besoin, son utilisabilité, etc ...
• Mais pour commencer, l'important est déjà de se poser des questions, quelques soient les critères d’évaluation : quelle est la qualité attendue ? quelle est la qualité de l'application actuelle ?

Développeur : une passion et un métier, sinon rien !

Introduction

Dans le développement logiciel depuis plus de 20 ans, je réalise depuis 2 ans (seulement mais réellement), et de plus en plus, à quel point le métier de développeur doit être une passion !

C'est un métier d'artisanat, où l'on fait rarement 2 fois la même chose, où il faut innover tous les jours. L'éco-système bouge très vite, les langages existants évoluent (pas très vite, mais tout de même), de nouveaux langages voient le jour (sont-ils adaptés à mon besoin ou pas ?), de nouvelles librairies sortent régulièrement, une techno révolutionnaire aujourd'hui sera remplacée par une autre encore mieux dans 3 ou 6 mois. Sans compter les bonnes pratiques que je vois évoluer et s'affiner sans cesse ...

Le métier de développeur est difficile ...