Architecture et Agilité : réconcilier les frères ennemis...•Tour d’ivoire •200 pages d’UML •Architecte en tant que rang plutôt que rôle •« Conception émergente

Architecture et Agilité : réconcilier les frères ennemis

Jean-Philippe Gouigoux

11 Octobre

search://gouigoux

www.agiletour.com 11/10/2012

pôle Architecture / Formation / Innovation

http://www.editions-eni.fr/Livres/Ecrire-du-code--NET-performant-Profilage-et-bonnes-pratiques/.4_3a6222cf-b921-41f5-886c-c989f77ba994_7c2e4187-5e19-44cd-be7c-3fe25c3358e9_1_0_d9bd8b5e-f324-473f-b1fc-b41b421c950f.html

http://www.editions-eni.fr/Livres/Excel-2010-et-PowerPivot-L-analyse-de-donnees-simple-et-efficace/.4_3a6222cf-b921-41f5-886c-c989f77ba994_432ab930-1b48-4e84-ad31-08856d4e1099_1_0_d9bd8b5e-f324-473f-b1fc-b41b421c950f.html

AVANT DE COMMENCER


Mind Map de la session


Quoi de neuf ?


InfoQ.com : 5 piliers de l’architecture

• Stratégie métier

• Veille

• Qualité réalisation

• Aptitude à la conceptualisation

• Dynamique d’équipe

www.agiletour.com

http://www.infoq.com/news/2012/07/iasa-wilt-five-pillars

11/10/2012

L’architecte frustré

• Tour d’ivoire

• 200 pages d’UML

• Architecte en tant que rang plutôt que rôle

• « Conception émergente » = espérer que tout se passera bien

www.agiletour.com

http://www.codingthearchitecture.com/2012/03/14/ the_frustrated_architect.html

11/10/2012

Architecture de tableau blanc

• Solutionner des non- problèmes

• Architecte hors-sol

• Solutions o Product owner

o Application immédiate

www.agiletour.com

http://odetocode.com/Blogs/scott/archive/2012/03/28/whiteboard-architecture.aspx

11/10/2012

Joli titre…

• Trois modes : inclus, dilué, hors équipe

• Architecte agile o Inclus dans l’équipe

o Pas de doc d’architecture avant le sprint zéro

o User stories d’architecture dans la backlog

www.agiletour.com

http://www.decideo.fr/Agilite-et-architecture-les-freres-ennemis_a5500.html

11/10/2012

L’inévitable « cheat sheet »

www.agiletour.com

http://gorban.org/post/32873465932/software-architecture-cheat-sheet

11/10/2012

• Architecture =

o Abstraire

o Structurer

o Prévoir

Pourquoi « frères ennemis » ?

www.agiletour.com

• Agilité =

o Simplicité (XP, Lean)

o Prééminence des tests (TDD)

o Besoins immédiats (YAGNI)

≠

11/10/2012

Buts de la session

• Détruire des mythes

• Rôle et outils de l’architecte logiciel

• Qualités d’une « architecture agile »

• Gestion de la complexité


DETRUIRE DES MYTHES


Mythe n°1

• « Architecture logicielle »


Architecture en bâtiment


« Architecture » logicielle ?


Pourquoi ?


http://lovichimodem.centerblog.net/5777381-le-RSA-une-usine-a-gaz-de-plus

Le développeur n’est pas un maçon logiciel

www.agiletour.com

Réalisation

Conception

Système

Application

Code

Compilation

Tests unitaires

11/10/2012

Abstraction


http://1.bp.blogspot.com/-8onZT22o5dE/TldUFC7f7RI/AAAAAAAAAHk/KPbPskLOKPM/s1600/Unknown-1.jpeg

Pareil en info ?



http://osakabentures.com/wp-content/uploads/2011/01/crm.jpg

Oui, mais…

www.agiletour.com

Trois occasions de se planter !

11/10/2012


http://osakabentures.com/wp-content/uploads/2011/01/crm.jpg



Mythe n°2

• « Si on n’inclut pas cette fonctionnalité tout de suite, on aura du mal à la rajouter »

o Faux, car plus tard, la fonctionnalité voulue sera mieux comprise

o Faux, car plus tard, on aura acquis plus de maîtrise du code existant

