Architecture Et Modélisation Agile

ARCHITECTURE, ANALYSE ET
MODÉLISATION AGILES
PRÉSENTATIONS
¡ Voici quelques points avant de commencer :
¡ Qui êtes-vous?
¡ Que connaissez-vous du développement Agile de

logiciels?
¡ Que pensez-vous apprendre aujourd’hui?

© Pyxis Technologies inc.
2
OBJECTIFS
Apprendre à faire l’équilibre entre l’élicitation en amont et une

approche émergente;
Apprendre à atténuer les risques techniques avec les approches
Agiles;
Apprendre comment les équipes autonomes et multidisciplinaires
utilisent les éléments d’architecture requis;
Apprendre à concevoir des solutions et à rédiger des documents
d’analyse de manière itérative et incrémentale;
Connaître l'impact des approches Agiles sur le rôle de l’architecte
et sur celui de l’analyste.
QU’EST-CE QU'UNE
ARCHITECTURE?
QU’EST-CE QU'UNE ARCHITECTURE?
V O T R E P R O J E T R E S S E M B L E- T- I L À C E C I ?
QUELQUES DÉFINITIONS
Une architecture, c’est :

¡ la structure d’un système;
¡ la décomposition du système en composants, leurs caractéristiques et
leurs interrelations.
Source : Bass, L; Clements, P.; Kazman; R. Software Architecture in Practice, Reading, MA : Addison-Wesley, 1998
Architecturer, c’est :
¡ déterminer une vision pour satisfaire les besoins du client;
¡ communiquer cette vision et l’architecture aux parties prenantes et à
l’équipe;
¡ prendre des décisions de conception cohérente et justifiée;
¡ affirmer un leadership technique pour s’assurer que la structure
réalisée suit les standards, est solide, est bien conçue, fonctionne
correctement et respecte la vision.
Source : P. Clements, R. Kazman, M. Klein; Evaluating Software Architecture; Addison Wesley

D ÉF IN IT ION S SU R LA M OD ÉLISAT ION
¡ La modélisation, c’est :
§ la représentation du fonctionnement d’un système sous forme de
diagramme ou modèle;
¡ Modéliser, c’est :
§ déterminer comment la solution répondra aux besoins,
§ vérifier des concepts et réfléchir avant de réaliser,
§ partager une solution sous forme de diagramme (modèle),
§ expliquer le code en prenant du recul (pérennité).
C OM PLEXIT É
Loin d’un accord

Chaos La plupart du
Compliqué temps, vous
Spécifications
êtes ici!
Co
d’affaires
Domaine
mp
lex
e
Près d’un accord
Simple Compliqué
Près d’une certitude Loin d’une certitude

Technologie
Technologies
Source : Stacey RD. Strategic management and organisational dynamics: the challenge of
complexity. 3rd ed. Harlow : Prentice Hall, 2002
QU’EST-CE QUE LE
DÉVELOPPEMENT
AGILE DE LOGICIELS?
LE DÉVELOPPEMENT AGILE DE LOGICIELS
M AN IF EST E
Les individus et leurs sont plus les processus et les

interactions importants que outils.
Une solution est plus une documentation

fonctionnelle importante qu’ exhaustive.
La collaboration avec est plus la négociation d’un

le client importante que contrat.
La réponse au est plus le suivi d’un plan.

changement importante que
Dans le contexte de votre travail,

qu’est-ce que cela signifie?
12 PRINCIPES
Accueilliez positivement les

Notre plus haute priorité est de Livrez fréquemment un logiciel
demandes de changement,
satisfaire le client en livrant même tard dans le projet. Les opérationnel avec des cycles de
rapidement et régulièrement des processus Agiles exploitent le quelques semaines à quelques
fonctionnalités à grande valeur changement pour donner un mois et une préférence pour les
ajoutée. plus courts.
avantage compétitif.
Réalisez les projets avec des

La méthode la plus simple et la
Les utilisateurs ou leurs personnes motivées.
Fournissez-leur l’environnement plus efficace pour
représentants et les transmettre de l’information à
développeurs doivent travailler et le soutien dont elles
ont besoin et faites-leur l'équipe de développement
ensemble quotidiennement et à l’intérieur de celle-ci, c’est le
tout au long du projet. confiance quant à l’atteinte des
objectifs fixés. dialogue en face à face.
Quels défis ces principes

posent-ils sur votre rôle?
12 PRINCIPES (SUITE)
Les processus Agiles encouragent

un rythme de développement
soutenu et soutenable. Ensemble, Une attention continue à
Un logiciel opérationnel est la les commanditaires, les l'excellence technique et
principale mesure d’avancement. développeurs à une bonne conception renforce
et les utilisateurs devraient être l’Agilité.
capables de maintenir
indéfiniment un rythme constant.
À intervalles réguliers, l'équipe

La simplicité — c’est-à-dire l’art de Les meilleures architectures,
réfléchit aux moyens
minimiser la spécifications et de devenir plus efficace, puis
quantité de travail inutile — est conceptions émergent d'équipes modifie son
essentielle. auto-organisées. comportement en conséquence.
Quels défis ces principes

posent-ils sur votre rôle?
L E S 5 VA L E U R S D E SC R U M
EN GRANDE ENTREPRISE
Le cours se
concentre sur ceci.
(architecture)
S C R U M : U N C A D R E D E T R AVA I L
L’ EM PI R I SM E
Transparence Inspection Adaptation

L’ EM PI R I SM E
Atelier
Le client souhaite avoir 20 avions

en papier.
¡ Combien de temps estimez-

vous que cela prendra?
QU’EST-CE QU’UNE Une approche
itérative,
incrémentale
ARCHITECTURE AGILE? et adaptative
ARCHITECTURE AGILE
C H OISIR U N E ST R AT ÉGIE
Cascade (waterfall) Agile

L'information initiale est L'information initiale est
supposée fiable et le risque considérée insuffisante, et le
est dans la réalisation des risque est dans la livraison
activités (ex. : efficacité). d'un produit à forte valeur
ajoutée.
Un diagramme de Gantt est
utilisé pour tracer le chemin Le chemin critique est
critique des activités. composé de biens livrables
(ex. : story mapping) et
l'avancement se mesure à
partir d’incréments pertinents
(ex. : terminés).
ARCHITECTURE AGILE
C H OISIR U N E ST R AT ÉGIE
ARCHITECTURE AGILE
L E S C A R N E T S D E P R O D U I T E T D ’ I T É R AT I O N
¡ Les besoins d’affaires

Carnet de Carnet
alimentent le carnet de produit
produit d’itération
et aident à fixer son ordre.
¡ À chaque début d’itération,
Priorité haute
l’équipe planifie son travail sur

les éléments prioritaires du
carnet en fonction de sa
capacité.
¡ Chaque nouvel élément est
inséré dans la liste selon sa
priorité.
¡ Il est possible de changer
Priorité basse
l’ordre des éléments qu’on n’a

pas commencé à traiter.
¡ En tout temps, il est possible
de supprimer les éléments
qu’on n’a pas commencé à

traiter.
Une stratégie est requise afin de planifier et de gérer les

éléments non fonctionnels.
ARCHITECTURE AGILE
U N PR OC ESSU S IN C R ÉM EN TAL
Atelier
Le PO souhaite une tour, la plus
haute possible, avec une guimauve
au sommet.
Matériel :
¡ Une guimauve
¡ 15 spaghettis
¡ 1 mètre de ruban adhésif
Règles :
¡ On mesure la tour de sa base
jusqu’au sommet de la guimauve.
¡ Il est interdit de s’appuyer sur les
murs.
¡ Il est interdit de découper la
guimauve.
ARCHITECTURE AGILE
P L A N I F I E R S E L O N L A VA L E U R D ’ A F FA I R E S
¡ Livrer de la valeur en
petits incréments nous
donne l’occasion
d’apprendre;
¡ Profiter de la
rétroaction des
utilisateurs;
¡ Éviter une analyse des
sujets moins
prioritaires ou sans
valeur;
¡ Encourager la
réactivité aux
changements;
¡ Atteindre plus
rapidement le marché.
Crisp's Blog » Henrik Kniberg

