Le rôle de l’architecte Agile - Mathieu Boisvert

2,304 views

Published on

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.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,304
On SlideShare
0
From Embeds
0
Number of Embeds
267
Actions
Shares
0
Downloads
27
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Plutôt qu’une analyse préliminaire, les méthodes Agiles préconisent une analyse en continu. Elles préconisent également que l’équipe de développement soit responsable de l’estimation de la portée du projet. 

    Au cours de cette présentation, on vous présentera différents contextes de projet et modèles de démarrage pour aider les participants à rendre plus Agile l’évaluation de leurs projets.

    Ce que vous apprendrez :
    Comment il est possible de calculer le budget requis sans l’étape d’analyse préliminaire;
    Comment il est possible de calculer le budget requis avant la constitution de l’équipe de développement.
  • /campus offre une gamme complète de cours de formation permettant d’acquérir les connaissances nécessaires pour maîtriser les notions de l’Agilité.

    /conseil, c’est une équipe d’experts qui accompagne nos clients et leurs équipes de direction dans la gestion et la réalisation de leurs projets Agiles.

    /studio développe des applications sur mesure et prend en charge les projets de nos clients ou les réalise conjointement avec eux.

    La force de Pyxis Technologies réside dans notre équipe de Pyxissiens passionnée qui vit l’Agilité chaque jour et en maîtrise les pratiques et techniques.
  • Je baigne dans la soupe agile depuis 2004
    Conseiller, formateur, co-auteur, Chargé de cours
    Accessoirement: directeur de la formation à Pyxis.
  • L’architecture c’est une stratégie de réalisation

    L’architecture ca existe. Agile ou pas, détaillée en amont ou émergente l’architecture ça existe

    Le problème vient de: …. (post-it)

    Recette pour résister aux changements
    Perte de pouvoir
    Changement de façon faire
  • Objectifs: Affirmer qu’on va s’éloigner de la rhétorique habituelle lors du séminaire et qu’on va discuter des vrais enjeux

    L’agilité vient avec son lot de Mythes.

    Révise les « misconceptions » de Scott Ambler ?

    Transition: revenons à pourquoi on veut plus d’agilité dans nos projets
  • Objectif: Distinguer complexité (inconnu) et complexité (envergure)

    Fonctionnel : répondre aux besoins (portée), processus affaire, utilisabilité, intégrité, simplicité, cohérence, BRE, cycle de vie
    Organique: langage, qualité code, intégration continue, déploiement
    Entreprise: services et systèmes, sécurité, conformité aux règlements et lois

    Multiples interdépendances systèmes
    Impacts majeurs sur le processus d’affaires
    Soucis horizontaux majeurs

    Ne rien oublier

    Y arriver dans les ressources disponibles (temps et argent) :
    - Ne pas rester bloquée par un manque de décision
    Ne pas recommencer ce qui est déjà

    Valider le système le résultat final avant la mise en service

  • S’arrêter « juste assez »: suffisamment pour définir un cadre pour les équipes de développement
    Garder les options ouvertes: pour conserver la flexibilité le plus longtemps possible
    Modèle proche des besoins affaires: pour vérifier véritablement les hypothèses: les siennes et celles des autres

    Mauvaises raisons
    Parce que ca fonctionne comme ca ici
    Pour pouvoir mieux évaluer le budget et ainsi franchir une gate de gouvernance
  • Es-ce qu’on utilise le DAD pour positionner

    Inception Phase
    Architecture Owner

    Qu’est-ce qu’on peut faire de la démo quand on est architecte?
    Ne pas laisser place à l’interprétation
    Négociation sur l’ordre de priorisation (par exemple, se servir des cas d’utilisation)
  • Objectif: mentionner que le carnet est orienté business, mais qu’il y a aussi de la place pour des considérations techniques… surtout si elles découlent de fonctionnalités à valeur ajoutée
  • Présentation des différents patterns de démarrage que je connais.
  • Faire une reflexio au niveau vision au départ du projet
    Vérifier les hypothèse dans les premières itérations
    Laisser plus d’espace à la livraison d’exigences affaires

    Transition: Oui mais ne devrait-on pas livrer exclusivement de la valeur d’affaire ??
  • Objectif: pour parler de comment jouer son rôle, faudrait s’entendre sur les objectifs du role


    http://www.agilearchitect.org/agile/role.htm

    One of the architect’s main jobs is communicating the architecture. He or she must become the solution’s “champion”, selling the vision and keeping it alive in the face of challenges.

  • Objectifs: Rappeler l’écosystème d’une équipe Agile

    Insister sur les « postures »

    Équipiers
    Contributeurs
    Collaborateurs

    Quels options pour les architectes ??
  • Objectif: présenter les 2 « postures » qui s’offre à l’architecte

    Présenter les pièges d’être dans l’équipe
  • Quelles décisions je cesse de prendre?
    Quelles décisions je commence à prendre?


    Exercice fort utile pour établir ces frontières est de faire du « Delegation Poker » pour se construire un « Authority Board »

    2 facteurs influencant ce modèle
    La nature de la décision
    La maturité de l’équipe

    Donc ce sera jamais la même facon de se comporter !!!!

    INTERACTIONS

    Ex:
    Ce sera une application WEB en java
    La table « Employé » comportera un champ « prénom » de 255 caractères
    Le composant A et le composant B interagirons par appel SOAP

  • Objectifs: rappeler que c’est pourri de communiquer par document

    Document pour pérennité
  • Objectifs: Rappeler l’écosystème d’une équipe Agile

    Insister sur les « postures »

    Équipiers
    Contributeurs
    Collaborateurs

    Quels options pour les architectes ??
  • Mathieu
  • JR
  • Le rôle de l’architecte Agile - Mathieu Boisvert

    1. 1. SavoirAgile.com Wébinaire - 18 février 2016 RÔLE DE L’ARCHITECTE AGILE
    2. 2. ©PyxisTechnologiesinc. Merci! PYXIS VOUS OFFRE UNE GAMME COMPLÈTE DE SERVICES
    3. 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. 4. ©PyxisTechnologiesinc. QUEL EST LE PROBLÈME?
    5. 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. 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. 7. IMPACT #1: ÉMERGENCE ET INCRÉMENTALITÉ Rôle de l’architecte Agile
    8. 8. ©PyxisTechnologiesinc. VOTRE PROJET RESSEMBLE-T-IL À CECI?
    9. 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. 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. 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. 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. 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. 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. 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. 16. IMPACT #2: COLLABORER AVEC LES ÉQUIPES Rôle de l’architecte Agile
    17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 26. ©PyxisTechnologiesinc. ÉquipierÉquipier Architecte Comité d’architecture STRUCTURE ÉLARGIE Équipe 1 Équipe 2 Vision, Contexte org, Normes, Orientation
    27. 27. CONCLUSION Le rôle de l’architecte Agile
    28. 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. 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. 30. Titre sur mesure POINTS FORTS 1 Période de questions ?
    31. 31. ©PyxisTechnologiesinc. NOS PROCHAINS WEBINAIRES

    ×