Lean Software Developement pour Alexandre Boutin de Yahoo!

Lean Software Developement
pour Alexandre Boutin de Yahoo!
Présentations Industrielles ­ Conférence 1
Carlos RAMISCH
éme
ENSIMAG 3 Année – Option ISI – Double diplôme (RI)
1 Introduction
La conférence du vendredi 28/septembre a eu par sujet la méthodologie de développement de logiciel Lean, présentée par Alexandre Boutin, chef de processus chez Yahoo!. M. Boutin a appris la méthodologie Lean directement des auteurs du livre "Lean Software Developpement", Mary Poppendieck et Tom Poppendieck, qui sont les premières personnes a suggérer l'adaptation de la méthodologie Lean au développement logiciel.
Au début, M. Boutin a présenté un bref résume sur l'origine de la méthodologie Lean chez Toyota, pour la production de voitures. Après, il a fait un parallèle entre les techniques et concepts Lean pour l'industrie et pour le logiciel, suivi d'une énumération détaillée et précise des 7 principes Lean.
Finalement, il a présenté quelques considérations et, bien sûr, les utilisations et points forts et faibles de l'idée proposée par Lean, les défis et difficultés, autant que les avantages.]
2 Origine et Concepts
Suite à une brève explication sur l'évolution des processus industriels, M. Boutin à exposé quelques principes crées et utilisées dans la manufacture de voitures chez Toyota. Parmi ces principes, il a expliqué la philosophie stop­the­line, qui veut dire de trouver les défauts le plus tôt possible; et le just­in­time, qui a pour principe de prendre les décisions et les actions juste quand elles sont nécessaires, et pas avant.
Sur le stop­the­line, M. Boutin a démontré quelques positions un peu polémiques, ou au moins, différentes de celles classiques que nous sont présentées en cours. Sur le test, par exemple, il dit que le test n'a pas pour but de trouver les défauts (dans les cours de génie logicielle, on nous a dit que si le test ne trouve pas des défauts, le test est mal fait). Par contre, le test doit éviter les défauts, c'est­à­dire, il doit être fait le plus tôt possible, pendant le codage. Aussi, ce principe élimine une des règles traditionnelles de que la personne ou équipe qui code et la personne ou équipe qui fait le test ne soit pas la même, bien comme le principe que le test doit détecter les erreurs pour qu'après, dans une étape de manutention, les erreurs soient corrigées.
Un des point les plus emphatiques de la présentation a été la interdiction à des grandes listes ou queues de tâches. Selon le just­in­time, le temps perdu dans le changement de contexte pour faire beaucoup de tâches en parallèle est assez important par qu'il diminue la productivité des équipes. Cela aussi peut être contraire à des approches de la génie logicielle, une fois que en GL, on essaye de tout spécifier, avoir un grand cahier de charges et, après, distribuer les tâches pour les équipes. À mon avis, ce principe est très intéressant et, d'après mes expériences professionnelles, il se vérifie la plupart des fois.
3 Les 7 principes de la méthodologie Lean
L'élimination du gâchis
Pour bien structurer la présentation de la méthodologie, on a divisé les sujets en 7 points distincts pour qu'une équipe ou un projet de développement logiciel soit Lean. Le premier point abordé a été l'élimination de gâchis (waste). Le gâchis dans la production industrielle ont une relation assez logique avec les gâchis de la production du logiciel. Par example, la surproduction d'un usine peut être comparé avec les fonctionnalités inutiles d'un logiciel. Ainsi, M. Boutin à établi des parallèles entre les 7 types de gâchis dans la manufacture et leurs équivalents dans le logiciel.
On a discuté un peu sur l'importance de l'élimination du gâchis pour augmenter le profit d'une entreprise, et on nous a présenté quelques techniques pour sa mise en œuvre, comme la taille du cycle de vie et des notations graphiques qui permettent avoir une vision plus précise du développement.
L'optimisation de l'ensemble
Ensuite, le deuxième principe est de optimiser l'ensemble, c'est­à­dire, de concevoir le logiciel dans un contexte et pas comme un module isolé des autres parties d'une organisation. Un point important ici est considérer que le logiciel est un produit plutôt qu'un projet. Comme ça, on peut prendre en compte des différents aspects importants, comme la évolution des besoins, le changement de l'environnement et l'importance de l'équipe et de la documentation pour la réussite du logiciel. Aussi, l'approche produit permet une approximation plus efficace entre le client et le logiciel pendant son développement, à fin de obtenir la satisfaction du client au bout d'un projet.
L'optimisation des processus et des équipes fait partie aussi de la méthodologie Lean, mais elle doit être conçu pour l'ensemble et pas pour les modules indépendants. Le rôle des chefs des équipes a été présenté par M. Boutin, en remarquant que l'existence de trop des niveaux de hiérarchie peut aussi être considéré du gâchis.
La qualité dès le début
Le troisième point concerne la qualité du logiciel. Selon les méthodes Lean, le logiciel doit être construit avec de la qualité dès le principe. Cependant, aujourd'hui la plupart des entreprises ne fait pas comme cela: il y a des étapes de test intensif et de correction de bogues après la codage, qui ont pour bout d'augmenter la qualité du logiciel avant de le délivrer. Avec ce principe, on peut trouver une relation intéressante entre les outils Lean et le modèle du cycle de vie itératif, plus spécifiquement les méthodes agiles (Xtreme Programming), où les phases de test et de correction sont exécutées à chaque itération, avec des itérations courtes (1 à 4 semaines, d'après M. Boutin).
Lean considère aussi très important faire du refactoring, c'est­à­dire, les transformations du code qui ne changent pas ses fonctionnalités mais qui améliorent sa lisibilité, en diminuant la complexité qui peut déranger la suite d'un projet. Toute complexité, selon M. Boutin, doit être évité: les branches de version parallèles, la taille des jeux de test, l'incohérence, etc.
La synchronisation est un point délicat dans les équipes de développement. Souvent on voit des projets qui ont des étapes de synchronisation très longues (et chères!). C'est pourquoi la synchronisation doit être faite plus fréquemment. À mon avis, il y a un peu d'exagération quand M. Boutin suggère des synchronisations tous les minutes (lui même avoue qu'il n'est pas d'accord avec cela). Quand même, à mon avis, elles doivent être plus fréquentes mais pas à chaque minute ou chaque heure, puisque cela peut même déranger les développeurs.
Reporter le compromis
Dans le 4ème principe, M. Boutin a présenté l'importance d'avoir des plans flexibles ou, selon lui, tolérants aux changements. Encore une fois, on voit le parallèle entre Lean et les méthodes agiles, qui ont le même principe. La souplesse doit être appliqué aussi aux relations inter­personnelles, comme par exemple simplement pour prendre un rendez­vous. Dans cette partie de la présentation, M. Boutin a donnée un exemple pratique de comment la flexibilité peut améliorer et optimiser la communication entre les personnes. Ce type de comportement s'appelle set­based design, et s'adapte plus facilement aux changements qu'une approche ponctuelle.
Livraison rapide
Patient Keeper est une entreprise qui développe des logiciels médicaux et hospitalières (assez critiques). Par contre, ils font la livraison d'une nouvelle version chez le client à peu près une fois par semaine. C'est étonnant qu'ils peuvent faire cela quand ils ont un produit tellement critique, et ils réussissent grâce à les méthodes Lean.
La livraison vite permet aux entreprises d'augmenter le profit, et aussi d'augmenter la compétitivité du produit face aux concurrents. Ce principe de délivrer vite, à mon avis, est contraire au principe de la qualité dès le principe, parce que on sait déjà que vitesse et qualité sont mutuellement exclusives. Je crois donc que ce principe est un des plus difficiles à comprendre et à accepter.
Respect pour les gens
Pour commencer à expliquer ce principe, on a fait une hypothèse très logique: les gens sont intelligents, ils ont l'habilitée de se auto­guider. À partir des exemples de ce qui se passe à Yahoo!, M. Boutin à expliqué le principes des petites queues de tâches où les gens vont chercher ses obligations, en oppositions aux grands cahiers de charge traditionnels dans les projets.
Les personnes valorisent dans son travail, avoir de la reconnaissance, de la confiance, du compromis et de la fierté. Ainsi, on peut gérer les équipes basé sur ces principes simples. La confiance et le compromis peuvent être achevées à travers des équipes stables et des cycles de vie avec des itérations petites. La fierté et la reconnaissance sont dues à l'idée de mesurer les capacités de l'équipe et pas des personnes. Aussi, le crédit pour les résultats sont communs à tout le monde.
Création de la connaissance
Les standards sont importants dans le développement logiciel, mais il est important de remarquer que les standards sont la meilleure façon de faire quelque chose dans un instant donné, c'est­à­dire, ils peuvent changer. Aussi, les standards Lean ne sont pas des grands livres de spécification, mais doivent pouvoir être écrits dans un feuille A3. Si on a un souci dans la chaîne, on ne peut pas traiter ses conséquences, mais on doit chercher la racine du problème. Comme ça, on évite les soucis après que le produit est délivré. Les outils pour faire cela sont les révisions du code et la documentation (aussi dans une feuille A3).
4 Conclusions
Finalement, M. Boutin a présenté le bilan de la présentation. Alors, il a établi des parallèles entre les approches classiques et l'approche Lean. Une des différences montrés concerne l'utilisation des ressources: les méthodologies classiques défendent l'utilisation maximale des ressources, pendant que la méthode Lean dit que on ne doit pas faire cela si on veut aller vite. Aussi l'attribution de responsabilités est une différence: Traditionnellement on veut contrôler les équipes pour avoir des réussites, pendant que avec Lean on considère que les gens ont une influence sur l'ensemble qui collabore pour la réussite du produit.
En synthèse, mon opinion sur la présentation est que, même parfois radical, la méthodologie Lean est un ensemble de principes déjà utilisés de façon isolée dans les entreprises. M. Boutin dit que Lean n'est pas une révolution, c'est­à­dire, Lean n'introduit pas des nouveautés pour le développement logiciel. Quand même, la réunion de ces principes et sa structuration logique est très intéressant, et peut être mis en pratique dans beaucoup de situations réels (en fait il est , déjà, mis en pratique dans plusieurs entreprises) avec grandes possibilités d'augmenter la qualité et le profit des logiciels.