Crystal Clear - 7 propriétés pour des projets couronnés de succès

Tiré du chapitre 2 de l’ouvrage Crystal Clear : A Human-Powered Methodology for Small Teams

Récemment, j’ai réalisé que les meilleurs consultants échangeaient des notes concernant les propriétés d’un projet plutôt qu’à propos des procédures suivies. Ils s’enquièrent de la santé du projet : “Est-ce qu’il y a une lettre de mission et un plan projet ? Livrent-ils fréquemment ? Est-ce que le sponsor et les différents utilisateurs experts sont en contact étroit avec l’équipe ?”

Par conséquence, et afin de ne pas prendre le même chemin à partir duquel une méthodologie est habituellement décrite, j’ai demandé aux équipes Crystal Clear de désigner les propriétés clés pour un projet. “Faire du Crystal Clear” est devenu accomplir les propriétés plutôt que suivre des procédures. Deux motivations justifient ce passage des procédures aux propriétés :

• Des procédures ne peuvent pas produire des propriétés. Des deux, les propriétés sont les plus importantes.

• D’autres procédures que celles que j’ai choisies peuvent produire les propriétés pour votre propre équipe

La famille Crystal se concentre sur trois propriétés livraison fréquente, communication étroite, et amélioration réflexive car ces propriétés devraient se retrouver dans tous les projets. Crystal Clear prend avantage de la taille réduite d’une équipe et de sa proximité pour fortifier et transformer la communication étroite en communication osmotique. À part ce changement, les développeurs expérimentés remarqueront que toutes les propriétés que j’ai soulignées dans ce chapitre s’applique à tous les projets, et pas simplement aux projets des petites équipes.

En décrivant Crystal Clear comme d’un ensemble de propriétés, j’espère atteindre le pouls du projet. La majorité des méthodologies décrites ratent ce point crucial qui sépare une équipe couronnée de succès de celle qui ne l’est pas. L’équipe Crystal Clear mesure son état autant par l’humeur de l’équipe et les moyens de communications que par la fréquence de ses livraisons. Nommer les propriétés donne aussi à l’équipe des phrases clés pour déterminer leur situation : “Nous n’avons fait aucune amélioration réflexive depuis quelques temps …” “Pouvons-nous avoir plus facilement accès à des utilisateurs experts ?”. Les noms des propriétés eux-mêmes aident les personnes à diagnostiquer et à discuter de la manière de corriger leur situation actuelle.

Propriété 1. Livraison fréquente

La propriété la plus importante de n’importe quel projet, grand ou petit, agile ou non, est la livraison d’un code testé, opérationnel à de vrais utilisateurs régulièrement à quelques mois d’intervalle. Les avantages en sont si nombreux qu’il est étonnant que n’importe quelle équipe ne le fasse pas déjà :

• Les sponsors obtiennent du feedback essentiel sur l’avancée de l’équipe

• Les utilisateurs obtiennent une chance de découvrir si leur demande d’origine correspond à ce qu’ils ont vraiment besoin et obtiennent en retour que le fruit de leurs découvertes nourrissent le développement.

• Les développeurs gardent leur attention focalisée, cassant ainsi les verrous de l’indécision.

• L’équipe obtient le déboguage de ses processus de développement et de déploiement, et un bon coup de fouet au morale à travers la réussite de ses réalisations.

Tous ces avantages viennent d’une seule propriété, la livraison fréquente. Dans mes entretiens, je n’ai jamais vu de période supérieure à quatre mois qui puisse encore offrir cette sécurité. Deux mois est plus sûr. Les équipes déployant sur le web peuvent livrer hebdomadairement.

Avez-vous livré un code opérationnel, testé et utilisable au moins deux fois dans les six derniers mois à vos utilisateurs ?

Que signifie au juste “livraison” ?

