Problème : bien souvent, ces solutions Cloud sont une boîte noire et au-delà de la facture correspondant aux ressources utilisées, il est à minima difficile d’en savoir plus sur la façon dont fonctionnent les fournisseurs de service Cloud, notamment sur le sujet du green IT. Parce que oui, si vous passez des heures à retravailler et limiter vos requêtes, que vos fonctionnalités sont sobres mais que l’hébergement Cloud que vous utilisez a pour principale source d’énergie une centrale à charbon, c’est pour le moins dommage. De même, si vos instances sont montées en permanence alors qu’elles connaissent des périodes de moindre utilisation (voire d’absence totale), on perd un peu de l’intérêt du green IT. Et enfin, il n’est pas toujours facile de se faire entendre sur ces questions, surtout quand les objectifs (de sprint, de produit, de politique d’entreprise) sont plus focalisés sur la performance économique que sur la préservation de la planète. 

Aujourd’hui, l’objectif est donc d’aborder ces différents sujets. D’une part, comment améliorer la consommation de ressources d’un cluster Cloud et de l’autre, comment adapter les KPI traditionnels, prisés par les directions financières, afin de les mettre au service d’une cause plus grande.

« C’est pas Versailles ici », ou comment optimiser son Cloud

Si la lecture du titre de cette partie vous a rappelé des souvenirs ou que vous vous êtes vous-même surpris ou surprise à prononcer ces mots, ces quelques paragraphes devraient vous parler. En effet, alors qu’on éteint la lumière lorsqu’on quitte une pièce, comment justifier de laisser des ressources informatiques allumées en continu, même lorsqu’elles ne sont pas utilisées ? Prenons l’exemple de vos environnements de recette et de développement : en dehors des heures de bureau, y a-t-il le moindre intérêt à les faire fonctionner, si ce n’est brûler (littéralement) du gaz et remplir les poches de Google et Amazon ? Des améliorations concrètes et rapides sont donc faciles à aller chercher (dans un premier temps). C’est le service que propose Kube-green, plug-in rapide à mettre en place (en 30 minutes c’est largement fait) et diablement efficace. Dans l’exemple qu’on trouve dans leur documentation, la mise en place d’une gestion très simple d’un cluster permet de réduire de près de 30% les émissions de gaz à effet de serre (GES) et jusqu’à 37% sur un cluster plus important. Rendez-vous compte : cela fait plus d’un tiers d’économie en quelques réglages. 

Remarque : le calcul de l’empreinte carbone se base sur un article rédigé par GoClimate et qui donne des estimations en fonction du type d’hébergement choisi.

OK, qu’est-ce que ça donne concrètement ?

Pour le tester, j’ai démarré un cluster Kubernetes en local, sur lequel j’ai créé un namespace, au sein duquel j’ai déployé une API, un front et une base de données. Ensuite, il m’a de lancer cette commande :

kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml

Après quelques secondes, Kube-green était déployé dans mon cluster, au niveau global. J’ai ensuite appliqué ce fichier, dans le même namespace où j’ai déployé mes applications.

apiVersion: kube-green.com/v1alpha1
kind: SleepInfo 
metadata: 
  name: sleep-test 
  Namespace: app-example 
spec: 
  weekdays: "*" 
  sleepAt: "*:*/5" 
  wakeUpAt: "*:*/7"

Dans celui-ci est écrit que je souhaite scale down tous les déploiements de ce namespace, tous les jours, à chaque 5ème minute de chaque heure et de la même manière, scale up à chaque 7ème minute (l’exemple n’a pas vraiment de sens, il s’agit là plutôt d’illustrer la syntaxe, il y a évidemment d’autres manières de configurer cette partie). On peut décider d’ignorer certaines ressources, ou de stopper également ou uniquement des cronjobs. Vous pouvez trouver ces informations dans la doc de Kube-green, que l’on peut remercier pour sa clarté. Si on observe les Pods du namespace ,on voit bien qu’ils se coupent et s’allument comme désiré :

Certes, cette solution n’est qu’un début, mais pourquoi ne pas aller plus loin ? On peut imaginer répliquer ce système pour ajouter les jours fériés, les pauses-repas, et ensuite en production, en adaptant le nombre de nœuds disponibles en fonction de l’activité prévue.

Il existe encore d’autres solutions, comme KEDA, qui permettent d’être encore plus flexible dans les choix de scalabilité. Cet outil, en plus de reprendre les fonctionnalités de Kube-green, permet d’allumer et d’éteindre nos composants Kubernetes en suivant des métriques que vous pouvez personnaliser à volonté, au lieu de vous baser sur des métriques classiques, comme le niveau d’activité du CPU ou de la RAM. On peut imaginer scale sur un indicateur qui mesure le trafic, ou bien qui va chercher des informations en base de données. Par exemple une quantité de data à intégrer, ou encore une métrique personnalisée qui remonterait la consommation en euros (ou en CO2 ?) pour les limiter. KEDA est certes plus compliqué à mettre en place et à tester mais il vaut le coup qu’on s’y intéresse.

