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.
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 ??