Manifeste pour une ERGONOMIE AGILE

Posté par jc-QualityStreet le 30 septembre 2007

Vous êtes nombreux à m’avoir sollicité sur cette question de l’Ergonome Agile :
en quoi consiste concrètement son travail dans des contextes UP, OpenUP, XP, SCRUM, DSDM ou Lean ?
Comment intégrer l’Expérience Utilisateur, le Design d’Interaction et le Graphisme dans un projet appliquant l’une de ces nouvelles méthodes, dites Agiles (car opposées aux cycles de développement traditionnels, en cascade ou V) ?

Tout d’abord, un constat : l’intégration d’une conception centrée utilisateur dans un contexte Agile n’est pas aisée, l’ergonome n’est pas attendu, et s’il ne parvient pas à prouver rapidement sa plus value, ou pire s’il retarde les équipes de dév. … on le sortira poliment du projet, c’est ça le Lean Thinking !!
Pourtant, croyez-moi les projets Agile ont un réel besoin d’ergonomie !!

L’ergonome Agile introduisait la nécessité pour nous autres Ergonomes ou Spécialistes de l’Interface Utilisateur, d’adapter notre démarche, nos outils et nos ivrables pour une collaboration plus efficace au sein d’équipes fonctionnant en mode itératif, incrémental. Cet article vous présente donc quelques pistes concrètes d’intégration de notre démarche mais n’hésitez pas à me contacter si vous voulez en savoir plus …

« … Le temps est donc venu pour l’ergonome de devenir Agile … », telle était donc ma précédente conclusion, mais quelles spécificités du profil de l’Ergonome Agile vont rendre sa collaboration plus efficace et surtout plus efficiente ? Quelles dimensions de son activité seront bénéfiques au projet, au client, aux utilisateurs finaux et en quoi son intervention donnera-t-elle satisfaction à l’équipe de développement ?

D’ABORD LE PROFIL DE L’ERGONOME AGILE
L’ergonome Agile possède…

Lire la suite

UP + SCRUM + XP + CMMI ?

Posté par jc-QualityStreet le 24 septembre 2007

Ou pourquoi, après avoir adapté et mis en place le Processus Unifié et autres pratiques Agiles au sein de mon organisation, je travaille sur le CMMI ?
_en marge de ma principale activité, l’ERGONOMIE DES IHM… trust me I am still an interaction designer :)_

Donc, voici mes quelques motivations :

• DISCIPLINER L’USAGE DES PRATIQUES AGILES SUR LE PLAN ORGANISATIONNEL (faiblesse relevée pour certains contextes lors de mon travail de Capitalisation)
• Donner un second souffle à la méthode en l’envisageant sous un angle nouveau
• Engager officiellement un programme reconnu d’amélioration des processus de développement : nouveau challenge, nouvelle roadmap…
• Aller plus loin sur les trois axes majeurs (Clients ; Projets ; Collaborateurs; jetez un coup d’oeil à Questions de motivation : Convergence) et compter sur un renforcement des bénéfices obtenus et attendus individuellement par chaque approche. En combinant Agilité et CMMI, on est plus forts comme le souligne Jeff Sutherland
• Profiter de la notoriété du CMMI sur le plan international

Ensuite, ce que j’aimerais sur cette question en 2008 :

• Une toujours plus grande implication des leaders Agile / CMMI dans ce rapprochement (à l’instar de la communication de Jeff Sutherland dernièrement)
• Une intégration plus formelle, plus systématique au sein du modèle CMMI de pratiques Agiles pour atteindre les objectifs génériques et spécifiques

Exemple de Plan de Projet

Posté par jc-QualityStreet le 20 septembre 2007

Bien plus qu’un livrable, le Plan de Projet (appelé aussi Plan de développement Logiciel), est un outil indispensable, nécessaire à la bonne marche de tout projet informatique (petit ou grand). Disons qu’avec un Plan de Projet correct, bien pensé et compris par les équipes, le projet débute sous les meilleurs auspices…

Le Plan de Projet est donc sous la responsabilité du Chef de projet , du Management ou du ScrumMaster (contextes Agile-CMMI), et rassemble en son sein toutes les informations utiles et nécessaires pour gérer le projet. Il est donc l’élément fédérateur du projet, la référence sur laquelle chacun va s’engager, et qui sera évidemment ensuite accessible par l’ensemble de l’équipe.

Juste ce qu’il faut de formalisme!

Le plan projet doit être soigné mais son caractère formel/ informel et la densité de son contenu vont varier en fonction des contextes et des tailles de projet. Il est essentiel de l’initier pour démarrer le projet; il va ensuite évoluer avec le rythme de celui (notamment au fur et à mesure des sprints dans un mode Agile)

Voici un modèle de Plan de Projet (structure type):

Juste ce qu’il faut de documentation!

