Scrum : introduction

AmauryOrganisation d'équipe12 commentaires sur Scrum : introduction

Scrum est une méthode de gestion de projet très intéressante. Pour mon premier article à son propos, je vais vous la présenter rapidement, et vous parler de l’un de ses concepts-clés : les sprints.

Scrum est une méthode agile qui ne se focalise pas spécialement sur les techniques de développement, mais plutôt sur l’organisation de projet et la gestion d’équipe. C’est une méthode moderne qui a fait ses preuves dans de nombreuses circonstances.

Présentation des rôles

L’image suivante présente d’une manière assez synthétique les différents rôles qui interviennent dans une équipe Scrum :

(image © Avangel, Wikipedia)

  • Le directeur de produit : Je préfère utiliser le terme de chef de projet fonctionnel. Son rôle est de présenter à l’équipe les fonctionnalités qu’elle devra développer, et de transmettre l’ordre de priorités. Il opère un suivi régulier avec l’équipe de développement, et remonte régulièrement les informations d’avancement au client.
  • Le Scrum Master : C’est un personnage très spécial qui prend en charge tous les aspects non techniques pour « protéger » l’équipe, particulièrement pendant les périodes de sprint (voir plus bas). Toutes les requêtes doivent passer par lui, pour s’assurer du respect de la méthode. C’est un rôle qu’on pourrait approcher de celui que je tiens – en temps que directeur technique – vis-à-vis de mes développeurs (hormis que je gère en plus des aspects techniques comme la validation des spécifications techniques).
  • L’équipe de développement : La théorie voudrait que l’équipe soit auto-gérée, et que ses membres prennent eux-mêmes leurs décisions de manière collégiale. D’expérience, j’ai rarement vu une équipe fonctionner correctement quand on la laisse faire ce qu’elle veut. Pour que ça fonctionne, il faut avoir des développeurs très compétents, avec de l’expérience, et surtout qui apprécie les contacts humains. Et malheureusement, toutes les équipes ont leurs stagiaires, leurs pas-très-bons-techniquement ou leurs autistes…

Les sprints

Au coeur de Scrum, il y a la notion de sprint. Le principe est de définir un lot de fonctionnalités à développer, puis de partir dans une phase de développement de durée « raisonnable » (2 à 4 semaines). Évidemment, l’ensemble des fonctionnalités doit avoir été prévu pour pouvoir être développé dans ce laps de temps.

L’important dans cet exercice, c’est de bien comprendre – et surtout faire comprendre aux autres acteurs – qu’une fois qu’on a défini la liste des fonctionnalités et qu’on a écrit les spécifications fonctionnelles, on entre dans une phase de quelques semaines pendant laquelle il est absolument interdit de changer les objectifs de développement. Cela a pour effet de pousser les clients à bien spécifier leurs besoins, car une fois que le sprint est lancé, il n’est pas possible d’ajouter de nouvelles fonctionnalités ni de changer l’ordre de priorité.

L’estimation du travail

AmauryOrganisation personnelleLaissez un commentaire sur L’estimation du travail

Quand on veut planifier son travail ou celui de son équipe, il faut obligatoirement commencer par faire une estimation du temps nécessaire pour réaliser chacune des tâches qui sont listées. Et c’est souvent un casse-tête, car on ne sait jamais par quel bout s’y prendre.

Nous allons voir les raisons qui doivent vous pousser à réaliser des estimations, les réactions les plus récurrentes, et les pistes à suivre pour y arriver.

À noter : J’avais commencé à écrire ce texte au sein d’un article consacré à la planification et aux approches top-down et bottom-up. Mais un article présent dans le dernier numéro du magazine PHP Architect (très bon magazine canadien, en anglais) m’a convaincu d’y consacrer un billet à part entière. Le sujet est intéressant.

Les motivations

On peut voir plusieurs aspects qui conduisent à la nécessité d’estimer préalablement la durée d’une tâche ou d’un projet :

Test Driven Development

AmauryOrganisation d'équipe2 commentaires sur Test Driven Development

Je vous parlais récemment des tests unitaires. Je vous parlais entre autre de la difficulté d’imposer la discipline nécessaire à la réalisation de tests unitaires corrects et de leur maintien opérationnel.

Il existe une méthode de travail qui permet de forcer l’écriture des tests unitaires (tout au moins au début des développements). Il s’agit des développements guidés par les tests (ou Test Driven Development en anglais).
Cette méthode est toute simple à comprendre : Avant d’écrire un bout de code, on commence par écrire les tests qui vont vérifier la conformité du code.