C’est bien beau vos histoires mais comment je vends ça moi ?

Ce qui est certain c’est qu’aujourd’hui les directions financières ont un objectif sur les questions d’argent plutôt que sur celles de la biodiversité ou de la sobriété énergétique (et en même temps, tant qu’on les appellera des directions financières…). C’est pour ça qu’il va falloir ruser : plutôt que de mentionner la diminution du bilan carbone de votre application, il vaudra toujours mieux mettre en avant la baisse de la facture de votre infrastructure (forcément, si on utilise moins de ressources, on émet moins de GES et on paie moins cher). En revanche, pour donner un objectif à vos équipes sensibles à ces questions, d’autres outils existent et notamment Kube Carbon.

Introduit en 2019 par Adam Hevenor, cet outil permet facilement de générer des courbes et des métriques suivant les émissions de GES de votre activité. Dans un article partagé sur Medium, il détaille son calcul de manière à faire le lien entre volume d’opérations informatiques et émission de gaz à effet de serre. La méthodologie n’est pas parfaite, et certains chiffres mériteraient sans doute d’être revus (la publication date déjà d’octobre 2019), mais elle explore néanmoins les différentes questions qui se posent à l’heure où l’usage du Cloud se démocratise. Quelle est l’empreinte carbone des services Cloud de Google ou d’Amazon ? Les deux vous répondront qu’ils sont neutres en carbone mais ce tour de passe-passe n’est possible que grâce à l’achat de crédits carbone et autres compensations, le tout sans avoir la moindre transparence concernant les volumes d’équivalent CO2 produits. C’est d’ailleurs la conclusion de l’article d’Adam qui appelle de ses vœux les grands du Cloud à plus de transparence sur ces questions (d’ailleurs ils pourraient intégrer à leur service le même type de graphes de façon native). Surtout, dans une période qui appelle à la sobriété, tout ce qu’il n’est pas nécessaire de compenser est bon à prendre.

Kube Carbon a donc cet avantage de fournir une vision chiffrée de votre impact carbone, avec pour objectif de devenir un indicateur important pour l’ensemble des acteurs.

OK, vous pouvez me refaire un topo pratique aux petits oignons comme pour Kube-green ?

Kube Carbon, techniquement, se résume à un dashboard Grafana, qui, dans l’état, ne fait que prendre des métriques, les transformer et nous les afficher. Ce qu’il faut retenir c’est la réflexion qu’a eu Adam Hevenor autour de ces indicateurs. Pour mieux me rendre compte de ce que cela représente, j’ai quand même déployé Prometheus, Grafana et importé ce dashboard.

Toujours sur mon cluster k8s local, j’ai exécuté ces commandes :

// create dedicated namespace and switch to it 
k create ns prometheus 
kubens prometheus 
// helm install for prometheus & grafana 
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts  
helm repo update 
helm install prometheus prometheus-community/prometheus 
helm repo add grafana https://grafana.github.io/helm-charts  
helm repo update 
// Expose grafana svc to local access 
kubectl expose service grafana --type=NodePort --target-port=3000 --name=grafana-ext 
// Get svc port for access

// Get secret data to log in grafana 
k get secret  grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

sum(container_cpu_usage_seconds_total * (.001/$flops_per_watt*$carbon_per_watt*$clock_speed)) / 1000000000

L’article Du green dans ton Cloud est apparu en premier sur EKITE.

La crise sanitaire, le dérèglement climatique, l’émergence des intelligences artificielles, sont autant de facteurs extérieurs qui peuvent avoir un impact plus ou moins direct sur nos modes d’organisation (entre autres). Quels impacts ont-ils déjà ou vont-ils avoir sur ces derniers ? C’est ce que nous essaierons d’explorer dans ce billet.

De nouveaux frameworks ?

