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, 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

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

La valeur des actifs logiciels

Publié par David Beaumier le mercredi 26 novembre 2014 à 09:39

J’ai beaucoup apprécié l’allocution d’ouverture du dernier Agile Tour de Québec par Michael Feathers. J’ai trouvé qu’il abordait des aspects souvent négligés en développement logiciel. Une des choses qui m’a particulièrement accrochée c’est lorsqu’il a mentionné que les organisations devraient devenir plus consciente de la valeur et de l'état de leurs actifs logiciels.

Aujourd’hui combien d’organisation seraient en mesure de fonctionner normalement sans utiliser une solution logicielle? J’en connais bien peu. La plupart des organisations ont des besoins assez élaborés : outils de collaboration, suivi des opérations, relation clientèle, gestion financière, partage de fichiers, systèmes de téléphonie, etc. Qu’elles aient acquis et piloté un progiciel ou investi dans le développement d’une application sur mesure, des ressources importantes ont été engagées dans ces  solutions logicielles.

Malheureusement, la nature même d’un logiciel (ne dit-on pas justement software en anglais) vient fausser la perception que peuvent en avoir les différentes fonctions de l’organisation. En comptabilité on inclut les logiciels dans la catégorie des « actifs incorporels », aussi appelée « capital immatériel ». Bien qu’il existe des façons de déterminer la valeur financière courante de ces actifs, ça se corse lorsqu’il vient le temps de planifier les investissements futurs requis pour maintenir ceux-ci dans un état permettant d’apporter de la valeur à l’organisation.

Avouez que c’est plus simple de déterminer que l’entrepôt vaut 250 000$ et de prévoir un montant annuel pour couvrir les taxes foncières, les assurances, etc. Un gestionnaire attentif remarquera probablement aussi que la toiture commence à être endommagée et qu’il faudra envisager son remplacement d’ici 2-3 ans.

L'hypothèque logcielle

Est-ce que le même gestionnaire sera en mesure de se rendre compte que le moteur de base de données de son système d’expédition s’apprête à être dépassé en fonction du volume projeté des ventes des prochains mois? Est-ce que les parties prenantes ont pris la peine d’inclure la capacité du système dans leurs analyses?  Pas certain. En contrepartie, est-ce que l’équipe de développement a communiqué le vieillissement de la technologie? A-t-elle mis en place ce qu’il faut pour mesurer les performances du système en production?

HypothequeLogicielleLe jour ou le système deviendra si lent qu’il ne sera quasiment plus utilisable (sans doute pendant la période la plus active de l’année) est-ce que l’organisation aura le luxe de procéder à une mise à jour tout en douceur? L’équipe de développement pourrait devoir prendre certains raccourcis pour livrer rapidement une solution corrigée. C’est une approche tout à fait acceptable si elle permet à l’organiser de retrouver sa vitesse de croissance. Par contre, toutes les parties impliquées doivent être conscientes de l’hypothèque logicielle qui grève maintenant le système.

Prenons l’exemple du camion de livraison d’un marchand de meubles pour illustrer cette situation. Si ce marchand néglige l'entretien de son camion en évitant de procéder à un changement d’huile pour pouvoir effectuer plus de livraisons, il risque d’en payer le prix s’il ne planifie pas un autre moment pour faire cet entretien. Une panne lors d'une grosse journée de livraisons risque lui coûter cher et lui causer bien plus de souci qu’une période d’entretien planifiée.

Feathers a mentionné dans son allocution que certaines organisations rendent ces hypothèques visibles et incluent dans le plan de produit les activités requises pour s’en libérer. En procédant au remboursement, l’organisation réduit la possibilité de se retrouver dans une situation où sa dette logicielle l’empêche de saisir une opportunité d’affaires.

C'est, à mon avis, un devoir qu’ont les professionnels du développement logiciel de garder l'organisation dans son ensemble informée de l'état de leurs systèmes. L’information doit pouvoir remonter de l’équipe de développement jusqu’aux parties prenantes. Il faut travailler pour éviter les situations où un gestionnaire se fait dire un bon matin « Votre logiciel est désuet. Il faut le réécrire et on en a pour x mois et ça vous coûtera x centaines de milliers de $ ».  En même temps, les organisations doivent devenir plus sensibles à l’égard de leurs actifs logiciels, poser des questions aux équipes et prévoir un plan pour limiter le gonflement de l’hypothèque logiciel. 

Pour en savoir plus

D'autres billets sur le même thème

Agile Tour 2014 - Les tests et la qualité: moteur de productivité

Publié par Félix-Antoine Bourbonnais, Pascal Roy le mardi 11 novembre 2014 à 00:00

Description

Comment transformer la qualité, les tests et le déploiement en moteur de productivité plutôt qu’en simple poste de dépenses? Portés par Lean et Agile, de grands acteurs (ex.: Google) ont transformé leur département d’assurance qualité pour le placer au coeur du processus de production! Limitez les tests réalisés après l’itération et diminuez la pression sur votre équipe qualité.

  • Présentateurs:  Félix-Antoine Bourbonnais et Pascal Roy
  • Niveau : Débutant
  • Public cible : Tous, spécifiquement Assurance qualité, gestionnaires et équipes de développement.

Présentation

Souligner les succès…

Publié par Vincent Crépin le lundi 3 février 2014 à 20:11

J’ai récemment été appelé à effectuer une intervention à La Capitale et c’était la première fois que l’occasion se présentait à moi. J’avais eu de bons mots de plusieurs personnes ayant effectué des interventions auparavant mais rien de précis. Bien évidemment j’ai été impressionné par leur nouvel édifice vert qui vaut le détour à lui seul. Mais ce n’est pas le sujet de mon article…

Lors de rencontres avec les architectes d’affaires et organiques, j’ai pu prendre connaissance du niveau d’implantation des techniques agiles dans le département du développement et je dois dire que j’ai été impressionné. Je n’avais jamais vraiment entendu parler de cet aspect de La Capitale mais parmi les endroits que j’ai visités, ils sont au sommet de la liste selon ce que j’ai vu.

Salle de développement à La CapitaleJe parle surtout ici des pratiques de développement (TDD, refactoring, intégration continue). Ils utilisent TDD pour tous leurs développement qui utilisent la plateforme Ruby on Rails. Ils possèdent actuellement une base de tests qui se comptent en plusieurs milliers et dont la couverture frôle le 100%. Ils ont une salle de développement dans laquelle la première chose que l’on remarque, c’est la présence intimidante d’un écran géant qui donne en temps réel l’état des builds (il y avait une tuile rouge quand je suis passé ;-)). Voici d’ailleurs une photo de cela.

On sent dans cette salle la très grande complicité entre les développeurs et tous ces facteurs se matérialisent par des mises en production exemptes de défauts.

Il va sans dire que cet accomplissement est un travail acharné d’équipe, comme on le devine tous. Je félicite ces personnes qui se sont battues pour leurs idées et qui ont accompli quelque chose de bien et qui peut servir de modèle pour notre communauté.

Archive