Quelques fois cela signifie que le logiciel est déployé à l’ensemble des utilisateurs à la fin de chaque itération. Cela peut être réalisable avec un logiciel déployable sur le web ou quand le nombre d’utilisateurs est relativement réduit.

Quand les utilisateurs ne sont pas en capacité de recevoir des mises à jours logicielles aussi fréquentes, l’équipe se retrouve dans un dilemme. Si elle livre le système fréquemment, la communauté des utilisateurs en sera ennuyée. Si elle ne livre pas fréquemment, elle peut rater des problèmes concrets avec l’intégration ou le déploiement. Elle rencontrera ce problème lorsqu’il sera trop tard - au moment de déployer le système.

La meilleure stratégie que je connaisse dans cette situation est de trouver un utilisateur bienveillant pour qui tester le logiciel ne pose pas de problème, que ce soit par courtoisie ou par curiosité. Déployez alors sur le poste de travail de cet utilisateur. Cela permet à l’équipe de mettre en pratique le déploiement et d’avoir un feedback utile de la part d’au moins un utilisateur.

Si vous ne pouvez pas trouver un utilisateur bienveillant à qui livrer, faites au moins une intégration complète et tester comme si vous alliez faire un déploiement. Cela laisse seulement une vulnérabilité potentielle du côté du déploiement.

Si l’équipe ne peut pas livrer le système à la totalité des utilisateurs régulièrement à quelques mois d’intervalle, le visionnage de l’application par les utilisateurs devient tout à fait essentielle. L’équipe doit s’arranger pour que les utilisateurs rencontrent l’équipe et voient le logiciel en action, ou du moins qu’il soit installé et testé chez un utilisateur. La corrélation entre ne pas tenir compte du point de vue des utilisateurs et l’échec du projet est évidente, quand finalement les utilisateurs, s’aperçoivent, mais trop tard, que le logiciel ne correspond pas à leurs besoins.

Propriété 2. Amélioration réflexive

La découverte qui m’a pris complètement par surprise est qu’un projet peut contre toute attente passer d’un échec retentissant au succès si l’équipe se rassemble, recense ce qui fonctionne et ce qui ne fonctionne pas, discute de ce qu’il pourrait mieux fonctionner, et applique ces changements au cours de la prochaine itération. En d’autres mots, réfléchir et améliorer. Il n’est pas nécessaire que l’équipe passe beaucoup de temps à faire ce travail - une heure à quelques semaines ou mois d’intervalles suffira. Le fait, seul, de prendre du temps en dehors du tohu bohu du développement quotidien pour réfléchir à ce qui pourrait mieux fonctionner est déjà efficace.

Est-ce que vous vous êtes réunis au moins une fois au cours des trois derniers mois pendant une demi-heure, une heure ou une demi-journée pour comparer des notes d’informations, réfléchir, discuter des habitudes de travail du groupe et découvrir ce qui vous permet d’aller plus vite, ce qui vous ralentit, et ce que vous pourriez pour améliorer ?

Propriété 3. Communication osmotique

La communication osmotique signifie que les informations circulent à portée d’oreille des membres de l’équipe, et ainsi qu’ils piochent les informations intéressantes comme par osmose. Cela est généralement accomplit en les faisant s’asseoir dans la même pièce. Donc, lorsqu’une personne pose une question, dans la pièce certains peuvent écouter ou pas, contribuer à la discussion ou continuer leur travail. Plusieurs personnes ont relaté leur expérience de manière identique à celle-ci :

Nous étions quatre personnes à faire de la programmation en binôme. Le patron est arrivé et a posé une question à mon partenaire. J’ai commencé à y répondre, mais j’ai donné le mauvais nom d’un module. Nancy, qui programmait avec Neil, m’a corrigé, sans même que ce dernier ait remarqué qu’elle parlait ou qu’une question ait été posée.

Lorsque la communication osmotique est en place, les questions et les réponses circulent naturellement et perturbent peu l’équipe aussi surprenant que cela puisse paraître.