Prenons l’exemple d’un code orienté objet. Imaginons que nous nous préparons à écrire une nouvelle classe.

  • On modélise l’objet, donc on connait ses méthodes publiques. On sait quelles entrées doivent produire quels résultats.
  • On écrit des tests pour vérifier les méthodes de l’objet.
  • On écrit le squelette de l’objet, avec juste les déclarations des méthodes.
  • On exécute les tests unitaires, qui tombent évidemment en échec.
  • On écrit le code de l’objet, en vérifiant que les tests passent un à un.

L’avantage avec cette manière de faire, c’est qu’au moment où le code est écrit, on est quasi-certain qu’il est conforme au comportement qu’on attend de lui. Pour peu qu’on ait pris soin de lancer régulièrement les tests unitaires au cours du développement, le code est rapide à valider.

Par contre, il va sans dire que si le TDD permet d’avoir des tests unitaires corrects pour de nouveaux développements, le problème reste entier pour l’évolution de code existant. La vigilance habituelle reste donc de mise, pour que les tests ne prennent pas la poussière. Mais il est possible de respecter cette démarche pour toutes les évolutions de code : On commence par modifier les tests unitaires existants, ou les compléter ; puis on effectue les développements qui valideront ces tests.

Mon expérience

Le TDD est ce que je qualifierais de vraie fausse bonne idée. En fait, j’ai vu plusieurs fois le même cheminement intellectuel être suivi par des équipes qui mettaient en place cette méthode :

Gestion de sources, versions de logiciels

AmauryQuestions techniques7 commentaires sur Gestion de sources, versions de logiciels

Lorsqu’on développe un logiciel, il est absolument nécessaire d’utiliser un outil de gestion de sources. Évidemment, il serait possible de stocker ses fichiers dans un répertoire. Mais si vous voulez travailler sérieusement, vous aurez besoin de stocker les différentes versions de vos sources, pour suivre leur évolution au fil du temps ; et si vous travaillez à plusieurs sur le même projet, cela devient impossible.

Les logiciels de gestion de sources permettent à plusieurs personnes de travailler sur les mêmes fichiers, chacun dans leur coin, puis de tout rassembler pour obtenir une version continuellement à jour des sources. Ils apportent des fonctions permettant de définir des versions globales. Il existe un grand nombre de ces systèmes :

  • Les ancêtres RCS et CVS ont laissé la place à Subversion, qui offre des fonctionnalités supplémentaires bien appréciables. Ce sont des systèmes centralisés faciles à appréhender et à installer, et sont sous licence libre.
  • De nouveaux système sont apparus, basés sur un modèle décentralisé. Parmi ceux-ci, ont peut noter que les plus connus dans le monde de l’open-source sont Bazaar (sponsorisé par Canonical, à l’origine de la distribution Linux Ubuntu), Git (utilisé pour le noyau Linux) et Mercurial.
  • Du côté des logiciels propriétaires, les plus connus sont Visual SourceSafe de Microsoft et BitKeeper (qui a été utilisé pour le noyau Linux jusqu’en 2005).

Je vais vous présenter l’utilisation de ces outils, en utilisant l’exemple de Subversion (SVN en abrégé) car c’est le système de plus répandu et celui que j’utilise ; mais ces concepts sont toujours valables.

Principes généraux

Gestion basique

A la base, les sources d’un projet sont disponibles sur la branche principale (trunk). Les développeurs y récupèrent les sources (checkout) sur leur propre environnement de travail, et y ajoutent leurs versions modifiées (commit).

SVN - checkout - commit

Tests unitaires et intégration continue

AmauryOrganisation d'équipe10 commentaires sur Tests unitaires et intégration continue

Je vais vous parler de deux notions qui sont assez connexes, et que certaines personnes ont tendance à mélanger un peu.

Les tests unitaires

Le but des tests unitaires est d’automatiser les tests de non-régression. Quand on développe un logiciel, on peut facilement faire des modifications sans se rendre compte qu’elles introduisent des bugs dans certains cas particuliers. C’est ce qu’on appelle des bugs de régression, en ce sens qu’on introduit de nouveaux bugs à la suite d’une évolution fonctionnelle. Comme il n’est pas humainement possible de tester systématiquement tous les cas d’utilisation possible, ces bugs peuvent se retrouver déployés en production, avec tous les problèmes que cela comporte.

