Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Pourquoi vos résolutions ne tiennent pas

Publié par Marc Allard le mercredi 14 janvier 2015 à 16:00

Source: www.clevelandpersonaltraining.comS’il y a un moment dans l’année où Google doit nous trouver prévisibles, c’est bien en janvier. Chaque début d’année, le moteur de recherche enregistre une hausse marquée des recherches pour les appareils de mise en forme comme les tapis roulants et les exerciseurs elliptiques, selon Google Trends. L’engouement pour les marathons, le gym et… les régimes connaît le même genre d’envolée.

Le coupable? Les résolutions du Nouvel An. Gonflés d’espoirs à l’amorce d’une nouvelle douzaine de mois, nous nous promettons de bouger plus, de manger mieux, d’arrêter de fumer, de faire le ménage dans nos finances, d’être plus performants au travail, plus organisés à la maison, plus disponibles pour nos enfants, nos familles, nos amis. La liste est longue. Mais amenez-en! Notre futur soi, version 2015, peut en prendre!

Le problème, c’est qu’il ne tient pas le coup, notre futur soi. Selon une étude de l’Université Scranton, aux États-Unis, parue en 2014, environ 92 % des gens renoncent à leurs résolutions en cours de route, un taux de succès de 8%... Pourquoi sommes-nous aussi poches? Certains auteurs de psycho-pop ne se lassent pas de répéter que c’est parce qu’on manque de volonté, parce qu’on ne veut pas assez. Or, c’est le contraire : on en veut trop — ou du moins, trop en même temps.

Depuis la fin des années 90, c’est ce que le psychologue américain Roy F. Baumeister s’est acharné à démontrer. La volonté, explique-t-il dans son livre Willpower: Rediscovering the Greatest Human Strength, est une réserve d’énergie mentale limitée. Plus on l’exerce sur une chose, moins il en reste pour autre chose. Aussi simple que ça.

Si, par exemple, je prends les marches au lieu de l’ascenseur pour monter au bureau alors que n’en ai pas l’habitude, j’aurais ensuite moins de volonté pour résister à la Kit Kat de la machine distributrice à la pause. Appliqué aux résolutions du Nouvel An, ce concept d’épuisement de la volonté, aussi appelé la «fatigue décisionnelle», signifie qu’il n’y a rien de pire qu’une liste de résolutions adoptées simultanément.

«Parce que vous n’avez qu’une réserve de volonté, écrit Baumeister, les différentes résolutions du Nouvel An compétitionnent toutes entre elles. Chaque fois que vous vous consacrez à une, vous réduisez votre capacité à tenir les autres.»

Bref, si vous êtes déjà gênés en pensant aux promesses que vous vous êtes faites le 1er janvier, vaut mieux y aller une à la fois. 

Et pour vous aider, voici une humble suggestion.

Pourquoi ne pas commencer l’année en échafaudant un kanban personnel dédié à vos résolutions? Sans doute êtes-vous familier avec ce simple outil de visualisation du flux de travail. Armés de post-it, prenez une grande feuille de papier et divisez-la en trois grandes sections verticales. Dans la première, collez les résolutions qui vous semblent les plus importantes ; dans la deuxième, déplacez celle (il devrait y en avoir une à la fois!) qui est en cours ; dans la troisième, ne laissez que celles que vous avez réussi à tenir.

Comme exercice annuel, ça peut paraître un peu intimidant. Mais qui sait, votre futur soi pourrait vous en remercier.

D'autres billets qui pourraient vous intéresser

L'inventaire, c'est du gaspillage

Publié par Louis-Philippe Carignan le lundi 13 janvier 2014 à 16:18

« In manufacturing, inventory is waste. »

Première phrase à la page 24
« Implementing Lean Software Development »
Mary et Tom Poppendick

Un peu plus bas dans cette page, les auteurs transposent ce concept en développement logiciel.

« The inventory of software development is partially done work. » 

Ok. Facile. En Agile/Lean, l’une des façons de minimiser le gaspillage est de compléter ce que l’on a commencé. Plus loin, aux pages 74 et 75 du même livre, les auteurs énumèrent ce qu’est le travail incomplet :

  • Documentation/requis qui n’est pas codé
  • Code désynchronisé
  • Code non testé
  • Code non documenté
  • Code non déployé

