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 – Ranger

Publié par David Beaumier, Jean-Francois Gilbert le jeudi 9 avril 2015 à 07:45

Dans ce second article de la série sur l’application de la méthode 5S en développement logiciel nous abordons le second concept : ranger (ou Seiton, en japonais). On peut résumer le concept de cette façon : « Une place pour chaque chose, et chaque chose à sa place » (source : Wikipedia).

Le but derrière cette notion de rangement est de s’assurer que les équipiers ne perdent pas de temps de travail à chercher les éléments dont ils ont besoin dans le cadre de leur travail. Dans le cas du développement logiciel il peut s’agir autant des classes communes, d’utilitaires pour effectuer certaines opérations que de documentation sur les patrons de conception. Quoi de plus frustrant que de chercher pendant plusieurs minutes où a été déposé l’utilitaire qui permet de convertir une base de données!

Vous trouverez ci-dessous quelques suggestions pour optimiser le rangement dans votre équipe de développement logiciel.

Bien structurer votre projet

Le découpage (dossiers) de votre projet devrait s’appuyer sur le vocabulaire du domaine d’affaires. Il est important d’avoir une uniformité dans le langage utilisé et cela doit se refléter dans le code aussi. Si on parle de « gestion des accès » dans votre application on ne devrait pas retrouver un dossier « autorisations » dans le projet.

Dans un projet Web, il peut être aussi intéressant de penser à une structure qui permette de rapidement distinguer les artéfacts selon qu’ils s’appliquent à la structure du document (html), aux styles (CSS) ou au code (JS).

Assurer une cohérence physique des dossiers et des paquetage

Des outils comme Resharper vous indiqueront s’il existe des écarts entre les dossiers physiques et le nom des paquetages (namespaces dans ce cas-ci). Avec le temps, on peut avoir renommé quelques dossiers, mais avoir oublié de faire les ajustements dans le code.

5S Ranger Resharpernamespacelocation

Valider la dépendance entre les paquetages

 La dépendance entre les paquetages devrait,  elle aussi, respecter le découpage fonctionnel. Ces dépendances sont souvent exprimées en UML sous forme de diagramme de paquetages.

Les fonctionnalités de Dependency Graph et de CodeMap de Visual Studio permettent de dresser une cartographie des dépendances qui vous permettra de valider que celles-ci sont conformes à la cible.

5S Ranger Dependencygraph

5S Ranger Vscodemap

Des outils comme JArchitect peuvent produire diverses métriques sur le niveau de dépendance entre les différentes parties du code. Celles-ci vous permettront de vérifier si les principes architecturaux ont été respectés et vous éviteront d’avoir un couplage trop fort entre les entités de votre système, ce qui a tendance à rendre l'entretien et la réingénierie plus difficile à long terme.

5S Ranger Dependencymatrix

N’oubliez pas la documentation

On ne parle pas ici de la documentation du code source en lui-même (bien qu’elle soit importante), mais plutôt de celle qui forme la base de connaissances de votre équipe. Comment un nouvel équipier saura quel outil utiliser pour produire un script de mise à jour de la base de données relationnelle? Où trouvera-t-il les règles de nomenclatures à respecter?

Que vous utilisiez un wiki ou un autre outil de gestion documentaire, assurez-vous d’y consigner les informations importantes. Souvent, un bref résumé et quelques liens pertinents permettent de conserver une documentation suffisante sur un sujet. Comme le disait Albert Einstein, « Ne mémorisez pas une information que l’on peut facilement retrouver ».

Mise à jour

Voici les liens pour consulter les autres articles.

D'autres billets qui pourraient vous intéresser

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

Publié par David Beaumier, Jean-Francois 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.

Mise à jour

Voici les liens pour consulter les autres articles.

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

L'approche "5 S" en développement logiciel

Publié par David Beaumier le jeudi 8 janvier 2015 à 15:48

Il n’y a pas si longtemps, j’ai participé à un atelier Lean avec une équipe que j’accompagne. L’animatrice de l’atelier, une experte Lean, a présenté différentes pratiques que les équipes peuvent utiliser pour revoir leurs façons de faire. Parmi celles-ci se trouvait l’approche « 5 S ». La méthode des « 5S » est une technique basée sur l’organisation optimale de l’espace de travail afin d’augmenter l’efficacité du processus.

Plus précisément, selon Wikipédia, 5 S « tire son appellation de la première lettre de chacune de cinq opérations constituant autant de mots d'ordre ou principes simples :

  • Seiri: supprimer l'inutile (ordonner);
  • Seiton: situer les choses (ranger);
  • Seiso : [faire] scintiller (nettoyer);
  • Seiketsu : standardiser les règles;
  • Shitsuke : suivre et progresser (être rigoureux). »

Souvent, les exemples présentés pour illustrer les principes du 5 S sont en lien avec le classement des outils nécessaires au travail, à la réduction d’éléments d’inventaire peu fréquemment utilisés, au rangement des espaces de travail (tels que les bureaux). L’image ci-dessous présente un bon exemple d’un espace « 5 S ». Dans ce coffre, chaque chose va à sa place et le système apporte une rigueur qui évite le retour possible au désordre.

Boite-a-outil

Pendant que l’animatrice présentait le concept, je me disais qu’il serait intéressant d’arrimer les concepts 5S à la réalité du développement logiciel. 

  • Ordonner : Avez-vous du code qui ne sert plus ou de la duplication de code dans votre application?
  • Ranger : Le code est-il à la bonne place et facilement accessible? Les espaces de nom (packages) sont-ils bien nommés et cohérents entre eux?
  • Nettoyer : L’équipe met-elle en pratique la réingénierie du code pour améliorer le code existant lorsqu’elle en a l’occasion?
  • Standardiser : Votre équipe possède-t-elle un standard de développement (connu et commun)?
  • Suivre : Avez-vous des mécanismes en place vous permettant d’obtenir rapidement et facilement un portrait de la situation par rapport aux règles énoncées précédemment?