Le Plan de Projet est central dans un contexte CMMI, au cœur du domaine de processus de niveau 2, Planification de projet (PP), et essentiel pour  la Gestion des exigences (REQM) et la Gestion des risques (RSKM). Autrement dit, si vous avez un Plan de Projet (ainsi que la démarche et le contenu qui vont avec …), c’est aussi un bon point de départ du point de vue du SEI quant à la maturité de ce domaine de votre organisation.

Mais surtout, le Plan de Projet fait partie de ce “Juste ce qu’il faut” de documentation qu’on retrouve aussi bien dans du process plutôt lourd (type RUP) - de moins en moins utilisés - que dans des versions beaucoup plus light du Processus Unifié (comme OpenUP), ou encore et de plus en plus dans des méthodes Agiles qui ont le vent en poupe comme SCRUM.

Scrum et la plupart des méthodes Agiles ne vous imposent bien évidemment pas de mettre en place un plan projet, vous laissant pas mal de marges de manœuvre quant à celui-ci. Mon expérience et mes activités de coaching agile m’ont néanmoins montré que la présence d’un plan de projet, souple, léger et ouvert était une vraie bonne pratique, rassurante à la fois pour l’Equipe, pour le Management et l’organisation.

Ergonomie Web : du bon usage des onglets

Posté par jc-QualityStreet le 18 septembre 2007

13 règles d’or proposées par Jakob Nielsen: c’est clair, c’est précis (on pourrait facilement les inclure dans une charte ergonomique).

Et surtout c’est très précieux pour éviter les dérives, et tout usage inapproprié. Car croyez-moi, des onglets utilisés là où il ne fallait pas, j’en ai vu et malheureusement j’en vois encore !! Voilà de la bonne ergonomie web.

CMMI et Méthodes Agiles : Questions de motivations

Posté par jc-QualityStreet le 16 septembre 2007

Après “Agile CMMI: moi j’y crois” et “CMMI, décidemment nous y sommes“, imaginons maintenant quelles pourraient être les motivations respectives des auteurs ou partisans des deux approches pour un rapprochement (selon moi inévitable) du CMMI (Capability Maturity Model Integration) et des Méthodes Agiles.
Au programme : Convergence … Complémentarité … Popularité … Amélioration continue … Succès.

Convergence
Agilité et CMMI se donnent les mêmes objectifs, notamment niveau Client (satisfaction, rétention, acquisition), niveau Projet (respect côut, délais, qualité) et niveau Collaborateurs (satisfaction, montée en compétence…). Partager le même but peut faciliter les rapprochements…

Complémentarité
CMMI définit le “Quoi” mais a besoin d’éléments pour atteindre les objectifs qu’il se fixe. L’agilité peut donc en partie constituer ces éléments et se charger d’une partie du “comment”, ce qui contribuera au passage à lever les idées reçues concernant les deux approches.
Qui dit Agile ne dit pas absence de discipline, Scott Ambler en parle remarquablement dans ce tout récent article « The discipline of Agile » ; Et, Qui dit CMMI, ne signifie pas pour autant lourdeur excessive.

Popularité
Sans enlever à la notoriété du CMMI, fort populaire dans certains contextes, il est évident que les Méthodes Agiles ont actuellement le vent en poupe. Déjà populaires dans les pays anglo-saxons, elles se démocratisent en France. Ainsi, intégrer plus largement, plus visiblement, plus concrètement, en son sein, des pratiques Agiles (pour chaque but par exemple) pourrait permettre au CMMI d’envisager d’autres cibles.

Amélioration continue
C’est un principe Agile, c’est l’essence même du CMMI … et un facteur motivationnel de 1er ordre pour l’ensemble des acteurs des univers CMMI et Agile, qui pourraient, dans l’agilité ou dans la maturité, trouver les moyens d’améliorer leurs propres pratiques, de combler leurs lacunes et faiblesses….

Succés
Dans le prolongement du point précédent, de récents retours d’expérience nous ont prouvé l’efficacité, que dire, le succès de la combinaison des méthodes Agile et du CMMI. Ensemble on est plus forts, c’est le message que fait passer Jeff Sutherland et dont je suis entièrement convaincu !

Si à votre tour, vous voyez d’autres « motivations », n’hésitez pas à nous les faire partager…

Gestion des risques: mieux vaut être AGILE

Posté par jc-QualityStreet le 10 septembre 2007

Les Méthodes Agiles et  le Processus Unifié ne se contentent pas d’une gestion “classique” des risques; ils approchent les risques d’un projet informatique de manière beaucoup plus offensive, à la fois en termes de considération et de traitement: le projet est entièrement organisé pour lever au plus vite les risques les plus forts, ceux menaçant le plus de compromettre la bonne marche du projet.

Savoir gérer les risques est une bonne pratique de gestion de projet enseignée déjà depuis bien des années … alors pourquoi vous en parler aujourd’hui ?