La communication osmotique et la livraison fréquente facilitent un feedback tellement rapide et riche que le projet peut opérer sans avoir grand besoin de structure supplémentaire. C’est pourquoi ces deux propriétés sont les deux premières de la liste.

Est-ce cela vous prends 30 secondes ou moins pour que votre question attire l’attention de la personne qui pourrait avoir la réponse ? Avez-vous entendu par hasard quelque chose de pertinent lors d’une conversation entre des membres de l’équipe il y a quelques jours ?

La communication osmotique, qui se nourrit de ce qui se trouve à portée d’oreille et du champ de vision, fonctionne vraiment seulement avec les petites équipes. Les grosses équipes mettront en place la communication osmotique dans des sous-équipes et la Communication étroite entre des sous-équipes.

La communication osmotique baisse le coût des communications et augmente la fréquence du feedback, de telle manière que les erreurs sont corrigées extrêmement rapidement et que la connaissance est vite diffusée. Les personnes apprennent les priorités du projet et qui détient quelle information. Ils piochent de nouvelles astuces de programmation, de conception, de test, d’utilisation d’outils. Ils attrapent et corrigent les petites erreurs avant qu’elles ne grossissent.

Si vous mettez en place un espace de travail du genre pièce de guerre, faites en sorte de mettre en place une autre pièce pour que les gens prennent l’air et rédigent leurs mails privés. Cela permet aux gens de se mettre en condition lorsqu’ils rentrent dans la zone commune, et qu’ils échappent à la pression en y sortant. Un tel aménagement est connu sous le nom d’aménagement “caves et communes”.

La communication osmotique génère ses propres inconvénients, un bruit de fonds et un flot de question au développeur le plus expert de l’équipe. Généralement, ici, les personnes s’auto-régulent, demandent à ce qu’il y ait moins de bavardages ou qu’on leur laisse du temps pour réfléchir.

Même la propriété offrant les meilleurs chances de succès peut s’avérer inappropriée sous certaines circonstances. La communication osmotique ne fait pas exception. Si le concepteur en chef est trop débordé et trop fréquemment interrompu au point d’être incapable d’avancer sur quoi que ce soit, il aura besoin d’un lieu de travail sans aucune interruption, et des communications avec l’équipe extrêmement limitées, ce que j’appelle un cône de silence. Un certain nombre de concepteurs en chef utilisent la tranche horaire 18h00 - 02h00 comme leur cône de silence, mais il serait mieux pour toutes les personnes concernées qu’un cône du silence acceptable soit mis en place pendant des heures de travail normales. La stratégie du cône du silence est décrite en détails un peu plus loin.

Propriété 4. Sécurité personnelle

La sécurité personnelle, c’est être capable de parler quand quelque chose vous ennuie, sans crainte des représailles. Cela peut impliquer d’évoquer à son manager que le planning est irréel, à un collègue que sa conception a besoin d’être améliorer, ou même de faire savoir à un collègue qu’il devrait prendre une douche plus souvent. La sécurité personnelle est importante parce qu’avec elle, l’équipe peut découvrir et corriger ses faiblesses. Sans elle, les personnes ne parleront pas, et les insuffisances continueront à faire des dégâts au sein de l’équipe.

La sécurité personnelle est une première étape vers la confiance. La confiance qui implique donner à quelqu’un d’autre du pouvoir sur soi, avec le risque concomitant de dégâts personnels, et par extension le degré avec lequel une personne est à l’aise avec le fait de donner ce pouvoir à quelqu’un. Certaines personnes font confiance aux autres naturellement, et attendent d’avoir été blessées avant de retirer leur confiance. D’autres ne sont pas enclins à faire confiance aux autres, et attendent avant d’obtenir la preuve qu’ils ne seront pas blessés avant de donner leur confiance. La présence de la confiance est corrélée avec la performance de l’équipe (Costa 2002).

