Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Appliquer les principes du « 5 S » dans votre code: Ordonner

Publié par David Beaumier et Jean-François Gilbert le jeudi 19 février 2015 à 13:32

Un de mes derniers billet présentait comment la méthode 5 S  peut s’appliquer au développement logiciel autant que dans un environnement de travail "physique".  Aujourd’hui, mon collègue Jean-François Gilbert et moi avons pensé donner suite à ce billet en vous proposant quelques outils et références fort utiles pour celui ou celle qui souhaite rendre sa base de code 5 S.

Notre objectif n’est pas ici de dresser une liste exhaustive des outils disponibles, mais bien de démonter comment chacun des concepts 5 S peuvent être mis en œuvre en tirant profit des facilités à notre disposition. Aujourd'hui, nous débutons la série avec le premier concept : ordonner (ou Seiri, en japonais). Cette première opération nous demande de supprimer l’inutile.

Retirer le code mort

Heureusement, plusieurs outils permettent maintenant d’identifier en temps réel si un bout de code est utilisé ou non. Il devient ainsi facile de prendre l’habitude de valider si une partie du code qu’on touche pourrait être éliminée.

Voici un exemple où Resharper est configuré de façon à fournir un indicateur visuel qui permet de voir en un clin d’œil les parties inutiles du code source. On peut d'ailleurs établir un parallèle entre ce type d'indicateurs et le management visuel, fortement utilisé en Lean management.

Resharper Indicateurvisuel Codemort

Identifier le code dupliqué

À bien des égards, le code dupliqué est pire que le code mort. Surtout si l'ensemble de ces rejetons n'évolue pas au même rythme. On risque de se retrouver avec des variantes du code de base qui peuvent être difficiles à réconcilier à terme. Et que dire du risque de bogues si on oublie de modifier une de ces copies!

Plusieurs IDE, tel que RubyMine, offrent des fonctionnalités pour identifier les parties de code qui se retrouvent dupliquées.

Rubymine Analyserduplication

Les utilisateurs de Visual Studio ne sont pas en reste avec la fonctionnalité Code Clone Detection.

VS Code Clone Detection

Voilà quelques exemple d'outils qui devraient vous permettre de mette en application la règle des scouts : « laisser le campement plus propre en partant qu’à l’arrivée ».

Et vous, avez-vous des outils préférés pour garder votre code ordonné? N'hésitez pas à partager vos coups de coeur en nous laissant un commentaire ci-dessous.

D'autres billets qui pourraient vous intéresser

Merci pour le feedback

Publié par Marc Allard le mardi 17 février 2015 à 19:19

Thanks For The Feedback

C’est la fin d’une dure journée. Au bureau, des clients vous ont tenu au téléphone pendant une heure à râler pour des pacotilles et votre boss vous a reproché de ne pas être assez patient avec eux. De retour à la maison, vos enfants ont boudé le repas équilibré que vous avez trouvé l’énergie de leur préparer. Et après la routine du dodo, quand vous avez eu enfin la liberté de vous affaler sur le divan pour regarder votre série préférée, votre douce moitié a voulu faire le bilan des factures et de tâches ménagères qui s’accumulent depuis trop longtemps. 

Dans ce temps-là, je ne sais pas pour vous, mais moi j’ai envie de faire comme certains commerces qui ferment un certain temps pour rénover. L’affiche dirait quelque chose comme : « Fermé pour travaux majeurs. Cause : surdose de feedback. »

« On nage dans un océan de feedback », écrivent Douglas Stone et Sheila Heen, dans leur livre Thanks for the Feedback, paru au printemps dernier. Stone et Heen ne parlent pas à travers leur chapeau. Ils font partie du Harvard Negociation Project, un programme fondé en 1979  dans l’université du même nom qui a révolutionné la science de la négociation et dont les membres ont été appelés à l’aide de graves conflits comme la crise des otages iranienne, les négociations de paix israélo-palestinienne et l’apartheid sud-africain.

Stone et Heen, eux, ont travaillé avec tout un assortiment de travailleurs : des PDG, des entrepreneurs, des opérateurs de puits de pétrole, des leaders religieux, des policiers, des cinéastes, des journalistes, des travailleurs de la santé, des astronautes, etc. Lorsqu’ils demandaient à leurs clients de décrire le genre de conversation qu’ils trouvaient le plus difficile, le feedback revenait tout le temps. Après tout, difficile d’en donner, même quand c’est impératif: la personne qui le reçoit se met sur la défensive ou en colère et elle se retrouve moins motivée, pas plus. Alors, pourquoi se casser la tête à en donner?

