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.

La conception importe plus que la production

Publié par David Beaumier le mardi 16 juin 2015 à 10:17

« It’s not the production system that matters most, but the design system ». Du moins, c’est le point de vue de Toyota lorsque son système de production (le fameux TPS – Toyota Production System) est comparé à son système de conception, le TPDS pour Toyota Product Development System.

C’est sans doute pour cette raison que Toyota a toujours accepté de recevoir les représentants des autres manufacturiers dans ses usines. Toyota savait que son principal avantage compétitif se trouvait plutôt au niveau du système de conception de ses produits. Et oui, même si la conception est une activité hautement créative, le système à l’intérieur duquel cette conception se fait peut, à plusieurs égards, être standardisé.

It’s not enough to do your best; you must know what to do and then do your best.

- W Edward Deming

En développement logiciel, bien des équipes ont tendances à associer leur processus de développement à un système de production. Je crois qu’elles auraient plutôt avantage à faire comme Toyota et scinder en deux leur processus : la conception du logiciel et la production du logiciel. Ne vous méprenez-pas, je ne vous propose pas de revenir au développement en cascade!

Je vous propose plutôt d’utiliser l’analogie de la chaîne de montage pour regrouper les activités de construction (build), de vérification, de déploiement et de mise en production de votre logiciel. Le fameux DevOps, quoi. Le serveur d’intégration continue, avec son build, ses tests et vérifications et par la création du paquetage applicatif, joue en quelque sorte le rôle de l’usine. La partie déploiement, mise en œuvre et opérationnalisation du produit équivaut cycle de distribution, de vente et de service habituellement associé au réseau des concessionnaires.

Les activités en amont, incluant le « codage », sont en réalité des activités de conception. C’est seulement un fois que le serveur récupère le code depuis votre gestionnaire de sources que l’usine se met en branle. Tout ce qui se fait avant sert à définir les spécifications structurelles et comportementales de l’application (qu’il s’agisse de l’interface utilisateur ou de traitements d’affaires). Le code source, les schémas de bases de données et la configuration représent les spécifications requises pour bâtir le produit.

Ce n’est donc pas suffisant de mettre votre usine en marche. Vous devez vous assurer qu’elle produit la bonne chose! Heureusement, nous avons la chance en développement logiciel de ne pas avoir à gérer les contraintes physiques. Nous pouvons construire une seule fois le produit et le cloner aussi souvent que souhaité. Il nous est possible de changer ses spécifications, le bâtir et l’essayer en peu de temps et pour peu de frais. Cette flexibilité devrait donc nous permettre de nous concentrer sur le produit à bâtir plus que sur sa fabrication. Ce n’est pas que l’aspect DevOps ne soit pas important, c’est juste que ce n’est habituellement pas en premier lieu pour votre efficacité à bâtir et opérer qu’un client va adorer votre produit.

Ne perdez pas de vue le premier des principes du manifeste agile: le client sera satisfait par la livraison de fonctionnalités à valeur ajoutée.

Principe1 Manifesteagile

Un cadre de travail agile, tel que Scrum, a l’avantage d’offre un modèle itératif pour la conception de produits. Jumelé à un système de production efficace ça permet de réduire la boucle de rétroaction afin de valider que vous avez conçu les fonctionnalités requises pour que votre client atteigne ses objectifs d’affaires.

Et vous, est-ce que votre équipe se perçoit comme un groupe de conception de produits ou se voit-elle plutôt comme une équipe de fabrication?

Simple, compliqué, complexe ou chaotique

Publié par Louis-Philippe Carignan le mardi 26 février 2013 à 15:03

L’Agilité est de plus en plus présente en entreprise. Selon une étude de Forrester publiée en 2010, les méthodes Agile sont maintenant plus utilisées que l’approche traditionnelle en développement logiciel. D’ailleurs, le CHAOS Reort, publié en 2011, montre que plus de projets Agile sont réalisés avec succès que l’approche traditionnelle (42% pour l’approche Agile tandis que 14% pour l’approche traditionnelle).

Le sondage 2011 de VersionOne nommé « State of Agile Survey » confirme que la gestion de projets avec Scrum est l’approche la plus utilisée lors de projets Agile. Vous avez peut-être vous-même eu un certain succès avec Scrum dans un projet pilote ou bien vous êtes peut-être maintenant rendu au stade où vous utilisez toujours l’Agilité lors de la phase de réalisation de vos projets de développement. Fier de ce nouveau succès professionnel, je trouve que l’être humain a tendance à répéter ce qui a bien fonctionné sans prendre le temps de prendre connaissance de la nouvelle situation qui se présente devant lui. L’objectif de ce billet n’est pas d’énumérer les situations où Scrum s’applique. Plutôt, il veut rappeler au lecteur quel type de problème on peut résoudre avec cet outil.