Pour moi, je transpose encore davantage ce concept dans ma liste de tâches professionnelles (ma todo liste). Je tiens donc ma liste de choses à faire très courte. Tout comme on ne veut pas avoir une longue liste de requis auquel on ne réussira jamais à faire au grand complet, je ne garderai jamais une longue liste de choses à faire puisque je sais très bien que je ne réussirai jamais à tout faire et que, d’ailleurs, de nouvelles tâches s’ajouteront à ma liste.

Ceci étant dit, j’étais quand même curieux d’avoir une deuxième opinion sur la question pour voir si ma réflexion était la bonne. Après tout, si je prône les valeurs Agile/Lean, je préfère prêcher par l'exemple.

Personal Kanban

Jim Benson a lancé le site personalkanban.com en 2009 où il explique comment il a transféré les principes industriels du Kanban pour visualiser et contrôler son travail personnel.

Dans son billet « Building your first personal Kanban », Jim explique comment monter son système Kanban :

  • Établir sa carte de valeur (value-stream)
  • Établir son backlog
  • Établir la limite du travail en cours (TEC)
  • Commencer à tirer sur les items du backlog

Puisque ma liste de tâches professionnelles s’exécute sous ce même principe, je lui ai donc écrit sur Twitter pour avoir son opinion à propos de la taille du backlog que l'on monte à l'étape 2.

Voici donc les réponses qu’il m’a données :

Conversation Jim Benson 

J’ai aimé ses réponses.  Lorsqu’il mentionne dans sa réponse du haut qu’un gros backlog est un signe que j’ai plus de « Work In Progress (WIP) » que je ne le croyais, c’est un signe de réviser ma limite WIP. Si ma limite WIP est très élevée, je me retrouve avec beaucoup de travail incomplet. Et puisque du travail incomplet est du gaspillage, je dois m’efforcer d’identifier ce qui ne sera jamais fait et m'en débarasser. 

Plus particulièrement, les questions suivantes dans la conversation Twitter m’ont aidé à identifier la taille du backlog :

  • What is your personal kanban goal?
  • What work is valuable there?

Dans le cas de la première question, l’objectif de mon Kanban professionnel est de réaliser les tâches avec le plus de valeur en premier.

Pour répondre à sa deuxième question, je valorise seulement le travail auquel je crois pouvoir m’attaquer rapidement (disons moins de 2 semaines). Le travail que je ne crois pas réaliser dans ce laps de temps est périssable. Quelque chose de nouveau sera plus important. 

Et votre liste de tâches professionnels?

Et qu'en est-il de votre liste de tâches? Si vous faîtes la promotion des valeurs Agile/Lean dans votre milieu de travail, est-ce que l'organisation de votre travail professionnel est elle aussi Lean?  

 

Mots-Clés :

Les valeurs de XP, Scrum, Kanban et ... les tiennes

Publié par Louis-Philippe Carignan le jeudi 28 février 2013 à 07:19

Oui, oui, je sais. On est super loin du code lorsqu’on parle des valeurs des méthodologies. Pourquoi m’embêtes-tu donc avec ça Louis-Philippe quand j’éprouve un grand plaisir à juste coder pendant ma journée?

C'est qu'il y a quelques années, j’étais à une formation de Lyssa Adkins où elle m’a demandé pourquoi j’étais impliqué dans l’Agilité. Je n’ai pas su quoi répondre et en haussant les épaules, Lyssa a vogué vers un autre groupe de personnes, sachant qu’elle venait de me faire réfléchir.

Plus tard dans la journée, Lyssa présentait une pyramide inversée qui expliquait que les valeurs étaient à la source des principes et des pratiques mis en place par la suite. J’ai encore cette photo bien que cela fasse plus de deux ans que j’aie assisté au cours.

Process Architecture

D’ailleurs, j’avais aimé le commentaire de Lyssa suite à ce dessin. Elle a fait référence au Projet Management Body of Knowledge (PMBoK) qui « presents a set of standard terminology and guidelines for project management » selon l’article sur Wikipedia. À mon avis, le PMBoK contient un tas de pratiques mais elles ne sont pas supportées par des principes et des valeurs, contrairement à l’Agilité qui a un manifeste et 12 principes.