De toute façon, tout le monde l’a expérimenté avec un patron déconnecté : le feedback est injuste ou infondé, et d’ailleurs le moment était mal choisi et le ton manquait cruellement d’empathie. Le donneur de leçons ne comprenait pas notre job et n’avait aucune idée de nos contraintes. Il aurait dû s’attarder à ce qui va vraiment mal dans la boîte — s’il veut une liste, ça nous ferait plaisir de lui fournir!

Durant longtemps, la solution a semblé du côté des émetteurs de feedback. Il fallait montrer aux cadres comment trouver les bons mots, le bon ton et s’assurer que leurs remarques soient pertinentes. On a toutefois oublié les récepteurs dans l’équation — et la clé se trouve de leur côté, soutiennent Stone et Heen. 

« Entraîner les cadres à donner du feedback (…) peut être utile, écrivent-ils. Mais si le récepteur ne veut pas ou s’il n’est pas apte à absorber le feedback, même la persévérance et une livraison habile du message ne pourront pas se rendre très loin. L’autorité ou le pouvoir des émetteurs importent peu; les récepteurs ont le contrôle sur ce qu’ils font, sur ce qu’ils laissent les atteindre, sur le sens qu’ils donnent à ce qu’ils entendent, et s’ils décident de changer. »

C’est vrai au bureau comme à la maison. Dans son livre sur l’agilité familiale, The Secrets of Happy Families, le chroniquer du New York Times Bruce Feiler rencontre Bill Ury, un des cofondateurs du Harvard Negociation project. Feiler s’interroge à savoir si les techniques de négociation qui ont fait leurs preuves en entreprises peuvent fonctionner dans un couple et avec les enfants. Ury lui répond que son questionnement est tout à fait normal, puisque le modèle hiérarchique qui prévalait depuis des lustres dans la société ne tient plus.

« Maintenant, nous sommes dans une période de transition, explique Ury. La démocratie se répand à travers le monde, les organisations deviennent de plus en plus horizontales. La même chose se produit avec les familles, au sein desquelles les membres veulent prendre part aux décisions qui les affectent. Ce qui veut dire que tout est négociable. Qui fait la vaisselle? Ce n’était pas une question il y a une génération. La nôtre est la première où la négociation est la norme. »

Or, toute négociation repose sur le feedback. Le problème, c'est que la rétroaction est difficile à recevoir, parce qu’elle entre en conflit avec quelque chose de fondamental : notre besoin d’être aimé, accepté et respecté tel qu’on est, expliquent les auteurs de Thanks for the Feedback. Ça ne nous vient pas naturellement de voir le bon côté du feedback; notre réflexe est plutôt de froncer les sourcils.

En se braquant, on perd cependant une source incroyable d’apprentissage. Je me souviens d’avoir lu par exemple que, très jeune, Eugenie Bouchard se distinguait des autres joueuses sur le court de tennis car elle était très attentive aux commentaires de ses entraîneurs et se faisait un devoir de corriger ses erreurs au plus vite pour élever son niveau de jeu. On sait où elle est rendue aujourd’hui! 

Pour le reste d’entre nous qui ne possédons pas cette attitude par défaut, Douglas Stone et Sheila Heen nous rassurent : c’est une habileté qui s’apprend. Même après une dure journée. 

D'autres billets qui pourraient vous intéresser

Entretien avec David Starr

Publié par Marc Allard le jeudi 5 février 2015 à 13:14

DavidstarrDavid Starr est un pionnier de l’agilité familiale. Il y a une dizaine d’années, cet ingénieur en logiciel de l’état de Washington, aux États-Unis, et père de quatre enfants (dont un atteint d’un TDAH et un du syndrome d’asperger), a eu l’idée de transposer à la maison les méthodes agiles. M. Starr et sa famille font partie des figures marquantes du best-seller de Bruce Feiler, The Secrets of Happy Families. Je l’ai interviewé il y a un peu plus d’un an, mais l’entrevue reste toujours aussi pertinente. La voici.  

Q. J’ai lu que vous teniez des réunions familiales à la manière agile, comment se déroulent-elles ? 

R. Chaque jour, on se réunit autour de notre plan hebdomadaire et on regarde notre progression par rapport à ce plan. À la fin de la semaine, on fait une rétrospective : on inspecte et on adapte pour voir comment se comporte notre famille. Et après, on recommence! 

