Le rôle de l architecte Agile

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?

La complexité en développement logiciel Loin d un accord Chaos Spécifications Près d un accord Compliqué Principe Agile: Les équipes s'auto- organisent afin de faire émerger les meilleures architectures, spécificanons et concepnons. Simple Compliqué Vous êtes plus souvent qu autrement ici! Près d une certitude Technologies Loin d une certitude

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

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

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 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) AnNcipaNon AdaptaNon 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 Carnet de produit Les besoins d affaires allimentent et fixent la priorité du carnet de produit Cas d unlisanon Thèmes Épics User Story Une stratégie pour gérer et planifier les considéranon d architectures est requise!

ÉvoluNon de la concepnon et du risque Tâches techniques Fonctionnalités Effort de développement Risque technique Faisabilité ConcepNon ConstrucNon Beaucoup de concepnon au départ Beaucoup de foncnonnalités affaire par la suite

Patterns de démarrage Mandat Faisabilité ConcepNon ConstrucNon ImplantaNon a) Directement en construcnon (proposinon Scrum) ItéraNon 1 ItéraNon 2 [ ] ItéraNon N ItéraNon finale AcceptaNon b) ItéraNon de démarrage (pranque dans la communauté) ItéraNon 0 ItéraNon 1 ItéraNon 2 [ ] ItéraNon N ItéraNon finale AcceptaNon c) ConcepNon préalable limitée Concept. préalable ItéraNon 0 ItéraNon 1 ItéraNon 2 [ ] ItéraNon N ItéraNon finale AcceptaNon d) ConcepNon itéranve Concpt 1 Concpt 2 Concpt 3 ItéraNon 1 ItéraNon 2 [ ] ItéraNon N ItéraNon finale AcceptaNon

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

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

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 L équipe Scrum se compose GesNonnaires du Scrum Master, Clients Des Équipiers, Du Responsable de produit, de l ensemble des individus ayant les compétences pour produire un incrément de produit. Experts Et l architecte? Les collaborateurs et les contributeurs sounennent l équipe

Ê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!

Leadership situanonnel 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 Source : Jurgen Appelo, Management 3.0 leading agile developers, developing agile leaders, Addison-Wesley, 2011

Quelques exemples Décision La communicanon entre les composants se fera via des appels SOAP Les validanons dans les formulaires se feront en temps réel Le module de chargement des données se fera à parnr d un fichier excel Le champ «descripnon» ne peut être NULL et ne peut excéder 200 caractères Nous débuterons par le module de prise de commande Niveau de délégagon Moment de la prise de décision

Quel est le contexte de la décision? Gouvernance Stratégique Niveau de déléganon TacNque Forming Storming Norming Performing Stades de maturité d une équipe Théorie du développement des groupes, Bruce Tuckman

Comment communiquez- vous? Efficacité de la communication Faible Forte Papier Conversation par courriel Enregistrement vidéo Enregistrement audio Options de documentation Conversation par téléphone Conversation par vidéo Face à face au tableau blanc Conversation face à face Options de modélisation Le développement de solunons logicielles est une acgvité coopéragve d'invennon et de communicanon. Froid Richesse du canal de communication Chaud

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

Structure élargie Équipe 1 Vision, Contexte org, Normes, OrientaNon Équipe 2 Architecte Équipier Équipier Comité d architecture

Le rôle de l architecte Agile CONCLUSION

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? 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é Démarrage et suivi Nous assurons une gesnon efficace de vos projets basés sur les principes et pranques Agiles 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.

Faire face à la complexité Architecture Émergente Complexe Sonder Comprendre Répondre Compliqué Comprendre Détailler Répondre Architecture Détaillée Simple Comprendre Catégoriser Répondre Recetes connues