o Faux, car si l’architecture ne permet pas cette modification, elle était de toute façon trop rigide


Concept d’ « architecture émergente »

www.agiletour.com

Architecture

Développement

Architecture

Développement

t

Cycle

en

V

Agili

té

11/10/2012

Mythe n°3

• « Le coût d’une modification augmente exponentiellement avec la progression dans le projet »

o Faux en mode agile : l’intégration continue garantit une livraison rapide (même si coût en amont)

o Faux en mode agile : le remaniement constant de l’application (XP) fait qu’un changement d’architecture ne prendra pas plus de temps sur un sprint que sur un autre


Corollaire sur le temps total d’un projet

www.agiletour.com

Temps

Complétion

Mode agile : les changements d’architecture sont plus nombreux mais rapidement absorbés

Cycle en V : un oubli sur l’architecture peut nécessiter de repartir quasiment du début du cycle.

11/10/2012

LE ROLE D’ARCHITECTE LOGICIEL


La caricature

• Moquerie de bon ton

o Tour d’ivoire

o Communication par tableau blanc

o Programmation UML


La part de réel

• Beaucoup d’échecs de projets IT à cause d’une sur-architecture par rapport aux besoins

• Architecte souvent vu comme un rang plutôt qu’un rôle


Bon chasseur, mauvais chasseur

• Niveau conceptuel

• Rôle différent du développeur

• Ne pense pas dans l’immédiat


Un développeur expérimenté ?

• Intérêt architecte limité en fonction de l’équipe

• Différent de l’expert

o Vision

• Connaissances techniques hors-champ

• Veille non technique

o Formalisme

• Mise en forme pour partage efficace

• Lien client pour feedback

www.agiletour.com

Développeur

Expert

Architecte

11/10/2012

\\fidji\Filière Edition\Projets\ESB\Version 1.0\VueGenerale.vsd

Rôle de l’architecte en milieu agile

• Empêcher la sur-architecture (paradoxal)

• Diffuser les bonnes pratiques

• Ne pas imposer, mais guider

o Architecture émergente

o Equilibre technique / métier


Qualités de l’architecte (InfoQ)

• Stratégie métier

• Veille

• Qualité réalisation o Usage

o Développement

o Opérationelles

o Sécurité

• Aptitude à la conceptualisation

• Dynamique d’équipe

www.agiletour.com

http://www.infoq.com/news/2012/07/iasa-wilt-five-pillars

11/10/2012

Qualités de l’architecte (ajouts perso)

• Reconnaitre ses erreurs, même énormes

o Calculs côté client

o Flash pour application LOB

o 80 tables au lieu d’un fichier XML

• Calculer les risques (formalisme)

• S’adapter vite

o Le diagnostic ne suffit pas (et dévalorise le métier)

o Agilité peut-être encore plus importante pour l’archi


Les outils de l’architecte (1)

• YAGNI (supérieur à DTSTTCPW)

• OOP

o Héritage = sur-architecture dans 90% des cas

o Utiliser plutôt SOLID

o Domain Driven Design

o Coder pour la testabilité

www.agiletour.com

SOLID : Top investissement !!!

11/10/2012

Les outils de l’architecte (2)

• Qualité de code

o Couplage afférent / efférent

o NDepend, Sonar, FXCop

• Remaniement

o Contenir la complexité

o Dette technique (gaspillage Lean, Sqale, dette archi)

o Couverture de code : Pareto ou Murphy ?

o Nettoyage de code mort


Mise en place du filet de sécurité


Etape 1


Etape 2


Etape 3


Etape 4


Etape 5


Etape 6


Plus simple ou pas ?

• Plus long au début, puis plus court

• Plus dur à lire pour un débutant

• On a fait apparaître des « caractéristiques désirables du code » (SRP, en particulier)


Atteindre l’étape « architecture »

www.agiletour.com

DLL API

DLL Métier

Nous sommes retombés de nous-mêmes sur la notion de délégué anonyme :

Notion complexe / Architecture simple

11/10/2012

Récursion code simple / remaniement simple


Code complexe : bon courage !


Exemple vécu

www.agiletour.com

65 étapes !

3 heures

Baby step 92% couverture

ROI : immédiat !

11/10/2012

Baby steps ?

www.agiletour.com

• Tout petits pas itératifs

