La problématique des rôles périphériques aux équipes Scrum est une problématique que l'ensemble des organisations se doivent de comprendre et de gérer. Dans les dernières années on a beaucoup parlé du rôle du chargé de projet mais assez peu de celui de l'architecte qui, comme le chargé de projet, détient une position de fort leadership, mais se demande comment maintenant utiliser ce leadership dans un contexte d'agilité et d'auto-organisation des équipes. Au cours de cette présentation, Jean-René, Frédérick et Mathieu présentent les principaux impacts de l'agilité sur le rôle de l'architecte et offriront des pistes de solutions quant à la façon de conduire la phase d'architecture et d'interagir pour les architectes avec les équipes.

1. SavoirAgile.com
Wébinaire -
18 février 2016
RÔLE DE
L’ARCHITECTE AGILE

2. ©PyxisTechnologiesinc.
Merci!
PYXIS VOUS OFFRE UNE GAMME
COMPLÈTE DE SERVICES

3. ©PyxisTechnologiesinc.
QUI SUIS-JE?
 À Pyxis depuis 2004;
 Différents rôles :
 conseiller;
 formateur;
 chargé de cours à UQAM;
 co-auteur du livre Choisir l’Agilité.
Contact:
mboisvert@pyxis-tech.com
ca.linkedin.com/in/mathieuboisvert/

4. ©PyxisTechnologiesinc.
QUEL EST LE PROBLÈME?

5. ©PyxisTechnologiesinc.
DOIT-ON EN DÉDUIRE QU’EN AGILE…
 On ne peut pas faire d’architecture en amont?
 On code, on ne réfléchit pas?
 On se préoccupe pas des soucis « horizontaux », on reste
focus sur le projet?
 Un architecte pour être utile doit programmer?
 Une équipe auto organisée ne peut être influencée?

6. ©PyxisTechnologiesinc.
OBJECTIFS DU WÉBINAIRE
 Informer sur les impacts de l’approche Agile sur le rôle de
l’architecte
 Présenter différentes façons de jouer efficacement le rôle
de l’architecte dans des projets Agile
 Déboulonner certains mythes entourant l’architecture dans
un mode Agile

7. IMPACT #1:
ÉMERGENCE ET
INCRÉMENTALITÉ
Rôle de
l’architecte
Agile

8. ©PyxisTechnologiesinc.
VOTRE PROJET RESSEMBLE-T-IL À
CECI?

9. ©PyxisTechnologiesinc.
BALANCER ANTICIPATION ET
ADAPTATION
Pratiques
•Éllicitation complète des besoins en amont
•Architecture détaillée en amont
•Communication par documents approuvés
Pratiques
• Compréhension des besoins « Juste
assez, juste à temps »
• Architecture émergente (dernier
moment responsable
• Cycle de rétroaction (feedback loop)
Risques
•Paralysie par l’analyse
•Sur ingénierie
•Se baser sur des fausses
hypothèses
•Solution non adaptée
Risques
•Réingénierie coûteuse
•Solution non globale
Ne pas se compromettre si ce n’est pas requis!

10. ©PyxisTechnologiesinc.
CADRE DE TRAVAIL SCRUM
Le carnet pour prioriser
les items avec des
stratégies:
• Juste assez,
• au bon moment,
• garder les options
ouvertes,
• jusqu’au dernier
moment
responsable.
La démonstration et la
livraison du dernier
incrément du système, pour:
• Valider le résultat,
• Confirmer les
hypothèses,
• Ajuster la conception
(architecture émergente)
responsable.

11. ©PyxisTechnologiesinc.
DES SPÉCIFICATIONS ORIENTÉES
SUR LES BESOINS AFFAIRES
Thèmes
Épics
User Story
Cas d’utilisation
Les
besoins
d’affaires
allimentent
et fixent la
priorité du
carnet de
produit
Une stratégie
pour gérer et
planifier les
considération
d’architecture
s est requise!
Carnet de produit
Spike

12. ©PyxisTechnologiesinc.
Projet
PATTERNS DE DÉMARRAGE
Itération
1
Itération
2 […]
Itération
N
a) Directement
en projet
(littérature Scrum)
Itération
1
Itération
2 […]
Itération
N
Itération
0
b) Ateliers
de démarrage
(commun)
Itération
N
Itération
0
c) Phase d’analyse
préliminaire
(commun)
Analyse
préliminaire
Itération
1
Itération
2 […]
Itération
N
d) Analyse
préliminaire
empirique
Itération
4
Itération
5 […]
Avant-Projet
Itération
2
Itération
3
Itération
1
(ou pas)
Décision

13. ©PyxisTechnologiesinc.
Risque
technique
Effortde
développement
ÉVOLUTION DE LA CONCEPTION
ET DU RISQUE
Fonctionnalités
Tâches techniques
ConstructionConception
Faisabilit
é
Beaucoup de
conception au départ
Beaucoup de
fonctionnalités
affaire par la suite

14. ©PyxisTechnologiesinc.
EXEMPLE 1: LE COMPTE D’ÉPARGNE
Couche
client en
Java
Interface
BD
Couche
serveur en
Cobol
Batch de
réconciliation
Systéme
financier
Le solde de Mathieu Boisvert pour commencer
Peu de valeur affaire, grande validation de l’architecture !

15. ©PyxisTechnologiesinc.
 L’agent de recommandation
 Commencer par les interfaces d’administration
 La refonte d’un système patrimoine
 Commencer par les transactions les plus fréquentes, les plus