ARCHITECTURE AGILE
PLANIFIER SELON LE RISQUE
¡ Atténuer le risque
par la livraison de
petits incréments
permet de limiter
les coûts tout en
livrant de la
valeur;
¡ Identifier les bons

risques à
atténuer.
Crisp's Blog » Henrik Kniberg

ARCHITECTURE
Rédaction et entretien AGILE
du carnet de produit
P L A N I F I C AT I O N C O M M U N E D E L A
Quadrants de Mike Cohn
VA L E U R D ’ AF FAIR ES E T D U R ISQU E
Ordonner les éléments selon la stratégie
Élevé
2
Stratégie Stratégie de
pour 1 capitalisation :
atténuer les Grande valeur et
Risque
risques : coûts faibles

Grande pour augmenter
valeur et rapidement la
coûts élevés 3 2 valeur du produit
3 1
Faible
Faible Forte
Valeur
d’affaires
Source : Estimating and Planning de Mike Cohn

ARCHITECTURE AGILE
É V O L U T I O N D U R ISQU E E T D E L A C O N C E P T I O N
Effort de développement
Risque
Éléments fonctionnels
Éléments non
rin 0 fonctionnels
rin 1
rin 2
3
Sp t 1
Sp t 2
Sp t 3
Sp t 4
Sp t 5
Sp t 6
Sp t 7
Sp t 8
rin 9
Sp t 1
Sp t 1
Sp t 1
t1
Sp int
rin
rin
rin
rin
rin
rin
rin
rin
r
Sp
CAS : CALCUL DE LA RÉSERVE
ACTUARIELLE
ARCHITECTURE AGILE
L E S P O I N T S D ’ I N S P E C T I O N D E L’ A R C H I T E C T U R E
La mêlée
quotidienne pour
planifier la journée
Le carnet de produit de travail, y compris
pour ordonner les l’architecture,
éléments avec des l’analyse et la
stratégies : modélisation.
• Juste assez;
• Options ouvertes;
• Proche du besoin
d’affaires.
La revue de sprint :
• Pour valider le résultat;
La séance de planification • Pour confirmer les hypothèses;
n’est pas qu’un atelier de • Pour ajuster la conception (architecture

coordination. C’est une émergente) responsable.
occasion de concevoir et de
modéliser.
ARCHITECTURE AGILE
LA DÉFINITION DE « TERMINÉ »
¡ L’incrément : la somme de tous les éléments du

carnet de produit (PBI) complétés au cours de
toutes les itérations précédentes;
¡ Terminé (done) : l’incrément potentiellement

livrable sans travail supplémentaire avant la mise
en production;
¡ La définition de « terminé » : convenue par les

membres de l’équipe de développement, le
Product Owner et les parties prenantes.
S’applique aux éléments du carnet de produit et à
l’incrément.
Amène de la transparence sur le travail réalisé
par l’équipe;
ARCHITECTURE AGILE
I M PA C T D U T R AVA I L N O N « T ER M I N É » SU R LA PER F O R M AN C E
Qu’est-ce qui arrive si je

mange en vitesse à la
Vitesse réelle
maison tous les midis de la
semaine?
Accumulation d’une dette

Dette importante, qui a un impact

sur la qualité et la performance
ARCHITECTURE AGILE
I M PA C T D U T R AVA I L N O N « T ER M I N É » SU R LA LI VR AI SO N F I N ALE
Décision de livrer Livraison
Révision
Révision
Révision
Révision
Révision
Plan
Plan
Plan
Plan
Plan
dette dette dette dette Itération de « stabilisation »
Croissance rapide et non linéaire

Ceci est nécessaire pour que l’inspection soit la plus

pertinente possible
ARCHITECTURE AGILE
C OM POSIT ION D E LA D ÉF IN IT ION D E « T ER M I N É »
¡ Axes de réflexion :
§ Qualité
§ interne (tests unitaires, revue de code, standard de code, etc.),
§ externe (tests fonctionnels, tests intégrés, tests utilisateurs, tests de
système, tests de performance, tests de sécurité, etc.),
§ sur quel environnement,
§ % couverture,
§ Internationalisation
§ Déploiement et exploitation (migration, scripts de déploiement, plan de mise
en production, environnement, etc.)
§ Documentation (fonctionnelle, technique, utilisateur, réglementaire,
validation, publication, etc.),
§ Conformité et autorisation (journalisation, contraintes corporatives,
approbation de dossier, revue architecturale, etc.).
§ Stratégie de branchement (branching strategy)
§ Gestion des anomalies (bugs) et de la dette technique
§ Maintenance
§ Autres attentes du Product Owner

§ Autres attentes techniques
ARCHITECTURE AGILE
GESTION DES ÉLÉMENTS NON FONCTIONNELS
Tant que
l’élément n’est Une fois que
pas mis dans
Conformité l’élément est
l’incrément, il
Fiabilité inclus dans
est géré
Disponibilité l’incrément, on
comme les
Portabilité l’ajoute à la
autres.
Scalabilité définition de
Sécurité « terminé »
Attention, le
Utilisabilité pour éviter de
risque et le
Maintenabilité créer une dette
coût technique.
augmentent!
Carnet de produit Définition de « terminé »
Les besoins d’affaires

Les éléments non fonctionnels
alimentent et fixent l’ordre ET doivent être planifiés et gérés.

du carnet de produit.
ARCHITECTURE AGILE
E X E M P L E D E « T ER M I N É »
¡ Tests de "charge" exécutés (pas maintenant)

¡ Solution déployée avec des "scripts" automatisés (pas maintenant)
¡ Code "poussé" et tests passent
¡ Texte "UI" traduit anglais et français
¡ Couverture de code 70%
¡ "COS" vérifiés
¡ Démo/revue avec un pair
¡ Aucun problème connu à moins d'accord avec l'équipe
¡ Compatibilité des "browsers" vérifiée (manuellement)
§ Safari - Chrome - Firefox - Internet explorer 9+ - Edge
¡ URLs sont optimisés pour "SEO"
¡ Pages vérifiées "mobile friendly"
¡ Tout le travail à faire connu est dans le backlog

ARCHITECTURE AGILE
E X E M P L E D E « T ER M I N É »
¡ Les notes de version (release notes) sont à jour

¡ Temps réponse des pages web:
§ Cible chargement < 1s (Acceptable < 4s)
§ Cible recherche < 3s (Acceptable < 7s)
¡ Déployé sur environnement de démo
¡ Compatibilité ascendante testée
¡ Version incrémentée
¡ "Tag" dans le "source control"
¡ Branche de développment "mergé" sur la branche "main"
¡ Documentation confluence mise à jour
¡ Tests d'acceptation passent
¡ Déployé sur environnement de pré-production
¡ Déployé sur environnement de production
¡ Utilisateurs finaux ont pris connaissance du déploiement et de son
contenu
CAS :
OBAMA
CARE
Titre sur mesure

POINTS FORTS 1
ARCHITECTURE Planifier
selon la
valeur
D’AFFAIRES d’affaires
ARCHITECTURE D’AFFAIRES
M OD ÈLES
Haut niveau : Détaillé :