Plusieurs mois après son cours, je complétais ma demande pour être formateur chez Scrum.org. Le formulaire m’a presque posé la même question que Lyssa. Cependant, j’y avais réfléchi longuement (merci Lyssa) et la réponse fût facile à écrire. Pour moi, les valeurs dans l’Agilité étaient en lien avec mes valeurs personnelles. Cela était donc facile pour moi de m’approprier ce truc puisque c’était comme si je parlais de moi. Je savais qu’en l’enseignant, les participants sentiraient vraiment mon intérêt pour ces approches et que cela ferait de moi un bon professeur (du moins, je l’espère).

À partir de ce moment, j’ai toujours cherché à identifier les valeurs présentes dans une équipe, un département ou une organisation dans laquelle je me retrouvais. Par exemple, si j’entendais une phrase comme « On a essayé Scrum mais ça ne marche pas », j’essayais d’identifier les valeurs dans l’équipe ou le département pour voir si la culture en place a tout simplement étouffée l’initiative.

Les valeurs de la méthode Kanban

J’ai été agréablement surpris de trouver un billet publié en janvier 2013 à propos des valeurs de Kanban. L’auteur, Mike Burrows, décortique les pratiques et principes de la méthode Kanban pour énoncer 9 valeurs qui supportent Kanban.  En lisant les commentaires sur le groupe Yahoo! Kanbandev, les réactions face à ce billet étaient majoritairement positives.

Voici donc les 9 valeurs de la méthode Kanban :

  • Transparency
  • Respect
  • Understanding
  • Leadership
  • Flow
  • Customer Focus
  • Agreement
  • Balance
  • Collaboration

À titre comparatif, j'ai créé le tableau ci-dessous pour mettre en parallèle ces valeurs à celles de Scrum et Extreme Programming. Les valeurs d'Extreme Programming sont détaillées dans la page Wikipedia tandis que les valeurs de Scrum ne sont pas listées. Bon, pour le bien de l’article je vais mettre les trois pilliers de Scrum ainsi que l’engagement (Commmitment) et le focus dans les valeurs de Scrum.

XP

Scrum

Kanban

Communication

Respect

Feedback

Courage

Simplicity

Transparency

Inspection

Adaptation

Commitment

Focus

Transparency

Respect

Understanding

Leadership

Flow

Customer Focus

Agreement

Balance

Collaboration

Si on revient au dessin de Lyssa au début du billet, les pratiques mises en place par ces méthodes sont supportées par un ensemble de valeurs qui leur sont propres. Par exemple, dans la méthode Kanban, l’un des principes est de visualiser le travail. On s’appuie sur la transparence pour établir ce principe et il y aura sûrement toutes sortes de pratiques qui émergent de ce principe. Mais si des gens dans l’équipe n’aiment pas montrer où ils sont rendus, et cela existe, ils auront de la difficulté à embarquer. Parce que naturellement, au fond d’eux-mêmes, ils vont résister parce qu’ils ne connectent pas avec cette valeur.

Dans un autre exemple, je me suis déjà retrouvé dans une équipe de développement où il était mal vu de dire qu’on allait dépasser nos estimés. Bien que les membres de l’équipe aient du courage pour admettre que certaines parties du logiciel étaient mal programmées, la culture de l’entreprise ne permettait pas de cultiver cette valeur. Difficile alors de mettre en place des dojos pour faire du refactoring lorsque la culture s’attend à ce que le travail soit parfait du premier coup.

Et c’est là que toi, la personne qui lit ce billet, doit se demander quelles sont tes valeurs personnelles, celles de tes collègues, celles de ton département, et voir si elles concordent avec les valeurs de la méthode que tu essaies de mettre en place. Tu veux de l’Agilité. Parfait. Tu veux mettre en place la méthode Kanban. Parfait. Mais avant d’envoyer ton monde en formation, je t’invite à identifier les valeurs de la méthode qui sont moins présentes dans ton équipe/département. C’est peut-être là que les premiers problèmes vont surgir lorsque vous allez mettre la méthode en place.

Mots-Clés :

Scaled Agile Framework (SAFe) : Les fondements

