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.

Découverte-Livraison

Publié par Louis-Philippe Carignan le jeudi 29 octobre 2009 à 01:45

Lors du passage de Mary et Tom Poppendieck à l'Agile Tour de Québec, j'ai eu la chance de m'entretenir avec Tom sur différents sujets. Ce qui m'a frappé, c'est son constat face aux nouveautés avec les méthodologies Agile. Selon lui, il n'y en a pas beaucoup depuis les 5 dernières années. Qu'en pensez-vous? Trouvez-vous que les méthodologies Agile progressent? À ma connaissance, le fameux manifeste aura bientôt 10 ans. Ça commence à être vieux l'Agilité ;-)

Cependant, une idée a retenu l'attention de Tom dernièrement. Lors d'une conférence Lean, un atelier apportait une nouvelle perception au développement logiciel. Selon l'idée, le développement logiciel était divisé en 2 parties: découverte du besoin (discovery) et livraison (deployment). Donc, au lieu d'aborder le système de développement de manière traditionnelle, c'est-à-dire analyse-développement-test-déploiment, il s'agirait plutôt d'organiser l'équipe pour découvrir le besoin exact du client et de le lui livrer le plus rapidement possible.

J'ai trouvé l'idée intéressante et e me suis m'y à comparer ça avec des compagnies qui font du juste à temps (Zara, Dell). Ces entreprises cernent le besoin du client et sont en mesure de livrer une solution rapidement. Peut-être que les équipes de développement pourraient s'inspirer de cette idée pour livrer exactement ce que le client veut. Il s'agirait de voir comment organiser nos équipes pour faire ça.

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.

Archive