Posté par jc-Qualitystreet le 19 mars 2010
Coach agile vs ScrumMaster : c’est parfois un peu flou… sans doute parce que le ScrumMaster utilise dans ses activités des techniques de coaching agile, sans doute parce que le coach Agile peut être amené sur certaines missions à jouer le rôle de ScrumMaster.
Pourtant selon moi aucune ambigüités : « Le ScrumMaster n’est pas un Coach Agile ». Avant de justifier cette assertion avec quelques éléments de comparaison, voici dans les grandes lignes en quoi consiste le travail de chacun.
Le ScrumMaster
Animateur d’une équipe qui applique la méthode Agile Scrum, le travail du ScrumMaster consiste à aider l’équipe à travailler de manière autonome et à s’améliorer constamment. Il est le garant de Scrum sur le projet. Le ScrumMaster va principalement agir en facilitateur, va protéger l’équipe et lever les obstacles empêchant l’équipe d’avancer.
Le Coach Agile
Le travail du Coach Agile consiste à accompagner pour une durée déterminée une Organisation, une équipe ou une personne dans son parcours vers ou dans l’agilité, pour des résultats concrets et mesurables. Le focus est mis sur l’agilité, une spécificité qui fait que le « Coach Agile », va généralement au-delà de la posture classique du métier de coach en s’aventurant sur d’autres terrains : formation, mentorat, conseil ou encore “évangélisation”, pour permettre à son client d’atteindre en toute autonomie les objectifs qu’il s’est fixés .
Eléments de comparaison
|
COACH AGILE
|
SCRUMMASTER
|
| Mission |
Centrée sur l’Agilité
Pour l’individu et/ou l’Équipe et/ou l’Organisation
Nécessite fortement de clarifier les objectifs et d’analyser précisément le contexte d’intervention
=> Grande Variabilité - Impact sur les activités |
Centrée sur Scrum
Pour l’équipe
Objectifs généralement clairs liés à la description du rôle (Garantir Scrum sur le projet, Faciliter, Protéger l’équipe, Lever les obstacles)
=> Peu de variabilité - Peu d’impact sur les activités |
| Champ d’intervention |
L’agilité au sens large |
Scrum |
| Relation au projet |
Indépendant - Tiers |
Partie-prenante - Dans le projet |
| Relation à l’équipe |
Ne fait pas partie de l’équipe
Ne protège pas l’équipe |
Avec l’équipe au quotidien
Protège l’équipe |
| Présence |
Ponctuelle et variable selon le contexte et les besoins. Présence plus forte au début de la mission, moins importante par la suite. Le Coach recherche l’autonomie de son Client… |
Continue. Sur toute la durée du projet. |
| Pré-requis Formation |
Formé aux méthodes, rôles et pratiques Agiles.
Formé au coaching (certifié ou non)
Bonnes connaissances des cycles de vie, des métiers et activités du SI (qui fait quoi …)
Connaissances de base en psychologie |
Formé au rôle de ScrumMaster (certifié ou non) |
| De l’expérience dans l’application de l’agilité |
Nécessaire |
Pas nécessaire |
| De l’expérience dans la mise en œuvre de l’agilité dans différents contextes |
Nécessaire |
Pas nécessaire |
| Agit en Formateur |
+++ |
Non |
| Agit en Facilitateur |
++ |
+++ |
| Agit en Mentor |
+++ |
+ |
| Agit en Coach |
+++ |
+ |
| Agit en Consultant |
+ |
Non |
| Est l’agent du changement |
+++ |
+ |
Note Echelle :
+++ (Oui Enormément) ; ++ (Oui Beaucoup) ; + (Oui Un peu) ; Non
Mais tout cela n’engage que moi !
Posté par jc-Qualitystreet le 15 mars 2010
L’année dernière c’était nickel !
Plus de 300 personnes sont attendues cette année pour LA conférence française consacrée aux méthodes AGILES. Le lieu reste inchangé: Chalet de la Porte Jaune (Bois de Vincennes), et j’y serai !
“Vous êtes en quête d’idées neuves pour rendre plus efficaces vos projets de développement logiciels ? Vous souhaitez en savoir plus sur les méthodes agiles, leurs bénéfices, leurs limites… Vous avez mis en place des pratiques agiles au sein de vos projets et vous souhaitez confronter vos retours d’expérience à ceux d’autres praticiens…” la conférence est faite pour vous.
Chefs de projet, clients, décideurs, développeurs… et tous les autres, inscrivez-vous dés maintenant (à tarif réduit)
Commentaires:
Classé sous: Agile
Posté par jc-Qualitystreet le 13 mars 2010
L’architecture de l’information, c’est une composante essentielle de l’Expérience Utilisateur, c’est surtout une activité incontournable de tout projet IT… à dimension variable selon la nature de ces mêmes projets : logiciels, applications métiers ou au contraire sites eCommerce et portails Intranet, des contextes dans lesquels la dimension contenu est beaucoup plus importante.
Architecture de l'information : un élément d'UX
Architecture de l’information : de quoi s’agit-il ?
L’architecture de l’information se définit comme l’organisation du contenu et des fonctionnalités d’un point de vue cognitif et graphique pour répondre aux besoins et attentes des utilisateurs finaux.
Plus simplement, cette activité généralement prise en charge par l’ergonome IHM ou d’autres métiers du web, côté Scrum Product Owner ou côté Equipe Scrum à vous de voir pour les projets agiles, consiste à aider les gens à trouver et à gérer l’information plus efficacement.
La bonne information à la bonne place…
L’architecture de l’information est donc une activité avant tout conceptuelle, tout en étant fortement structurante pour le projet. D’où la nécessité d’initier le travail au plus tôt. Dans des contextes AGILE, les premiers éléments, dits « High level » devront donc être maîtrisés en sprint 0/1, parfois sur la base de données recueillies avant le démarrage officiel du projet.
Dans les grandes lignes, travailler sur l’architecture de l’information va ainsi consister à :
- Classifier, catégoriser l’information et attribuer les libellés les plus signifiants (sur la base d’inventaires de contenu et de tri de carte)
- Distinguer et prioriser les fonctionnalités et contenus en fonction des besoins utilisateurs et exigences Business (sur la base d’interviews, d’enquêtes, d’études utilisateurs comme le modèle de Kano)
Modèle de Kano
- Construire et décrire une structure d’information efficace (Arborescence ; « Concept model »)
Workshop Arborescence
Arborescence
Concept Model par Daniel M. Brown
- Déterminer le système de navigation le plus performant (modèle global, local et contextuel en tenant compte des fonctions de recherche) (cinématiques - zoning)
Système de navigation - Pages intérieures
- Faire les premiers zoning illustrant le système de navigation envisagé
Bref dites-vous bien que tout ce temps passé sur l’architecture de l’information (”Juste ce qu’il faut” et dans un mode collaboratif), c’est du temps gagné à court terme pour l’équipe qui développe et à moyen terme pour les futurs utilisateurs.
Posté par jc-Qualitystreet le 7 mars 2010
L’adoption de l’agilité induit du changement, et le plus souvent un CHOC CULTUREL majeur pour les organisations qui auront tendance au départ à nier ou à minimiser son impact…
Il y a les Valeurs, les Principes et les PRATIQUES AGILES (scrum, xp …) listées ci-dessous
Les Valeurs se déclinent en Principes qui se concrétisent en Pratiques
Le discours des coach Agile sur le rapport Valeurs-Pratiques peut paraître ambivalent car au quotidien, nous travaillons beaucoup sur le mise en œuvre progressive et en contexte de ces pratiques Agiles. Au moment des bilans, c’est aussi celles-ci que nous examinons de prés…
Pourtant aucune ambigüité : les pratiques sont au service des valeurs qu’elles représentent. A chaque pratique sa valeur (les 4 de l’Agile Manifesto et les 5 XP) : à nous de ne pas perdre de vue ce lien et de revenir sans cesse au travers de notre coaching à ce socle commun de toutes les Méthodes Agiles.
Et au fait, quelles sont-elles ces pratiques dites Agiles ?
Voici ma petite liste des pratiques agiles. Evidemment sur un projet, ces pratiques agiles ne suffisent pas, et doivent être complétées de pratiques issues d’autres disciplines, en particulier Ergonomie / Expérience Utilisateur, Tests et Ingénierie des exigences, dont l’efficacité n’est plus à prouver ….
- Vision du produit
- Roadmap (Plan “high level” de plusieurs versions) & Release plan (Plan de la version en cours)
- Daily Scrum
- Demo de fin de sprint
- Planification de sprint
- Rétrospective
- Estimation collective (planning poker)
- Taskboard (et Kanban Board)
- Liste des obstacles
- Agile Risk Board (gestion agile des risques)
- Radiateur d’informations
- Sprints courts et « timeboxés »
- Backlog de produit
- Backlog de sprint
- Definition du Done
- BurnDown chart (base tâches en heures)
- BurnUp chart (base vélocité en points)
- ScrumMaster dédié
- Client / Product Owner sur site
- Equipe cross fonctionnelle
- Equipe colocalisée
- Standards de développement
- User Stories
- Programmation en binôme
- Conception simple
- Refactoring
- Propriété collective du code
- Intégration continue
- Livraison fréquente (d’une partie du produit)
- Tests Unitaires
- TDD (Développement piloté par les tests)
- ATDD (Développement piloté par les tests d’acceptation)
- Tests de recette (à chaque sprint)
- Automatisation des tests
Bon, ça reste ouvert …
Commentaires:
Classé sous: Agile