Si vous avez répondu par la négative à certaines de ces questions, il y a peut-être lieu de procéder à un examen de votre base de code afin d’identifier des améliorations potentielles dans un ou plusieurs des 5 axes.

Mettre en œuvre

Fondamentalement, les principes 5S nécessitent une volonté sincère d’individus désireux de faire mieux. En s’appuyant sur le côté itératif et empirique de l’agilité, on peut en venir à mettre en place en environnement 5S optimal tout en débutant avec des initiatives ciblées. En ce début d’année, période propice aux bonnes résolutions, je vous invite à inclure au moins une initiative liée aux principes 5S au carnet de votre prochain sprint. Qu'en dites-vous?

Mise à jour

Chacun des cinq principes fait l'objet d'un article. Voici les liens pour consulter ceux-ci.

D'autres billets qui pourraient vous intéresser

L’engagement : Un des piliers de votre transition agile

Publié par Philippe Tremblay le vendredi 7 février 2014 à 11:00

L’engagement des employés est au cœur du succès des entreprises depuis très longtemps.  C’est l’une des caractéristiques qui se dégage de la réussite de Toyota et son système Lean.  Les valeurs et principes agiles sont eux aussi étroitement liés à l’engagement des employés.  En fait, la relation est telle qu’il est difficile d’identifier la cause et l’effet lorsqu’on parle d’engagement et d’adoption agile.  Est-ce l’engagement des employés qui permet de réussir   la transition ou plutôt l’adoption des principes agiles qui favorise l’engagement des employées?  Explorons tout d’abord l’effet de l’engagement des employés sur une adoption agile.

La courbe d’adoption

L’adoption des principes agiles dans une organisation demande un effort soutenu et une persévérance pratiquement sans limites afin d’introduire un changement durable dans les façons de faire (les pratiques) et d’être (la culture) de l’organisation.  Une analogie représentant bien ce parcours de transformation agile est celle de la courbe d’adoption des technologies présentée par Geoffrey A. Moore dans son livre Crossing the Chasm.

 Crossing +the +Chasm +-+Intel +IT+Center

Lors d’une adoption agile, le rythme de progression au départ est généralement rapide puisque les petites victoires apparaissent dès que certains principes de base sont appliqués.  Bien qu’encore embryonnaire en début de transition, les principes tels l’auto-organisation et la communication face à face pointe habituellement leurs bénéfices à la surface du statuquo assez rapidement.  De plus, les organisations débutent souvent l’adoption sous forme de projet pilote ou en canalisant les apprentissages de l’approche empirique à un sous-groupe de l’entreprise.  Ce qui a pour effet de mettre sous la loupe l’apparition de bénéfices… et des défis.

Après un certain temps, l’adoption des principes et valeurs agiles est confrontée aux diverses difficultés d’un tel changement.  Que ce soit la culture, les pratiques existantes (souvent implicites), les enjeux personnels ou tout simplement les défis techniques, la vitesse de progression n’est définitivement plus la même.  C’est ici que le parallèle au « Chasm » (gouffre) prend tout son sens.  Pour traverser ce gouffre, vous devrez équiper votre initiative d’un nombre plus substantiel de « visionnaires » et pour ce faire, le niveau d’engagement que vous avez su (ou saurez) créer représentera le secret de votre succès.  Cette étape critique pourrait bien être le point où le vent tourne, le moment où ce sera la façon de faire traditionnelle qui commencera à être vue comme « étrange » et moins fréquemment les pratiques agiles.

Agile comme catalyseur de l’engagement

Il est à la fois très difficile et assez simple de stimuler l’engagement dans une organisation.  La difficulté est souvent causée par les pratiques développées dans les organisations lors de leurs croissances.  Ces pratiques parfois explicites par des règles, des processus sont maintes fois beaucoup plus implicites.  Implicite de par les interactions informelles entre les individus, les « façons de faire les choses » qui ont émergé pour contourner les dysfonctions du système ou la perte du sentiment d’accomplissement dans le travail des gens causée par la surspécialisation et la division du travail.

La simplicité des éléments propulseurs d’engagement est parfois désarmante pour les organisations.  Elle l’est encore plus lorsque ces éléments sont mis en relation avec la complexité des défis mentionnés ci-haut.  Une adoption progressive et adaptée des principes Lean et Agile suscitera indéniablement l’engagement présent de la part des gens d’une organisation.  Voici quelques-uns des principes à l’œuvre dans ce « mécanisme humain » :

  • Amélioration continue : Augmente le sentiment d’accomplissement et de maitrise de sa profession
  • Respect pour les gens : Responsabilisation et implication directe dans les résultats de l’entreprise
  • Travail d’équipe : Favorise le développement des gens et l’apprentissage exponentiel par l’échange continu et ouvert des membres d’équipe
  • Collaboration avec les clients : Rends très explicite la contribution du travail des gens dans la satisfaction du client
  • Philosophie long terme : Augmente le sentiment d’appartenance, car les décisions d’aujourd’hui ne sont pas prises au détriment des intérêts long terme de l’organisation et de ses gens
  • Améliorer la source des problèmes : Aucun diachylon n’est posé sur les symptômes.  Les gens savent qu’ils peuvent soulever des problèmes et que ceux-ci seront adressés, améliorés

Voici un autre billet présentant un rapport sur les facteurs qui influencent l’engagement dans les organisations ainsi qu'une série de recommandations pour propulser l'engagement des individus.

Archive