Toltèque Agile

Conception agile : où en sommes-nous ?

28 septembre 2017

L'agile suppose une "conception émergente". Qu'en est-il concrètement ? Classique ou émergente, la conception reste incontournable dans un développement professionnel.

Un article de Martin Fowler avait fait le buzz au début de l'agile, en 2000 : is design dead ?  La disparition d'une phase clairement identifiée "conception" dans l'Extreme Programming, méthode itérative, posait question.

En deux mots, la conception dans XP (reprise dans les principes du Manifeste agile) est permanente, comme l'expression de besoins par les stories ou bien l'acceptation par les tests automatisés. Elle est aussi émergente.

 

Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

 

Or, ce style de développement - conception simple - suppose un certain nombre de savoir-faire de la part du Développeur. La toute première étape étant de prendre conscience qu'il est temps de ne plus programmer comme nous le faisions au temps des cartes perforées (mes premiers programmes en 1980...).

- Test Driven Developement : développement de code propre par une conception émergente exprimée en tests.

- Refactoring : modifier la structure d'un code existant pour le nettoyer a posteriori ou le préparer pour une nouvelle évolution.

- Sans compter les règles de code propre : éviter les commentaires, KISS...

 

Je constate sur  le terrain que ces compétences ne sont pas très répandues. C'est d'ailleurs une question de culture d'organisation, voire sociétale, plus que de responsabilité exclusive du Développeur. Pour autant, la conception émergente est simplement inaccessible à bien des équipes.

 

Du coup, nous tombons parfois dans l'un des deux travers :

- soit nous revenons à une "Big Design Up Front", la phase de conception du cycle en V (par exemple un (ou deux !) sprint de conception dans Scrum)

- soit cette activité pourtant nécessaire est... zappée !

 

Soit nous retombons dans les pièges du cycle en V (effet tunnel par manque de feedback concret et rapide), travaux inutiles et parfois inadaptés aux évolutions futures, soit le résultat, sans conception, est pire qu'avant ! Un comble dans une approche agile ! Bienvenue dans FreeStyleDevelopment !

 

Alors... Que faire ?

Je crois que la première étape (pas facile facile...) consiste à ne pas se mentir sur les compétences (et l'envie...) des Développeurs, également sur les signaux plus ou moins clairs émis par le Management : pouvons-nous envisager ou pas une conception vraiment émergente ? D'autant plus que la conception émergente impose un harnais de tests  automatisés type jUnit, pas facile de convaincre de son utilité... pourtant évidente dès que l'on y a touché.

Pour faire simple : sur une échelle de 1 à 10 (1 = aucune compétence en conception émergente, 10 = je maîtrise grave !) où vous situez-vous ?

 

Dans le cas où la réponse est inférieure à 5 (par eemple...), que mettons-nous en place ? Sans tomber dans la grosse conception du début, il me semble qu'une réflexion s'impose.

Rester dans une approche agile consiste à respecter les principes tels que

feedback concret et rapide.

Dès lors, la conception pourrait a minima s'exprimer dans un skeleton qui sera très rapidement, dès la première itération, effectivement opérationnel, voire porteur d'une première (toute simple !) story.

En résumé, la question devient : comment mettre en œuvre les valeurs et principes  du Manifeste agile ?

Personnes et interactions

Logiciel opérationnel (cf feedback concret)

...

Reste que le développement de logiciels est un sacré beau métier !

Scrum : une permissivité nuisible à l'agile