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.

Faites face a la demande

Publié par Louis-Philippe Carignan le mercredi 26 octobre 2011 à 11:15

Comment faire pour aligner une équipe, un département ou une organisation toute entière dans la même direction? Bien que les entreprises se dotent de valeurs et principes honorables, n'y aurait-il pas une façon plus concrète permettant à tous les employés de ramer dans la même direction? Voyez des entreprises qui se démarquent dans leur industrie respective à l'aide de la pensée système. Celles-ci ont toutes la même façon de penser : faire face à la demande.

Découvrez comment cette pensée système peut être transposée dans le domaine du développement logiciel. Alors que la philosophie Agile gagne en popularité, on peut se demander si nos manières de faire actuelle en T.I font, elles-aussi, face à la demande.

N'hésitez pas à nous contacter si vous souhaitez en savoir plus sur ce sujet ou organiser une présentation dans votre organisation.

Mots-Clés :

Connaissez-vous les f-laws?

Publié par Louis-Philippe Carignan le vendredi 20 novembre 2009 à 20:16

Le livre A LITTLE BOOK OF f-LAWS, 13 common sins of management est un petit bijou à lire si vous voulez une interprétation différente du management dans votre milieu de travail. En plus du condensé vous pouvez aussi vous procurer le livre complet de 180 pages. Sur le site officiel du livre on décrit les f-laws de cete façon: "f-LAWS are truths about organizations that we might wish to deny or ignore".

Grosso modo, l'auteur, Russell Ackoff, est un "system thinker" dans la même branche que les Demings ou Seddon. Qu'est-ce qu'une pensée système? C'est permettre de comprendre un système comparativement à une pensée analytique où on décortique un système pour y produire de l'information sans vraiment s'attarder à sa compréhension.

Parmi les 13 lois citées dans la version gratuite, celle-ci m'a particulièrement faire sourire: "Overheads, slides and power point projectors are not visual aids to managers. They transform managers into auditory aids to the visuals". Qui peut dire qu'il n'a jamais vu un gestionnaire (peu importe son rang) répéter presque mot pout mot le contenu de sa présentation... Pourtant, l'art de présenter ça s'apprend!

Lean souvent copié mais rarement égalé

Publié par Louis-Philippe Carignan le samedi 14 novembre 2009 à 18:27

On m'a envoyé un lien vers une entrevue avec Michael Hoseus, un ancien dirigeant d'une usine Toyota au Kentucky. Les 2 vidéos, ainsi que l'article, étaient très intéressant. Je suis très d'accord avec Michael Hoseus lorsqu'il parle de confiance entre partenaires (fournisseurs, clients, employés), un élément souvent oublié de Lean.

Les gens recherchent souvent la recette Lean et croit qu'on peut devenir Lean en cartographiant la valeur de ses processus d'affaires, mettre des pages A3 ici et là, suivre les cinq S et faire de l'amélioration continue aléatoire. Cependant, la confiance est l'un de ses éléments qui est oublié puisqu'il n'est pas tangible que les outils Lean. Globalement, je pense que la culture d'entreprise est l'élément le plus difficile à comprendre lorsqu'on veut adopter Lean. Est-ce que le management peut adopter une culture Lean qui permettra d'utiliser à leur pleins potentiels les outils Lean?

Jim Womack a tenu un webinar à ce sujet dernièrement. Selon lui, le management est la partie la moins couverte dans Lean. Lors du webinar, il pose la question "Quelle est la valeur joutée du management?" (what is the work of management) et donne son idée à ce qu'est le management dans une organisation Lean.

Le dernier livre des Poppendieck, Leading Lean Software Development, semble pointer dans la même directement. Bref, je pense que lorsqu'on regarde pour adopter Lean, ce n'est pas juste les processus qu'il faut voir, mais plutôt inclure aussi les gens (processes AND people).

Mots-Clés :

Par où commencer avec l'Agilité?

Publié par Louis-Philippe Carignan le dimanche 2 août 2009 à 02:39

C'est une bonne question et, à mon avis, la réponse dépend de vos besoins. Est-ce que vous cherchez à améliorer votre qualité logiciel? Est-ce que vous cherchez à améliorer votre temps de livraison? Cherchez-vous à motiver votre équipe? Est-ce que vous aimeriez adopter une mentalité d'amélioration continue? Bref, qu'est-ce qui vous pousse à regarder vers les méthodologies Agile?

Par exemple

Disons que votre principal problème est la qualité du logiciel livré au client. De nombreux bogues surviennent chez le client. On répare ces bogues et de nouveaux bogues apparaissent en même temps puisque de nouvelles fonctionnalités sont ajoutées au logiciel. Même si vous mettez en pratique une approche traditionnelle (revue de code, phase de tests exhaustive), votre nombre de bogues rapportés par le client reste le même. Comment s'en sortir? Comment l'Agilité peut-elle m'aider à régler mon problème?