Lorsqu’une personne s’aperçoit que les autres ne la trahiront pas ou ne lui feront pas de mal sur la base des informations qu’elle leur a révélé, elle leur révèlera des informations avec un plus grand degré de liberté, ce qui accélèrera le projet. Par conséquent, la sécurité personnelle est une propriété essentielle à atteindre.

Pouvez-vous dire à votre patron que vous avez sous-estimé de plus de 50%, ou que vous venez juste de recevoir une offre d’emploi tentante ? Pouvez-vous exprimer avec lui votre désaccord en réunion d’équipe ? Est-ce que les personnes peuvent mettre fin à des long débats sur les conceptions des uns et des autres sur un désaccord amical ?

La confiance est amélioré avec la livraison fréquente. Lorsque le logiciel est livré, les personnes reconnaissent qui a fait sa part du travail et qui a esquivé, qui a dit la vérité, qui a blessé ou protégé qui, et qui, en dépit de son comportement apparent, pourrait être cru sur tel ou tel aspect. Avec la sécurité personnelle, ils parlent du fond du cœur pendant les sessions d’améliorations réflexives.

La sécurité personnelle va main dans la main avec la capacité à être amical, la disposition d’écouter avec une bonne volonté. Le projet souffre lorsque quelqu’un de l’équipe arrête d’écouter avec bonne volonté, ou perd l’inclination à passer des informations potentiellement importantes. En plus de la compétence personnelle, l’avancée d’un projet repose uniquement sur la vitesse de propagation de l’information au sein de l’assemblée (en “mètres-mème par minute”, si vous préférez).

Soyez prudent, toutefois, à ne pas confondre la sécurité personnelle avec la politesse. Certaines équipes semblent avoir mis en place la sécurité personnelle, mais elles n’ont pas la volonté de montrer de désaccord couvrant leurs désaccords avec de la politesse et de la conciliation, elles ne détectent pas et ne réparent pas les erreurs qui existent.

Propriété 5. Attention

L’attention, c’est savoir d’abord ce sur quoi travailler, et ensuite avoir le temps et la tranquillité d’esprit d’y travailler. Savoir ce sur quoi travailler vient de la communication sur la direction de l’objectifs et des priorités, et donc généralement du sponsor exécutif. Le temps et la tranquillité d’esprit vient d’un environnement où les personnes ne sont pas extirpées de leurs tâches en cours pour travailler sur d’autres, ce sont des choses incompatibles.

Est-ce que tout le monde sait quels sont leurs deux items les plus prioritaires sur lesquels travailler ? Ont-ils la garantie d’avoir deux jours d’affilé et deux heures de travail ininterrompues chaque jour de pouvoir y travailler ?

Savoir seulement ce qui est important est insuffisant. Les développeurs indiquent régulièrement que les réunions, les demandes pour faire des démos, et des demandes pour corriger des anomalies à la volée les empêchent de faire leur travail. Il est assez habituel pour une personne d’avoir besoin de 20 minutes et une quantité d’énergie considérable pour retrouver son raisonnement après l’une de ces interruptions. Quand les interruptions arrivent trois ou quatre fois par jour, il n’est pas inhabituel pour une personnes de rester simplement inactive entre deux interruptions, car elle ressent que cela ne vaut pas le coup de réinvestir de l’énergie dans un raisonnement alors que la prochaine distraction va arriver en plein milieu de ce dernier.

Les personnes à qui l’on demande de travailler sur deux ou trois projets en même temps indiquent qu’elles sont incapables d’avancer sur aucun d’eux. Il semble qu’une personne ait besoin d’une heure et demi pour retrouver son raisonnement après avoir travaillé sur un autre projet.