Publié par Philippe Tremblay le lundi 21 janvier 2013 à 16:25

Le Scaled Agile Framework (SAFe) est un cadre agile tentant de répondre aux nombreux défis auxquels doit faire face une grande entreprise lors d’une transition agile (voir notre article précédent à ce propos).  SAFe est un cadre éprouvé depuis plusieurs années par M. Dean Leffingwell lors de ses expériences avec des centaines d’équipe chez des compagnies telles John Deere et Nokia.  Une part de ce bagage de connaissances est disponible dans les quelques ouvrages écrits par M. Leffingwell, mais le point culminant du partage de cet itinéraire professionnel se retrouve désormais sous la forme d’un cadre agile publiquement accessible à tous : http://scaledagileframework.com.

SAFe

Agile & cie

Pour être en mesure de bien comprendre et surtout appliquer ce cadre, il est impératif d’avoir une vision et une compréhension étendue de l’agilité et ses confrères.  Plusieurs éléments de la grande famille de l’univers « agile » se retrouvent réunis au cœur du cadre.  Que ce soit des principes, des cadres existants ou certaines techniques, ceux-ci sont mis à profit afin d’atteindre la haute performance organisationnelle; terre promise de l’agilité :

  • Scrum
  • Lean
  • Principes du « Product development flow »
  • Kanban
  • Pratiques XP (eXtreme Programming)
  • Kaizen (amélioration continue)
  • Intégration continue
  • Analyse et architecture agile

Un pour tous et tous pour un

Cette intégration d’un ensemble assez large de composants du monde « agile » aspire à l’union des forces de chacun afin de résoudre les problèmes qui existent lors d’une transition vers l’agilité organisationnelle.  Bien que les bénéfices d’une telle approche soient trop variés (ainsi que dépendants du contexte) pour en effectuer une description exhaustive, nous aimerions vous en présenter quelques-uns.

  • Alignement (vision, objectifs, capacité, équipes, architecture, etc.)
  • Transparence organisationnelle
  • Utilisation de l’ensemble des forces (respect, implication et accomplissement de chacun)
  • Amélioration du cycle complet de « production »
  • Réduction des gaspillages à tous les niveaux de l’entreprise
  • Vision économique du flux de développement
  • Qualité intégrale

Conclusion

Le survol de ce qui compose le Scaled Agile Framework (SAFe) et de ses objectifs nous a permis d’établir les bases nécessaires à la compréhension du cadre.  Les prochains articles approfondiront certains aspects du cadre et surtout, tenteront d’identifier les bénéfices pouvant être obtenus par chacune de ces facettes.

Ce cadre, bien que très rigoureux, doit être considéré comme toute autre méthodologie ou pratique, c’est-à-dire que ce n’est pas une panacée.  Mais indéniablement, le caractère public du cadre (ouvert à tous) ainsi que l’expérience acquise dans de nombreuses entreprises en font un choix hors du commun et très certainement un point de départ solide pour quiconque voudrait démarrer une initiative d’agilité à grande échelle.

Mots-Clés :

Vidéos du Lean Software and Systems Conference 2012

Publié par David Beaumier le vendredi 1 juin 2012 à 19:53

Une douzaine de sessions de la conférence Lean Software and Systems 2012 sont maintenant disponibles pour visionnement en-ligne. La conférence, qui en était cette année à sa 4ième édition, s'est déroulée du 13 au 18 mai dernier à Boston.

Parmi celles-ci je retiens le keynote de David J. Anderson qui fait un état de la situation du la popularité de l'approche Kanban en 30 minutes.

Il y a aussi Jeff Patton qui tente de briser certains mythes associés à Lean et Kanban et de mettre l'emphase sur certains aspects parfois négligés de la pensée Lean.

La présentation de Michael Kennedy Set-Based Decision Making aborde l'aspect de la complexité des systèmes et des approches possibles pour développer des produits dans un comtexte où l'on n'a pas toujours en main toutes les réponses au moment de concevoir un produit.

Les amateurs de mesures et de tableaux de bord ne seront pas en reste avec la présentation de Larry Maccherone et Karl Scotland sur les façons d'obtenir des indicateurs quantitatifs avec une approche Kanban.

Bons visionnements!

Mots-Clés :

Archive