¡ Dossier d’affaires et charte ¡ Règles et objets d’affaires;
de projet; ¡ Glossaire : pour établir un
¡ Processus d’affaires; langage commun.
¡ Cas d’utilisation et story
mapping;
¡ Maquettes d’écran et
diagramme de navigation;
¡ Personas.
Il s’agit d’un pivot naturel des méthodes Agiles.

O U T I L S - C H ART E D E PR OJ ET AGILE
Objectifs du projet Matrice Priorité et compromis

1. Réduire le délai de traitement des RFA de 3 m ois Priorité 1 Priorité 2 Com prom is Com m entaires
¡ Comporte 1 à 2 pages; 2. Simplifier le processus opérationnels de réception du RFA

3. Réduire de 80% des coûts de réception papier et saisie manuelle
Objectif
Échéancier X
X
4. Améliorer le service à la clientèle / Plan de communication claire et efficace /

Améliorer les outils de support RH et R$ X Implique temps supp.
5. Réduire de 80% les demandes d'information du ministère après réception Facteurs de réussites
¡ Aide à prendre des 6. Assurer la sécurité et confidentialité des données du RFA
Client / Customers
1. Le 1er juillet 2005, l'analyse préliminaire doit être complété
2. Le 15 septembre 2005, les SG reçoivent la 1ère communication
décisions éclairées. CPE

Garderie conventionnée
Vérificateurs externes
Module
Module
Module
de
de
de
saisie
saisie
transmission
3. Le 1er janvier 2006, le guide d'utilisateur est livré aux SG.
4. Le 1er janvier2006 , l'environnement de formation est prêt.
5. Le 1er mars 2006, les SG peuvent s'enregistrer.
DFR Module de réception 6. Le 15 mars 2006, les vérificateurs externes peuvent s'enregistrer.
Project Context Diagram 7. Le 1er avril 2006, le système est prêt pour la saisie et l'importation.
GDF : PES-RFA Risques

1. Disponibilité réduite des ressources de la DFR
Gestion Transmission 2. Contrôle de la portée du projet

9.
3. Le 15 ma i des
Adhésion 2006, le systède
services megarde/Gestion
e st prê t pour la
duré c e ption de s RF A
changement
Clients SG 4. Maîtrise des NTIC/Nouveau processus
5. Formation des utilisateurs et service support
Définition paramètres de
transmission 6. Ressources partagées avec d'autres projets
Attribution code utilisateur Ressources dédiées
et mot de passe
Gestion Clients Nom Rôle Durée
La charte devrait être Saisie des donneés :
balance de vérification,
internes Patrice Gervais
Normand Alexin
ScrumMaster
Responsable de produit
Durée du projet
Durée du projet
consultée pour donneés de rémunération Johane Blanchet Développement Durée du projet

et données d'occupation Philippe Jean Développement Durée du projet
Attribution code utilisateur
Louise Hebert Développement Durée du projet
mesurer la valeur
et mot de passe
Lucie Sageau Itération 2 à 7
Gestion Martin Blanchard
Développement
Développement Itération 3 à 7
Clients VE Réception
acquise lors de la Livrables
Livrable 1
Tests d'acc.
01-Feb-06
Mise en prod.
15-Feb-06
Module d'enregistrement des services de garde
revue d’itération et Livrable 2 15-Feb-06 01-Mar-06
Attribution code utilisateur Définition paramètres de Module d'enregistrement des vérificateurs externes
pour organiser le
et mot de passe réception Livrable 3 01-Mar-06 15-Mar-06
Vérification des donneés Module saisie et l'importation des données
Arrimage aux systèmes Livrable 4 15-Mar-06 01-Apr-06
carnet de produit lors Production de rapports
du ministère(SRF-CAFE) Module de transmission complète
Livrable 5 01-Apr-06 15-Apr-06
de la séance de Module de réception complète
planification.
O U T I L S - E X E M P L E D E D O S S I E R D ’ AF FAIR ES
Source : http://www.businessmodelgeneration.com/
O U T I L S - C H ART E D E PR OJ ET AGILE
¡ Décortiquez le texte de la charte de projet.

Atelier
• Lisez la charte de projet.

• Identifiez les risques
• Identifiez les mesures de succès
10 minutes
O U T I L S - E X E M P L E D E TA B L E A U D E V I S U A L I S AT I O N D U P R O D U I T
Vision : Développement d’une version électronique du canevas de produit pour aider

les équipes à construire de superbes produits
Groupe cible Besoins Produit Valeur
Utilisateurs : Les Soutenir la création Tablette : Les Avoir une nouvelle

directeurs et les PO de nouveaux données sont gérées source de revenus
produits et profiter par GreenHopper.
Clients : Les des fonctionnalités Confirmer la
moyennes et de GreenHopper IUG : Semblable à un notoriété de la
grandes entreprises tableau physique, marque
Obtenir un meilleur utilisation intuitive
rendement de
l’investissement que Fournit un gabarit
si on développait pour les profils, les
une nouvelle scénarios utilisateurs
plateforme et les cas

d’utilisation
Source : http://www.romanpichler.com/blog/agile-product-innovation/the-product-vision-board
P L A N I F I C AT I O N PA R L E S P R O C E S S U S D ’ A F FA I R E S
Comprendre les processus

d’affaires et leurs liens
Déterminer les événements

de vie et rédiger les cas
d’utilisation
Ordonner les éléments des carnets

de produit
Source : Conférence La revue d'itération intégrée… Et autres fabuleuses

pratiques Agiles adaptées au contexte de la SQI 48
I N S C R I P T I O N D ’ U N PA RT I C I PA N T
Sélectionner le cours Choisir l’option de Saisir l’adresse de

Inscrire les participants
paiement facturation
Cours PSPO tlescut@pyxis-tech.com
Mélanie Tardif
Montréal, 23-24 fév., jlaganiere@pyxis- q VISA
Bureau 120
CSPO, 1050 $ + taxes tech.com q MasterCard 440, boul. Armand-
Québec, 12-13 mars, mboisvert@pyxis- q PayPal Frappier
CSPO, 1050 $ + taxes tech.com
q Facture Laval (Québec) H7V 4B4
Mélanie choisit une Mélanie inscrit trois Marie choisit

Mélanie choisitson mode
un mode Mélanie entre son
séance publique du participants. dede
paiement
paiement(facture).
(facture) adresse de facturation.
cours PSPO.
Confirmer l’inscription Transmettre un courriel

Consulter les modalités Accepter ou refuser les L’inscription est Scrum.org
de vente modalités complétée. À : tlescut@pyxis-tech.com
Lorem ipsum dolor sit q Accepter Participants : … Cher Tristan,

amet, consectetur… q Refuser Lieu : Montréal Nous sommes heureux
Total : 3150 $ + taxes de…
Mélanie consulte les Mélanie accepte les Le système confirme Le système transmet un
modalités de vente. modalités de vente. l’inscription à l’écran. courriel aux participants.
Source : http://www.romanpichler.com/blog/agile-product-management-tools/agile-scenarios-
and-storyboards (traduction)
C AS D ’ U T ILISAT ION
Saisir l’adresse de
facturation
Sélectionner le cours Choisir l’option de
Inscrire les participants paiement Mélanie Tardif
Cours PSPO Bureau 120
tlescut@pyxis-tech.com
Montréal, 23-24 fév. q PayPal 440, boul. Armand-
Mélanie Frappier
Laval (Québec) H7V 4B4
Mélanie choisit une Mélanie inscrit trois Marie choisit

Mélanie choisitson mode
un mode Mélanie entre son
séance publique du participants. dede
paiement
paiement(facture).
(facture) adresse de facturation.
cours PSPO.
Confirmer l’inscription Transmettre un courriel