Parmi les chefs de projets que j’ai interviewé, le consensus est que le nombre de projets dont une personne peut être en charge tout en restant efficace est de un et demi projets. À partir du moment où un troisième projet est ajouté, le développeur devient inefficace sur l’ensemble des projets. Mettez-ceci en contraste avec les chefs de projets inexpérimentés, qui sous-estimant le coût que cela implique de changer de projets, assignent aux développeurs de travailler sur trois à cinq projets en même temps. Un jour, j’ai rencontré un développeur qui avait été assigné à 17 projets simultanément. Vous pouvez imaginez qu’il avait rarement pu avoir le temps d’aller rendre compte dans différentes réunions de son manque d’avancement sur tous les fronts.

Propriété 6. Accès aisé aux utilisateurs experts

Un accès continu aux utilisateurs experts offre à l’équipe

• un endroit où déployer et tester les livraisons fréquentes,
• un feedback rapide sur la qualité des produits finis,
• un feedback rapide sur leurs décisions de conception, et
• des exigences à jour

Les chercheurs Keil et Carmel ont publié des résultats montrant combien il est essentiel d’avoir des contacts directs avec les utilisateurs experts (Keil 95). Ils ont écrit, en étudiant les chefs de projets qui avaient travaillé avec ou sans un accès facile à de vrais utilisateurs :

” … dans 11 cas sur 14, le projet qui a été le plus couronné de succès est celui qui avait le plus grand nombre de contacts que ceux qui ont moins eu de succès. … Il a été prouvé que cette différence a été statistiquement significative dans un comparatif t-test (p<0,01).”

Leur recherche les a conduit à faire une recommandation bien précise : “Réduisez le fait de vous reposez sur des contacts indirects.” En d’autres mots, ayez vraiment accès à de vrais utilisateurs.

Est-ce que cela prend moins de 3 jours, en moyenne, depuis le moment où vous êtes arrivé avec une question sur l’utilisation du système jusqu’au moment où un utilisateur expert répond à la question ? Pouvez-vous avoir la réponse en quelques heures ?

Tout cela c’est bien gentil, mais combien d’utilisateurs, et combien de temps ?

Le contact à un vrai utilisateur expert même une heure par semaine est extrêmement précieux. Plus il y a d’heures disponibles pour l’équipe avec un utilisateur expert chaque semaine, plus cette proximité est avantageuse pour elle. La première heure, toutefois, est des plus cruciale.

L’autre chose qui est importante est la durée jusqu’à ce qu’une question soit répondue. Si une question n’est pas répondue dans un délai supplémentaire de 3 jours, les programmeurs sont susceptibles de faire le code à leur idée, et d’oublier de re-vérifier la validité de leur décisions lorsqu’ils seront à nouveau en présence des utilisateurs. Par conséquent, ils devraient pouvoir joindre par téléphone l’utilisateur expert pendant la semaine.

Avant de quitter cette propriété, je vous demande de lire à nouveau les derniers paragraphes de la livraison fréquente, dans lesquels je décris les problèmes qui surviennent lorsqu’aucun arrangement n’est fait pour avoir le feedback de vrais utilisateurs. Même les équipes qui font toutes les autres pratiques du développement agile se retrouvent à faire face à de mauvaises nouvelles catastrophiques à la fin du projet si elles négligent les feedbacks pendant le projet.

Propriété 7. Environnement technique avec tests automatisés, gestion de configuration & intégration fréquente

Les éléments que je souligne dans cette propriété sont des éléments vitaux si connus qu’il en est embarrassant de devoir les mentionner. Passons-les en revue un par un puis tous ensemble.

Test automatisé. Certaines équipes arrivent à livrer en ne faisant que des tests manuels, donc cela ne peut être considéré comme un facteur essentiel de succès. Toutefois, chaque développeur que j’ai interviewé qui s’est mis aux tests automatisés jure qu’il ne travaillera plus jamais sans eux à partir de maintenant. Je trouve cela tout simplement stupéfiant.

