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.

Leçon de vie

Publié par Jean-Francois Gilbert le lundi 9 mars 2015 à 00:00

Il y a quelques temps, j'ai commencé à travailler sur une preuve de concept relativement complexe. Au départ, je n'avais qu’une vague idée des outils et de l’architecture que j’allais utiliser. Il y avait tellement d'inconnus que je ne savais pas trop par où commencer. 

J'ai donc avancé le projet un peu à tâtons. Je m’efforçais de répondre aux exigences fonctionnelles complexes tout en explorant une plateforme que je connaissais peu. Bref, j'en avais un peu par-dessus la tête. Pour sauver du temps et parce que je croyais tout jeter à la poubelle de toute façon, j'ai commencé à coder sans écrire de tests unitaires. Je vois d’ici vos hochements de tête désapprobateurs. Mais je croyais que les chances que mon code puisse être réutilisé plus tard étaient tellement minces que ça me ralentirait d’écrire des tests tout de suite. Oh, mais quelle erreur !

Au début, je dois avouer que ça allait plutôt bien. J'essayais des choses, je changeais d'idée, j’effaçais le code, j’essayais autre chose. Pas de temps à perdre, je produisais du code à la vitesse grand V ! Étant habitué à programmer presqu'exclusivement en mode TDD, je ressentais quand même un certain malaise. Je n'avais pas mon filet de sûreté habituel et je n’étais pas particulièrement fier du design de mes classes. Mais bon, mon prototype fonctionnait, non ?

A un certain moment j’ai réalisé que globalement, la piste que je suivais depuis plusieurs jours était la bonne. Il y avait bien quelques inconnus ici et là, mais je commençais à avoir entre les mains quelque chose d’intéressant. Or, puisque j'avais codé un peu en cow-boy, le design n'était pas génial et ma solution commençait à être sens dessus dessous. J'ai donc commencé à faire du réusinage pour être capable de mieux me retrouver. C'est à ce moment que des bugs ont commencé à faire surface. Je me suis mis à perdre un temps fou. Les modifications étaient suivies par des séances de débogage dans Visual Studio et je maudissais les dieux de la programmation, mais surtout moi-même. Au lieu d'avancer, je faisais des pas en arrière à chaque fois que je modifiais du code.

Je n'ai eu d'autre choix que de recommencer du début. Mais cette fois, j'ai bâti mon code comme je suis habitué de le faire : en TDD. J’ai quelque fois eu le goût de prendre le code du prototype et le copier dans mes nouvelles classes, mais j'ai presque toujours résisté à la tentation. Bien sûr, j'ai gardé certains concepts mais le fait de recommencer du début a fait émerger un design différent et surtout meilleur.

En bref, soyez plus brillants que moi. Prenez le temps de bien faire les choses dès le début et en bout de ligne vous gagnerez du temps. Je crois qu'on peut se permettre d'expérimenter de nouveaux outils sans faire de tests unitaires exhaustifs. Mais il faut savoir identifier le moment où on a une assez bonne idée de la solution et reprendre les bonnes pratiques de développement.

En terminant, voici quelques billets qui pourraient vous intéresser concernant le TDD et les tests unitaires.

Jusqu'à quel point dois-je tester mon code ?

TDD : comment partir du bon pied ?

Comment rendre vos tests plus propres grâce aux builders ?

 

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

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

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 puissance des scénarios d’acceptation

Publié par David Beaumier le lundi 22 décembre 2014 à 13:08

Source: specflow.org

Récemment, j’avais comme tâche de préparer les scénarios d’essais pour un récit (User Story) que l’équipe devait réaliser. Il faut savoir que l’équipe utilise des scénarios basés sur la syntaxe Gherkin (avec l'outil SpecFlow) pour définir le comportement attendu de l’application. Le récit en question étant très simple (il concernait l’accès une fonctionnalité selon les permissions de l’utilisateur), je vous avoue que je me suis demandé avant de débuter si ça valait la peine d’écrire ces quelques scénarios. Dans le fond, il y a seulement deux cas possibles : l’utilisateur a accès ou non. Simple n'est-ce pas?

Et pourtant, dès que j’ai entamé la rédaction du premier scénario, les questions fonctionnelles se sont mises à surgir… Par exemple, comment réagir si l’utilisateur n’a pas de droit d’accès à la fonctionnalité : désactiver l’écran, le vider ou bien rediriger l’utilisateur vers la page principale du module? Devrait-on arrimer la structure des permissions de ce module avec le nouveau modèle maintenant utilisé dans l’application? Cela a rapidement suscité un échange avec les collègues sur ce qui est facilement faisable, sur les standards dans l’application pour ce type de cas et sur l’expérience utilisateur. Tout ça pour en venir à la meilleure option en fonction des critères d’acceptation du récit.

Évidemment, les discussions n’ont durées que quelques minutes. Comme on le dit en anglais, ce n’était pas du « rocket science »! Par contre, l’écriture de ces scénarios a permis de clarifier en amont plusieurs aspects qu’il aurait fallu éclaircir de toute façon. Nous avons pu le faire en amont, en prenant le temps nécessaire et en impliquant toutes les personnes concernées. L'introduction des scénarios d'acceptation dans le cycle de développement permet d'avoir ce genre de discussions (en général plus poussées, mais vous voyez le genre) et évite les attentes implicites inconnues de l'équipier qui implémente la fonctionnalité.

Et vous, utilisez-vous les scénarios d'acceptation dans votre équipe? Quels sont les principaux bénéfices que vous en retirez? Je vous invite à partager votre expérience avec nos lecteurs en utilisant la section commentaire ci-dessous.

D'autres billets qui pourraient vous intéresser

Pour aller plus loin

Si vous songez à introduire les scénarios d'acceptation dans votre équipe je vous suggère fortement la formation Tests d’acceptation: introduction à ATDD et au BDD. En plus d'introduire les concepts associés aux essais d'acceptation, cette formation vous permettra de prendre conscience des impacts que cette pratique pourrait avoir au sein de votre équipe et de votre organisation.

Archive