Consulter les modalités L’inscription est Scrum.org
Accepter ou refuser les
de vente complétée. À : tlescut@pyxis-tech.com
modalités.
Lorem ipsum dolor sit Participants : … Cher Tristan,
q Accepter Lieu : Montréal Nous sommes heureux
amet, consectetur…
Total : 3150 $ + taxes de…
Mélanie consulte les Mélanie accepte les Le système confirme Le système transmet un
modalités de vente. modalités de vente. l’inscription à l’écran. courriel aux participants.
Source : http://www.romanpichler.com/blog/agile-product-management-tools/agile-scenarios-
and-storyboards (traduction)
CAS :
COMMERCE
ÉLECTRONIQUE
D’ASSURANCE
VOYAGE
Titre sur mesure

POINTS FORTS 1
Atelier RECONNAISSANCE MUSICALE
¡ Définissez le processus
d’affaires d’une application
de reconnaissance musicale.
¡ Comment ordonner le carnet

de produit de manière à
produire un incrément
fonctionnel le plus
rapidement possible tout en
atténuant les risques?
15 minutes
O U T I L S - É TA B L I R L E S P R O C E S S U S
¡ Décortiquez le texte de l’étude de cas afin d’établir les

Atelier
processus d’affaires.
¡ Écrivez les étapes du processus en commençant par un
verbe à l’infinitif.
¡ Utilisez la terminologie avec laquelle le client est à l’aise
(pas de « saveur informatique »).
Travail en équipe :
• Écrivez les étapes
• Ordonnancez les étapes en séquence
30 minutes
O U T I L S - É TA B L I R L E S C A S D ’ U T I L I S AT I O N
¡ Établissez les cas d’utilisation à l’aide du texte de l’étude et

Atelier
du processus d’affaires.
¡ Utilisez la terminologie avec laquelle le client est à l’aise
(pas de « saveur informatique »).
• Inscrivez les conditions d’entrée.
• S’il y a lieu, indiquez le chemin du cas d’utilisation.
• Inscrivez le comportement attendu.
20 minutes
P L A N I F I C AT I O N AV E C P L U S I E U R S É Q U I P E S
Coordonnateur responsable de la
vision systémique
(PO de PO)
Les carnets
découlent
des processus
Projet A Projet B Projet C d’affaires et sont
organisés autour du
PO PO PO
et son et son et son même cas
équipe équipe équipe
d’utilisation.
M ESU R ER LA VALEU R D ’ AF FAIR ES
¡ Valeur nominale : ¡ Valeur subjective :

§ Générer de nouveaux § Kano : Obligatoire, important,
revenus, facultatif,
§ Augmenter les revenus § Sondage de satisfaction;
actuels,
§ Réduire les pertes,
§ Augmenter l’efficacité des
¡ Rendement de
opérations (Lean); l’investissement :
§ Éléments de haute valeur et
coûteux pour réduire les
¡ Valeur estimée : risques,
§ Lois des grands nombres, § Éléments de forte valeur et
§ Impact mapping; peu coûteux pour capitaliser.
Intrant important à la planification du

carnet de produit
M ESU R ER LA VALEU R D ’ AF FAIR ES - E X E M P L E
¡ Utilise les catégories Obligatoire-Important-Facultatif.

¡ Utile pour estimer la portée que l’on peut prévoir d’ici la fin du
projet et aussi pour suivre la valeur acquise d’une itération à
l’autre.
DÉMARRAGE D’UN
PROJET AGILE
DÉMARRAGE DE PROJET
É Q U I L I B R E E N T R E A N T I C I PAT I O N E T A D A P TAT I O N
Pratiques d’architecture : Pratiques d’architecture :

•Élicitation complète des besoins en amont; •Compréhension des besoins;
•Architecture détaillée en amont; • Architecture émergente (dernier
moment responsable);
•Communication par documents approuvés.
• Cycle de rétroaction (feedback
loop).
A n tic ip
atio n
Risques : A d ap ta
tio n
• Paralysie par l’analyse;
• Suringénierie; Risques :
• Fondement sur de Architecture • Réingénierie coûteuse;
fausses hypothèses; • Solution non globale;
• Solution non adaptée. • Difficulté par le manque

de conception.
T EC H N I Q U ES D ’ AD APTAT I O N
¡ Accélérer le cycle de rétroaction : pour vérifier les hypothèses le

plus rapidement possible et faire émerger des solutions avec des
incréments les plus pertinents possibles.
T EC H N I Q U ES D ’ AD APTAT I O N
¡ Juste assez : pour lancer la première itération et préparer les

suivantes, sans se compromettre tant que ce n’est pas requis.
T EC H N I Q U ES D ’ AD APTAT ION
¡ Dernier moment responsable : pour conserver la flexibilité le

plus longtemps possible et prendre des décisions plus éclairés.
The important decisions that a Software Architect

makes are the ones that allow you to NOT make the
decisions about the database, and the webserver, and
the frameworks.
- Robert C. Martin
Source : http://blog.cleancoder.com/uncle-
bob/2016/01/04/ALittleArchitecture.html
M OD ÈLES D E D ÉM AR R AGE
Avant-projet Décision Projet
a) Directement
en projet (littéra- Itération Itération Itération
ture Scrum) 1 2 […] N
b) Ateliers
Itération Itération Itération Itération
de démarrage 0 1 2 […] N
(commun)
c) Phase d’analyse
Analyse Itération Itération Itération Itération
préliminaire préliminaire 0 1 2 […] N
(commun)
(ou pas)
d) Analyse
Itération Itération Itération Itération Itération Itération
préliminaire 1 2 3 4 5 […] N
empirique
F I N AN C EM EN T D E T YPE L E A N S TA RT U P
Image tirée de l’article Agile with Guts de Nicolas Gouy

Adapté aux modèles de démarrage Scrum (A) et itération 0 (B)

F I N AN C EM EN T PAR U N E PH ASE D ’ AN ALYSE PR ÉLI M I N AI R E ( C )
Au moment de l’étude Pendant le déroulement

de l’opportunité du projet
Non-variable /
Exigences Budget Échéancier
(fonctionnalités)
Non négociable (coûts) (calendrier)
On s’appuie sur
une vision.
On s’appuie sur
un plan.
Budget Échéancier Exigences

(coûts) (calendrier) Variable / (fonctionnalités)
Négociable
Du plan découle les estimations relatives au De la vision découle les estimations

coût et au calendrier. relatives aux fonctionnalités.
Source : « Choisir l’Agilité » de Mathieu Boisvert et Sylvie Trudel

F I N AN C EM EN T PAR U N E PH ASE D ’ AN ALYSE PR ÉLI M I N AI R E ( C )
Ne pas confondre les ateliers de démarrage avec une analyse

préliminaire
Avant-projet Décision Projet
b) Ateliers Itération Itération Itération Itération

de démarrage 0 1 2 […] N
(commun)
c) Phase d’analyse
Analyse Itération Itération Itération Itération
préliminaire préliminaire 0 1 2 […] N
(commun)
On ne peut pas obtenir un résultat aussi fiable en réduisant

le temps consacré à l’analyse préliminaire.

A N A LY S E P R É L I M I N A I R E E M P I R I Q U E ( D )
UN MODÈLE DE FINANCEMENT COMPLÉTEMENT AGILE
Itération Itération Itération Itération Itération Itération Itération Itération Itération Itération Itération
1 2 3 4 5 6 7 8 9 10 …
LE BUT EST DE RÉDUIRE