Leurs raisons est en rapport avec l’amélioration de la qualité de vie. Pendant la semaine, ils revoient des sections de code sachant qu’ils peuvent rapidement vérifier s’ils n’ont pas par inadvertence cassé quelque chose en chemin. Lorsqu’ils voient que le code fonctionne le vendredi, ils rentrent à la maison sachant qu’ils seront capables lundi de détecter si quelqu’un a cassé quelque chose pendant le week-end - ils ré-exécutent simplement le code le lundi matin. Les tests leur donnent la liberté de mouvement pendant le jour et la tranquillité d’esprit pendant la nuit.

Gestion de configuration. Le système de gestion de configuration permet aux personnes d’enregistrer leur travail de manière asynchrone, de sauvegarder les changements, de préparer une configuration particulière pour la livraison, et de revenir à cette configuration plus tard en cas de problème. Cela laisse les développeurs libres de développer leur code à la fois ensemble et séparément. C’est l’outil de non-compilation le plus régulièrement cité par les équipes.

Intégration fréquente. Beaucoup d’équipes font de l’intégration système plusieurs fois par jour. Si elles n’arrivent pas faire cela, elles le font une fois par jour, ou au pire, un jour sur deux. Plus elles intègrent fréquemment, plus elles détectent les erreurs rapidement, moins de nouvelles erreurs apparaissent, plus fraîches sont leurs pensées, plus réduite est la portion de code qui doit être recherchée contenant le malentendu.

Les meilleures équipes combinent ces trois éléments en intégration continue avec tests automatisés. Ils détectent les erreurs d’intégration dans la minute.

Pouvez-vous exécuter les tests systèmes jusqu’au bout sans avoir à être physiquement présent ?

Est-ce que tous vos développeurs enregistrent leur code dans le système de gestion de configuration ?

Insèrent-ils un commentaire à propos de ce qu’ils ont enregistrés ?

Est-ce qu’il y a de l’intégration système au moins deux fois par semaine ?

Témoignage : La collaboration au-delà des frontières organisationnelles

Il y a un effet secondaire à traiter la sécurité personnelle, la capacité à être amicale dans une équipe, et la facilité d’accès aux utilisateurs experts : il devient naturel également d’inclure d’autres parties prenantes dans les projets.

Géry Derbier, qui a travaillé avec les services de La Poste pour élaborer un logiciel pour piloter une nouvelle infrastructure traitant tous les courriers entrant et sortant du nord de la France, a rapporté avoir utilisé Crystal. Avec 25 personnes, son projet rentrait dans la catégorie Crystal Jaune. Toutefois, les principes de la famille des méthodologies Crystal lui étaient connus, tout particulièrement le principe “étirer pour adapter”, et par conséquent, lorsque cela était possible il a choisi d’étendre Crystal Clear à son contexte qui était plus important.

Nous avons discuté de son projet, et à un moment donné nous avons abordé le point des relations entre l’équipe de test d’intégration située à 30 km de là, le métier et l’ergonome travaillant pour La Poste. J’ai posé des questions du style : “À quelle fréquence cette personne rendait-elle visite à l’équipe ? Comment ressentait-elle cette situation ? Que ressentait son responsable à de ses allées-venues si fréquente ?” La réponse de Géry pour les deux groupes externes a été : “Un jour par semaine ; confortable ; content d’avoir été impliqué si tôt.”

Après notre discussion, j’ai réalisé que Géry avait mis en place une sécurité supplémentaire dans son projet collaboration au-delà des frontières organisationnelles. Son projet était relié à la fois au client et aux environnements d’intégrations avec un collègue à sa chaque extrémité. Selon les termes stipulés dans le contrat, La Poste payait régulièrement à quelques mois d’intervalles (la livraison fréquente) en fonction des résultats des tests d’intégrations. La direction de La Poste obtenait un logiciel livré par incrément et payait en fonction. Les patrons de Géry, qui n’avait aucune expérience avec la livraison incrémentale, en étaient content également car ils voyaient les livraisons régulières se transformer en paiements réguliers. Géry avait une structure de soutien chaque côté.

