Coopérer : travailler mieux pour vivre mieux ?
Tout est dit dans le titre ! Voila une étude internationale qui va s’intéresser aux effets de la coopération sur les conditions de travail, et leurs répercussions sur les comportements citoyens, la performance, les réactions de stress et de burnout.
Pour cela, il suffit de répondre au questionnaire ici (en anglais).
Les résultats devraient permettre d’en savoir un peu plus sur le sujet, peu exploité, de la coopération. Ca devrait aussi permettre de répondre a la question : les équipes agiles sont-elles vraiment plus coopératives ? Quelles conséquences pour les collaborateurs ?
Vous avez un avis sur la question ? Ca m’intéresse !
Comment libérer les projets du triangle de fer
Lorsque je fais le point avec un client sur la situation de son organisation, on en arrive souvent à faire un même constat : les équipes sont à fond en production, cravachent dur pour livrer tout ce qui est dans le cahier des charges et tenir les délais. Trop de fonctionnalités, trop peu de temps… des previsions ne seraient-ce qu’un peu depassées et les marges diminuent… Ce n’est pas l’envie qui manque de developper d’autres axes, mais le temps manque tout simplement. On est pris dans le triangle de fer !
Le triangle de fer
Parmi les décideurs d’un projet, chacune des parties prenantes a une perspective différente sur le projet : * la perspective financière qui cherche à obtenir un produit/système à moindre coût, * la perspective managériale dont le but est de respecter les délais et de manager les personnes. Cela se résume dans la figure suivante, dite du “triangle de fer”.
La réussite d’un projet repose donc sur la satisfaction de ces trois critères : livrer l’ensemble des fonctionnalités, dans les délais et au budget prévu.
Faire varier les ressources ?
Ce triangle est qualifié de triangle de fer car il ne peut évoluer. Un projet doit aboutir dans les délais en livrant l’ensemble des fonctionnalités. Classiquement, la seule variable d’adaptation sur laquelle on peut jouer passe donc par l’ajustement des ressources.
Si les délais et le périmètre sont fixes et que le projet prend du retard, on peut alors avoir l’impression qu’assigner des personnes supplémentaires permettra de résoudre les problèmes et de livrer dans les temps. C’est le genre de solution d’autant plus facile lorsque l’on dispose d’une ressource abondante (et les mauvaises langues diront corvéable à merci =;]) : on rajoute des stagiaires. Toutefois, cette approche a des limites. Comme on dit : “9 femmes ne peuvent avoir un enfant en 1 mois” .
On sait, notamment depuis le livre “Mythical Man-Month” de Brooks que le fait de rajouter des personnes sur un projet en retard est d’ailleurs avant tout une source de complexification et d’échec des projets. Comme il le dit lui-même “Adding people to a late project makes it later.”
“Rajouter des personnes sur un projet en retard ne fait que le retarder d’avantage.”
Ca parait bête à dire, mai les ressources humaines ne sont pas interchangeables. Ou alors seulement dans le cas de projets sans vraies contraintes de ressources, de délais ou de complexité.
Une dimension cachée : la qualité
Le triangle de fer contient une dimension cachée, implicite : la qualité. Ce n’est plus un triangle : c’est une pyramide ! Autant il est facile de quantifier les ressources, de surveiller les délais ou de lister les fonctionnalités, autant pour évaluer et garantir la qualité d’un projet informatique, on entre dans l’irrationnel, les cncantations vaudoues, les rituels mysterieux…
“Pourvu que ca tienne !”
C’est regrettable à dire, mais dans le monde logiciel : la qualité tend à être un élément à part des fonctionnalités. Parlez à un client de qualité et il vous dira qu’il la veut… mais sans être prêt à en payer le prix. Si l’on cherche à figer à la fois les délais, les coûts et le périmètre d’un projet, on ne dispose d’aucune marge de manoeuvre et on risque vite être déçu. Quand les échéances se rapprochent et que les budgets explosent, on a plus aucune marge de manoeuvre et c’est justement elle la première victime : la qualité.
Autant se tirer une balle dans le pied. A long terme, c’est le genre de situation synonyme d’un client insatisfait car les méchantes bestioles (1 et 2) refont toujours surface! Tant qu’on est sur une note humoristique, Mike Vizdos lui aussi aborde le sujet avec ses cartoons.
La dimension humaine
Comment tenir les délais en essayant de ne pas trop bâcler la qualité, si l’on ne tombe pas dans le piège de rajouter du monde dans l’équipe ou tout simplement lorsque l’on ne dispose pas de personnes supplémentaires à mobiliser ? En fournissant ‘un dernier coup de fouet’… ‘en se mobilisant’… ‘en faisant le forcing’…
C’est le genre de comportement courant, voire même valorisé ! Il faudrait presque ériger un monument à la mémoire des héros infatigables qui à grands renforts de café tapote sur leurs claviers des nuits entières et livrent l’oeil hagard une application impeccable au petit matin…
Nous le savons tous, ce n’est jamais un bon présage sur le plan de la qualité. Ni à long terme pour l’ambiance et l’épanouissement au travail…
Comment s’en sortir ?
Comme nous le rappelle Alistair Cockburn, il y a une dimension supplémentaire : le processus. Comment donc s’en sortir ? Grâce à une approche agile bien sur.
Etre agile : “Cheating legally to win” !
Le point essentiel est de se débarrasser du “Big Design Up-Front”, qui consiste à recueillir l’ensemble des besoins avant la conception et le développement. C’est un aspect que j’avais aborde précédemment et que je risque de répéter…
L’approche agile propose à la place de privilégier un raffinement progressif des besoins en s’appuyant sur des discussions fréquentes. On recueille juste ce qu’il faut de besoins et on développe les fonctionnalités correspondantes pour obtenir un feedback rapide sur une application fonctionnelle.
On prend ainsi en compte le fait que les besoins évoluent fatalement non seulement en même temps que l’environnement métier ou le marché, mais surtout avec la connaissance que l’on acquière au fur et à mesure du projet.
Pire, prendre en compte l’ensemble des exigences dans une même livraison, c’est courir droit vers l’explosion des besoins. Cela revient au mieux à livrer des fonctionnalités inutiles. Au pire, à ne rien livrer, parce que l’on est tout simplement débordé.
Voila pour aujourd’hui. Je répondrais dans la deuxième partie à la question : comment l’agilité aide-t-elle concrètement dans tout ça ?
Methodes Agiles et Design d’interaction
J’ai fait Mardi dernier pour Designers Interactifs une présentation que j’avais annoncée dans un précédent billet sur les méthodes agiles et le design d’interaction.
Le public était varié puisque l’on y trouvait des directeurs artistiques, développeurs et graphistes. Dont certains qui avaient déjà entendu parler de l’agilité. Il y avait même quelques pratiquants dans l’assemblée. La présentation avait plusieurs objectifs.
Tout d’abord montrer les problèmes que soulèvent les pratiques classiques de gestion de projet et ce qu’apporte l’approche agile. Ensuite montrer les points communs avec le Design centré utilisateur : approche centre sur le client, importance des tests et du feedback utilisateur.
Mais aussi montrer les changements de comportement que ça implique. Le principal est d’abandonner le fonctionnement traditionnel par phases pour une approche itérative ou le produit est progressivement raffiné. Enfin donner une idée des pratiques agiles qui peuvent être mises à profit par les designers interactifs pour évoluer. C’était presque un manifeste pour une ergonomie agile.
La présentation est disponible sur slideshare en slidecast, c’est a dire avec une bande son qui l’accompagne. Seul petit hic, en ce moment il ne fait pas bon courir dans les bois pendant des heures sous la grêle et ma voix n’est donc pas des plus claires… Pour ceux qui veulent creuser un peu la question de l’utilisabilite agile, Scott Ambler en donne un bon apercu.
J’étais très curieux à la fois de l’accueil que pourrais recevoir une telle présentation et des échanges qui pouvaient s’ensuivre et je n’ai pas été déçu. On a eu des témoignages, avec notamment celui d’une graphiste qui travaille dans une équipe XP avec une itération d’avance par rapport aux développeurs et à qui l’approche agile semblait très naturelle.
On a aussi abordé les obstacles que chacun pouvait voir à passer à une approche agile. Celui qui est le plus revenu est celui de l’implication des clients non matures : - des clients qui ne s’impliquent pas dans la boucle, - une perspective client bicéphale, - des clients qui veulent se décharger de toute responsabilité, - des clients qui veulent tout, tout de suite…
C’est vrai, l’approche agile demande d’éduquer le client, de lui faire comprendre qu’on ne peut avoir le beurre et l’argent du beurre : un produit qui me correspond, mais sans m’impliquer… Toutes les fonctionnalités, maintenant ! Pour ça, il faut mettre en place les choses progressivement, en lui donnant une visibilité sur l’avancement, en l’assistant pour piloter le projet par la valeur, et surtout en effectuant des livraisons fréquentes de produit bien concret.
Viens ensuite l’inévitable question des contrats. J’aurais d’ailleurs pensé que cette question se serait invité au débat avec plus d’ardeur, je suis positivement étonné. En effet, les participants n’était pas trop inquiets à l’idée de fonctionner par lot.
Bref, un accueil très positif. Certains seraient même conquis par l’agilité et pourtant, je n’ai pas parle de télépathie…
Mettre les exigences en boite
Dave Nicolett nous présente une méthode très intéressante pour structurer l’expression des besoins dans une approche agile, sous forme de user-stories ou scénarios. Je préfère utiliser ce dernier terme car à mon sens plus pratique et évocateur.
L’idée est d’organiser le déroulement d’une interview client en 9 étapes successives, de façon à cerner l’ensemble des facettes des scénarios envisagés. On voit ça dans le schéma ci-dessous, retranscrit à ma manière.
On définit ainsi le problème, puis qui il affecte, puis comment serait la situation une fois le problème résolu (sans présager de la manière de le résoudre).
On retrouve ce principe de se projeter dans l’avenir dans l’exercice que j’aime bien utiliser Design the Box ou on imagine le produit une fois réalisé (Décidément on parle beaucoup de “box” !). Dans le même style, Claude Aubry évoquait récemment Remember the future qui fonctionne sur les mêmes principes.
Revenons à nos moutons. Pour chacune des facettes, l’interview pose trois types de questions. D’abord des questions ouvertes pour dégrossir le problème et découvrir les préoccupe sous-jacentes. Ensuite, on essaie de quantifier les choses et enfin on s’assure que l’on a bien saisi en reformulant. C’est l’occasion de se rendre compte s’il y a des éléments à préciser auquel cas on revient en arrière. Et en plus, comme on le voit dans le schéma, cette technique permet justement de faire ressortir les besoins non fonctionnels.
On a alors tout ce qu’il faut pour exprimer directement notre scénario. Dave Nicolett envisage de les exprimer sous leur forme “canonique” :
"As a <role> I want to<action> so that <value>."
Ce qui donne en français
"Comme <rôle>, je veux <action>, de façon a <valeur>."
Personnellement, j’énonce les scénarios différemment et c’est justement ce qui m’a marque dans cette technique, c’est qu’il suffit de prendre les colonnes dans l’ordre pour les formuler sous la forme :
"Pour <valeur>, comme <rôle>, je veux <action>."
On a ainsi une expression des scénarios explicitement 1. conduite par la valeur, 2. centrée sur l’utilisateur et 3. independant de la solution ou des taches.
C’est justement tout l’intérêt d’exprimer ses besoins au moyen de scénarios ! Reste en plus à le faire de manière itérative, selon un raffinement progressif qui l’imite l’inventaire…
Présentation - méthodes agiles et design d’interaction
Je ferai une présentation sur les méthodes agiles le 4 Décembre prochain au Cafe Dune de 20h à 21h30 dans le cadre des Designers Interactifs.
“Un cahier des charges respecté mais un client pas 100% convaincu… La motivation et la créativité engluées dans le ventre mou des projets qui s’allongent… Un marché, des besoins, des technologies, des usages en évolution constante…”
Voila quelques-uns des problèmes que cherchent à résoudre les méthodes agiles par une approche basée sur la collaboration et des livraisons rapides et régulières au client.
Cette présentation dressera donc un aperçu des méthodes agiles, des valeurs qu’elles mettent en avant et des pratiques sur lesquelles elles reposent. Elle devrait être l’occasion d’engager un débat autour des questions telles que : - la place du design d’interaction au sein des projets - la collaboration au sein des equipes et avec le client, - les rapports entre expérience utilisateur et feedback, - la relation entre livrables et valeur produit.
Elle s’adresse a tous ceux - DA, webdesigner, chef de projet - qui souhaite échanger sur leurs expériences et pratiques en matière de conception centrée utilisateur et conduite de projet ou tout simplement découvrir de nouvelles perspectives. N’hésitez donc pas d’ici la à faire part en commentaires de vos questions, attentes ou témoignages pour rendre l’échange le plus interactif et fructueux !
Wireframes, fidelite et feedback
J’ai assisté la semaine dernière à la présentation faite par Eric di Pol pour Designers Interactifs sur l’utilisation des wireframes. Il a commencé par nous introduire quels utilisations ceux-ci avaient, selon deux axes : le support et le degré de fidélité.
- Premier axe : soit un support print, plutôt pour de la documentation. Soit à l’opposé, une utilisation logicielle pour simuler et valider.
- Second axe : la fidélité, qui va de lofi à hifi, basse et haute fidélité. D’un cote des wireframes haute-fidélité, sensés être très proches du produit final et en donner une bonne idée. Et à l’opposé des wireframes lo-fi, beaucoup moins fidèles au produit final.
Cela étant dit, en fait la question primordiale est : dans quel but utiliser des wireframes. Est-ce que le but est juste de documenter ou est-ce que le but c’est de simuler et valider avec le client ? Seconde question à propos de la validation : est-ce pour une validation a priori ou comme référence a posteriori ?
On a donc une matrice à deux entrées avec 4 perspectives différentes, qui permettent d’essayer de répondre à cette question : des wireframes pour quoi faire ?
La première de ces perspectives c’est l’usage de wireframe haute-fidélité pour le print : on investi beaucoup de temps pour quelque chose de fidèle que l’on va pouvoir montrer mais qui ne permet aucune simulation.
A l’opposé dans la matrice, on va avoir le lofi logiciel qui permet , grace à des bibliothèques de widgets, assez facilement de concevoir mais pas de simuler. Quel investissement en temps cela demande-t-il de faire du lofi logiciel, au regard de l’utilité et des bénéfices ?…
Cette même question se pose pour du hi-fi logiciel, ou l’on pousse le réalisme avec des widgets précis et un comportement réaliste, notamment dans l’enchaînement des pages. Et la, il me semble que l’on atteint un paradoxe en passant du temps avec des outils cela dit très bien fait. Eric nous a d’ailleurs montré les avantages de Visio et la puissance d’Axure pour arriver à pousser très loin le réalisme. Puissance qui va jusqu’à générer une documentation. Ces deux outils sont largement repandus et tres utilises puisque l’on en parle partout, de GUUUI à Quality Street récemment.
On a donc un investissement important lié à l’utilisation d’outils pour la production de ces wireframes et en retour ça nous permet à la fois de simuler et de générer une spécification presque fonctionnelle. “Presque”, c’est la le problème. Reste au produit final à respecter cette spécification très poussée !
Mon avis sur la question, c’est que l’on a un outil qui permet de figer des le départ cette spécification très propre et les moyens d’obtenir une documentation qui permet l’accord contractuel du client. Le problème, c’est que, même s’il est puissant et relativement convivial, cet outil demande une certaine maîtrise, ce qui exclut de travailler avec le client de façon collaborative.
On est loin d’une perspective agile : on se situe bien dans le cadre d’une approche classique à phases distinctes et faibles espaces de feedback entre client/designer d’interaction/chef de projet/développeurs. L’accent est mis sur un document plutôt que sur une interface directement fonctionnelle comme élément de specification.
Reste le dernier point, à mon sens le plus intéressant, et qui s’inscrit parfaitement dans une approche agile basée sur l’interaction avec le client et des itérations courtes : le lofi non logiciel ou prototypage papier, décrit par Carolyn Snyder. Dans l’idée de cette dernière, si l’on construit un prototype, c’est pour le tester avec des clients. Le principe, c’est au contraire d’investir relativement peu dans le support en restant dans la basse fidélité. On dispose ainsi d’outils appropriables par tous : papier, postits, tableaux blancs avec lesquels il est facile de simuler en changeant de post-its et d’annoter pour le client.
Ces propriétés sont très utiles dans une séance de travail conjointe entre maîtrise d’oeuvre et maîtrise d’ouvrage : on peut facilement interagir avec le client sans faire de supposition sur la forme finale. Celle-ci n’est donc pas décidée par un architecte dans sa tour d’ivoire mais dépendra des technologies et compétences utilisées par celui qui implémente : on fait du push).
Il est ainsi plus facile de faire comprendre à l’utilisateur que ce que l’on cherche à valider, c’est le workflow et les fonctionnalités globales et non l’apparence précise. Cela suppose que le développeur soit implique pour “contraindre” en fonction de ce qui est possible ou non, selon les technologies employées. Ca ne pose pas de problème si l’on est en mesure de faire fréquemment des démonstrations au client du produit fonctionnel. L’étape de réalisation est donc “encadrée” par deux occasions de collaboration avec le client : une séance de travail de prototypage papier et une séance de démo. Quand le client ou son proxy n’est pas sur site avec les développeurs ! Voire…
Je n’ai parlé que des aspects fonctionnels et pas des aspects purement graphiques, que l’on perd justement avec le prototypage papier. Il est pour cela intéressant de travailler sur l’identité graphique dans un premier stade avec des planches de tendance et par la suite directement avec une interface fonctionnelle. On différencie ainsi, comme le fait Garrett dans The Elements of User Experience, les aspects lies au périmètre fonctionnel, à la structure et au squelette d’une part et ceux lies à la surface d’autre part. Mais, c’est un sujet à part entière qui nécessitera d’autres articles.
Pour résumer, l’avantage du prototypage papier, c’est d’avoir un outil qui permet de valider facilement avec le client, à moindre coût et rapidement.
Scrum en 69 mots
A partir d’une discussion sur la liste ScrumDev (en) [1] est nee l’idée de décrire Scrum en 100 mots. Claude Aubry en propose d’ailleurs une définition en français sur son blog [2]. Sans assister pour autant à une course à la miniaturisation, en voila un résumé encore un peu plus succinct, mais je l’espère représentatif et suffisamment complet, qui peut servir d’”Elevator Pitch”.
> Scrum est un processus léger permettant de gérer et de contrôler le développement de produits logiciels. Mettant en oeuvre des pratiques incrémentales, Scrum est une méthode efficace, qui met l’accent sur la qualité et les exigences du client en se recentrant sur les personnes et leurs interactions. C’est l’une des méthodes agiles les plus employées, car elle permet d’améliorer notablement la productivité tout en accélérant le retour sur investissement.
Donc, si vous avez à parler de Scrum en coup de vent à quelqu’un qui s’interroge dessus mais qui file en réunion et n’a pas le temps, vous arriverez peut-être à placer 69 mots…
Liens :
Qu’est-ce que l’agilité ?
Le coeur de l’agilité :
- des livraisons régulières, fiables et dans les temps, gràce à des itérations courtes.
- délivrer les fonctionnalités les plus prioritaires, gràce à une collaboration entre Responsable Produit et Equipe
- amélioration continue du processus gràce au retour de chacun
L’objectif des méthodes agiles est de concilier satisfaction du client et de l’equipe de développement. L’agilité c’est avant tout faire les choses importantes en premier, par petites étapes, en apprenant et en s’améliorant au fur et à mesure. L’agilité suit 4 valeurs clés énoncées dans le Manifeste Agile, elles-mêmes déclinées en un ensemble de 12 principes.
Les individus et les interactions priment sur les processus et les outils.
Les méthodes agiles mettent l’accent sur la transparence et la visibilité, de facon à avoir une progression robuste et saine. Saine parce qu’elle s’effectue dans un climat favorable à la coopération de tous en direction d’un but commun. Robuste, car elle met l’accent sur les capacités de l’équipe polyvalente dans son ensemble plutôt que de reposer sur les épaules d’individus séparés aux compétences ultra pointues. Cela suppose aussi d’adopter un rythme soutenable par tous à long terme.
Le logiciel fonctionnel prime sur la documentation exhaustive.
A quoi sert d’établir des documents de conception à rallonge lorsqu’on se rend compte après coup qu’ils ne correspondent pas aux besoins effectifs du client ? Les approches classiques très prescriptives tendent à enfermer l’ensemble des acteurs dans des processus lourds, au détriment de la production effective de logiciel utilisable. Les méthodes agiles adoptent une approche très pragmatique en disant que la production de documentation doit mettre d’avantage l’accent sur tout ce qui permet le transfert des connaissances au sein de l’équipe se limiter à ce qui est juste nécessaire et suffisant.
La collaboration avec le client prime sur la négociation contractuelle.
Il s’agit de travailler en étroite collaboration entre celui en mesure de juger de la valeur du produit realise et ceux en mesure de le développer. Le client apporte donc un feedback régulier à l’équipe de développement et peut suivre la progression. Cela permet de privilégier les attentes réelles du client par rapport aux documents contractuels vite dépassés par la réalité du terrain. Cela nécessite une approche responsable des différentes parties autour de la table, pas toujours facile à établir car basée sur une véritable relation de confiance.
La réponse aux changements prime sur le suivi d’un plan.
Que ce soit le client ou l’équipe de développement, tout le monde a intérêt à ce que le planning soit flexible, pour pouvoir répondre aux changements provenant du contexte métier, d’évolutions des priorités ou des attentes client, mais aussi de l’utilisation de technologies novatrices.
Principes agiles
Les 4 valeurs énoncées dans le Manifeste Agile se déclinent en 12 principes généraux communs à toutes les méthodes agiles :
Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
Les responsables métiers et les développeurs doivent collaborer quotidiennement au projet.
Batissez le projet autour de personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
La méthode la plus efficace pour transmettre l’information est une conversation en face à face.
Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent.
Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
La simplicité - l’art de maximiser la quantité de travail à ne pas faire - est essentielle.
À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.
Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
Livrer fréquemment une application fonctionnelle, de toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte.
Manifeste agile
En 2001, 17 grands noms de l’informatique (parmi lesquels Martin Fowler et Ward Cunningham, l’inventeur du wiki) et spécialistes des méthodes de développement logiciel se rassemblent pour échanger leurs points de vue et leurs expériences. C’est d’abord un constat commun de refus des méthodologies lourdes qui dominent le monde informatique et qui expliquent en grande partie la crise que connait le milieu. Au delà de ce constat, ils caractérisent pour la première fois leurs pratiques sous un terme commun : des méthodes “agiles”. De cette rencontre naîtra le Manifeste Agile, véritable cri de ralliement pour la défense d’un certain nombre de valeurs, certes évidentes mais rarement appliquées en pratique.
Nous avons découvert de meilleures manière de développer du logiciel par la pratique et en aidant les autres. A travers ce travail, nous en sommes arrivés à valoriser : - Les individus et les interactions priment sur les processus et les outils - Le logiciel fonctionnel prime sur la documentation exhaustive - La collaboration avec le client prime sur la négociation contractuelle - La réponse aux changements prime sur le suivi d’un plan Bien qu’il y ait de la valeur dans les éléments de droite, nous valorisons d’avantage les éléments de gauche.