Alors que Scrum a mis l’Agilité au centre des débats en lui donnant une forme accessible quasi immédiatement, s’imposant comme un incontournable pour toute personne souhaitant intégrer des composantes agiles ou s’y former, il a désormais beaucoup moins la cote. Trop rigide, difficile à mettre intégralement en pratique, les alternatives ont fleuri et nous voyons désormais des concurrents radicalement différents. Nous avons déjà eu l’occasion de vous parler de FAST ou du Shape Up, qui sont elles-mêmes des façons de faire très différentes et qui préfigurent de la capacité de toutes et tous de proposer des renouvellements très éloignés des paradigmes habituels. Nous pourrions également mentionner Unfix (https://coach-agile.com/2022/10/unfix-model-cest-quoi/) que nous n’avons pas encore explorée, ou les topologies d’organisation (https://www.orgtopologies.com/).

Quelle sera la suite ? Verrons-nous de nouvelles façons de faire encore plus originales (spoiler : oui) ?

Crises sanitaires, dérèglement climatique et adaptation

Depuis 2020, la crise sanitaire a eu de nombreux impacts. Au-delà du drame humain qu’elle représente (force aux familles des victimes, au personnel soignant et aux travailleurs et travailleuses essentiels), elle a contribué à normaliser le travail à distance dans les métiers où il est possible. Ces changements ont nécessité des adaptations mais sont désormais largement acceptés et font même partie des demandes légitimes des salariés et des salariées. Les organisations ont déjà commencé à s’y adapter comme le rapporte l’article Remote Agile: Problems, solutions, and pitfalls to avoid, qui prend l’exemple d’une entreprise financière pour décrire les difficultés rencontrées et les solutions apportées, comme par exemple la démultiplication des réunions et la façon de les gérer. Pour autant, tout le monde n’est pas encore convaincu même s’il semble que la démocratisation du travail à distance s’imposera à terme comme un indispensable de nos industries numériques.

De même, le dérèglement climatique et l’explosion des inégalités nous obligent à revoir nos modèles. Après plusieurs dizaines d’années à faire la sourde oreille, il n’est désormais plus possible de ne pas faire le constat des conséquences de l’activité humaine. Il est aujourd’hui encore trop tôt pour observer les impacts de ces changements sur nos métiers, sans doute du fait d’un caractère moins brutal et inévitable que n’a pu l’être la crise sanitaire de 2020. Dans le cadre d’une lutte contre les effets du dérèglement climatique, l’un des angles du sujet serait de mettre en place une politique de décroissance, quand bien même celle-ci ne semble pas être la tendance actuelle des organisations. Le média degrowth.info, dont le sujet est la spécialité a commencé à réfléchir à des stratégies pour appliquer ce principe, mais aujourd’hui sa réflexion reste globale et le média ne s’est pas penché sur les spécificités de l’Agilité.

Et les intelligences artificielles dans tout ça ?

Un autre facteur émergent de changement pourrait être les nouvelles intelligences artificielles. Même si elles ne sont pas aujourd’hui en capacité de remplacer directement certains rôles, nous pouvons imaginer que cet outil s’affine, que son utilisation devienne une expertise comme on peut être expert en développement logiciel ou en gestion de produit et que ces métiers s’intègrent aux frameworks Agiles. Elle pourrait également s’avérer être un précieux outil d’estimation ou de priorisation à l’avenir, comme semblent l’indiquer certains articles (ici chez Zenhub, ici chez Hackernoon).

Nous l’avons donc vu, tous ces éléments sont susceptibles de venir influer de façon plus ou moins directe sur nos modes d’organisation présents et futurs. Adaptation plus ou moins subie, plus ou moins voulue, c’est de toute façon le sens de l’histoire que de remettre en question l’ordre établi afin de chercher à s’améliorer dès que nous le pouvons. Et vous, voyez-vous d’autres phénomènes qui pourraient venir chambouler les choses ?

L’article L’Agile, c’est très bien… Et après ? est apparu en premier sur EKITE.

L’article La facilitation : fourre-tout ou rôle hybride ? est apparu en premier sur EKITE.

FAST, c’est un framework d’Agilité à l’échelle proposé par Ron Quartel, coach Agile (entre autres) basé à Seattle et qui a eu l’occasion de développer cet outil à l’occasion de l’une de ses missions. L’objectif était de pousser à l’extrême la notion d’auto-organisation et de fluidité d’équipe (comprenez, les personnes ne font pas partie d’une équipe en particulier mais se réorganisent en permanence). Résultat, une vingtaine de pages pour décrire le fonctionnement d’une organisation plus ou moins étendue (jusque 150 personnes) avec des unités temporelles de 2 jours. Comment ça peut marcher ? On vous en dit plus tout de suite !

 

FAST, c’est-à-dire ?

 

Pour parler de FAST, il faut conjuguer Open Space Technology et Open Allocation. Comprenez, pour l’un, qu’il s’agit de laisser les personnes décider sur quoi il est préférable de travailler, dans un environnement colocalisé, et pour l’autre, qu’il s’agit de laisser les personnes s’auto-organiser sur la meilleure façon de travailler ensemble. Ces deux critères sont à la base de ce framework, combinée avec le découpage et l’animation du (des) produit(s). Celui-ci se rapproche d’un Story Mapping classique permettant de prioriser le travail à faire et de diffuser la vision produit.

Ces éléments vont donc permettre d’animer des cycles de valeur (et non pas des itérations) de 2 jours, dans lesquelles on trouve une seule réunion qui termine le cycle en cours et ouvre le suivant, en faisant à la fois le bilan du travail réalisé et en re-mélangeant le travail à faire.

Le diagramme suivant résume en quelques images le fonctionnement d’un cycle FAST (source twitter @FSTAgile) :

Déroulement d’un cycle FAST

 

OK, mais comment en savoir plus ?

 

Ron Quartel le créateur de FAST

L’avantage des outils qui se structurent, c’est que les personnes qui en sont à l’origine sont généralement disponibles pour en parler. Nous avons donc pu obtenir un rendez vous en visio avec Ron Quartel, le fondateur de FAST. En direct de Seattle où il était 6h du matin pour lui, nous avons pu faire connaissance, échanger et poser les questions que nous avions. Ron est quelqu’un de très curieux et accessible, on sent la volonté de contribuer au développement de l’agilité en apportant cette méthode issue de sa propre expérimentation et non la volonté de vendre un framework.

Fast est encore au stade de recherche et d’expérimentation, James Shore (auteur de « The art of Agile Development ») mène en ce moment des tests de FAST sur son projet. Plusieurs fois au cours de l’entretien Ron nous a répondu : « Il faudrait tester », loin de penser avoir toutes les réponses il nous propose d’apporter notre pierre à l’édifice en expérimentant nous-même et en contribuant. Il nous a même invité à proposer nos idées pour le nommage de certains détails qui pourraient être déceptifs (l’étape du Show & Tell notamment, à ne pas imaginer comme étant une Démo Scrum mais comme un passage en revue rapide).

Ron a insisté sur la notion de « bulle d’autonomie » : il est nécessaire d’avoir suffisamment de marge de manœuvre pour pouvoir mettre FAST en place. Il faut également un management qui laisse de l’espace et qui autorise l’expérimentation. Son seul regret sur son expérimentation est le changement de management qui a mis fin à cette aventure. Il nous a parlé de « TEAL management » qui est le dernier stade d’évolution d’une organisation qui s’approche de l’auto-gouvernance d’après Frédéric Laloux (dans Reinventing Organizations : Vers des communautés de travail inspirées).

La gouvernance de l’équipe

Nous avons aussi pu parler de l’importance de lancer cette approche accompagné de personnes volontaires et motivées par ce mode de fonctionnement, tout le monde n’est pas demandeur de plus d’autonomie et cela peut être un frein au lancement de FAST. Dans la dimension humaine toujours il a plusieurs fois insisté sur l’importance de très vite se mettre d’accord sur la notion de « Tribe Agreement » (comment les décisions seront prises ensemble et comment les conflits seront résolus ) pour avancer sereinement vers la suite.

Certaines de nos questions touchaient à l’autonomie et aux problèmes qui auraient pu en découler, nous étions curieux par exemple de savoir si les tâches de run n’étaient pas délaissées, si les tests et les release se faisaient également en bonne harmonie. Le problème ne s’est jamais présenté sur son projet, l’expérimentation de Fast avait justement démarré parce que plusieurs produits étaient gérés en parallèle par son équipe et qu’il ne voulait pas « punir » les plus anciens développeurs en les faisant travailler sur la partie Legacy. En affichant tout sur la Product Map toutes les tâches sont identifiées (même les tests ou les release apparaissent, il n’y a pas de tâche implicite) et l’équipe se les répartit en bonne intelligence sans besoin d’assignation de la part du Product Manager. La notion de responsabilité collective est plusieurs fois revenue.

L’ajout de règles de fonctionnement supplémentaires se fait quand et si nécessaire, Ron a pris l’exemple de la partie Run qui a été affichée à part sur un kanban par son équipe pour plus de visibilité.

 

L’article FAST (& Furious) Agile, c’est déjà le futur est apparu en premier sur EKITE.

Néanmoins, avec l’émergence de l’Agilité, ce paradigme a rapidement été remis en question. Les facteurs fixes sont désormais le budget et le délai, et le périmètre sert d’ajustement. L’objectif est d’avoir l’assurance de pouvoir délivrer de la valeur quand bien même le besoin ne serait pas couvert de façon exhaustive.

Par la suite, d’autres formes sont apparues, en considérant la qualité du produit comme une variable d’ajustement par exemple (nous déconseillons fortement cette approche, vous vous en douterez). D’autres vont encore plus loin en intégrant le facteur humain à cette vision, aboutissant à la forme d’une maison.

Ces différentes formes sont déjà bien connues et documentées, mais que se passe-t-il lorsque l’un ou l’autre de ces facteurs ne sont plus maîtrisés ? C’est là que notre titre prend sens et que l’on bascule de l’autre côté du miroir : voici venue l’heure de vous présenter notre pentragramme des enfers et ses 5 bêtes de l’apocalypse. Bien entendu, ces horreurs peuvent se combiner et il n’est pas rare de rencontrer des projets où 3, 4 voire les 5 facteurs sont complètement délaissés… Laissez-vous donc guider au travers de notre bestiaire de la (mauvaise) gestion de projet.

Non maîtrise du coût : le puit sans fond

Première catastrophe, le puit sans fond correspond au projet qui engloutit des sommes colossales en permanence. Cela peut se produire dans les grands chantiers de transformation ou de rénovation (exemple : reconstruction de la cathédrale Notre Dame de Paris) pour lesquels les budgets ont peu ou pas de limite. Malheureusement, lorsque les résultats ne sont pas à la hauteur, les investissements consentis rendent difficile toute remise en question ou arrêt du projet (que ce soit pour le gâchis financier que cela reviendrait à accepter ou pour toutes les personnes impactées par ce type de décision). De fait, toute prise de décision devient difficile, les équipes peuvent devenir surdimensionnées et l’organisation de tant de personnes inenvisageable.

Non maîtrise du délai : la chimère

La chimère est mystérieuse, vaporeuse, se cache à la moindre occasion au point qu’on se demande si elle va finir par arriver un jour. À force de repousser sans cesse sa mise en place, on prend le risque d’obtenir un produit qui sera déjà obsolète à sa sortie. Surtout, que ce soit du côté des équipes qui travaillent sur le projet, ou du client qui attend une solution, la frustration arrivera vite et entraînera une perte de crédibilité pour l’ensemble des parties prenantes.

Non maîtrise du périmètre : l’usine à gaz

Autre invocation qui découle d’un périmètre qui évolue en permanence, l’usine à gaz apparaît lorsque les décideurs ne parviennent pas à poser des limites sur les fonctionnalités qui seront intégrées à un projet. Evidemment, dans ce genre de situation, la conduite du changement et l’adoption d’un produit sont rendus difficiles voire impossibles puisqu’elles représentent un volume de connaissance beaucoup trop important pour être digéré et inclues dans des gestes métier. De la même manière, côté technique, le projet ne pourra pas être maintenu de par sa complexité. Toute mise à jour, évolution ou correction sera un calvaire pour les équipes en charge de les réaliser puisque. Enfin, à vouloir tout faire, la solution sera irremplaçable puisque la décommissionner reviendrait à reproduire le cycle de l’usine à gaz. A noter : dans le cadre d’un périmètre non maîtrisé on pourrait également parler de sables mouvants si le périmètre varie du tout au tout d’un cycle à l’autre.

Non maîtrise de l’aspect humain : le cimetière

Ne l’a-t-on pas tous connu ? Ce projet d’où les salariés ne repartent qu’à grands coups de courriers recommandés ? Lorsque les crises mettent de l’urgence dans les cycles projets, il arrive que les membres des équipes soient les premiers à en souffrir. Bien entendu, ces démissions à répétition amènent avec elles une perte continue de la connaissance du projet, et donc une réactivité médiocre lorsqu’il faut apporter des solutions. Au-delà de l’aspect opérationnel, ce genre de situations peut également engendrer des problèmes juridiques en fonction du degré d’avancement de la crise humaine du projet.

Non maîtrise du risque : la bombe à retardement

Dernière invocation possible, celle résultant d’une lacune dans la prise en compte des risques dans le cadre d’un projet. Que l’on parle de risques de sécurité ou de risques opérationnels, les conséquences peuvent être désastreuses. Peut-être pas à court ou moyen terme, mais on finit toujours pas être rattrapé par la patrouille lorsque l’on va trop loin. Parmi les résultats qu’on peut observer dans le cas de la bombe à retardement, on peut citer pêle-mêle la possibilité de failles de sécurité, d’amendes et de procédures judiciaires mais aussi plus simplement de services indisponibles et d’objectifs de projets non atteints.

Vous l’aurez sans doute compris, l’équilibre entre les enjeux d’un projet est primordial. Il convient d’en assurer la juste répartition afin d’éviter de sombrer dans une (ou plusieurs !) de ces invocations. Les dérives guettent toutes les organisations, quelle que soit leur taille.

L’article Le pentagramme de fer est apparu en premier sur EKITE.

Un Design System, qu’est-ce que c’est ?

Un Design System, c’est un outil utilisé pour concevoir des produits numériques, à destination des concepteurs UX (User Experience) et UI (User Interface) afin d’assurer l’homogénéité et la cohérence de l’expérience vécue par les personnes utilisant les différents produits dépendant d’une même entité. Par exemple, si vous commandez vos billets sur le site internet SNCF ou si vous téléchargez votre billet sur l’application mobile, vous remarquerez une grande similitude entre les éléments visuels et le fonctionnement de ces deux outils. C’est parce qu’ils dépendent tous les deux d’un même Design System. Concrètement, on y retrouve plusieurs livrables (sans être exhaustif) : les éléments composant l’identité visuelle de la structure représentée, des principes de design mais également les déclinaisons techniques afin que les développeurs n’aient pas à recréer chaque élément qui existe déjà.

Source : sqli.com

OK cool, mais à quoi ça sert ?

Qu’il s’agisse du Design System d’une entité internationale ou, d’un produit conçu et développé par une seule personne, il trouvera son utilité. De façon évidente, il permet d’homogénéiser les pratiques et d’éviter de générer de la confusion chez les utilisateurs. Il permet aussi de fédérer les équipes autour d’une vision commune du design, que chacun·e viendra enrichir en fonction des nouveaux besoins. Cette vision permet d’animer les équipes et de donner du sens aux prises de décision. Enfin, et c’est le point le plus pragmatique, il permet à tous les membres de l’organisation de gagner du temps. Ne pas devoir imaginer un nouveau visuel, une nouvelle configuration ou une nouvelle expérience, c’est gagner du temps sur des tâches fastidieuses pour se concentrer sur de la recherche UX ou d’autres sujets. De même pour les développeurs, la ré-utilisabilité des composants est un avantage précieux dans un monde où il est toujours plus vital de pouvoir délivrer rapidement.

Super, est-ce que c’est utile tout le temps ?

A l’échelle d’une grande organisation, l’outil s’impose de lui-même comme le meilleur moyen de partager et maintenir des éléments de design entre les différents métiers qui en ont besoin. Cela devient moins évident pour de petites équipes ou des personnes travaillant seules, même s’il peut être intéressant d’avoir cet outil pour capitaliser lorsque l’on doit travailler sur plusieurs sujets en parallèle.

Ça a l’air trop beau, c’est quoi les contraintes ?

Forcément, un Design System peut vite devenir une grosse machine et il est nécessaire de suivre quelques règles pour éviter qu’un outil voué à l’harmonie devienne l’épicentre d’un chaos incontrôlable. Il peut être nécessaire d’avoir un minimum d’expérience afin d’avoir le recul nécessaire et déterminer ce qu’il est pertinent d’y intégrer et son fonctionnement. Il est également important de faire preuve d’une grand rigueur afin de le maintenir et que sa vie soit aussi épanouie que sereine. Enfin, un dernier point d’attention est d’avoir une politique claire afin de pouvoir l’appliquer et le mettre en place correctement. S’il est mal ou pas communiqué, vous aurez toute les chances de le voir faillir à remplir son objectif, ce qui serait fort dommage, vous en conviendrez.

Conclusion

Voilà, vous avez toutes les clés pour comprendre ce qu’est un Design System et à quoi sert cet outil. Pour continuer à vous acculturer au Design, vous pouvez aller vous renseigner sur le concept d’Atomic Design qui en est une composante importante (cf vidéo un peu plus haut).

L’article Le Design System pour les non-designers est apparu en premier sur EKITE.

Le Cargo Cult est à l’origine une notion historique, très bien expliquée sur Wikipédia. En résumé, cela désigne l’attitude des indigènes Mélanésiens face à l’arrivée des colons occidentaux au tournant des XIXème et XXème siècles. N’ayant aucune connaissance des modes de production industriel, certains ont commencé à imiter certaines pratiques sans les comprendre. Avec un peu de recul on peut trouver l’idée un peu trop basique pour s’imaginer que cela puisse être transposé à l’échelle d’une équipe, voire d’une organisation, et pourtant ! Toutes et tous les agilistes que nous sommes ont déjà rencontré ce type de phénomène et se seront attelés à le combattre.

Mais quid des convaincus du cycle en V ? Quid des directeurs de programme qui ne jurent que par le sacro-saint reste à engager et le rétro-planning ? À tous ces défenseurs du reporting Excel, nous allons vous donner les armes pour combattre la dictature agile. Dans les lignes qui suivent, nous vous proposerons une petite recette afin de réussir votre Cargo Cult Agile à tous les coups.

Contexte

Mettez-vous en situation : on vous impose d’entamer une transformation agile sur votre programme afin d’expérimenter ce mode de fonctionnement à la mode chez la concurrence.

Travailler en proximité avec le client, ne plus estimer en jours de charge et livrer toutes les deux semaines c’est bien beau… mais pas chez vous. Il est l’heure de s’organiser avant la bataille.

Conseil n°2 : Laissez vos équipes dans l’obscurité

Malgré vos efforts appuyés dès le départ, vous ne pourrez pas empêcher les plus récalcitrants de vos collaborateurs de vouloir mettre en pratique une véritable démarche agile, de se former aux principes et de vous challenger dans ce (non-)changement de paradigme que vous souhaitez mettre en place. Ne vous laissez pas désarçonner et coupez leur l’herbe sous le pied en leur affectant des jalons intenables. Jalons dont vous vous arrangerez pour que le contenu change le plus fréquemment possible, bien entendu. Faites également le nécessaire pour qu’ils se heurtent le plus souvent possible à une inertie structurelle infinie et donnez leur des responsabilités sur des éléments hors de leur contrôle.

Conseil n°3 : Imposez de fausses pratiques agiles

Réussir un cargo cult agile n’est pas si simple et il convient de ne pas relâcher vos efforts trop tôt. Afin de maintenir un niveau de frustration élevé et éviter que les équipes ne fassent preuve d’initiative, continuez de les noyer sous un flot continu de nouvelles pratiques et d’idées issues d’autres contextes que vous imposerez et renouvellerez sans cesse. Votre imagination et votre capacité d’improvisation sont les seules limites (inspirez-vous des réunions de Michael Scott).

Crédit : The Office

Conseil n°4 : Constatez avec votre direction que l’agilité ne fonctionne pas

Quelques mois plus tard, lors de votre comité de pilotage où l’on demandera ce que donne l’expérimentation agile qui a été mise en place dans votre département, vous aurez tous les éléments pour conclure en beauté votre cargo cult agile. Turn-over à deux chiffres, mécontentement de vos collaborateurs, budgets explosés… Clairement, l’agilité ne marche pas, c’est juste une usine à échecs, il est temps de reprendre votre pilotage Excel, vos cahiers des charges réalisés au forfait. Cela vous permettra de retrouver le confort de ce que vous connaissez depuis des années, ce ne sont pas quelques agitateurs et leurs rétrospectives qui vont venir remettre en cause des décennies de pilotage de projet classique. Ce n’est quand même pas pour rien si on fait des cahiers des charges de 200 pages depuis les années 70, ça a fait ses preuves !

Conclusion

Bien entendu, vous aurez compris que le ton de ces quelques lignes est ironique et que nous ne vous préconisons pas de mettre en oeuvre cette recette. L’agilité est avant tout une question d’état d’esprit et d’adaptation au changement. Comprendre et connaître le sens des actions que l’on décide est l’un des fondements de l’agilité, avec l’adaptation au contexte, afin de tenir compte des personnes et des spécificités de votre organisation. Néanmoins, ces quelques lignes doivent vous permettre à l’avenir d’identifier plus facilement des comportements ou des phénomènes relevant du cargo cult agile (évidemment, dans la vraie vie ces éléments ne découlent pas d’une volonté de faire échouer une transformation agile) et à mettre en place des solutions afin d’en sortir.

Enfin, il serait trompeur d’imaginer que l’agilité est possible et pertinente dans n’importe quel contexte. Avant d’entamer une transition vers un mode de fonctionnement agile, il convient de se poser les bonnes questions, tant en termes de maturité des équipes qu’en termes d’accompagnement (il est toujours pertinent d’avoir un regard extérieur dans ce type de transformation, de plus en plus d’organisation mettant en place des cellules ou des collectifs dédiés à l’agilité, donc n’hésitez pas à vous rapprocher d’eux si vous avez besoin d’aide).

Pour en savoir plus :

L’article sur le sujet de My Agile Partner présente plus en détails l’histoire du Cargo Cult avant de faire le lien avec l’agilité. Dans le même type de pratique, l’article sur le Zombie Scrum de scrum.org prend l’exemple spécifique d’un Cargo Cult appliqué au framework Scrum et de ses conséquences.

L’article Comment réussir votre Cargo Cult Agile ? est apparu en premier sur EKITE.

Le User Journey Mapping (UJM) s’inscrit dans une démarche de conception d’un produit.

L’objectif est de modéliser le parcours d’un utilisateur (ou d’un client) dans les différentes étapes qui constituent un produit (ou une marque). Cette modélisation prend en compte le ressenti de la personne étudiée. Le périmètre peut varier en fonction de ce sur quoi on souhaite focaliser l’attention : depuis le suivi d’une relation avec plusieurs occurrences de contact jusqu’à l’étude d’une fonctionnalité très spécifique.

Dans cet article, nous étudierons ce qui fait la spécificité du User Journey Mapping, ses qualités, ses limites et nous finirons par une étude de cas afin de mieux comprendre son utilisation.

Pour construire un UJM, il est fortement conseillé d’entrer dans une démarche de recherche utilisateur (en bref : intéressez-vous à vos utilisateurs). Mieux vous connaîtrez les comportements et le ressenti des personnes qui se servent de votre application ou service, plus simple sera la construction du User Journey.

Cet outil ne vous donnera pas de solution, il va mettre en évidence les frustrations qui peuvent interférer avec une solution existante dans un périmètre donné. Une fois les frustrations identifiées, il faudra décider de leur résolution (ou pas).

User Journey, Experience Map, Blueprint : quelles différences ?

Quand on prend le descriptif pur et dur, il peut être difficile de faire la différence entre les multiples possibilités qui existent pour représenter le cheminement d’un persona (ce qu’on appelle la cartographie de l’UX).

Le Service Blueprint, par exemple, va plutôt se concentrer sur ce qui est mis en jeu au sein de l’organisation en termes d’outils et d’interventions humaines. Il peut apporter des informations sur la chaîne de traitement et permettre d’identifier les points de friction ou de complexité.

L’Experience Map va, lui, chercher à comprendre le ressenti des individus qui vivent une situation sans forcément s’attacher à une solution particulière. C’est l’analyse du comportement face à une problématique donnée.

La User Journey Map, quant à elle, va se concentrer sur une solution ou un service bien précis (et existant). Qu’il s’agisse de la conception, de la refonte ou de l’amélioration continue d’un produit, elle cherche à identifier les émotions, pensées et actions d’un persona ainsi que des opportunités d’amélioration.

Qu’est-ce que ça peut apporter ?

Comme tout outil de cartographie UX, le User Journey Mapping permet de prendre du recul, ce qui est parfois bienvenu sur des processus existants ou en cours de conception. Dans sa construction, ce type d’exercice permet d’aligner les différentes parties prenantes et ainsi d’évacuer les ambiguïtés existantes. Une fois mis en place, cet outil invite à analyser le comportement des personas afin d’identifier les irritants présents sur le parcours, pour lesquels des solutions (ainsi que leur implémentation) pourront être imaginées (ou non s’il est décidé que l’effort nécessaire n’est pas intéressant en regard de la valeur générée).

Quand l’utiliser ?

L’intérêt principal de cet outil provient de son appui sur une solution existante. Il ne s’agit pas de partir de zéro pour imaginer une solution (à l’inverse d’une experience map ou d’un story mapping) mais de connaître le parcours utilisateur déjà en place pour identifier les opportunités d’évolution. Le User Journey Mapping est particulièrement intéressant lorsque l’on veut mettre à l’épreuve un produit pour choisir son devenir.

Son utilisation est ponctuelle. Réalisé par l’UX ou le Product Owner, le User journey mapping dresse l’état des lieux d’un bout de parcours utilisateur pour identifier les opportunités d’évolution. Partagé avec les décideurs, il permet de choisir les pistes pour les développements à venir. Il est alors intéressant de partager les résultats et décisions associées avec les parties prenantes pour que chacun puisse comprendre le contexte qui va entraîner l’évolution du Produit.

Un exemple pour illustrer : l’opérateur relais colis

Prenons l’exemple de Camille, qui est fleuriste et dont la boutique est un point de retrait de colis. Son rôle lui impose d’être disponible pour les clients qui souhaitent retirer des colis, c’est également une opportunité de faire venir dans sa boutique des personnes qui n’y seraient pas forcément venues sans ce motif. Le User Journey Mapping que nous avons choisi de construire s’étend entre le moment où une personne entre dans sa boutique pour récupérer un colis et le moment où elle en sort.

Le choix de ce type de situation a été motivé par plusieurs éléments.

La majorité de la documentation existante et donc, des exemples de User Journey, se concentre sur l’expérience d’un achat en ligne (voir liens en fin de page). Sans critiquer ce choix qui répond aux sujets de beaucoup de personnes, il n’adresse pas la situation d’une application dite « métier » que nombre de développeurs et chefs de projets connaissent. Nous sommes donc bien dans le cas d’un User Journey Mapping et non pas d’une Customer Journey Map.

Les limites

Comme nous l’avons vu précédemment, cet outil possède de nombreux avantages. Néanmoins, cette méthodologie possède également ses limites. Cela va vous paraître évident, mais il est important de le préciser, un User Journey Mapping doit se baser sur des retours utilisateurs. Il doit être orienté, il doit raconter une histoire vraie axée sur un utilisateur et non pas sur de simples hypothèses. Sans oublier que cet utilisateur est une vraie personne qui subit des aléas dans son quotidien et qui peut donc passer d’un parcours à un autre sans avertissement. Pourtant le User Journey est quelque chose de très linéaire.

Il doit se concentrer sur un parcours de notre utilisateur cible. Or, nous le savons, en fonction des évènements de notre quotidien, nos parcours changent. Prenons comme exemple le trajet domicile à notre lieu de travail (ou le retour), un embouteillage ou une course à faire peut nous faire changer d’itinéraire.

Cependant, il est impossible de représenter l’ensemble de ces parcours dans une User Journey Map (cela deviendrait forcément illisible).

Ce que d’autres en disent…

L’article de Stéphanie Walter sur le sujet est très intéressant. Elle prend l’exemple d’une application dans le cadre d’un garage automobile et de réparations complémentaires, elle donne des étapes clés pour réaliser une User Journey Map et des templates utilisables sous Miro.

La présentation de Aaron Agius vaut également le détour. Elle définit en détails l’ensemble des éléments qui composent une User Journey Map et reprend de nombreux exemples (beaucoup centrés autour de relations commerciales).

L’article User Journey est apparu en premier sur EKITE.