La collaboration au-delà des frontières organisationnelles n’est pas un résultat donné à tous les projets. Elle résulte d’un travail fait avec une capacité à être amicale honnêtement et avec intégrité à l’intérieur et à l’extérieur de l’équipe. Il est difficile à atteindre si l’équipe ne bénéficie pas elle-même de la sécurité personnelle et dans une moindre mesure de la livraison fréquente. Je considère l’existence d’une bonne collaboration au-delà des frontières organisationnelles comme la preuve partielle que les sept premières propriétés peuvent être atteintes.

Réflexion sur les propriétés

Je ne crois pas qu’aucune des procédures prescrites existantes ne peut garantir que le projet atterrisse dans la zone de sécurité à chaque fois. Jamais, à l’exception du développement incrémental, ai-je surgi sur un projet avec un ensemble de règles à la main, même si j’ai mes favorites. C’est pourquoi Crystal Clear est bâtie autour de propriétés essentielles au lieu de spécifications de procédures.

Une équipe Crystal travaille pour mettre en place les sept propriétés, utilisant toute convention de groupe, toute technique et tout standard correspondants à la situation. Les conventions peuvent varier par projet et par mois. De nouvelles techniques sont inventées avec chaque nouvelle technologie (et deviennent généralement obsolètes quelques années plus tard). D’un autre côté, ces sept propriétés ont été appliqués sur des vrais projets ayant réussis depuis plusieurs dizaines d’années.

Mon intention avec Crystal est de ne pas interférer avec les façons naturelles de travailler des individus sur les projets lorsque cela est possible, et de permettre le plus possible de variété entre les différentes équipes, tout en permettant néanmoins à ces différents projets d’atteindre la zone de sécurité. Pour permettre la variété, je dois supprimer les contraintes. Supprimer les contraintes signifie trouver les mécanismes les plus larges possibles offrant un filet de sécurité. Ceux sur lesquels j’ai choisi de me reposer sont les suivants :

• Les gens sont bons par nature à regarder autour d’eux et à communiquer.

• Ils prennent des initiatives lorsqu’on leur donne l’information.

• Ils font mieux dans un environnement qui est sécurisant par rapport à la sécurité de l’état émotionnel des individus et plus particulièrement par rapport aux attaques personnelles.

• Ils font de leur mieux s’ils peuvent satisfaire leur besoin de contribution, d’accomplissement, et de fierté au travail.

Le filet de sécurité de Crystal Clear est bâti sur ça.

La sécurité personnelle donne aux gens le courage personnel de partager tout ce qu’il découvre.

La communication osmotique leur donne une plus grande chance de découvrir des informations importantes les uns des autres, et de le faire à un coût de communication très faible.

L’amélioration réflexive leur donne un moyen pour appliquer le feedback à leur processus de travail.

L’accès facile aux utilisateurs experts leur donne l’opportunité de découvrir rapidement de la part du/des utilisateur(s) l’information pertinente.

La livraison fréquente créé du feedback sur les exigences du système et sur le processus de développement.

L’environnement de développement technique incluant test automatisé, gestion de configuration & intégration fréquente permet aux personnes de faire des changements dans le système en toute sécurité, de synchroniser de multiples esprits qui sont en mouvement en même temps, et d’obtenir rapidement du feedback sur les étapes intermédiaires du système. L’attention permet à l’équipe de donner toute son énergie dans le bon sens sur les choses les plus importantes.

Un jour, Ron Jeffries a défini Crystal comme suit : “Rassemblez quelques développeurs dans la paix, l’amour et l’harmonie livrant du code un mois sur deux, et un bon logiciel en émergera.” Il est proche de la vérité.

Auteur : Alistair Cockburn
Source : 7 Properties of Highly Successful Projects from Crystal Clear
Date de parution originale : 29 Août 2010

Traducteur : Nicolas Mereaux
Date de traduction : 02/12/2015

Ce(tte) traduction est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.