LE BUT EST DE LIVRER AVEC
LE RISQUE ET D’ESTIMER LES
UNE PLUS GRANDE VÉLOCITÉ
PARAMÈTRES DU PROJET
Avant-projet Projet
• L’équipe est réduite, semblable au • Changement dans la composition de
modèle traditionnel, mais avec l’équipe : plus de développeurs, moins
l’ajout de quelques développeurs d’analystes;
principaux. • Continuité : pas de transfert de projet;
• L’analyse est faite dans l’ordre de la • Carnet de produit, définition de « terminé »,
valeur d’affaires et du risque (style outil de suivi et incrément de base déjà en
Agile et Lean Startup). place : pas seulement un document
• En plus des documents, les d’analyse;
incréments valident les plus grandes • Transfert des coûts d’avant-projet au budget
hypothèses. du projet de développement.
• L’investissement est une dépense.
LES ACTIVITÉS DE DÉMARRAGE
Produit
•Vision et besoins établis clairement

•Définition de « terminé » connue
•Carnet de produit découpé au bon niveau de détail
Équipe
•Savoir-faire, savoir-être, compétences nécessaires

•Outils et processus connus (définition de prêt)
Environnement
•Environnement et outils installés

•Espace collaboratif et visuel disponible
Architecture
•Architecture de haut niveau en place permettant l’émergence de solutions

Cadre de gestion
•Plan de livraison itératif et incrémental établi

A R C H I T E C T U R E E T A N A LY S E D É TA I L L É E
Besoin initial Épuration Itération 1

¡ Le carnet de
produit est
ordonné.
¡ L’équipe
com prend ce
qu’on lui
tils n
O élisatio n
u dem ande de
Mod ersatio réaliser.
v
Con
¡ L’équipe peut
estim er.
É VA L U AT I O N D ES R ISQU ES
Impact
(1) * (5) (2) * (5) (3) * (5) (4) * (5) (5) * (5)
très élevé (5)
Impact
(1) * (4) (2) * (4) (3) * (4) (4) * (4) (5) * (4)
élevé (4)
Impact
(1) * (3) (2) * (3) (3) * (3) (4) * (3) (5) * (3)
modéré (3)
Impact
(1) * (2) (2) * (2) (3) * (2) (4) * (2) (5) * (2)
faible (2)
Impact T. Élevé
(1) * (1) (2) * (1) (3) * (1) (4) * (1) (5) * (1)
faible (1) 2
Impacts 1
Probabilité Probabilité Probabilité Probabilité Probabilité
Probabilités très faible (1) faible (2) modérée (3) élevée (4) très élevée (5)
Risque
3 2
3 1
Faible
Faible Forte
Valeur
d’affaires
OUTILS POUR SPÉCIFIER LES BESOINS
S TO RY M APPIN G
¡ Jeff Patton propose l’atelier de « Story Mapping »

§ Fournit une vue d’ensemble de la portée à couvrir.
§ Aide à limiter l’analyse détaillée et à adopter une stratégie de juste-à-
temps.
§ Permet d’organiser la planification en tenant compte des besoins
importants.
S TO RY M APPIN G
Atelier
¡ Raconter une histoire
¡ Ordonner (ex: Fréquence, importance, criticité, etc.)
¡ Déterminer les strates
60 minutes
S TO RY M APPIN G – E X E M P L E P O U R D E S S T R AT E S
Tiré du livre « Choisir l’Agilité » de Mathieu Boisvert et Sylvie Trudel

ARCHITECTURE
D’ENTREPRISE
ARCHITECTURE D’ENTREPRISE
LES DOCUMENTS
Diagrammes de haut niveau :

¡ Diagramme de contexte
(services et systèmes);
¡ Conformité aux règlements et
lois;
¡ Conformité aux normes
(sécurité, journalisation,
accessibilité, performance,
etc.).
Il faut rapidement inclure plusieurs éléments non

fonctionnels dans la définition de « terminé ».
LES ÉLÉMENTS REQUIS
FONCTIONNELS
LES ÉLÉMENTS REQUIS FONCTIONNELS
M OD ÈLES

¡ Processus d’affaires; ¡ Cas d’utilisation et scénarios
¡ Cas d’utilisation; utilisateurs;
¡ Maquette d’écran; ¡ Diagrammes de classes;
¡ Diagramme de navigation; ¡ Diagrammes d’activités;
¡ Règles et objets d’affaires; ¡ Diagrammes d’états;
¡ Glossaire; ¡ Diagrammes de séquences;
¡ Modules, package et épopées. ¡ Diagrammes de flux;
¡ Règles et objets d’affaires.
S C É N A R I O U T ILISAT EU R
¡ Un scénario utilisateur, c’est une courte description d’un

besoin du point de vue de l’utilisateur.
¡ Il met l’accent sur le qui, le quoi et le pourquoi, mais

jamais sur le comment.
¡ Les détails sont traités dans de futures conversations

entre l’équipe, le PO et les collaborateurs.
le », je
« r ô
t a n t que
¡ Les scénarios utilisateurs sont En u e l que
« q
ve u x , a i n si je
écrits de manière à être compris »
chose r ».
u
par le PO et l’équipe. « va l e
S C É N A R I O U T ILISAT EU R – C R IT ÈR ES « IN VEST »
¡ Les 6 critères de qualité du scénario utilisateur

Indépendance quant aux autres scénarios
Indépendant utilisateurs et à la technique
Discussion ultérieure sur les détails

Négociable
Source de valeur pour l’utilisateur
Valeur ajoutée ou le client final du produit
Possibilité d’estimer la complexité du scénario

Estimable utilisateur par l’équipe de réalisation
Suffisamment petit Possibilité de réalisation en une itération

Validation par les critères d’acceptation

Testable
Source : Bill Wake
S C É N A R I O U T I L I S AT E U R
Carte
En tant que candidat, je veux trouver les offres d’emploi correspondant à des
arguments afin de me permettre d’accéder à leur description et ultimement de
poser ma candidature.
Conversation Condition de succès
Besoins d’affaires et contraintes : Condition de succès :
• Arguments : compétence, région, • Je constate que tous les critères sont
domaine d’activité, langue; vides à l’entrée de la fonction.
• Si aucun argument saisi dans la • Je saisis des critères, puis je lance la
recherche = aucun résultat; recherche et je constate le résultat.
• Besoin d’une pagination sur la liste • Je vide les critères, puis je déclenche la
des résultats de recherche; recherche et je constate le résultat vide.
• Possibilité de trier les résultats par • J’effectue un tri à même les colonnes du
colonnes dans le tableau des tableau des résultats et je constate le
résultats; classement des résultats.
• Moins de 1 seconde;
• Première implémentation de la liste

déroulante dynamique;
• Réutilisation du moteur de recherche.
Source : http://xprogramming.com/articles/expcardconversationconfirmation
S C É N A R I O U T ILISAT EU R - D ÉC OU PAGE
¡ Priorités :
§ Gérer les postes, gérer les candidatures;
¡ Étapes d’un processus :
§ Afficher un poste, poser une candidature;
¡ Règles d’affaires :
§ Afficher un poste, permettre l’expiration de son affichage,
assurer la validité des données du formulaire…;
¡ Données :
§ Faire une recherche par nom (simple), région (complexe)…;
¡ Opérations (CRUD) :
§ Créer et modifier un profil, supprimer un profil, afficher les profils…;
¡ Extraction des soucis transversaux :
§ Assurer la sécurité, la performance…;
¡ Traçage du chemin :
§ Pour valider l’architecture, faire une minuscule tranche verticale qui traverse les
couches applicatives.
¡ Extraction des boîtes d’étude (spike)
Si la condition de succès d’un PBI est longue et difficile à rédiger, c’est que
§ Choisir le moteur de génération de rapports
le scénario utilisateur couvre probablement trop de considérations.
S C É N A R I O U T I L I S AT E U R - D ÉTAILLER
¡ Détaillez les scénarios utilisateurs.