La matrice de Stacey

Ralph Stacey de l’Université de Hertfordshire a mis au point une matrice qu’il nomme « The Stacey Matrix ». Cette matrice permet de prendre connaissance du degré de complexité d’une situation selon le niveau d’incertitude et le niveau d’accord face à la situation. 

La matrice de Stacey

L’axe des X montre le niveau d’incertitude où, à la gauche, il y a peu d’incertitude (close to certainty) tandis qu’il y aura de plus en plus d’incertitude lorsqu’on s’éloigne vers la droite. Sur l’axe des Y, on évaluera le niveau d’accord. Plus on se rapproche de l’origine, plus le niveau d’accord est fort tandis que plus on s’éloigne de l’origine, plus on devient en désaccord sur un sujet. On peut accoler plusieurs thèmes sur ces axes.

Par exemple, on peut se servir de cette matrice dans le choix des technologies à employer pour un projet. Les technologies viendront donc meubler l’axe des X où le degré d’incertitude permettra de nous situer au bon endroit. Quant à l’axe des Y, lors d’un projet, il pourra représenter les requis. Selon le niveau d’accord par le monde Affaires (i.e. votre clientèle à qui est destiné le produit final) face à leurs besoins, on peut alors se situer sur l’axe des Y.

Simple Stacey Chart

À une plus simple expression de la matrice de Stacey, on retrouve 4 états que l’on énumère de la façon suivante :

  • Connu (simple): Tout est connu
  • Compliqué (complicated): Il y a plus de connus que d'inconnus
  • Complexe (complex): Il y a plus d'inconnus que de connus
  • Chaotique (anarchy): Très peu d'éléments connus

Selon mon expérience, des besoins plus ou moins bien connus et une solution inconnue me situe dans la zone complexe de la matrice de Stacey. Selon moi, cela représente souvent l’état de plusieurs projets de développement logiciel en démarrage. Le client a une idée générale de son besoin mais ne sait pas encore à quoi va ressembler la solution finale.

Dans cette zone de complexité de la matrice, Scrum est un excellent outil pour gérer l’imprévisible. Par son approche empirique, Scrum permet de faire de petits pas en livrant des incréments de la solution finale pour permettre de gérer l’inconnu. Le style de management dans cette zone est aussi prescrit par Scrum. À l’aide d’un leadership au service de l’équipe, on fera émerger des idées tout en augementant le niveau de communication dans l’équipe.

Cependant, tous vos projets ne sont pas aussi complexes et ne requiert pas l’Agilité. Et c’est cette nuance que je vois largement ignorée. Par exemple, si vous êtes dans un projet d’entretien, demandez-vous si vous êtes encore dans la même zone de complexité. Si vos clientèles en maintenance ont des besoins très précis et indépendants l’un de l’autre, vous serez moins haut sur l’axe des Y puisque le niveau d’accord sera plus fort. L’impact de ces demandes sur le produit actuellement en production sera peut-être plus faible. En d’autres termes, le changement technologique demandé sera faible et bien compris, ce qui nous pousse vers la gauche sur l’axe des X.

Toutefois, il se peut que vous restiez dans une zone complexe si vos clients ne s’entendent pas sur leurs besoins mutuels. Il se peut aussi que le logiciel à entretenir soit mal conçu, provoquant ainsi de longues séries de tests avant une mise en production.

Pour conclure

L’objectif de ce billet est de rappeler au lecteur que l’Agilité ne s’applique pas à toutes les situations. Selon le niveau de complexité de votre projet, vous devez utiliser la bonne approche. La matrice de Stacey est un outil qui vous permet de vous positionner quant au niveau de complexité de votre projet. Une fois cela déterminée, il suffit de prendre l’approche pour gérer cette complexité.

Il existe plusieurs outils sur le marché pour vous aider à choisir entre l’Agilité et l’approche traditionnelle. Par exemple, Dean Leffingwell, auteur du Scaled Agile Framework, offre un questionnaire de 10 questions pour vous aider à déterminer quelle approche prendre. À mon avis, un retour à la base, c’est-à-dire bien comprendre l’envergure du projet ainsi que voir sa position dans la matrice de Stacey, vous permettra de voir clair quant à l’approche à prendre.

 

Références des graphiques:

http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm

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.

 

  • Plus récents
  • 1
  • Plus anciens

Archive