… à l'Ecole de la V.I.E …

Agile et Crystal Clear

Plus qu’une méthodologie, Crystal est un cadre méthodologique très fortement adaptable aux spécificités de chaque projet.

Crystal ou plus précisément la famille de méthodologies Crystal  a été créé en 1997 par Alistair COCKBURN.

Le principe est de sélectionner la méthode applicable en fonction de la criticité du projet et du nombre de personnes à coordonner.

Nous nous intéresserons ici à une des déclinaisons de Crystal, Crystal Clear, qui s’ntéresse aux petites équipes Agile (6 personnes maximum).

Les valeurs partagées

Les valeurs partagées par l’équipe Crystal Clear sont :
– communication
– releases fréquentes
– souplesse

Communication :
La communication est omniprésente dans une équipe qui travaille avec la méthode Crystal. Ceci est une condition sine qua non pour réussir le « jeu coopératif » qu’est le projet. En effet, Alistair Cockburn écrit : « Software development is a cooperative game, in which the participants help each other in reaching the end of the game – the delivery of the software » La communication est tellement cruciale que le nombre de membres d’une équipe est limité à 6 personnes pour que l’équipe puisse fonctionner. Il est recommandé que tous les membres de l’équipe soient placés dans la même pièce ou, au pire, dans deux pièces voisines afin de faciliter la communication par la proximité. Toujours dans l’idée que la communication et la collaboration produisent un travail de meilleure qualité, les schémas de modélisation sont généralement faits en groupe sur un tableau blanc. Enfin, la collaboration avec les clients / utilisateurs est très serrée. Ce sont les utilisateurs qui expriment leurs besoins en écrivant des cas d’utilisation très sommaires. Toutes les précisions seront apportées par la suite au cours de conversation entre utilisateurs et développeurs.

Releases fréquentes :
Dans un souci de souplesse fac e au changement, il est très important d’es- pacer au minimum les releases. Cette pratique permet en outre au client d’avoir au moins une partie utilisable de son application sans attendre la fin du projet. Les livraisons fréquentes contraignent toutefois à réduire les livraisons au strict minimum utile : le code source commenté et le manuel d’utilisation.

Souplesse :
Crystal est une méthode très souple, tant au niveau des procédures à suivre que des normes à utiliser. Par exemple, les normes de codage et de nommage sont très peu contraignantes voire inexistantes pour certains points : ceci n’est pas problématique dans la mesure où la taille de l’équipe reste inférieure à 6 personnes et où ces personnes ont l’habitude de travailler ensemble, d’aider les autres à revoir leur code ce qui rend les normes quasi naturelles. L’équipe est relativement libre de s’organiser à sa guise : parmi les développeurs par exemple, on peut distinguer deux types d’approche. Certains commenceront par prendre une feuille de papier et un crayon pour essayer de schématiser la manière dont ils vont construire et organiser leur code avant de démarrer réellement la programmation. D’autres au contraire fonceront tête baissée dans l’écriture du code ce qui implique pour eux de consacrer plus de temps par la suite au refactoring du code. La méthode Crystal n’est pas directive sur la manière de procéder : les personnalités de chacun sont prises en compte et tant que le travail résultant est le même à la fin, la méthode reste d’une grande souplesse.

Le processus Crystal

Le processus Crystal se décline de la façon suivante :
– spécifications
– conception et planning
– itérations

Spécifications :
Une première phase consiste à interroger le client et les utilisateurs pour qu’ils expriment leurs besoins. Une pratique assez répandue consiste à observer les utilisateurs dans leur travail pour mieux connaître leurs besoins et leur environnement. Les spécifications sont collectées sous forme de cas d’utilisation sommaires : il s’agit de décrire en une phrase une interaction entre l’utilisateur et le système. En collaboration avec les utilisateurs, les différents cas d’utilisation sont classés par ordre de priorité ce qui permet de savoir quelles fonctionnalités ont le plus de valeur et quelles fonctionnalités sont à développer en premier.

Conception et planning :
Une première ébauche de conception est faite dans cette phase, c’est à dire au tout début du projet. Cela inclut le choix des technologies qui seront utili- sées pour la réalisation et une première ébauche de l’architecture pour se donner une vision globale. Enfin, juste avant d’entrer dans la phase itérative, il convient de planifier les itérations qui vont suivre. Crystal recommande des itérations d’une longueur d’environ 2 ou 3 mois, chacune produisant un livrable fonctionnel.

Itérations :
C’est au cours de cette phase que se fait la réalisation proprement dite de l’application. Le premier travail consiste à clarifier et préciser les spécifications au cours de discussions plutôt informelles entre utilisateurs et développeurs. Ensuite, les développeurs font tous ensemble un travail de conception pour déterminer la manière dont ils vont mettre en place les objets de base sur lesquels va s’appuyer le système. Les développeurs se répartissent les différentes parties. Dans les deux se- maines qui suivent le début d’une itération, il convient de mettre en place une maquette qui permettra de faire une démonstration aux utilisateurs. Cette pratique permet bien souvent de déceler des incompréhensions dans les besoins exprimés. Les développeurs sont ensuite libres de procéder comme ils l’entendent pour développer la partie dont ils ont la charge. Les tests sont omniprésents dans le processus de développement : l’architecture est conçue de manière à pouvoir supporter des tests régressifs et des tests automatiques. Les classes de tests font partie intégrante du code et sont souvent écrite avant le code lui même. Le refactoring du code est lui aussi permanent. Il se fait en général en binôme pour optimiser la qualité du code.
Deux ou trois fois par itérations, des démonstrations sont faites aux clients / utilisateurs ce qui permet de toujours bien recadrer le projet en conformité avec les exigences du client. L’écriture du manuel utilisateur est effectuée soit juste avant la livraison d’une release, soit dès le début de l’itération ce qui force les développeurs à définir plus précisément dès le début ce vers quoi ils s’engagent. L’itération se termine par l’intégration et la mise en production de l’application qui est testée une fois de plus avant d’être livrée au client.

Les pratiques Crystal

Les pratiques Crystal sont au nombre de 10 :
– petite équipe
– livraisons fréquentes
– aménagements permanents
– communication osmotique
– confiance, liberté d’expression et sécurité personnelle
– focus sur l’objectif et disponibilité
– contact permanent avec les utilisateurs
– environnement de travail approprié
– collaboration étroite
– réflexion constante

Les avantages de Crystal Clear

Crystal Clear présente tous les avantages des méthodes agiles : flexibilité par rapport au changement, rapidité, livraisons fréquentes, etc.
Par contre, dans la version que nous avons décrite ici, elle reste limitée à des équipes de taille inférieure à 6 personnes, en raison de l’absence d’une personne ou d’un groupe chargé de la coordination.
Les processus et pratiques de Crystal sont très souples et conviennent parfaitement pour des petites structures.

En fait, les approches Crystal et eXtreme Programming sont très proches, à ceci près qu’eXtreme Programming nécessite beaucoup plus de discipline et est plus contraignante. D’un côté, cette particularité rend eXtreme Programming certainement un peu plus productive que Crystal Clear, mais d’un autre côté, tout le monde n’est pas forcément prêt à en accepter les principes alors que Crystal Clear sera certainement acceptée plus facilement.

Filed under:
Agile, agile, Crystal, crystal, crystal clear, Méthodes Agile by admin