Posté par jc-QualityStreet le 9 mars 2009
Quand une équipe fait appel à moi pour une mission de coaching Agile ou que je m’engage dans un séminaire interactif consacré à l’agilité, mes interlocuteurs sont toujours surpris et curieux de me voir aborder ces questions là …
Vous êtes le premier à nous en parler…
Je n’avais pas vu le Sprint Zéro sous cet angle…
Ça me rassure, j’y vois plus clair…
Attendez mais c’est donc compatible avec notre process de déploiement…
Sans pour autant fixer des règles ultra figées qui n’auraient guère de sens dans un contexte Agile, j’ai pourtant des messages forts à délivrer et quelques repères à proposer :
- Oui, dans un projet Agile, il y a un Sprint 0 au démarrage, un sprint vraiment différent des autres, même si sa durée selon les contextes est variable (de quelques jours à 3 semaines) en fonction de la maturité de l’Equipe sur certaines questions…
- Oui dans un projet Agile, il y a souvent un “End Game”, un sprint un peu particulier en fin de version…
Et puisqu’un schéma vaut mieux qu’un long discours, voilà un exemple de cycle de vie (agile) :
SPRINT 0
Le Sprint Zéro n’est pas un vrai sprint (agile) au sens où il ne se termine pas forcément par la livraison d’un produit qui marche, et que sa durée est variable (de quelques jours à 3 ou 4 semaines). Ce sprint est pourtant essentiel pour mettre le projet sur de bons rails et permettre à l’équipe d’apprendre à travailler ensemble.
C’est un moment privilégié pour construire sa collaboration et prendre ses marques.
Quelles sont les activités typiques menées en Sprint 0 ?
- Partager une VISION claire du produit
- Analyser les risques
- Déterminer un plan de release (version)
- Produire un Backlog de produit estimé et priorisé
- Préparer l’environnement de développement (y compris quelques docs)
- Définir la posture ergonomique de l’interface et identifier les cibles (Personas)
- Selon les contextes, travailler l’architecture
- Dans tous les cas rôder l’équipe qui se DECOUVRE
END GAME
“End Game” mais pas vraiment une fin dans le sens où dans les faits ce sprint apparaît davantage comme une transition. Ce sprint, c’est le moment où l’équipe met la touche finale à la version et travaille de concert avec ceux qui vont déployer et exploiter au quotidien la future application.
Attention : CE N’EST PAS UNE PHASE DE TEST, même si certains types de test y trouveront une place privilégiée (tests d’acceptation, performance globale, alpha ou beta testing).
La durée du End Game est aussi variable (selon les activités menées au préalable), il peut être très court même courir sur deux sprints…
Quelles sont les activités typiques pouvant être menées en End Game ?
- Test final de la version dans un environnement similaire à la Prod
- Tests d’acceptation et tests utilisateurs sur l’ensemble de la version (même si des tests ont été réalisés au fur et à mesure)
- Tests d’install
- Possibles tests d’intégration de parties tierces non disponibles jusqu’alors
- Rework car qui dit test dit activité de dév
- Touche finale à la documentation
- Formation des utilisateurs
- Travail sur les bases de données
- …
Posté par jc-QualityStreet le 4 septembre 2008
ou vers une gestion de projet Agile (c’est plus polémique) …
ScrumMaster c’est l’un des 3 rôles (avec le Product Owner et l’Equipe) proposé par Scrum; c’est aussi un point de vigilance pour moi en tant que Coach Agile.
Le rôle de ScrumMaster consiste à aider l’équipe à travailler de manière autonome et à s’améliorer constamment, un rôle que l’on peut exercer évidemment avec ou sans la certification de la Scrum Alliance.
Le ScrumMaster est selon moi le symbole vivant d’une gestion de projet 3.0, une gestion de projet différente, collaborative et plus humaine. C’est donc aussi pour beaucoup une question de motivation et un nouvel état d’esprit.
Et puis après tout, parler de “gestion de projet agile”, c’est aussi une façon de tendre la main à tous ces chefs de projets élevés au lait PMI (Project management Institute) , bien loin de l’agilité…
WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 10 avril 2008
Oui mais y-a du boulot car CMMI (Capability Maturity Model Integrated) n’offre pas à l’ergonomie un domaine réservé !
Voici néanmoins quelques pistes dans ce billet sur Ergonomic Garden : “CMMI, Ergonomie: quelle collaboration possible ?” et dans les commentaires associés.
Une 1ère étape pour des bénéfices mutuels…
Un référentiel CMMI évidemment ajusté, léger et dynamique (Esprit Agile et Lean Thinking prennent ici tout leur sens) peut donc s’enrichir et bénéficier ici ou là, des techniques, outils et méthodes de l’ergonomie informatique pour atteindre des objectifs spécifiques bien définis. Outre une meilleure qualité de vos produits, plus d’efficacité, la démarche ergonomique éliminera pas mal de zones de flou et rationalisera vos choix d’interface !
Dans le même temps, la mise ne place de ces bonnes pratiques d’ergonomie, dans un cadre CMMI, va les institutionnaliser et permettre à une organisation de gagner en maturité en terme de Conception Centrée Utilisateurs, et devenir réellement USER FOCUSED.
Vers un TRIO GAGNANT: CMMI, Méthodes Agiles, Ergonomie…
Mais associer ergonomie et CMMI n’est qu’une étape dans des cycles d’amélioration continue. Le vrai challenge, et les GAINS LES PLUS NOTABLES n’interviendront qu’au travers:
Alors, au boulot !
Posté par jc-QualityStreet le 6 mars 2008
J’introduisais dans mon précédent billet la nécessité pour une organisation de travailler sur ses processus de développement, ses processus organisationnels, pour une intégration et une diffusion naturelle de la Conception centrée Utilisateurs et de l’Ergonomie.
Bref, je posais la nécessité d’améliorer ses processus pour plus de bénéfices et pour répondre aux exigences d’un environnement toujours plus compétitif.
Amélioration des processus ?
Attendez, mais,
“nous sommes Agiles…” diront certains,
“nous sommes CMMI niveau 3…” ajouteront d’autres,
Très bien, vous avancez … mais vous vous rendez bien compte que ce n’est pas suffisant, qu’il y a des trous, des zones de flou, des gaspillages … que l’utilisabilité de vos produits n’est pas toujours à la hauteur… quant à vos Utilisateurs…
Ce que je vous propose c’est de DEVENIR réellement USER FOCUSED, de mettre en pratique les techniques et méthodes de Conception Centrée Utilisateurs, dans un esprit Kaizen, tout en vous appuyant sur vos pépites, ces bonnes pratiques de développement que vous avez su mettre en place avec votre expérience, en vous servant de l’Agilité (c’est un excellent point de départ).
Et concrètement ?
J’apprécie beaucoup, pour sa simplicité, son accessibilité et son réalisme, l’échelle de maturité en Ergonomie (littéralement utilisabilité) de Jakob Nielsen (2006) (je la présente en détail à la fin de ce billet).
En 30 secondes, ce petit indicateur permet à votre Organisation de se situer sur une échelle de 1 à 8 niveaux, et me permet de vous montrer rapidement et facilement vers quoi nous allons tendre.
Bref, c’est un bon point de repère même si derrière TOUT RESTE A FAIRE !
En fonction de votre existant, de vos objectifs, notre stratégie d’amélioration continue pourra donc nous conduire dans un premier temps vers:
- le niveau 4 (”Budget Ergonomie dédié“),
- le niveau 5 (”Ergonomie disciplinée“),
- le niveau 6 (” Démarche ergonomique systématique“),
- le niveau 7 (”Conception Centrée Utilisateurs“)
- OU le niveau 8 (”Organisation Centrée Utilisateurs, total user focused“)
de cette échelle, avant de capitaliser et d’aller plus loin par la suite…
Voici pour conclure les 8 niveaux de maturité d’une organisation en matière d’ergonomie.
ET VOUS, OU VOUS SITUEZ-VOUS ?
Niveau 1: Hostilité à l’égard de l’ergonomie
En résumé, “A good user is a dead user”, l’ergonomie, on ne connaît pas et on ne veut pas connaître. Heureusement c’est de plus en plus rare.
Niveau 2: Ergonomie Centrée Développeur
Les décisions se fondent avant tout sur l’intuition. On échange, on réfléchit mais cela reste très technique. C’est fait par des développeurs pour des développeurs …
Niveau 3: Parcelles d’ergonomie
Pas de reconnaissance de l’ergonomie, pas de budget dédié mais quelques actions menées ici ou là. Il peut arriver que l’organisation fasse appel à un ergonome extérieur.
Niveau 4 : Budget Ergonomie dédié
Un budget est alloué (mais peut facilement se réduire du jour au lendemain); ce budget peut par exemple couvrir tout ou partie de l’activité d’un collaborateur. L’ergonomie reste encore perçue comme une sorte de potion magique qui rendra l’interface plus sexy; elle intervient encore tardivement. D’ailleurs, on ne sait pas trop ce que fait un Ergonome !
Niveau 5 : Ergonomie disciplinée
Un groupe, un pôle ergonomie est officiellement crée. Son leader fixera les orientations au sein de l’organisation et sur les projets. Une base de connaissances ergonomie est constituée et maintenue. La cause de l’ergonomie avance… même si les conditions d’intervention sont loin d’être idéales.
Niveau 6 : Démarche ergonomique systématique
L’ergonomie est instituée sur les projets. Les techniques et méthodes de conception centrée utilisateurs sont des pratiques considérées au démarrage de tous les projets avec un degré d’intervention variable selon la nature et l’importance du projet. Cela devient très intéressant !
Niveau 7 Conception Centrée Utilisateurs
L’ergonomie est l’affaire de tous. Des recherches Utilisateurs sont menées régulièrement: elles alimentent les projets. La qualité ergonomique du produit est mise au 1er plan : elle est vérifiée, mesurée, des objectifs sont fixés.
Niveau 8 : Organisation Centrée Utilisateurs (total user focused)
Les données recueillies dans les recherche utilisateurs vont alimenter la stratégie produit et la stratégie d’entreprise. L’expérience Utilisateurs est étendue à tous les canaux, à toutes les formes d’interaction avec les clients.
L’original: http://www.useit.com/alertbox/maturity.html
