Doit-on sacrifier l'UML sur l'autel de l'Agile ?

Tandis que la mise en place d’organisations agiles priorisent le time-to-market, celles-ci ont tendance à diluer les compétences qui étaient en quelque sorte isolées dans l'ancienne méthodologie du cycle en V

De toute évidence, les activités de modélisation de données UML transversales traditionnelles ne correspondent plus aux nouvelles organisations agiles

Pourtant, une livraison rapide ne signifie pas (ne devrait pas signifier) un manque de contrôle des travaux et des efforts investis

Dans ce cadre, la modélisation des données est un moyen de les garder sous contrôle et d'optimiser les futurs sprints

Alors, comment les anciennes activités UML peuvent-elles converger avec les nouveaux processus agiles ?

Ce qui ne doit plus être fait :

1) La modélisation des données ne doit plus être transversale et isolée du développement

2) La modélisation des données ne doit pas être désynchronisée du développement, ni trop tôt / trop grande (non implémentable) ni trop tard (n'a pas aidé les sprints fermés)

3) La modélisation des données ne doit pas être axée sur le monde idéal (déconnectée des cas d'utilisation)

4) L'utilisation de solutions de modélisation complexes (très coûteuses et donc uniquement utilisées par un groupe de personnes sélectionné) n'est plus une bonne idée

Que peut-on faire, à mon avis :

1) La modélisation des données doit être incluse dans les développements de sprint

2) La modélisation des données doit être effectuée dans le périmètre fonctionnel du sprint actuel

3) La modélisation des données doit désormais être basée sur le codage et le time-to-market

3) L'outillage UML doit être intégré dans l'IDE et doit être bidirectionnel avec le code (exemple la solution open source Modelio ou Microsoft Visual Studio)

4) Tout membre des squads doit avoir accès à cet outil UML intégré (car UML est là pour ouvrir tous les esprits afin de rationaliser les implémentations de données et de code)

5) Un leader des données (profil fonctionnel et idéalement aussi architecte logiciel) doit être présent et mobile pour toute squad pour le bien des sprints

Les clés du succès de cette vision sont :

1) Garder les données sous contrôle constamment le long des sprints

2) Construire un niveau minimum de documentation (que restera-t-il lorsque les squads seront parties ?)

3) La communication avec les gens du métier est plus facile avec UML qu'avec le code C # / Java / Scala / etc ...

4) Prendre des décisions cohérentes sur la mise en œuvre des données dans les sprints

5) Anticiper les impacts sur les futurs sprints

6) Planifier plus efficacement le chemin de la transformation

En un mot, garder le meilleur des deux mondes.

Pour finir, ne sous-estimez pas la data, elle est les fondements fonctionnels de l'architecture d'entreprise

Crédit, logo, Wikipedia, https://fr.wikipedia.org/wiki/UML_(informatique)