o Correction simpliste

o Tests unitaires

o Retours sur erreurs

Tests unitaires

11/10/2012

ARCHITECTURE AGILE ?


Proposition de propriétés de base

• Diffuse

o Intègre la formation / diffusion des pratiques

o Architecte inclus dans l’équipe SCRUM

• Emergente

o Pas de user story « architecture »

o Architecture itérative (même si long terme)

• Adaptable

o Simplicité, découplage, légèreté (MongoDB, ESB, …)


Approche Agile


Deux retours immédiats

• « On va commencer par une classe Outils avec toutes les fonctions dont on a besoin »

o Non ! (YAGNI)

• « C’est lequel le post-it avec la structure du projet? »

o Solution et projets Visual Studio

o Création de la fenêtre, du service, de la structure BD


Exemple : TP de formation .NET


YAGNI

www.agiletour.com

• Conséquences

o Pas de 3-tiers

o Pas de service

o Pas de base de données !

o 1 solution avec 1 projet

11/10/2012

Un post-it pour la structure initiale ?

www.agiletour.com

Architecture ? Structuration ?

4h p1

11/10/2012

• Mais

o Séparer GUI / métier

o Contrats simples

o Interface persistance

Architecture émergente

• « The frustrated architect » très critique

o Hoping for the best

• L’émergence est facilitée par l’architecte

o Vision stratégique des enjeux long terme

o Connaissance des outils alternatifs

• Eviter la sur-architecture est l’objectif n°1


Quand je parle de long terme…


Mise en place d’une architecture SOA

• 2003 : web services

• 2005 : 100% SOAP

• 2007 : intégration autres applis

• 2009 : extranets

• 2010 : web services publics

• 2011 : REST

• 2012 : début urbanisation ESB

• 2015 (?) : architecture complètement SOA


REX sur une architecture émergente

• Ne prendre que ce qui est utile

o L’équipe est convaincue

o Un client est prêt à payer

• Etaler le risque dans le temps

• L’infrastructure doit être elle-même agile

o ESB = souplesse

o ESB propriétaire = menottes


GESTION DE LA COMPLEXITÉ


Faire simple

• Ne veut pas dire simpliste

• Les exigences non fonctionnelles

o Robustesse

o Sécurité

o Montée en version parallélisable (besoin admin.)

o Rarement exprimées dans la backlog

o etc.


Fibonacci simpliste


Fibonacci simple


… mais peu performant !


Fibonacci équilibré entre simple et performant


C’est compliqué de faire simple

• Extranet contacte Back Office

• Faire communiquer les serveurs ou transformer les messages ?

• Vases communicants entre

o Complexité pour l’utilisateur

o Complexité pour le développeur

• L’architecte doit équilibrer et maîtriser la complexité par des solutions hors-champ


Les degrés de complexité

• Réalisation (accidentelle)

o YAGNI, DRY, SOLID

• Structurelle (accidentelle)

o Ré-architecture

• Métier (incompressible)


Solution : aborder la complexité dans le temps

• SI qui se simplifie ou se complexifie ?

• Pente naturelle : empilement

• Rationalisation très longue

o Comme pour le remaniement, parfois besoin de complexifier avant de re-décomposer

• Exemple : découplage d’un annuaire


JUST DO IT !


• Architecture =

o Abstraire => simplifier

o Structurer => assouplir

o Prévoir => s’adapter

« Frères ennemis », vraiment ?

www.agiletour.com

• Agilité =

o Simplicité (XP, Lean)

o Prééminence des tests (TDD)

o Besoins immédiats (YAGNI)

11/10/2012

Courage, notion fondamentale de l’agilité

• Pas le temps ?

o Remaniement au fur et à mesure des besoins

• Qualité suffisante ?

o Le code pourrit

o Sustainable pace

• Trop de dette technique ?

o Commencez petit

o Assurez un retour immédiat (motivation, qualité)


Citation

• Comment pourrait-on faire du développement agile sur une architecture qui ne le serait pas ?

• Hugues Cornuaille, Certified Scrum Master


Questions… et peut-être même réponses !


Documents

Architecture et Agilité : réconcilier les frères ennemis...•Tour d’ivoire •200 pages d’UML •Architecte en tant que rang plutôt que rôle •« Conception émergente