Q. Et vous faites ça vraiment chaque matin ?

R. On appelle ça notre mêlée quotidienne (daily huddle). On se réunit chaque matin cinq minutes alors qu’ils (les enfants) se préparent pour aller à l’école et on se dit : «OK, à quoi va ressembler la journée ?» Ça incite vraiment les enfants à se demander à quoi va ressembler leur journée. Bien sûr, ça va probablement changer, mais au moins ça les start avec un sentiment de contrôle sur eux et sur leur journée. Logistiquement, il faut souvent faire ça un enfant à la fois, mais c’est OK aussi. 

Q. Et à quoi ressemble la rencontre familiale hebdomadaire ? 

R. C’est plus élaboré. On réfléchit à ce qui s’est passé dans la dernière semaine — c’est là que se trouve la vraie valeur de l’exercice. On a des conversations super constructives, utiles et bénéfiques durant cette rétrospective. On évalue ce qu’on a fait pour atteindre les objectifs de la semaine et  à quel point on a réussi, mais aussi comment on s’est amélioré. Parfois, on va discuter d’enjeux personnels, mais on focalise vraiment sur la famille en tant que groupe. De là, on essaie de déterminer de nouveaux objectifs pour la semaine suivante. 

Q. Cette semaine, par exemple, sur quel objectif travaillez-vous ? 

R. Il y en a deux. Le premier est anodin — c’est d’être en mesure de répondre à son téléphone. Nous sommes six dans cette maison et ça arrive qu’on ne soit pas capable de joindre personne. On a découvert que c’est parce qu’ils (les enfants) ne rechargent pas leurs téléphones ! (…) C’est ce qui m’a amené à bricoler une petite station de recharge et à inciter les enfants à déposer leur téléphone à un même endroit. Ça, c’est de la logistique, mais ça adoucit les choses dans la maison. 

Le deuxième, c’est de diminuer les frictions et d’augmenter l’harmonie avant le souper. (…) Pour y arriver, on demande à chaque membre de la famille ce qu’il est prêt à faire pour atteindre l’objectif. Par exemple, ma fille a accepté cette semaine d’aider mon plus jeune garçon [qui a un TDAH] à se calmer quand il se fâche — ce qui lui arrive souvent. Et ça, c’est l’exemple parfait de ce qu’on tente de faire, c’est-à-dire de voir comment on peut s’entraider. 

Q. Transposer des méthodes du travail à la maison reste tabou. Pour beaucoup de gens, on ne doit pas mêler les deux….

R. J’ai réalisé à un certain moment que les choses qui fonctionnent au travail fonctionnent parce qu’elles fonctionnement, et non simplement parce que c’est dans un contexte de travail. (…) Nous sommes tous des humains. Qu’on soit ensemble pour atteindre un objectif dans une business ou qu’on soit ensemble pour atteindre un objectif en famille, les dynamiques sont très similaires. 

Q. Et d’après vous, d’où vient cette réticence à s’inspirer du travail pour s’épanouir en famille ?

R. Pour plusieurs, ça peut être apeurant d’appliquer des stratégies venues du monde du travail à la famille. Certains ont connu des entreprises avec une hiérarchie qui s’apparente à un système totalitaire. Or, le développement agile a mis ce système à l’envers en forçant les leaders de l’organisation à être au service des gens qui travaillent pour eux. C’est beaucoup plus humain et beaucoup plus approprié pour ma famille, parce que je suis au service de mes enfants pour qu’ils deviennent des adultes qui fonctionnement bien.

D'autres billets qui pourraient vous intéresser

Faire le double en moitié moins de temps avec Scrum

Publié par David Beaumier le mardi 3 février 2015 à 18:31

Scrum TwicetheworkhalftimeJ'ai récemment terminé la lecture du plus récent livre de Jeff Sutherland, le co-créateur de Scrum, s'intitulant Scrum: The Art of Doing Twice the Work in Half the Time. L'objectif avoué de Jeff Sutherland avec la publication de ce livre est de faire rayonner Scrum à l'extérieur du secteur des TI et du développement logiciel en particulier. Celui-ci s'adresse donc à des gestionnaires et leaders de tous les horizons. Personnellement, j'ai trouvé qu'il avait atteint son objectif. Il ne peut faire abstraction des succès de Scrum dans le monde du développement logiciel, mais il présente beaucoup d'exemples d'organisations oeuvrant dans d'autres secteurs d'activités qui appliquent Scrum. On voit clairement que Scrum a sa place dans les organisations modernes, particulièrement celles qui font face à des défis créatifs et qui doivent affronter l'incertitude (que ce soit face au marché ou au développement du produit/service lui-même).

