Méthodologie Crystal Clear —
Simplicité et Perfection pour
les Applications Commerciales

• Les méthodolo­gies axées sur les per­son­nes sont plus béné­fiques que celles axées sur les processus.
• La méthodolo­gie doit être adap­tée au pro­jet et à l’équipe indi­vidu­els — il n’ex­iste pas de méthodolo­gie uni­verselle de développe­ment d’application.

1. Livrai­son rapi­de de code utile : Pass­er de déploiements de code lourds et peu fréquents à des ver­sions plus petites et plus fréquentes.
2. Amélio­ra­tion par la réflex­ion : Recueil­lir des infor­ma­tions sur ce qui a bien ou mal fonc­tion­né dans la ver­sion précé­dente du logi­ciel pour amélior­er la prochaine version.
3. Com­mu­ni­ca­tion osmo­tique : Cock­burn a décrit la per­cep­tion et l’échange d’in­for­ma­tions entre les développeurs tra­vail­lant dans la même pièce comme un bruit de fond, sim­i­laire à l’osmose.

• Clear : 2 à 8 per­son­nes tra­vail­lant ensem­ble dans un ou des bureaux adjacents
• Yel­low : 10 à 20 personnes
• Orange : 20 à 50 personnes
• Red : 50 à 100 personnes

Le code géné­tique de Crys­tal Clear con­siste en :

• Mod­èle de jeu économique­ment coopératif : Cock­burn con­sid­ère le développe­ment logi­ciel comme une série de “jeux” com­posés d’in­ven­tion et de com­mu­ni­ca­tion, con­traints par les ressources. Chaque jeu a deux objec­tifs : livr­er le logi­ciel dans ce jeu et se pré­par­er au prochain jeu de la série. Chaque nou­veau pro­jet néces­site de nou­velles stratégies.
• Pri­or­ités choisies : Com­munes à toutes les méthodolo­gies Crys­tal, deux pri­or­ités sont : safe­ty et développe­ment efficace.
• Car­ac­téris­tiques choisies : Celles-ci ren­for­cent la pri­or­ité de sécu­rité. Trois sont fon­da­men­tales (livrai­son de code rapi­de et fréquente, com­mu­ni­ca­tion per­son­nelle, amélio­ra­tion par la réflex­ion), tan­dis que les qua­tre autres sont sup­plé­men­taires : sécu­rité per­son­nelle, focus, accès facile aux experts, et un envi­ron­nement tech­nique de qual­ité avec tests automatisés.
• Principes choi­sis : Un con­tin­ue la direc­tion clé de la per­son­nal­i­sa­tion de la méthodologie : 

Le niveau de détail dans les exi­gences logi­cielle, les doc­u­ments de con­cep­tion et la plan­i­fi­ca­tion dépend des spé­ci­ficités du pro­jet, y com­pris le degré d’in­ter­ac­tion per­son­nelle entre les mem­bres de l’équipe et les dom­mages qui peu­vent être causés par des erreurs non détectées.

Proces­sus Cyclic de Crys­tal Clear

La plu­part des pro­jets avec Crys­tal Clear se com­posent de six cycles, définis­sant les respon­s­abil­ités et les tâch­es de l’équipe de projet :

