tag:blogger.com,1999:blog-5897468304664210802024-03-04T22:53:45.983-08:00Continuous improvementAnonymoushttp://www.blogger.com/profile/17257124104532108556noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-589746830466421080.post-78938913717894444752014-03-02T04:58:00.001-08:002014-03-02T04:58:57.672-08:00Principe YAGNI : N'anticipez pas le futur.<div class="separator" style="clear: both; text-align: center;">
<a href="http://sthiery.blogspot.com/2014/03/principe-yagni-nanticipez-pas-le-futur.html" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjR0wA265jlCBjDBkohfsnT3G2AcBKZHDaAaZrW8b7_I3tCGYRBUBKhVOiQMvE_YlPjXAFvHky5sf_QKHOr1rOExtShszAr9DiR4AeIqstyIp7iFGAYXutkb6dZ-B8dpFjf9TZ41DnLww/s1600/avenir.jpg" height="95" width="320" /></a></div>
<div style="text-align: justify;">
<i><span style="color: red;">"You ain't gonna need it"</span></i> ou principe <b><span style="color: red;">YAGNI</span></b> est sans doute l'un des principes les moins bien compris des développeurs. </div>
<br />
<br />
<br />
<br />
<a name='more'></a><div style="text-align: justify;">
<br />
<br />
Rempli de bonnes intentions, nous sommes tous enclin à faire des développements informatiques supplémentaires; ces développements ne servent à rien pour l'application sur le moment mais peuvent <u>éventuellement</u> faciliter l'intégration de futures évolutions. De bonnes intentions certes, mais qui est à même de prédire l'avenir ? Dans 99% des cas, le futur nous donne tort ; tout ce que nous imaginons ne se produit jamais. Arrêtons donc de jouer aux astrologues du virtuel et arrêtons de nous prendre pour la "Madame Irma du bit" !<br />
<br />
<div style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;">
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0pQc4nZgteUu2ZtHl0b8Vq8TJX-1L45_lWTowQiw1HG7vm8Tr1Xmu2D75Z_aqvS_Zj4TehxJ4beJ3cHxgvIXV3UMo4zWWLpyHEPMTrPOSGvPmpHNf16yi2zdr8pI7zoGi5eNtksL-eg/s1600/image.jpg" height="240" width="320" /></div>
Un exemple concret pour illustrer ce fait : vous venez de refaire votre salle de bain et vous souhaitez voir raccorder votre nouveau lavabo à la canalisation d'eau. N'y connaissant rien en plomberie, vous faites alors appel à un professionnel. Une heure de travail devrait être largement suffisante pour réaliser cette tâche.<br />
<br />
Imaginez que le plombier ne suive pas le principe YAGNI, voici un scénario possible : au bout d'une journée, votre "professionnel de la plomberie" vous annonce fièrement que le travail a été plus long que prévu ; votre lavabo est maintenant utilisable et, cerise sur le gâteau, un tuyau a été mis en place entre la canalisation et la chambre d'à côté. Surpris et énervé, vous lui demandez des explications ; il vous répond alors : "Si un jour vous échangez votre chambre avec votre salle de bain, le tuyau sera déjà en place et vous gagnerez du temps". Bilan de l'opération : vous payez 1 journée de travail au lieu d'une heure, le mur de séparation entre votre salle de bain et votre chambre a été percé et un tuyau pointe son nez dans votre chambre ! Imaginez votre tête !<br />
<br />
Cet exemple, volontairement fantaisiste, est pourtant celui que nous proposons régulièrement à notre chef de projet. Les conséquences sont pourtant les suivantes :<br />
<br />
- un surcoût de développement<br />
- un surcoût dans l'écriture des tests<br />
- un code rendu souvent plus compliqué<br />
- des portions de code qui ne répondent à aucune spécification.<br />
<br />
Conclusion : comme l'écrit Horace dans l'un de ces poèmes: "<i>Carpe Diem</i>" : <i><span style="color: red;">Cueille le jour présent sans te soucier du lendemain</span>. </i><br />
<br />
<br />
<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/17257124104532108556noreply@blogger.com0tag:blogger.com,1999:blog-589746830466421080.post-88348440909129852882014-02-15T05:16:00.000-08:002014-02-17T11:48:25.262-08:00Le pair-programming - retour d'expérience<br />
<div style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;">
<a href="http://sthiery.blogspot.com/2014/02/le-pair-programming-retour-dexperience.html"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioox-IJf85Tu1ejq5fP0SNcYPr9jRo90_ZtmKSos4_CXvnB7CYJkgcHVvbNyhqEp1rUhibLg4UcRIfU6zB-dTn-cKAXPTbHhUhHGxSWC7UeUtLzbNeMdmAoNs9nylkntloXs3Qk1ni8A/s200/fusion.png" height="200" width="200" /></a></div>
<div style="text-align: justify;">
En 2010, j'ai eu la chance de vivre dans une équipe "Full Extreme Programming" pendant 15 mois. Bilan de cette expérience : des séances de développement intenses, un véritable travail d'équipe et un enrichissement technique et humain incomparable.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Je me propose dans cet article de revenir sur l'une des pratiques XP encore trop peu utilisée à mon goût : le pair-programming. </div>
<br />
<br />
<br />
<br />
<a name='more'></a><br />
<h3>
<span style="color: red;">Pair-programming et préjugés </span></h3>
<br />
<div style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;">
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeIFVOw_v-qohAE7vZWFF4gCVbQZyrXvl1RUDLZmHmsDSEuLIAV3v-kbfq-RcLNWdnjd3R58ubqbmPk-A0vSsokRZxWldJvbgTR3n2YLLLOrpxS0wDRc3qh-jaaXTs4EDBsHXc9Diq-g/s1600/pairprogramming.jpg" height="132" width="200" /></div>
<div style="text-align: justify;">
Le pair-programming est souvent vu d'un mauvais œil côté management : "2 développeurs par poste! Et pourquoi pas trois tant que l'on y est!". Ce sont d'ailleurs ces mêmes managers qui sont prêts à doubler la taille de leur équipe pour doubler leur productivité ... et leur bonus.<br />
<br />
Cette "logique" mathématique n'est pourtant pas de mise dans d'autres métiers : un futur chirurgien par exemple devra apprendre les bons gestes, les bons réflexes aux côtés d'un chirurgien expérimenté pendant au moins une dizaine d'années . Est ce que le responsable d'un hôpital se pose la question de savoir si affecter 2 chirurgiens par opération divise par deux la productivité de son établissement ? Ayant été malheureusement obligé de passer de nombreuses fois sur une table d'opération, je peux vous dire que je suis plutôt rassuré d'avoir 2 spécialistes pour s'occuper de moi. Ce n'est pas leur productivité immédiate qui m'intéresse alors. Qu'importe si l'opération dure 2 ou 4 heures, du moment que la qualité de l'intervention soit au rendez-vous. Hors de question de devoir revenir pour me faire opérer à nouveau ou encore que l'opération soit un demi succès ...</div>
<div style="text-align: justify;">
<br /></div>
<h3>
<span style="color: red;">Pair-programming et qualité</span></h3>
<div>
<span style="color: red;"><br />
</span></div>
<div style="text-align: justify;">
Il ne faut pas s'arrêter à cette impression visuelle de gâchis de compétences ou de non-optimisation du temps de travail des développeurs. Le pair-programming joue un rôle important dans la dynamique d'une équipe. Voici listées toutes les conséquences positives de l'adoption de cette pratique :</div>
<br />
<div style="text-align: justify;">
<b><span style="color: yellow; margin-left: 40px;">Diffusion des bonnes pratiques</span></b><br />
<br />
<div style="margin-left: 40px;">
La revue de code est un moyen de garantir que les bonnes pratiques se propagent petit à petit dans l'équipe. Le pair-programming est encore plus radical : le feedback est instantané ; nul besoin de modifier son code après coup : les conseils sont pris en compte en direct.</div>
</div>
<br />
<b><span style="color: yellow; margin-left: 40px;">Augmentation de la qualité du code</span></b><br />
<br />
<div style="margin-left: 40px;">
<div style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;">
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMRKrwRZW0HuZsHkf_v5ddPN5fGFR9a3y39oZkY0lG3LVs65pDdkbjvFyg0FMZESC6HcaJGXkXdgZpy-aqcS4s1cLutOilq04olmophrZFxgvU8HyA1s9XJlRa6ci9NBMDzxoDNBs0LA/s1600/electronicalMess.jpg" height="200" style="text-align: start;" width="150" /></div>
<div style="text-align: justify;">
Combien d'applications sont devenues de véritables "poubelles" de code après quelques années ? Pour les managers non techniques, voici un exemple de la vie réelle : Considérez cette baie électronique. Votre responsable vous demande de modifier ou d'ajouter une connexion sans bien évidemment faire de régressions. Quel est votre degré de confort pour intervenir dans un tel environnement ? Je vous pose cette question car c'est ce que vous demandez de faire chaque jour à de très nombreux développeurs alors que vous n'êtes pas conscient de l'état de votre application.<br />
<br />
Le pair-programming permet d'éviter cette situation. La confrontation des idées et une prise de décision partagée permet d'aboutir à un code plus simple - et non simpliste - lisible et donc maintenable. Du coup, l'équipe continue à délivrer de nouvelles fonctionnalités de manière constante au cours du temps et ne se retrouve pas dans une situation de productivité quasi-nulle quelques mois ou années plus tard. </div>
</div>
<div style="text-align: justify;">
<span style="text-align: center;"><br />
</span></div>
<div style="text-align: justify;">
<span style="color: yellow; margin-left: 40px; text-align: center;"><b>Partage de la connaissance</b></span></div>
<br />
<div style="margin-left: 40px;">
<div style="text-align: justify;">
Les développeurs intégrant une nouvelle équipe sont très souvent livrés à eux-mêmes, sans véritable formation. Du coup leur montée en compétence est lente et fastidieuse. Le pair-programming est une des meilleures réponses pour éviter cette situation. Dans mon ancienne équipe, nous avons intégré des stagiaires de la sorte. Dès le premier jour, ces derniers codaient et donnaient leur avis sur le code de l'application. Leur apport est immédiat : tout code compliqué est détecté et donc remanié aussitôt. Au bout de 6 mois de vie dans l'équipe, les stagiaires avaient le niveau d'un développeur plutôt expérimenté. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
La formation et le partage de connaissance via le pair-programming permet d'éviter le code propriétaire. Toute partie du code est connue par au moins 3 développeurs. Ainsi, toute absence d'un développeur ou tout départ en vacances ne met plus en risque l'équipe entière.<br />
<br /></div>
<div style="text-align: justify;">
</div>
</div>
<h3>
<span style="color: red;">Pair-programming et pré-requis</span></h3>
<div>
<span style="color: red;"><br />
</span></div>
La mise en place du pair-programming requiert cependant quelques éléments de base :<br />
<br />
<b><span style="color: yellow; margin-left: 40px;">Un espace de travail qui n'entrave pas le déplacement</span></b><br />
<br />
<div style="margin-left: 40px; text-align: justify;">
Un membre de l'équipe doit pouvoir circuler dans l'open-space sans gêner ses équipiers. Réfléchissez à l'agencement, la forme et la taille des bureaux ainsi qu'à l'environnement immédiat.</div>
<br />
<b><span style="color: yellow; margin-left: 40px;">Une atmosphère de respect dans l'équipe</span></b><br />
<br />
<div style="margin-left: 40px; text-align: justify;">
Le pair-programming a des implications sociales. Les relations entre individus, l'égo des personnes sont mis en lumière. Il est donc très important d'instaurer une ambiance de confiance, de respect afin que la parole de chacun soit écoutée. </div>
<br />
<b><span style="color: yellow; margin-left: 40px;">Une organisation non parasitée par les mails</span></b><br />
<br />
<div style="margin-left: 40px; text-align: justify;">
Le pair-programming demande une grande concentration des personnes. Il et souhaitable que ces dernières soient préservées au maximum de tout parasitage extérieur. Impossible de lire une centaine de mails par jour comme cela est désormais légion dans beaucoup d'entreprises.</div>
<br />
<h3>
<span style="color: red;">Pair-programming et dangers</span></h3>
<div>
<span style="color: red;"><br />
</span></div>
<div>
<b style="margin-left: 40px; text-align: justify;"><span style="color: yellow;">Mise en place dans une équipe</span></b></div>
<br />
<div>
<div style="margin-left: 40px; text-align: justify;">
Si une équipe est en cours de création, indiquer clairement aux postulants que le pair-programming est une des pratiques de l'équipe. Cela évitera d'embaucher des profils qui quitteront le navire avant même le premier mois de développement.</div>
<div style="text-align: justify;">
<br /></div>
<div style="margin-left: 40px; text-align: justify;">
Si une équipe est déjà en place, forcer tous ses membres à pair-programmer peut être contre-productive. De nombreux développeurs ne souhaitent en effet pas pair-programmer : les personnes qui doutent d'elles-mêmes et les personnes non communicantes peuvent appréhender ces interactions forcées. Les faux experts, quant à eux, verront leur supercherie être rapidement démasquée.</div>
<div style="text-align: justify;">
<br /></div>
<div style="margin-left: 40px; text-align: justify;">
Limitez plutôt dans un premier temps le pair-programming aux tâches complexes et/ou impactantes et laissez l'équipe se faire un avis sur les expériences réalisées.</div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<b style="margin-left: 40px; text-align: justify;"><span style="color: yellow;">Rythme soutenable</span></b><br />
<b style="text-align: justify;"><span style="color: blue;"><br />
</span></b></div>
<div style="margin-left: 40px; text-align: justify;">
<div style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;">
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQOqhQs20wDoka8eo8ata9okZqukDFgJxgKL5zKwm-LFyYcWCBCUQfYP3UPIkYR0KDxA-4Nyw5xNN8PWq42TCHkUiJyljJu9uNA2wlEANbQNwn3m-SpBk19pG4tiIvkv0L9ERSCtUv3Q/s1600/rythmeSoutenable.jpg" height="125" style="text-align: center;" width="200" /></div>
Le pair-programming est une expérience véritablement énergivore. Les sessions doivent ainsi être limitées à 6 heures par jour pour que le rythme soit soutenable ... n'en déplaise à ceux qui ne valorisent que le temps de présence au travail et non le travail réellement effectué. Mais 6 heures de haute concentration sont plus productives que 10 heures à switcher entre son environnement de développement, les mails, internet et la messagerie interne.<br />
<br />
De même, laisser les développeurs travailler seul ou se former seul au moins une demi journée par semaine. Cet espace temporel permet l'émergence d'idées pertinentes pour améliorer le code ou les pratiques de l'équipe ou encore de réaliser des mini-projets de tests de frameworks, de nouveaux outils, de design ou autres.<br />
<br /></div>
<div style="margin-left: 40px; text-align: justify;">
Enfin, même si le pair-programming est de mise dans votre équipe, chaque développeur doit conserver son propre PC. Il est important que chacun puisse garder un espace personnel.<br />
<br /></div>
<div style="text-align: justify;">
<h3>
<span style="color: red;">Le mot de la fin</span></h3>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Les problèmes d'une équipe de développement sont principalement des problèmes humains. Favoriser la collaboration, la communication et les interactions est bien souvent déjà un grand pas vers une solution. Alors qu'attendez vous pour expérimentez cette pratique sur vos projets ?</div>
Anonymoushttp://www.blogger.com/profile/17257124104532108556noreply@blogger.com0tag:blogger.com,1999:blog-589746830466421080.post-57188427330797369722014-02-09T09:51:00.000-08:002014-02-09T09:55:39.422-08:00Fixer un bug n'a pas de valeur<div style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><a href="http://sthiery.blogspot.com/2014/02/fixer-un-bug-na-pas-de-valeur.html"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxx-M5eBlFTMVJxhilfZZA-tVgZeps8hn19VGSizeFxK1amdhex7CGQGwCJumGCEksvGwzAONEBcJEplQ9acDNRZQ4X8-499FPSk3s8DgSHV6coU3URNapuW10J5UnmtRqY1T9o3oaNQ/s1600/NullValue.jpg" height="200" width="196" /></a></div><div style="text-align: justify;">Le thème de cet article peut surprendre mais de nombreux responsables d'applications et de nombreux développeurs continuent encore trop souvent à considérer la fixation d'un bug comme un travail normal alors que cela devrait les perturber. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<a name='more'></a><br />
Trop souvent, le but de certains responsables d'application est d' "occuper" tous les membres de son équipe. Cela est un but louable si les développements prévus ont de la valeur pour l'utilisateur ou pour l'équipe. <b>Mais</b> f<b>ixer un bug n'a pas de valeur.</b></div><div style="text-align: justify;"><br />
De même, pour de trop nombreux développeurs, passer plusieurs journées à faire du debug est passionnant. Etre un archéologue du virtuel, un Sherlock Holmes des temps modernes attire. C'est aussi une des manières de se rendre indispensable sur des applications mal développées : et oui, le mythe du "faux" héros fascine et est d'ailleurs plutôt lucratif et valorisant dans certaines structures. <b>Mais</b> f<b>ixer un bug n'a pas de valeur.</b><br />
<br />
</div><div style="text-align: justify;">Un bug n'est rien d'autre qu'un défaut de fabrication. Fixer un bug n'est donc que corriger ce dernier. Tout le temps passé à cette fin est du temps, de l'énergie et donc de l'argent gaspillé.<br />
<br />
Pourquoi l'exemple de l'industrie ne fait-il pas office de référence?<br />
<br />
<div style="text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuU3GDlA_o7DfOKPQvN0d7XzfOc_NCgW8LeTCeiYSpfiXo8fKN0YQvqJrgMJvLMUGXBzsVTTLo6uz9OKeC8Ulv5GYrQrz0P1LDpvKHYewnxFKnHYl4P6E_n_YYBL0NbFWj0IfWhDRXOg/s1600/carsdefect.jpg" height="480" style="text-align: start;" width="640" /></div><br />
Un "bug" a des conséquences catastrophiques pour un constructeur automobile :<br />
<br />
</div><div class="MsoNormal"><div style="text-align: justify;">- des milliers de clients insatisfaits chez qui le doute grandit quant à la qualité du véhicule acheté</div></div><div class="MsoNormal"><div style="text-align: justify;">- une confiance dans le constructeur qui s'effrite</div></div><div class="MsoNormal"><div style="text-align: justify;">- une image de marque qui est sérieusement entachée</div><div style="text-align: justify;">- un coût de rappels des véhicules impactés prohibitif</div><div style="text-align: justify;"><br />
</div></div><div class="MsoNormal"><div style="text-align: justify;">Pourquoi dans l'informatique n'a t'on pas encore systématiquement une aversion pour le bug alors que des solutions existent pour les éviter ?</div></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"> - Favoriser la collaboration entre le client/business analyst, les développeurs et les testeurs.</div><div style="text-align: justify;"> - Favoriser le pair-programming ou au minimum la revue de code entre développeurs</div><div style="text-align: justify;"> - Ecrire des scenarii d'acceptance avant la phase de développement</div><div style="text-align: justify;"> - Maîtriser fonctionnellement son application et ne pas laisser galoper l'entropie d'année en année.</div><div style="text-align: justify;"> - Créer un filet de sécurité pour développer en toute sécurité en se dotant de tests automatisés pertinents, orientés comportement et non implémentation ...</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Investir dans la qualité, ralentir pour mieux accélérer telle est l'idée clé. Encore faut il ne pas avoir une vision court-termiste du retour sur investissement ...</div>Anonymoushttp://www.blogger.com/profile/17257124104532108556noreply@blogger.com0tag:blogger.com,1999:blog-589746830466421080.post-676313829105817552014-01-25T05:52:00.002-08:002014-01-25T06:32:41.345-08:00Agile Avatars<br />
<div style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;">
<a href="http://sthiery.blogspot.com/2014/01/agile-avatars.html"><img alt="" border="1" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvzcFuoA6wRIqFrDBg6b-XGGO5VkloUqt7uQ7t2S8MNnj1sEwRUZbf8XY8ItHPqjAb6O30VXUzs7J1fM1dlPFMjEFzWcTIPhyphenhyphenolE3xBKtHAYrCY3IwOIbFXqlMdqLiZmbQXC4Q7Buu0A/s320/agile_avatar_1.jpg" height="198" title="Agile Avatars" width="200" /></a></div>
L'amélioration continue concerne même les tableaux Kanban ou Scrum ... <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<a name='more'></a><br />
<div style="text-align: justify;">
Dans mon équipe, nous utilisons un tableau kanban pour suivre l'évolution de notre flux d'activités. De simples post it collés au tableau matérialisent nos user stories. Cependant force est de constater que l'utilisation conjointe d'un post it, d'un avatar papier et d'un petit aimant n'était pas optimale.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Il y a un mois, je suis mis à la recherche d'un site internet proposant la création de magnets personnalisés. J'ai finalement trouvé un site tout simple, "AgileAvatars" (<a href="http://agileavatars.com/">http://agileavatars.com</a>)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Après avoir contacté le responsable de ce site, j'ai récupéré toutes les informations :</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
- les photos doivent être carrées et avoir au minimum un format de 400 x 400 pour que le rendu soit de bonne qualité.</div>
<div style="text-align: justify;">
- le prix proposé est d'1 euro par magnet de 4cm par 4cm.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
J'ai donc commandé une centaine de magnets pour toute notre équipe de coaches. Je n'ai pas été déçu du résultat. Pour preuve, voici un exemple de magnet reçu :</div>
<br />
<div style="text-align: center;">
<img border="1" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikCjTd6LuxmUuVH1WNOU0MHcSJFevgveIQOzUBtHOymYgSDlpxbbLxKahX7UmyMlqZtnu-N0ReFPcv8jIkrEBCFSE_q41UJoiVr-IykmLfcMbb1lSkO6FJanPeKDJQ89dBV8XTVMzLfw/s320/agile_avatar_2.jpg" /></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: left;">
Au final, nous ne nous énervons plus sur notre tableau et nos avatars ont fière allure. Comme quoi l'amélioration continue peut aussi concerner de petits éléments matériels ...<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/17257124104532108556noreply@blogger.com0