Embed Size (px)
DESCRIPTION
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.
Citation preview
Le rôle de l’architecte Agile Jean-‐René Rousseau et Mathieu Boisvert 6 novembre 2012
Copyright © 2012, Pyxis Technologies inc. Tous droits réservés
Qui sommes-‐nous? Jean-‐René Rousseau • Coach et Formateur agile à Pyxis • Accompagné une vingtaine d’organisaNons diverses depuis 2005
Mathieu Boisvert • Architecte foncNonnel agile à la SIQ; • Coach agile à Pyxis • Chargé de cours à l’UQAM • Co-‐Auteur du livre Choisir l’agilité.
Quel est le problème?
Loin d’une certitude Près d’une certitude
Technologies
Loin
d’un a
ccor
d Pr
ès d’
un ac
cord
Sp
écifi
catio
ns
Compliqué
Com
pliq
ué
Simple
Chaos
La complexité en développement logiciel
Vous êtes plus souvent qu’autrement ici!
Principe Ag
ile:
Les équipes
s'auto-‐org
anisent afin
de
faire émerger
les meilleu
res
architectur
es, spécifica
Nons et
concepNon
s.
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 uNle doit programmer?
• Une équipe auto organisée ne peut être influencée?
ObjecNfs du séminaire • 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
IMPACT #1: ÉMERGENCE ET INCRÉMENTALITÉ
Rôle de l’architecte Agile
Compléxité d’un système
Risques des architectures
• Perdre le besoin de vue • Paralysie par l’analyse • Se baser sur des fausses hypothèses • Perdre la flexibilité et l’adaptabilité
Balancer An1cipa1on et Adapta1on
AnNcipaNon
AdaptaNon
PraGques • ÉllicitaNon complète des besoins en amont • Architecture détaillée en amont • CommunicaNon par documents approuvés
PraGques • Compréhension des besoins « Juste assez, juste à temps » • Architecture émergente (dernier moment responsable • Cycle de rétroacNon (feedback loop)
Risques • Paralysie par l’analyse • Sur ingénierie • SoluNon non adaptée Risques
• Réingénierie coûteuse • SoluNon non globale
Cadre de travail Scrum
Le carnet pour prioriser les items avec des stratégies: • Juste assez, • au bon moment, • garder les opNons
ouvertes, • jusqu’au dernier
moment responsable.
La démonstraNon et la livraison du dernier incrément du système, pour: • Valider le résultat, • Confirmer les
hypothèses, • Ajuster la concepNon
(architecture émergente) responsable.
Des spécificaNons orientées sur les besoins affaires
Thèmes
Épics
User Story
Cas d’uNlisaNon
Les besoins d’affaires allimentent et fixent la priorité du carnet de produit
Une stratégie pour gérer et planifier les considéraNon d’architectures est requise!
Carnet de produit
Risque technique
Effo
rt d
e dé
velo
ppem
ent
ÉvoluNon de la concepNon et du risque
Fonctionnalités
Tâches techniques
ConstrucNon ConcepNon Faisabilité
Beaucoup de concepNon au départ
Beaucoup de foncNonnalités affaire
par la suite
ImplantaNon
Patterns de démarrage
ConstrucNon ConcepNon Faisabilité Mandat
ItéraNon 1
ItéraNon 2
[…]
ItéraNon N
ItéraNon finale AcceptaNon
a) Directement en construcNon (proposiNon Scrum)
ItéraNon 1
ItéraNon 2
[…]
ItéraNon N
ItéraNon finale AcceptaNon ItéraNon 0
b) ItéraNon de démarrage (praNque dans la communauté)
ItéraNon N
ItéraNon finale AcceptaNon ItéraNon 0
c) ConcepNon préalable limitée
Concept. préalable
ItéraNon 1
ItéraNon 2
[…]
Concpt 3
ItéraNon N
ItéraNon finale AcceptaNon Concpt
1 d) ConcepNon itéraNve
Concpt 2
ItéraNon 1
ItéraNon 2
[…]
Exemple de la planificaNon conjointe entre des besoins affaires et contraintes TI
Identification des processus affaires
Utiliser un événement de vie pour parcourir entièrement le processus avec un cas précis Exemple: Projet mineur en construction de 15000$ en gré à gré en réparation majeure.
Prioriser le carnet avec les fonctionnalités et les items techniques pour livrer le cas d’utilisation
IMPACT #2: COLLABORER AVEC LES ÉQUIPES
Rôle de l’architecte Agile
Responsabilités d’un architecte • Établir et communiquer une stratégie de réalisaNon
• Assurer un leadership sur la soluNon développée (guider, accompagner)
• Être le gardien des contraintes organisaNonnelles
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 souNennent l’équipe
GesNonnaires Clients
Experts
Et l’architecte
?
Être ou ne pas être dans l’équipe ?
• Équipier est sans doute la meilleure posture pour accomplir vos objecNfs – Aurez-‐vous la disponibilité nécessaire? – Arriverez-‐vous à garder un pas de recul?
• Plus souvent qu’autrement l’architecte se posiNonne comme un collaborateur
Le défi du collaborateur • Il faut à tout prix éviter les situaNons suivantes: – L’équipe aQend après une décision – L’équipe se fait systémaNquement reprendre ses iniNaNves et perd ainsi confiance
– L’équipe n’a pas accès à l’informaGon qui lui permetrait de décider
– Bref… l’équipe a constamment besoin de son architecte… qui n’est pas toujours disponible!
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 collaboraNon 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 situaNonnel
Source : Jurgen Appelo, Management 3.0 – leading agile developers, developing agile leaders, Addison-Wesley, 2011
Théorie du développement des groupes, Bruce Tuckman SituaNonal Leadership, Paul Hershey and Ken Blanchard
• Les membres de l‘équipe apprennent à se connaître
• L‘équipe est inquiète et manque de connaissances
• Les membres de l’équipe échangent leurs idées
• L’équipe vit une période de turbulence mais veut essayer
• Les membres de l’équipe arrivent à un objecNf et un plan commun
• L’équipe commence à se responsabiliser
• Les membres de l’équipe travaillent ensemble et performent avec une supervision minimale.
• L’équipe est compétente, responsable et engagée
Forming Storming Norming Performing
Stades de maturité d’une équipe
Telling ParGcipaGng DelegaGng
Styles de leadership
Niveau de maturité des équipes
Comment communiquez-‐vous?
Le développement de soluNons logicielles est une acGvité coopéraGve d'invenNon et de communicaNon.
Efficacité
de la com
mun
ication
Richesse du canal de communicationFroid Chaud
Faible
Forte
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
Opportunités de collaboraNon
• Sprint 0 – Transfert « face à face » des travaux d’architecture en amont – Beaucoup de « tableau blanc »
• Sprint Planning – ConcepNon 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, validaNon d’hypothèse
• DéfiniNon de TERMINÉ – Étapes de validaNon – Soucis horizontaux
• Revue de sprint – Challenger la soluNon
Équipier Équipier
Architecte
Comité d’architecture
Structure élargie Équipe 1 Équipe 2 Vision,
Contexte org, Normes,
OrientaNon
CONCLUSION Le rôle de l’architecte Agile
Faire de l’architecture Agile • Pour faire face à la complexité il faut laisser une place à l’émergence dans nos stratégies de concepNon
• Il faut limiter l’effort iniNal de concepNon • Il faut chercher à valider rapidement ses hypothèses
• Il faut uNliser des modèles de concepNon qui nous garde très près du besoins d’affaires
Être un architecte Agile • Prendre une décision ce n’est qu’une parNe de l’équaNon.
• La communicaNon « face à face » sera toujours la plus efficace
• Soyez inclusif dans vos acNvités de modélisaNon
• Travaillez au bon niveau de détail • Ajustez votre style de leadership au contexte • L’humilité est votre ami J
Références -‐ web • www.direcNoninformaNque.com/la-‐transformaNon-‐agile-‐du-‐role-‐de-‐larchitecte/
• www.agilemodeling.com/essays/agileArchitecture.htm
• www.agilearchitect.org/agile/index.asp • www.marNnfowler.com/arNcles/designDead.html
• www.infoq.com/arNcles/agile-‐architecture
Références -‐ Livres
Comment peut vous aider?
Démarrage et suivi Nous assurons une gesNon efficace de vos projets basés sur les principes et praNques Agiles
PlanificaNon stratégique Nous établissons un plan de transiNon Agile adapté à votre contexte
DiagnosNc Nous évaluons votre niveau de maturité Agile et votre capacité d’adopNon de l’agilité
ImplantaNon Nous vous aidons à devenir une organisaNon qui ne cesse de s’améliorer via l’uNlisaNon de l’agilité
Chez Pyxis, nous metons en praNque ce que nous prônons. La priorité lors de nos intervenNons est donc d’établir un fort partenariat avec nos clients. Vos succès sont au coeur de notre moNvaNon.
![Vida Eniko˝ – Frédérick Airault ALLONS-Y 1Vida Eniko˝ – Frédérick Airault 1 MÉTHODE DE FRANÇAIS PLUS Corrigés. 1 döni [dəni] frédérik [fʁedeʁik] ɑ̃dré [ɑ̃dʁe]](https://img.pdfslide.fr/doc/110x75/610eaa817a33dc210b4652e0/vida-eniko-a-frdrick-airault-allons-y-1-vida-eniko-a-frdrick-airault.jpg)