1. Cycle de pro­jet : Bien que le pro­jet lui-même soit une unité de pro­duit, il est générale­ment suivi d’un autre pro­jet répé­tant le cycle. Le cycle de pro­jet est com­posé de trois par­ties : pré­pa­ra­tion (assem­blage de l’équipe, recher­ché à 360°, déter­mi­na­tion de la méthodolo­gie), une série de deux cycles ou plus de livrai­son, et un “rit­uel de com­plé­tion”. Durée : de quelques jours à plusieurs semaines.
2. Cycle de livrai­son : Implique la recal­i­bra­tion du plan de sor­tie du logi­ciel, une série d’une ou plusieurs itéra­tions aboutis­sant à un code inté­gré testé, livrai­son à de réels util­isa­teurs, et un “rit­uel de com­plé­tion”. Durée : 1 semaine à 3 mois.
3. Itéra­tion : Com­posée de trois par­ties prin­ci­pales : plan­i­fi­ca­tion de l’itéra­tion, activ­ités du cycle quo­ti­di­en et d’in­té­gra­tion, et le “rit­uel de com­plé­tion” du projet.
4. Semaine/jour de tra­vail : Le choix du jour ou de la semaine comme unité de temps du cycle dépend du for­mat et de l’équipe du pro­jet. Des exem­ples inclu­ent des réu­nions heb­do­madaires de départe­ment, des rap­ports de chef d’équipe, et des sémi­naires “brown-bag” (dis­cus­sions autour d’un déje­uner sur les prob­lèmes de projet).
5. Péri­ode d’in­té­gra­tion : Développe­ment, inté­gra­tion et tests sys­tème. Cer­taines équipes effectuent des tests de build con­tinu avec une machine dédiée, tan­dis que d’autres intè­grent quo­ti­di­en­nement ou trois fois par semaine. Plus le cycle d’in­té­gra­tion est court, mieux c’est. Durée : 30 min­utes à 3 jours (selon l’ex­péri­ence de l’équipe).
6. Développe­ment : Rédac­tion et véri­fi­ca­tion d’une par­tie du code. C’est le tra­vail prin­ci­pal d’un pro­gram­meur dans le développe­ment agile. Un mem­bre de l’équipe prend une petite tâche, pro­gramme une solu­tion (idéale­ment avec test), et véri­fie cela en con­fig­u­ra­tion avec l’ensem­ble du sys­tème. Durée : 15 min­utes à plusieurs jours.

Straté­gies et Tech­niques de Crys­tal Clear

• Recher­ché à 360° : Au début du pro­jet, l’équipe doit com­pren­dre à quel point le pro­duit est utile et sig­ni­fi­catif et s’il peut être créé avec les ressources et tech­nolo­gies disponibles. Le pro­jet est exam­iné dans des domaines tels que valeur com­mer­ciale, exi­gences, tech­nolo­gies néces­saires, plan de pro­jet, com­po­si­tion de l’équipe, et méthodolo­gies choisies. La mise en œuvre prend quelques jours à 1 – 2 semaines.
• Vic­toire Pré­coce : Une vic­toire unit l’équipe et ren­force la con­fi­ance de chaque mem­bre. Dans le développe­ment d’ap­pli­ca­tion, la stratégie de vic­toire pré­coce con­siste à trou­ver le pre­mier morceau de code fonc­tion­nel, sou­vent un petit élé­ment de fonc­tion­nal­ité utile du sys­tème. Cette petite vic­toire aide les mem­bres de l’équipe à appren­dre les styles de tra­vail des autres, les util­isa­teurs obti­en­nent une idée pré­coce du sys­tème, et les spon­sors voient les capac­ités de l’équipe.
• Change­ment d’Ar­chi­tec­ture Incré­men­tal : L’ar­chi­tec­ture du sys­tème devrait évoluer à mesure que les besoins tech­nologiques et com­mer­ci­aux changent au fil du temps. La stratégie répond à cela en per­me­t­tant à l’équipe de mod­i­fi­er pro­gres­sive­ment l’ar­chi­tec­ture sans per­turber la fonc­tion­nal­ité glob­ale du sys­tème. La même stratégie peut être appliquée à des change­ments fonc­tion­nels dans le sys­tème final.
• Radi­a­teurs d’In­for­ma­tion : Affichages placés là où les gens peu­vent les voir en tra­vail­lant ou en se reposant. Ils mon­trent des infor­ma­tions néces­saires sans avoir besoin de pos­er de ques­tions sup­plé­men­taires, incar­nant la règle de Crys­tal Clear “plus de com­mu­ni­ca­tion, moins d’in­ter­rup­tions”.
  
  Le radi­a­teur d’in­for­ma­tion doit être grand, facile­ment acces­si­ble, sim­ple à utilis­er et à lire, et con­tenir des infor­ma­tions à jour. Des exem­ples inclu­ent des tableaux Scrum et Kan­ban et un glos­saire de tra­vail inter­pré­tant la ter­mi­nolo­gie du projet.