Atelier
¡ Ayez des conversations en face à face et utilisez un tableau
blanc.
¡ Utilisez des feuillets Post-It ® .
Note : Pour l’exercice, discutez au minimum de l’interface
graphique et de la base de données.
• Ayez une conversation technique sur les scénarios utilisateurs.
• Inscrivez, dans la section Conversation, vos décisions et vos
contraintes techniques.
• Collaborez.
• Concevez et modélisez, au besoin.
• Ajoutez ou découpez, s’il y a lieu, des scénarios utilisateurs et
spikes.
30 minutes
ARCHITECTURE
TECHNIQUE
ARCHITECTURE TECHNIQUE
M OD ÈLES
¡ Glossaire (langage ¡ Contrats d’interface;

commun); ¡ Modèle d’objets de
¡ Diagramme de couches; données;
¡ Diagramme de contextes; ¡ Règles d’affaires;
¡ Schéma des tables et ¡ Schéma des tables et
relations (sommaire). relations (détails).
ADAPTER SA COMPLEXITÉ AU BESOIN
Besoin simple et faible durée de

vie du produit :
¡ Une interface simple est généralement Vue
suffisante.
¡ Pas vraiment de domaine d’affaires; la
logique d’affaires et la logique de Contrôleur
présentation se confondent.
¡ Le modèle est assez simple et
Modèle
probablement collé sur la base de Base de
données. données
¡ On sépare quand même la vue, le
modèle et la logique.
¡ Il y a une forte dépendance au modèle.
ADAPTER SA COMPLEXITÉ AU BESOIN
Besoin complexe, longue

durée de vie :
Environnement ESB
IU
¡ Une architecture de type Adaptateurs
« Ports and Adapters » est
nécessaire.
¡ On veut isoler le domaine Domaine
d’affaires de l’environnement d’affaires
d’exécution à l’aide d’une
couche d’adaptation.
¡ On veut que les dépendances
aillent vers le domaine
Base de
d’affaires. données
Tiers
PIÈGES HABITUELS SI ON MANQUE DE VISION
Trop complexe : Trop simple :

¡ Ça arrive souvent quand on ¡ Ça arrive souvent quand on
veut prévoir tous les cas se concentre sur les
possibles. quelques PBI de l’itération
¡ Ça fonctionne, mais on a courante.
gaspillé de l’effort par ¡ Ça crée le besoin d’une
rapport à ce qui était requis. itération de stabilisation
pour faire évoluer la
conception.
Itération(s) de
stabilisation
10 fonctions 20 fonctions
1 000 000 $ 200 000 $
P I L O T É E PA R L E D O M A I N E
¡ Le domaine d’affaires doit piloter la conception.

§ Le domaine d’affaires, c’est le sujet abordé par le logiciel. Par exemple, la
messagerie texte, vocale ou vidéo et la facturation.
¡ En fonction de ce domaine d’affaires, le produit logiciel prendra
une forme particulière. Il sera organisé et découpé pour répondre
au besoin (et non l’inverse).
Form follows function (Fonctionnalisme)
- Louis Sullivan
Source :
https://en.wikipedia.org/wiki/Form_follows_function
¡ Le domaine d’affaires doit être la base du vocabulaire utilisé par

l’équipe de réalisation et les affaires pour modéliser et nommer les
composants du système.
Langage Langage
technique d’affaires
Équipe de PO et parties
développement prenantes
Langage commun
¡ De nombreux autres concepts sont à explorer dans la conception

pilotée par le domaine.
P R AT I Q U E S D ’ I N G É N I E R I E
¡ Programmation en binôme (pair programming);

¡ Développement piloté par les tests (TDD);
¡ Clean Code;
¡ Intégration continue;
¡ Proximité des opérations et du développement.
T EST S
Réf: https://dzone.com/articles/testing-triangle-circle-and
S P I K E ( B O Î T E D ’ ÉT U D E )
¡ C’est utile lorsqu’il y a trop d’inconnus pour un élément à

réaliser.
¡ Ça permet d’acquérir les connaissances nécessaires :

§ Pour réduire les risques,
§ Pour se familiariser avec une nouvelle technologie ou un nouveau
domaine,
§ Pour avoir une meilleure compréhension du besoin,
§ Pour augmenter la fiabilité des évaluations.
Inspiré de http://www.extremeprogramming.org/rules/spike.html et de
http://scaledagileframework.com/spikes
S P I K E — C E Q U E C ’ E S T E T C E Q U E C E N ’ E S T PA S
¡ Écrire un dossier ¡ Explorer pour décider;

fonctionnel; ¡ Valider une hypothèse;
¡ Écrire un dossier ¡ Réduire les risques;
organique; ¡ Se familiariser avec une
¡ Lire un dossier nouvelle technologie ou un
nouveau domaine;
technique;
¡ Avoir une meilleure
¡ Soutenir le mode en compréhension du besoin;
cascade.
¡ Augmenter la fiabilité des
estimations.
U N EXEM PLE D E S P I K E
• Réaliser ou acheter;
• Choisir un fournisseur;
• Évaluer l’impact sur la
performance; Je dés
ire
• Choisir une technologie; process comprendre c
u o
• Vérifier des hypothèses pouvoir s de paiement mment intégr
évaluer pa er
la réali r VISA, ainsi le
techniques; sation. je vais
Temps
: 3 jour
• Se familiariser avec une s
technologie; Conditi
on
- Proto de succès :
• Se familiariser avec ty
- Éléme pe fonctionne
un produit existant; nts lég l de pai
aux ement
en ligne
• Faire le prototype d’un aspect
fonctionnel;
• Établir l’interaction avec le client;
• Valider la navigation.
Inspiré de http://www.extremeprogramming.org/rules/spike.html et de
http://scaledagileframework.com/spikes
CAS : COMPTE À HAUT RENDEMENT
A R C H I T E C T U R E D E D ON N ÉES ET IN F R AST R U C T U R E
Ne devenez pas le goulot d’étranglement :

§ Éduquer les gens à propos de la vision sur l’infrastructure;
§ Créer des « carrés de sable » à l’intention des équipes de
développement;
§ Garder les droits d’exécution sur les environnements
supérieurs;
§ Soutenir les responsables internes des équipes;
§ Avoir des outils et tests d’acceptation automatisés;
§ Inclure les contraintes relatives à l’infrastructure dans la
définition de « terminé »;
§ Déployer souvent.
LA SUITE
Atelier
¡ Définir l’architecture
¡ Identifier les NFR
¡ Identifier les stratégies
¡ Identifier les risques; atténuer les risques
30 minutes
DOCUMENTATION AGILE
DOCUMENTATION AGILE
C OM M U N IC AT ION E F F I C A C E
Face à face au
tableau blanc
Forte
Conversation
face à face
Le développement de
Efficacité de la communication
Conversation solutions logicielles

par vidéo
Conversation
est une activité
Options de
Enregistrement par téléphone
modélisation coopérative
vidéo
Conversation d’invention et de
par courriel
communication.
Enregistrement
audio Options de
Papier documentation
Faible
Froid Chaud
Richesse du canal de communication
DOCUMENTATION AGILE
C ON VER SAT ION S ET C OLLABOR AT ION
Des outils qui soutiennent les conversations

et assurent une plus grande collaboration.
Dac!
Oui!
Ah!
OK!
Source : blogs.perficient.com/spark/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/
DOCUMENTATION AGILE
C H OIX D E L’ O U T I L AD ÉQ U AT
¡ Outils inclusifs et collaboratifs à

préconiser, par exemple :
§ Tableaux blancs,
§ Feuilles de papier statique,
§ Feuillets, Post-it ® ,
§ Cartes bristol,
§ Google Docs;
¡ Parfait d’utiliser un diagramme libre, et