Une des notions importantes, quand on fait du développement, est de savoir que plus un bug est détecté tôt, plus il sera facile à corriger. Les gros soucis arrivent quand on fait du « sur-développement » par-dessus un bug de régression ; il devient très difficile de faire un retour en arrière sur le code incriminé, car cela impliquerait de supprimer des fonctionnalités. Il faut alors corriger ce nouveau code, en essayant de trouver une aiguille dans une botte de foin.

Concrètement, les tests unitaires consistent en un ensemble de scripts, qui ont chacun en charge la validation d’un morceau de code (ou d’une classe si vous faite de la programmation orientée objet). Il est assez évident de tester de la sorte les bibliothèques de fonction : les « librairies » peuvent être vues comme des boîtes noires, avec des entrées et des sorties. Il suffit d’injecter certaines données en entrée, et vérifier la conformité de ce qu’on obtient en sortie.
Pour du code applicatif, c’est un peu plus délicat, car on est parfois obligé de mettre en place un environnement de test sophistiqué (bases de données avec lots de test, génération de données aléatoires, gestion des tentatives de hack, …). Mais bien heureusement il existe de très nombreux frameworks pour vous aider à y arriver ; suivant votre plate-forme de développement, vous pouvez vous intéresser à JUnit (Java), SimpleTest (PHP), CppUnit (C++), JSUnit (Javascript), ASUnit (ActionScript), Test::Unit (Ruby), Test::Unit (Perl), unittest (Python), NUnit (.NET), …

Le cycle itératif

AmauryOrganisation d'équipe4 commentaires sur Le cycle itératif

Si vous avez lu mon billet sur le Cycle en V, vous savez pourquoi ce type de méthode de travail n’est pas adapté à la plupart des projets informatiques, qui réclament une plus grande souplesse. En l’appliquant de manière rigide, on finit par obtenir des logiciels mal adaptés (fonctionnalités sans priorités), livrés en retard (chaque étape bloque les suivantes) et souvent buggués (la technique se plie au fonctionnel).
C’est ainsi qu’est née la méthode du cycle itératif (ou incrémental), qui tente de formaliser une approche plus pragmatique et maniable.

Cycle itératif

Définition

Cette méthode se décompose en 6 étapes, dont 4 qui en constituent le « coeur » :

  • L’expression de besoin : Le client explique ce qu’il veut obtenir. On peut faire un parallèle avec l’étape de faisabilité du cycle en V, et dans une moindre mesure avec les spécifications fonctionnelles. L’idée reste que les informations en entrée peuvent être modifiées par la suite du processus.
  • Le coeur du processus itératif :
    • Spécification : C’est la traduction en langage technique des besoins fournis en entrée. C’est la réponse aux questions « qu’est-ce qu’on fait ? » et « comment on va le faire ? ».
    • Développement : Il s’agit de la réalisation concrète de ce qui a été défini.
    • Validation : C’est l’ensemble des tests qui permettent de s’assurer que le développement effectué correspond bien à ce qui était attendu.
    • Évaluation : Cette étape sert à effectuer un retour sur les écueils rencontrés et les fonctionnalités abandonnées pendant les 3 étapes précédentes, et l’utiliser comme informations d’entrée pour un nouveau cycle.
  • Déploiement : Les livrables qui ont été validés sont déployés pour que le client y ait accès.

Le cycle en V

AmauryOrganisation d'équipe10 commentaires sur Le cycle en V

Le cycle en V est une méthode d’organisation très connue dont l’origine remonte à l’industrie et qui a été adaptée à l’informatique dans les années 80. C’est l’une des premières méthodes qu’on apprend à l’école, et elle reste toujours d’actualité.

La grande force du cycle en V, c’est qu’il définit assez précisément la manière dont les choses devraient se passer.

Cycle en V - théorie

On peut y distinguer 3 grandes parties : La phase de conception, la phase de réalisation (codage) et la phase de validation. Les phases de conception et de validation se découpent en plusieurs parties. Chaque étape ne peut être réalisée qu’une fois que l’étape précédente est terminée, ce qui diminue les prises de risque sur le projet.
Ce qui est bien visible sur le diagramme, c’est que chaque étape de conception possède son alter ego de validation. Il devient alors assez aisé de valider un projet, car le référentiel de test est connu très précisément.

Les différentes étapes

Le cycle en V est constitué de 9 étapes qui ont toutes leur importance.