D'entrée de jeu, sachez que ce n'est pas un livre pour apprendre comment mettre Scrum en application, il en existe déjà plusieurs qui sont excellents. C'est plutôt un livre qui présente les bénéfices qu'une organisation peut retirer en mettant Scrum en action. Et ça, je trouve que ce livre le fait merveilleusement bien. Jeff Sutherland a écrit ce livre en collaboration avec son fils, un ancien du réseau radiophonique NPR, ce qui n'est sans doute pas étranger au style d'écriture simple, direct et très imagé qu'on y retrouve.

Bien que je ne fasse pas, à priori, parti du public cible du livre, j'ai eu beaucoup de plaisir à le lire. Après plus d'une décennie à mettre en oeuvre les pratiques Agiles et Scrum en particulier, j'ai trouvé cette lecture rafraîchissante et motivante. On s'éloigne parfois de l'essence de Scrum en le pratiquant au quotidien et les aspects mécaniques (telles que les cérémonies ou les artéfacts) peuvent finir par prendre le dessus sur les principes. Parce qu'il doit prouver son affirmation (le double de travail en la moitié moins de temps), Sutherland revient sur les fondements de Scrum et il met l'emphase sur les aspects qui font de Scrum un cadre de travail capable de rendre les individus et les équipes performants: la dynamique des équipes, l'importance accordée au temps, la réduction des gaspillages (sous toutes leurs formes), la visibilité sur la réalité et la gestion des priorités.

Cette lecture m'a aussi permis de prendre conscience de l'arrimage qui existe entre Scrum et le mouvement Lean. À maintes reprises, Sutherland démontre comment tel ou tel aspect de Scrum vient mettre en oeuvre un des principe du Lean. Il consacre même un chapitre entier à l'élimination des gaspillages, un fer de lance du mouvement Lean. Est-ce une stratégie pour favoriser un rapprochement de Scrum avec la communauté Lean et Kanban alors qu'il y a souvent eu des tensions entre ces deux groupes, souvent vu en opposition l'un à l'autre? Je ne sais trop, mais j'ai personnellement bien apprécié qu'on me présente la complémentarité des deux approches.

C'est donc une lecture que je vous recommande même si vous oeuvrez en développement logiciel et ce, quel que soit votre rôle. Je la recommande aussi fortement à tout gestionnaire, peu importe son secteur d'activité. N'hésitez donc pas l'offrir en cadeau à votre patron ou à le laisser traîner dans un endroit stratégique de vos bureaux. Je peux vous affirmer que la couverture attirera l'attention de beaucoup de gens (autant par sa couleur que son titre)!

En terminant, je vous propose cette vidéo d'une quinzaine de minutes où Jeff Sutherland présente plusieurs des éléments qu'il aborde en détail dans son livre.

D'autres billets qui pourraient vous intéresser

Le professionnalisme en développement logiciel illustré!

Publié par Anis Berejeb le jeudi 29 janvier 2015 à 16:50

Bonjour! c'est mon premier billet sur developpementagile.com et j'en suis honoré!

J'ai quelque chose à vous raconter! Mettons que vous allez voir un menuisier pour qu'il vous construise une armoire, et que vous lui demandiez ceci :

Profdevlogiciel BD1

Que croyez-vous que le menuisier va penser de vous? ..

Profdevlogiciel BD2

Ok.. et si nous inversions la question, que penseriez vous si le menuisier AVAIT accepté de vous livrer cette armoire?

Profdevlogiciel BD3

Quand vous allez voir n'importe quel professionnel, vous supposez qu'il agira en tant que tel. d'ailleurs généralement, son attitude  professionnelle est principalement la raison pour laquelle vous l'auriez choisi.

Le métier de développeur est une profession. il ne doit y avoir aucune différence en terme d'attitude professionnelle entre un professionnel du logiciel et un professionnel de la santé par exemple.

En tant que professionnels du développement logiciel, nous sommes supposés avoir la meme attitude, agir de la même façon et livrer du travail de qualité digne de notre métier.

En s'inspirant fortement du courant de l'artisanat logiciel ou "software craftsmanship" fondé par Bob. C. Martin, je vous présente la bande dessinée "les 9 principes du développeur agile professionnel".

Profdevlogiciel Recap

Téléchargez la bande dessinée gratuitement sur www.berejeb.com

Archive