ce, dans presque tous les cas;
¡ Outils spécialisés à utiliser

judicieusement :
§ Meilleure façon de communiquer,
§ Pérennité.
DOCUMENTATION AGILE
ÉBAUCHES
Des outils qui soutiennent les

conversations et assurent
une plus grande
collaboration.
Soyez visibles
et transparents.
Source : http://www.codingthearchitecture.com/presentations/dublinaltdotnet2013-agile-
software-architecture-sketches
DOCUMENTATION AGILE
P R O TO T Y P E PA P I E R
¡ Modèle basse fidélité d’une interface utilisateur;

¡ Activité hautement inclusive;
¡ Invitation à collaborer.
Note : Cela favorise

la créativité, la
rétroaction et les
itérations pendant le
processus de conception.
DOCUMENTATION AGILE
M AQU ET T E E N F I L D E F E R
¡ Prototype haute fidélité;

¡ Connaissance d’outils spécialisés;
¡ Solution de rechange au prototype papier :
§ Défilement, polices de caractères spéciales ou effets particuliers
des couleurs;
¡ Attention!
§ Solution non inclusive,
§ Une maquette trop belle
peut donner l’impression

que le logiciel est terminé.
CAS :
PROTOTYPE
PAPIER
Titre sur mesure

POINTS FORTS 1
Source : http://www.youtube.com/watch?v=GrV2SZuRPv0
DOCUMENTATION AGILE
D OC U M EN TAT ION
¡ Documenter pour les bonnes raisons :

§ Pérennité du système,
§ Obligations contractuelles ou normatives;
¡ La bonne question est plutôt « Quand est-ce le moment le plus

responsable pour documenter? »;
¡ Une autre bonne question : « La documentation demeurera-t-elle

toujours vraie? ».
RESPONSABLE DE
L’ARCHITECTURE
RESPONSABLE DE L’ARCHITECTURE
C OM POSIT ION D E L’ ÉQU IPE
Côté affaires Rôles engagés
Le Product Owner (PO) est responsable du carnet de

produit de l’équipe et de la planification de la livraison.
Il s’assure que l’équipe réalise le bon produit.
L’équipe de développement est responsable de la

Direction gestion des activités de développement et de la qualité
Utilisateurs Expert d’affaires du logiciel produit. Elle s’assure que tout est réalisé
correctement.
Le Scrum Master assure le fonctionnement de Scrum

Product Owner sans autorité directe. Il expose les contraintes et
(PO) problèmes non apparents et aide l’organisation à les
surmonter par ordre d’importance.
Scrum Master Équipe Rôles impliqués
Les parties prenantes ont des intérêts dans le résultat

Experts de la livraison. À cause de leur imputabilité, il est
Administrateur important d’être transparent avec eux concernant les
de bases de résultats et les difficultés vécues par l’équipe.
Direction données
Les spécialistes sont au service de plusieurs équipes

dans l’organisation. Il est important d’être transparent
avec eux pour assurer une cohésion et une cohérence
au niveau de l’organisation.
Côté TI
ARCHITECTURE OWNER
¡ Guider la création et l’évolution de l’architecture de la solution;

¡ Accompagner l’équipe sur les considérations relatives à
l’architecture;
¡ Aider à concentrer les efforts nécessaires pour définir
l’architecture initiale;
¡ S’assurer que l’équipe comprend les principes d’architecture de
l’organisation et y adhère;
¡ S’assurer que l’équipe connaît les actifs de l’organisation et
qu’elle les utilise de façon appropriée;
¡ S’assurer que la solution est intégrée et testée périodiquement;
¡ S’assurer que les préoccupations non fonctionnelles sont bien
représentées dans le carnet de produit et dans la définition de
« terminé ».
Source : Roles in a Disciplined Agile Delivery: Architecture Owner (traduction)

R ELAT ION AVEC LE PR OD U C T OW N ER
Vous avez besoin de lui.

Product Owner
> Avoir le besoin;
Il se soucie des Il est responsable du
utilisateurs. succès du produit.
> Ordonner;
Il a une vision Il est responsable > Élaborer la vision;
globale du du carnet de produit
produit. (priorité). > Obtenir de la rétroaction.
Il agit comme un L’équipe veut le
entrepreneur. satisfaire.
Il a besoin de vous.
> Définir les besoins;

Ajustez votre langage pour
> Détailler certains éléments;
qu’il soit compris par tous.
> Prévoir les incertitudes;
Prendre les bonnes décisions;
>
> Comprendre l’impact.
U N E ÉQU IPE AU TO - O R G A N I S É E
Des gens ayant des connaissances complémentaires s’engagent dans

le projet et travaillent ensemble en ayant un objectif commun.
Ils possèdent collectivement les connaissances, les

méthodes de travail et le savoir-être pour réaliser un
incrément fonctionnel au cours de l’itération.

S A P O S I T I O N D A N S L’ É Q U I P E
L’équipier est sans doute le La plupart du temps

meilleur rôle pour atteindre l’architecte agit comme un
vos objectifs : collaborateur :
¡ Aurez-vous la disponibilité ¡ Comment conjuguer
nécessaire? l’autonomie de l’équipe et
¡ Arriverez-vous à garder un l’imputabilité de
pas de recul? l’architecte?
S A P O S I T I O N D A N S L’ ÉQ U I PE : É Q U I P I E R
Comportements à adopter :
¡ S’engager dans l’itération;

¡ Modéliser avec l’équipe;
¡ Collaborer avec les parties prenantes et
les équipiers et apporter sa contribution;
¡ Partager la propriété collectivement :
§ Écouter les idées des autres,
§ Faire preuve d’humilité,
§ Donner le droit à l’erreur;
¡ Rendre les modèles visibles.
S A P O S I T I O N D A N S L’ É Q U I P E : C O L L A B O R AT E U R
Comportements à adopter :
¡ Être disponible pour l’équipe;
¡ Collaborer avec les parties prenantes
et les équipiers;
¡ Déléguer à l’équipe certaines parties
des responsabilités d’architecture;
¡ Faire travailler l’équipe, modéliser p a s
avec celle-ci; l y s e z re
¡ Alléger le cycle de prise de décision p a ra r vot
et d’approbation; N e i p e p a i té .
u il
¡ Donner le droit à l’erreur; l’é q s p o n ib
¡ Assurer l’accès à l’information in di
relative à l’architecture.
M OD E D E D ÉLÉGAT ION D U LEAD ER
1. Imposer (tell) : Imposer une décision à l’équipe
2. Vendre (sell) : Décider et convaincre l’équipe
3. Consulter (consult) : Consulter l’équipe avant de décider
4. Collaborer (agree) : Décider en collaboration avec l’équipe
5. Aviser (advise) : Influencer la décision prise par l’équipe
6. Demander (inquire) : S’informer d’une décision prise par l’équipe
7. Déléguer (delegate) : Laisser l’équipe prendre ses propres décisions

Source : Jurgen Appelo, Management 3.0–Leading Agile developers, developing Agile leaders, Addison-Wesley, 2011
TA B L E A U D E D ÉLÉGAT ION ( A R C H I T E C T E V S É Q U I P E)
Niveau de délégation
1. 2. 3. 4. 5. 6. 7.
Décision sur… Imposer Vendre Consulter Collaborer Aviser Demander Déléguer
Documentation des
standards des IUG
Modification de la
base de données
Choix technologique
Solution technique
Modélisation et
analyse des besoins
…
Membre Membre
Architecte PO
d’équipe d’équipe
Source : Jurgen Appelo, Management 3.0–Leading Agile developers, developing Agile leaders, Addison-Wesley, 2011
STRUCTURE ÉLARGIE
Équipe 1 Vision, contexte Équipe 2

