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.

UML, agilité, et rétroaction

Publié par David Beaumier le vendredi 4 octobre 2013 à 16:17

Depuis longtemps j’utilise UML comme formalisme pour exprimer certains concepts et favoriser une compréhension commune des personnes impliquées dans le développement d’une fonctionnalité.  Je suis partisan d’un UML pragmatique et des principes de modélisation Agiles.

Il m’arrive régulièrement d’utiliser un bloc-note ou un tableau blanc pour jeter les bases d’une conception. À ce moment-là, il est clair pour toutes les personnes impliquées qu’il s’agit d’une conception initiale, d’un draft quoi.  Personne ne s’attend à ce stade-ci que tous les cas de figure aient été envisagés dans les moindres détails. Il y a une entente tacite sur le niveau de précision du diagramme.

Cependant, il arrive parfois qu’il soit plus pratique d’utiliser un outil de modélisation pour réaliser un diagramme UML. Personnellement, j’apprécie beaucoup Enterprise Architect de Sparx Systems que j’utilise depuis nombre d’années. Avec le temps, j’en suis toutefois venu à  constater que l’entente tacite qui existe lorsque je modélise sur papier ou au tableau ne tient plus vraiment lorsque je produis un modèle informatisé. Les gens plutôt ont l’impression d’avoir devant eu un « plan » précis de ce qui doit être fait.

L’analogie qui me vient à l’esprit est celle d’un plan de bâtiment. Un plan fait avec un logiciel de DAO semble dégager une impression de précision et d’achèvement alors que, dans les faits, il peut être aussi préliminaire qu’un plan à main levée.  Dans l’exemple ci-dessous, le plan fait par DAO semble plus achevé. Pourtant, avec l’esquisse je pourrais déjà débuter les travaux puisque j’ai des mesures. Comme je suis un menuisier Agile, et qu’ainsi ma priorité est de satisfaire mon client en lui livrant rapidement des fonctionnalités, je suis en mesure de débuter un mur et l’assemblage des chevrons dès maintenant.

Plan fait avec un logiciel de DAOPlan fait à la main

J’ai déjà vécu un problème similaire avec les interfaces graphiques  à l’époque où j’utilisais des outils de conception visuelle se rapprochant énormément du produit final. Trop souvent les utilisateurs avaient l’impression que la fonctionnalité était quasiment terminée, tellement la maquette était réaliste. Bien souvent cela avait comme conséquence de limiter l’échange d’idées puisque les parties prenantes voyaient la solution comme déjà établie. Aujourd’hui, j’utilise l’outil Balsamiq Mockups pour produire des maquettes qui ne laissent aucune place à l’ambigüité quant à leur niveau de précision. Ci-dessous, un exemple de ce que permet de faire Balsamiq. C’est vraiment merveilleux car les utilisateurs sont conscient de la facilité à modifier un tel design et sont plus enclins à proposer des améliorations.

Maquette Balsamiq

C’est tout récemment que j’ai eu une révélation sur les diagrammes faits dans Enterprise Architect : pourquoi ne serait-il pas possible de leur donner un style à la Balsamiq? De cette façon il serait évident pour tout le monde qu’il ne s’agit pas de modèles complets et finaux, mais plutôt  d’une base pour débuter le travail. Quelle idée géniale, me dis-je! Avant de soumettre l’idée aux gens de Sparx Systems, j’ai tenté une petite preuve de concept en modifiant légèrement l’apparence des polices de caractères d’un diagramme. Après quelques minutes d’expérimentation, j’ai découvert les options « Hand Drawn » et « Whiteboard Mode » dans les propriétés du diagramme. Wow, c’est déjà là… Trop génial!

Ea Handdrawn Ea Whiteboard
Mode dessin à la main (Handdrawn) Mode tableau blanc (Whiteboard)

