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.

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 :

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 :

Mes présentations Agile Tour Québec 2012

Publié par Louis-Philippe Carignan le mardi 6 novembre 2012 à 19:00

J'aimerais remercier les organisateurs du Agile Tour Québec 2012 de m'avoir donné la chance de présenter à deux reprises lors de cet évènement. Ce fût un plaisir échanger avec les participants et tel que demandé, j'ai mis sur SlideShare.net mes présentations.

Une introduction au Lean Product Development

Conditions de succès: Spécifications ou assurance-qualité

Tester pour apprendre à Agile Montréal

Publié par Louis-Philippe Carignan le jeudi 18 octobre 2012 à 18:00

J'aimerais remercier les organisateurs de la communauté Agile de Montréal pour leur chaleureux accueil jeudi soir. Merci à Martin Goyette d'avoir pris le temps de bien m'orienter dans ma présentation et de m'avoir accueilli à la station de métro pour éviter que je tourne en rond.

Pour les personnes intéressées, vous retrouverez ci-joint la présentation que j'ai donné. Vous pouvez télécharger le fichier PDF en allant sur le site Slideshare d'Elapse Technologies.

Ma courte revue du livre "Product Development for the Lean Enterprise"

Publié par Louis-Philippe Carignan le lundi 3 septembre 2012 à 12:00

Après avoir assisté à la présentation de Michael N. Kennedy à la conférence Lean Software & Systems Conference à Boston en mai dernier, je me suis procuré les deux livres du conférencier comme lecture d’été. Certains diront que M. Kennedy a fait une belle job de vente pendant sa conférence. Je suis tout à fait d’accord. Ce conférencier m’a donné le goût d’approfondir quelque chose que Mary Poppendieck touchait à peine dans ses livres.

Après quelques jours d’attente suite à ma commande sur Amazon, les livres « Product Development for the Lean Enterprise » et « Ready, Set, Dominate » sont arrivés dans ma boîte aux lettres. Pour les curieux, ces livres ne sont pas disponibles en format électronique.

 Livre-Product-Development-for-the-Lean-Enterprise-Kennedy-Michael-N  Livre-Ready-Set-Dominate-Kennedy-Michael-N

Je m’attendais à un livre de référence sur le sujet. À ma grande surprise, le premier livre de Kennedy est écrit sous la forme d’un roman (business novel) où une entreprise voit ses revenus diminuer tandis que ses coûts de développement augmentent. Elle commence à perdre des clients à cause des prix trop élevés de ses produits. La compétition est de plus en plus féroce. Comme toute entreprise qui doit survivre, elle se doit de réagir. À l’aide d’une intrigue légère, on y introduit l’approche du développement de produit basé sur le savoir (knowledge based design) comme solution pour renouer avec les profits. J’ai apprécié ce style d'écriture puisque cela facilite et agrémente la lecture en s'identifiant aux personnages. Les mises en situation nous rappellent notre propre contexte au travail ainsi que les types de personnage que l’on retrouve dans nos réunions.

À la fin de chaque chapitre, l’auteur revient sur ce qui s’est produit pour nous clarifier certains points. Cette section « Discussion » nous permet de revisiter des concepts qu’on aurait peut-être manqués pendant notre lecture.

Je recommande fortement ce livre aux gens qui désirent approfondir les approches pour le développement de produit. Dans l’Agilité, on ne mentionne jamais la découverte et le partage de connaissances comme valeur. Ce thème est central dans ce livre puisqu'il est à la base du succès chez Toyota. Dans l'Agilité, on mise sur les individus, leurs interactions et leur collaboration. On parle de bonnes pratiques d’ingénierie. Les livres de Mary Poppendieck nous ont révélé les 7 gaspillages en développement logiciel. Mais lorsque votre projet logiciel fait partie d’une solution plus globale, je pense que l’Agilité ne vous guide pas complètement et que l’approche « knowledge based design » vous sera d’une grande utilité. Pour des gens qui sentent avoir fait "le tour de l'Agilité" et à la recherche d'un autre point de vue en développement de produit, ce livre vous sera utile. Bien que Toyota soit la référence de l'approche "knowledge based design", Kennedy en fait mention sans exagération. On cite quelques chiffres pour mettre en valeur cette approche mais sans plus. Dans l'histoire fictive, on fait référence à Toyota lorsque les personnages se posent des questions. Mais l'auteur fait attention pour ne pas simplement développer un cultre d'adoration envers Toyota. 

J’ai commencé la lecture du second livre de Kennedy. Toujours sous la forme d’un roman, il revient un an plus tard avec l’entreprise introduite dans son premier livre pour mesurer le progrès qu’elle a fait avec l’approche « knowledge based design ». Bien que le premier livre nous donnait les grandes lignes de l’approche, le deuxième livre nous raconte les difficultés rencontrées lorsqu’on l’implémente. Bien que j’aie beaucoup apprécié le premier livre où on m’a vendu les concepts, le deuxième me ramène sur terre où l’on me présente les difficultés que l’on peut rencontrer lors de sa mise en œuvre. Jusqu’à présent, je le trouve plus difficile à lire puisque je dois revenir sur les concepts de l’approche et réfléchir comment ils ont été mal mis en œuvre dans l’entreprise fictive.

 

Archive