organisationnel,
normes,
orientation
Architecte
Équipier Équipier
Comité d’architecture
Scrum de Scrum
D ÉM AR R AGE D E PR OJ ET ET I T É R AT I O N 0
¡ Élaborer et communiquer la vision de l’architecture;

¡ Participer à des démonstrations de faisabilité;
¡ Participer à l’écriture et à l’ordonnancement des scénarios
utilisateurs;
¡ S’assurer que les bons éléments se retrouvent dans la
définition de « terminé » :
§ Soucis des étapes de validation,
§ Soucis horizontaux;
¡ Transférer en personne les travaux d’architecture;
¡ Utiliser les tableaux blancs.
À T I T R E D E C O L L A B O R AT E U R
Planification :
§ Collaborer à la conception et à la modélisation.
Itération :
§ Enlever les obstacles relatifs à l’architecture;
§ Travailler en binôme (transmission des connaissances,
essais, validation des hypothèses);
§ Faire des revues;
§ Faire des dojos, au besoin.
Revue d’itération :
§ Approuver ou refuser les éléments;
§ Confirmer les hypothèses;
§ Ajuster la conception (architecture émergente).

CONCLUSION
OBJECTIFS
¡Produire un incrément fonctionnel;

¡Permettre le prochain incrément.
Source : Scott Ambler (http://www.agilemodeling.com)

PRINCIPES
¡ Voyager léger;
¡ Accueillir positivement les demandes de changement;
¡ Modéliser pour les bonnes raisons;
¡ Utiliser de multiples modèles;
¡ Ne pas compromettre la qualité;
¡ Réduire le délai des rétroactions;
¡ Maximiser l’investissement des parties prenantes;
¡ Rester proche du modèle d’affaires.
Source : Scott Ambler (http://www.agilemodeling.com)

CONCLUSION
PRINCIPES D’UNE ARCHITECTURE ÉMERGENTE
¡Penser grand, agir petit, échouer tôt, apprendre

vite;
¡Trouver le dernier moment responsable;
¡Réaliser les éléments les plus risqués ou à plus
forte valeur ajoutée;
¡Avoir une itération 0 et traiter les spikes;
¡Faire la preuve avec un logiciel fonctionnel;
¡Faire confiance à l’équipe.
CONCLUSION
O C C A S I O N S D E C O L L A B O R AT I O N
¡ Démarrage de projet : ¡ Atelier de travail :

§ Transfert en personne des travaux § Transmission de l’information,
d’architecture en amont, § Montée en compétence de l’équipe;
§ Utilisation des tableaux blancs;
¡ Définition de « terminé » :
¡ Planification de l’itération : § Étapes de validation,
§ Préparation des travaux de § Soucis horizontaux;
l’itération à venir avec l’équipe;
¡ Revue d’itération :
¡ Mêlée quotidienne : § Mise au défi de la solution.
§ Visibilité sur les enjeux pour offrir
de l’aide,
§ Planification de la journée;
¡ Travail en binôme :
§ Transmission des connaissances,

essais, validation des hypothèses;
CONCLUSION
FA I R E D E L’ A R C H I T E C T U R E A G I L E
Pour faire face à la complexité :

¡ Il faut laisser une place à l’émergence dans nos
stratégies de conception.
¡ Il faut limiter l’effort initial de conception.
¡ Il faut chercher à valider rapidement les hypothèses et à

éliminer les risques.
¡ Il faut utiliser des modèles de conception qui nous

gardent très près des besoins d’affaires.
CONCLUSION
ÊTRE UN ARCHITECTE AGILE
¡ Prendre une décision, ce n’est qu’une partie de

l’équation.
¡ La communication en « face à face » sera toujours la
plus efficace.
¡ Il faut être inclusif dans les activités de modélisation.
¡ Il faut travailler au bon niveau de détail.
¡ Il faut déléguer et faire confiance.
¡ Il faut ajuster son style de leadership au contexte.
RÉFÉRENCES
¡ www.directioninformatique.com/la-transformation-agile-du-role-de-
larchitecte
¡ www.agilemodeling.com/essays/agileArchitecture.htm
¡ www.agilearchitect.org/agile/index.asp
¡ www.martinfowler.com/articles/designDead.html
¡ www.codingthearchitecture.com
¡ www.infoq.com/articles/agile-architecture
¡ www.romanpichler.com
S’IL Y A UNE CHOSE QUE J’AI APPRISE, C’EST… Échanges
libres
POURQUOI CHOISIR L’AGILITÉ?
QU’EST-CE QUI VOUS SERA UTILE?

Conclusion
Veui l l ez rempl i r
l e questi onnai re
d’ amél i orati on
conti nue. Vos
commentai res
nous ai dent à
nous amél i orer...
Titre sur mesure
POINTS FORTS 1 Merci !
pyxis-tech.com
2017-05-10

Architecture Et Modélisation Agile

Transféré par

Droits d'auteur :

Formats disponibles

Architecture Et Modélisation Agile

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Architecture Et Modélisation Agile

Transféré par

Droits d'auteur :

Formats disponibles

ARCHITECTURE, ANALYSE ET

¡ Voici quelques points avant de commencer :

¡ Que connaissez-vous du développement Agile de

¡ Que pensez-vous apprendre aujourd’hui?

Apprendre à faire l’équilibre entre l’élicitation en amont et une

Une architecture, c’est :

correctement et respecte la vision.

Source : P. Clements, R. Kazman, M. Klein; Evaluating Software Architecture; Addison Wesley

Loin d’un accord

Près d’une certitude Loin d’une certitude

Les individus et leurs sont plus les processus et les

Une solution est plus une documentation

La collaboration avec est plus la négociation d’un

La réponse au est plus le suivi d’un plan.

Dans le contexte de votre travail,

Accueilliez positivement les

Réalisez les projets avec des

Quels défis ces principes

Les processus Agiles encouragent

À intervalles réguliers, l'équipe

Quels défis ces principes

Transparence Inspection Adaptation

Le client souhaite avoir 20 avions

¡ Combien de temps estimez-

Cascade (waterfall) Agile

¡ Les besoins d’affaires

l’équipe planifie son travail sur

l’ordre des éléments qu’on n’a

qu’on n’a pas commencé à

Une stratégie est requise afin de planifier et de gérer les

Crisp's Blog » Henrik Kniberg

¡ Identifier les bons

Crisp's Blog » Henrik Kniberg

Ordonner les éléments selon la stratégie

risques : coûts faibles

Source : Estimating and Planning de Mike Cohn

n’est pas qu’un atelier de • Pour ajuster la conception (architecture

¡ L’incrément : la somme de tous les éléments du

¡ Terminé (done) : l’incrément potentiellement

¡ La définition de « terminé » : convenue par les

Qu’est-ce qui arrive si je

Accumulation d’une dette

Dette importante, qui a un impact

Décision de livrer Livraison

Croissance rapide et non linéaire

Ceci est nécessaire pour que l’inspection soit la plus

§ Autres attentes du Product Owner

Carnet de produit Définition de « terminé »

Les besoins d’affaires

alimentent et fixent l’ordre ET doivent être planifiés et gérés.

¡ Tests de "charge" exécutés (pas maintenant)

¡ Tout le travail à faire connu est dans le backlog

¡ Les notes de version (release notes) sont à jour

Titre sur mesure

Haut niveau : Détaillé :

Il s’agit d’un pivot naturel des méthodes Agiles.

Objectifs du projet Matrice Priorité et compromis

¡ Comporte 1 à 2 pages; 2. Simplifier le processus opérationnels de réception du RFA

4. Améliorer le service à la clientèle / Plan de communication claire et efficace /