Voilà donc, d’un simple clic on peut obtenir une apparence « napkin » pour nos diagrammes. Tout comme avec Balsamiq, il devient alors possible de restaurer l’entente tacite sur la précision du diagramme tout en profitant des avantages d’un outil de conception visuelle. Non seulement cela repositionne les échanges au bon niveau,  mais j’ai en plus l’air d’être super bon en dessin.

Bonne conception!

La documentation en mode Agile

Publié par Jean-Francois Gilbert le vendredi 15 juin 2012 à 08:00

Une des zones grises dans les méthodes Agiles se situe au niveau de la documentation. Selon le manifeste Agile, on préfère “des logiciels opérationnels plus qu'une documentation exhaustive”. Les gens ont souvent tendance à interpréter cela comme une invitation à ne pas documenter. Pourtant, la documentation a sa place dans un projet Agile mais il faut se poser quelques questions avant d’écrire un document.

  1. Pourquoi écrire ce document ?

Ça peut paraître bête mais il faut parfois remettre en question l’existence même d’un document. Si personne dans votre équipe n’est en mesure d’expliquer pourquoi un document doit être écrit, c’est probablement que vous n’en avez pas besoin ! Si le document n’est pas totalement inutile, revoyez quand même son contenu. Par exemple, est-ce qu’une analyse destinée uniquement aux développeurs a besoin d’un sommaire exécutif de 5 paragraphes ?

Ne soyez tout de même pas trop prompt à laisser tomber votre documentation. Parfois elle a vraiment sa raison d’être. La vie d'un logiciel ne se termine évidemment pas à sa livraison. Une équipe totalement différente peut prendre en charge le support. On ne peut s'attendre à ce qu'ils regardent uniquement les tests unitaires pour comprendre le fonctionnement de l’ensemble de l'application. Même à l’intérieur de l’équipe, tout ne peut être transmis oralement. On ne peut pas non plus demander des PO ou analystes de connaître par cœur toutes les règles d’affaires.

  1. Combien de temps ce document doit-il exister ?

Pendant une phase de design, il est parfois bien utile de mettre sur papier des diagrammes ou toute autre information importante. Une ébauche d’architecture faite sur un coin de table peut parfois devenir un document officiel. Le hic c’est qu’il n’est peut-être plus très près de la réalité après quelques temps. Il vous a été utile mais vous n’en avez plus besoin ? Vous ne voyez pas l’utilité de le garder à jour ? Allez-hop, dans la poubelle ! Un document inexact est souvent pire qu’un document absent.

  1. Est-ce que c’est la meilleure façon de communiquer l’information ?

Parfois, des règles d’affaires complexes doivent être écrites car personne n’arrive à se les rappeler. Très bien, mais trouvez le bon format de document. Un bon vieux diagramme d’activité (UML) peut souvent mieux illustrer un processus qu’un long paragraphe de texte. Une matrice de données dans Excel, un prototype d’écran dessiné avec Paint, un diagramme dans Visio, le format importe peu. Mais posez-vous la question avant de l’écrire : Est-ce qu’il y a une façon plus simple de communiquer l’information ? Si vous aviez un standard de document et que ce n’est pas la meilleure façon de communiquer l’information, il est temps de remettre en question ce standard.

  1. Si le document mérite d’être conservé, comment s’assurer qu’il restera à jour ?

Le problème de désuétude et d’inexactitude de la documentation présente un défi. Il est évident que si on est capable d’atteindre une certaine stabilité dans les spécifications, il y aura moins de changements à apporter aux documents. Un truc pour s’assurer de garder la documentation synchro avec le logiciel est d’ajouter la mise à jour de la documentation à la définition de « complété ». Plutôt que d’attendre à la fin et de perdre le fil de ce qui a été modifié, on met à jour la documentation au fur et à mesure que l’on complète les users stories.

En conclusion, comme c’est souvent le cas dans les méthodes Agiles, il n’y a pas de règles strictes sur ce qui doit être documenté, et comment on doit le faire. Il faut trouver ce qui est « juste assez » et le bon type de document pour régler le bon problème dans votre équipe.

  • Plus récents
  • 1
  • Plus anciens

Archive