Premièrement

Premièrement, je suggérerais de mesurer votre problème. Dans notre exemple, combien de bogues avez-vous dans votre logiciel? Ou plus précisément, combien de bogues sont rapportés par votre client? Est-ce vraiment la source de l'insatisfaction de votre client? Ou est-il mécontent des interfaces graphiques qui sont peu conviviales? Bref, mettre des valeurs numériques à votre problème est un bon point de départ. En plus de mesurer votre problème, vous donner un objectif pour l'équipe (réduire le nombre de bogues). Aussi, vous informez vos supérieurs que le nombre de bogues peut limiter les profits puisqu'il cause de l'insatisfaction chez le client.

Deuxièmement

Toujours dans l'exemple des bogues, comment les méthodologies Agile peuvent-elles m'aider avec mon problème? Un bon point de départ est les tests unitaires couplés avec l'intégration continue. Selon mon expérience, cette combinaison peut diminuer le nombre de bogues envoyés au client. Remarquer que vous continuerez à écrire des bogues dans le logiciel. Cependant, l'intégration continue attrapera les bogues avant qu'ils soient livrés au client. Vous pourrez alors les réparer avant la livraison. De nombreuses études démontrent qu'un bogue réparé avant la livraison coûte jusqu'à 4 fois moins cher qu'un bogue livré au client.

Facile mais..

Facile à dire mais difficile à faire. Je suis très d'accord avec vous. L'idée semble noble mais nous avons tous des horaires surchargés. Comment mettre du temps sur ces concepts lorsque votre est chargée. De plus, vous avez sûrement des ressources qui seront réticentes au changement. Alors comment s'y prendre? À mon avis, démarrer avec un projet pilote pour prouver votre point. Avez-vous un projet personnalisé qui démarre pour 6 mois? Si oui, regardez comment l'intégration continue et les tests unitaires peuvent y être intégrés. Je placerais aussi des gens ouverts au changement et prêt à essayer de nouvelles méthodes de faire dans ce projet. J'accompagnerais cette équipe en les encourageant que leurs efforts auront un impact sur le reste de l'entreprise. Donnez leur votre appui et support moral. Dès que le projet pilote se met en branle, gérer le changement. Assurez-vous que l'expérience est positive, même si les résultats seront négatifs.

Quality is free

La phrase peut sembler loufoque. Je crois que la qualité est gratuite puisque le temps passé à bâtir un système de qualité (intégration continue, tests unitaires) n'est pas repris avant la livraison lors d'une séance de tests. Je crois que la phrase suivante du livre Peopleware résume bien le thème sur la qualité.

The trade-off between price and quality does not exist

in Japan. Rather, the idea that high quality brings on

cost reduction is widely accepted.

On revient à notre problème

Par où comment-on avec l'Agilité? Je crois que cela dépend de votre problème. Dans cet article, je souligne l'importance de pratiques d'ingénierie telles que l'intégration continue et les tests unitaires. Ces pratiques proviennent des méthodologies Agile et peuvent vous aider à résoudre votre problème de qualité. Cependant, si vous problème est plutôt vers le manque de communication, Scrum est une méthodologie plus appropriée pour vous. Hélas, on en reparlera dans un autre article sur ce blogue.

Lean management et... St-Hubert

Publié par Louis-Philippe Carignan le samedi 4 avril 2009 à 04:24

J'étais au comptoir pour emporter hier soir au St-Hubert. J'ai été surpris de voir un chronomètre pour la commande à l'auto. Un écran montrait le temps d'attente moyen entre le moment où le client passe sa commande et la reçoit au comptoir à l'auto. Comment rattachons-nous cet exemple à Lean Management? Le but du système est de livrer la commande au client. Il faut donc une mesure qui dérive du but du système. Dans ce cas-ci, c'est le temps de livrer la commande. Pour améliorer l'unité de mesure, c'est-à-dire diminuer le temps d'attente, le management doit agir sur le système (le resto St-Hubert).

Par exemple, si on a un nouveau cuisinier, il y a de forte chance que le temps d'attente augemente. Le management devra donc former les nouveaux cuisiniers pour garder le temps d'attente bas. Cepedant, juste à voir l'équipe travailler à l'heure de pointe, j'ai l'impression que la machine est déjà bien "rodée" chez St-Hubert.

Question pour les lecteurs: Si l'on entraîne les nouveaux cuisiniers qui se joignent à l'équipe chez St-Hubert de façon à garder le temps d'attente bas, est-ce que de votre côté vous formez les nouveaux membres de vos équipes de développement dand le même objectif? Sont-ils perdus pendant plusieurs semaines à tenter de comprendre un demi-million de lignes de code de votre produit? Ah oui, j'oubliais, l'écran du chronomètre chez St-Hubert, c'est le "visual workspace", un outil Lean.

Mots-Clés :

Archive