Tech­niques Pop­u­laires Incluent :

1. For­ma­tion de la Méthodolo­gie : La per­son­nal­i­sa­tion de Crys­tal Clear se fait en deux étapes : entre­tiens de pro­jet (créa­tion d’une mini-bib­lio­thèque d’ex­péri­ence organ­i­sa­tion­nelle soulig­nant les points forts et faibles du pro­jet) et un ate­lier de for­ma­tion de méthodolo­gie (analyse de l’ex­péri­ence pour amélior­er les forces et com­penser les faib­less­es). Les infor­ma­tions de la pre­mière étape sont util­isées dans la seconde.
2. Ate­lier de Réflex­ion : Péri­odique­ment, l’équipe devrait pren­dre une pause d’une heure pour réalis­er un “ate­lier de réflex­ion,” dis­cu­tant de ce qui fonc­tionne bien ou mal, ce qui néces­site une amélio­ra­tion, et ce qui peut être fait dif­férem­ment dans les prochaines étapes du projet.
3. Plan­i­fi­ca­tion Blitz : Per­met aux spon­sors, util­isa­teurs et développeurs de créer ensem­ble une feuille de route pro­jet avec des con­traintes de temps.
4. Réu­nions Quo­ti­di­ennes : Réu­nions cour­tes pour déter­min­er l’é­tat, les pro­grès et les prob­lèmes du pro­jet. Ces réu­nions né sont pas des­tinées à la dis­cus­sion, seule­ment à l’i­den­ti­fi­ca­tion des prob­lèmes. Les résul­tats sont enreg­istrés dans un ges­tion­naire de tâch­es en ligne ou sur un tableau Kan­ban physique.
5. Pro­gram­ma­tion en Paires : Dans ce proces­sus, deux per­son­nes tra­vail­lent sur une tâche de pro­gram­ma­tion sur un seul appareil. La pro­gram­ma­tion en paire est sou­vent cri­tiquée pour élim­in­er les approches indi­vidu­elles des tâch­es et néces­siter des rela­tions inter­per­son­nelles de haute qual­ité au sein de l’équipe pro­jet. Une tech­nique alter­na­tive, “dia­pos­i­tive par dia­pos­i­tive,” implique deux per­son­nes assis­es assez proches pour voir les écrans des autres mais tra­vail­lant sur des tâch­es dif­férentes sur des postes de tra­vail séparés. Cela cor­re­spond au con­cept d’ ”inter­ac­tion osmotique.”

Lec­tures Recom­mandées sur Crys­tal Clear

Ressources clés pour étudi­er Crys­tal Clear comprennent :

• “Crys­tal Clear: A Human-Pow­ered Method­ol­o­gy for Small Teams” par Alis­tair Cock­burn : Le livre essen­tiel pour com­pren­dre la méthodolo­gie de son créa­teur. Il con­tient de nom­breuses études de cas, exem­ples et mini-guides sur la mise en œuvre des élé­ments indi­vidu­els de Clear dans une organisation.
• “Pair Pro­gram­ming Illu­mi­nat­ed” par Lau­rie Williams : Une analyse détail­lée de l’une des tech­niques de Crys­tal Clear, la pro­gram­ma­tion en paire. Le livre four­nit des con­seils pra­tiques sur l’u­til­i­sa­tion de PP dans le développe­ment logiciel.
• “Développe­ment Logi­ciel Agile : Le Jeu Coopératif” par Alis­tair Cock­burn : Explique le con­cept du développe­ment logi­ciel comme un “jeu coopératif d’in­ven­tion et de com­mu­ni­ca­tion.” Cock­burn développe des idées de Crys­tal Clear dans ce livre, qu’il for­malise ensuite dans “Crys­tal Clear: A Human-Pow­ered Method­ol­o­gy for Small Teams.”
• Le site offi­ciel du créa­teur de Crys­tal Clear : Bien que ce né soit pas un livre, il offre une richesse d’in­for­ma­tions, y com­pris des inter­views, des dia­grammes, des bil­lets de blog et des dis­cus­sions sur la méthodolo­gie. Le seul incon­vénient est le design peu accueil­lant du site.