révélatrices
 Le logiciel de taxation
 Commencer par les activités les plus risqués
AUTRES EXEMPLES

16. IMPACT #2:
COLLABORER AVEC
LES ÉQUIPES
Rôle de
l’architecte
Agile

17. ©PyxisTechnologiesinc.
RESPONSABILITÉS D’UN ARCHITECTE
 Établir et communiquer une stratégie de
réalisation
 Assurer un leadership sur la solution développée
(guider, accompagner)
 Être le gardien des contraintes organisationnelles

18. ©PyxisTechnologiesinc.
STRUCTURE D'ÉQUIPE AGILE
du Scrum Master ,
Des Équipiers, Du Responsable
de produit,
de l’ensemble des individus ayant
les compétences pour produire
un incrément de produit.
L’équipe Scrum se compose…
Les collaborateurs et les contributeurs
soutiennent l’équipe
Gestionnaires Clients
Experts
Et
l’architecte
?

19. ©PyxisTechnologiesinc.
ÊTRE OU NE PAS ÊTRE DANS L’ÉQUIPE ?
 Équipier est sans doute la meilleure posture pour
accomplir vos objectifs
 Aurez-vous la disponibilité nécessaire?
 Arriverez-vous à garder un pas de recul?
 Plus souvent qu’autrement l’architecte se positionne
comme un collaborateur

20. ©PyxisTechnologiesinc.
LE DÉFI DU COLLABORATEUR
 Il faut à tout prix éviter les situations suivantes:
 L’équipe attend après une décision
 L’équipe se fait systématiquement reprendre ses initiatives et perd
ainsi confiance
 L’équipe n’a pas accès à l’information qui lui permettrait de
décider
 Bref… l’équipe a constamment besoin de son architecte… qui n’est
pas toujours disponible!

21. ©PyxisTechnologiesinc.
ARCHITECT OWNER (DISCIPLINED
AGILE DELIVERY)
 Guider la création et l’évolution de l’architecture de la
solution
 Mentorat auprès de l’équipe sur les considérations
d’architecture
 Leader les efforts d’architecture initiale
 S’assurer que l’équipe comprend et adhère aux principes
d’architecture de l’organisation
 S’assurer que l’équipe connaît les « assets » de
l’organisation et les utilise de façon approprié
 S’assurer que la solution est intégré et testé fréquemment
 S’assurer que les préoccupations non fonctionnelles sont
bien représentées dans le carnet de produit et/ou la définition
de terminé

22. ©PyxisTechnologiesinc.
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
LEADERSHIP SITUATIONNEL
Source : Jurgen Appelo, Management 3.0 – leading agile developers, developing agile leaders, Addison-Wesley, 2011

23. ©PyxisTechnologiesinc.
QUELQUES EXEMPLES
Décision Niveau de
délégation
Moment de la prise
de décision
La communication entre les
composants se fera via des appels
SOAP
Les validations dans les formulaires
se feront en temps réel
Le module de chargement des
données se fera à partir d’un fichier
excel
Le champ « description » ne peut être
NULL et ne peut excéder 200
caractères
Nous débuterons par le module de
prise de commande

24. ©PyxisTechnologiesinc.
COMMENT COMMUNIQUEZ-VOUS?
Le développement de
solutions logicielles
est une activité
coopérative
d'invention et de
communication.
Efficacitédelacommunication
Richesse du canal de communication
Froid Chaud
FaibleForte
Options de
documentation
Options de
modélisation
Papier
Enregistrement
audio
Enregistrement
vidéo
Conversation
par courriel
Conversation
par téléphone
Conversation
par vidéo
Conversation
face à face
Face à face au
tableau blanc

25. ©PyxisTechnologiesinc.
OPPORTUNITÉS DE COLLABORATION
 Sprint 0
 Transfert « face à face » des
travaux d’architecture en amont
 Beaucoup de « tableau blanc »
 Sprint Planning
 Conception détaillée du sprint à
venir
 Encore du « tableau blanc »
 Daily Scrum
 Visibilité sur les enjeux pour
offrir de l’aide
 Binôme
 Transfert de connaissance,
essais, validation d’hypothèse
 Définition de TERMINÉ
 Étapes de validation
 Soucis horizontaux
 Définition de PRÊT
 Analyse d’impact
 Pistes de solution
 Revue de sprint
 Challenger la solution

26. ©PyxisTechnologiesinc.
ÉquipierÉquipier
Architecte
Comité d’architecture
STRUCTURE ÉLARGIE
Équipe 1 Équipe 2
Vision,
Contexte org,
Normes,
Orientation

27. CONCLUSION
Le rôle de
l’architecte
Agile

28. ©PyxisTechnologiesinc.
FAIRE DE L’ARCHITECTURE AGILE
 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 ses
hypothèses
 Il faut utiliser des modèles de conception qui nous
garde très près du besoins d’affaires

29. ©PyxisTechnologiesinc.
ÊTRE UN ARCHITECTE AGILE
 Prendre une décision ce n’est qu’une partie de
l’équation.
 La communication « face à face » sera toujours la plus
efficace
 Soyez inclusif dans vos activités de modélisation
 Travaillez au bon niveau de détail
 Ajustez votre style de leadership au contexte
 L’humilité est votre ami 

30. Titre sur mesure
POINTS FORTS
1
Période de
questions
?

31. ©PyxisTechnologiesinc.
NOS PROCHAINS WEBINAIRES