• Parce que le Processus Unifié surtout et l’Agilité ont redonné au risque une place de choix : les risques pilotent le projet (du moins pour le Processus Unifié), le contenu des itérations, et impactent donc l’activité de chacun d’entre nous (du développeur au testeur, de l’ergonome au Client ….).
• Parce que les bonnes pratiques Agiles, issues de SCRUM ou XP (courtes itérations, livraison incrémentale, daily scrums, reporting visuel, intégration continue, feedback client …) sont des armes redoutables pour faire face aux risques inhérents à tout projet informatique
• Parce que sur terrain, l’analyse des risques doit être conduite dans cette finalité, ce qui nécessite une véritable prise de conscience … Place à l’offensive (c’est là qu’elle prend tout son sens), n’y allons pas à reculons, ou simplement parce que le PMI nous dit de le faire ou que c’est un domaine de processus du CMMI !
• Parce qu’on sous estime (voire néglige) toujours des activités majeurs : Surveiller, Suivre et réajuster, Communiquer, Capitaliser pour les autres projets. Dans mon organisation, le pilotage par les risques (l’un des 6 principes du Processus Unifié) a été perçu comme un point fort; l’analyse a selon les cas été bien menée, servant de base à une priorisation des dév. (après arbitrage), malheureusement la suite n’a pas toujours suivi, sans parler de la base de risques, inexistante !! A nous d’aller jusqu’au bout et de s’en donner les moyens …
• Et parce qu’au final, la gestion des risques s’applique partout : petit ou gros projets, informatique ou non, comme le suggère la définition de l’AFNOR (« Un risque est un événement dont l’apparition n’est pas certaine et dont l’apparition est susceptible d’affecter les objectifs du projet »)

Bon, allons à l’essentiel, et glissons-nous un instant dans la peau de notre Chef de Projet Agile …
La gestion des risques sera partagée par l’équipe mais tout de même sous ma responsabilité… Je vais tout d’abord user et abuser du RISK BOARD tout au long du projet. Pour le rest dans les grandes lignes:

1. Je mène l’analyse des risques de mon projet (sur la base de check-list, celle du SEI par exemple, grilles, critères, brainstorming …), évidemment pas tout seul en m’appuyant sur l’expertise de mes collègues techniques et analystes, sans qui je ne suis rien ! Je m’aide aussi de ces 5 catégories de risque pour y voir plus clair : Client / Organisation du projet / Métier (et fonctionnel) / Technique (et technologique) / Fournisseur (pratique quand on a des sous traitants).
2. Très vite, et grâce au concours de mes collègues experts et de l’équipe, je valorise les risques en termes de Sévérité de l’Impact (délais, coûts, qualité…) et Probabilité d’apparition, ce qui me donne pour chaque risque un indicateur (une note) de criticité. C’est très classique.
3. Je documente ensuite une fiche de risque, disons pour les 8 à 10 risques majeurs ; risques que je suivrai tout particulièrement. C’est à ce moment que je vais consulter mon responsable des tests car sa stratégie de tests sera impactée.
4. Je veille ensuite à ce que les risques ne se transforment pas en problème, organise mon projet pour « lever » au plus vite les risques majeurs (en traitant par ex. en priorité les use cases / user stories contenant les éléments les plus risqués), utilise les bonnes pratiques Agiles les plus appropriées (côté technique, côté test, ou côté gestion de projet) et choisis plus globalement d’appliquer à mes risques l’une des 3 stratégies suivantes : Evitement, Transfert (autres équipes, autres projets ….) ou Acceptation (provisoirement en cherchant à réduire son impact, sa probabilité d’apparition ou définitivement si son impact est faible; le cas échéant, je passe au plan de secours)
5. Je surveille, effectue le suivi et réajuste ma liste de risques … estimation et planification des itérations … arbitrages mais aussi feedback, rétrospective et adaptation ; toutes ces pratiques garderont le risque au coeur des préoccupations de mon équipe.
6. Je mets à jour ma liste des risques et communique (notamment auprés de mon équipe) sur ceux-ci à chaque début et fin d’itération, et chaque jalon important ; communication verbale et écrite … Sans compter mes scrums tous les 2 ou 3 jours où ils sont régulièrement évoqués : en quoi puis-je t’aider ? .
7. Mon projet se termine, je capitalise : la destinée de mes risques fut variable mais je les ai tracés, j’ai récolté de précieux indicateurs … et je commence à me constituer une base de risques disponible pour les projets suivants.

Au final: de l’AGILITE avec anticipation des difficultés et des points bloquants, maîtrise rassurante du projet et de ses évolutions, atteinte des objectifs, mais aussi une démarche disciplinée, définie et maîtrisée telle qu’attendue par le CMMI entre autres dans les domaines de processus suivants (PP, Planification du projet ; PMC, Surveillance et contrôle du projet ; RSKM, Gestion des risques).