Open Agile

Suite à mon précédent billet sur la planification en méthode Agile dans lequel j’avais abordé le principe du planning de release et d’itération, je vous propose de continuer sur la planification est de développer le planning de release. Dans un prochain billet, je détaillerais la réalisation du planning d’itérations.

Au point de départ, nous avons un client qui nous a contactés pour développer une application. Ce projet est constitué d’un ensemble de besoins à la fois fonctionnel et technique (backlog).

La première action à réaliser dans le cadre de ce projet est de définir le planning de release. L’objectif est d’avoir une vision globale du projet en terme de planning, d’activité et de coût.  Comment réaliser un planning de release ? Le schéma suivant nous donne une première approche, que nous allons détailler par la suite.

Un projet est soumis à plusieurs conditions, qui sont régies par le classique triangle : ressources (coût, budget), calendrier, périmètre (fonctionnalités, caractéristiques). Ce sont ses éléments qui vont nous permettre de constituer notre planning de release. Prenons un simple exemple, un client souhaite X fonctionnalités avec un cout de X euros. Après une première estimation des besoins du client, nous devons lui indiquer que par rapport aux coûts nous ne pourrons pas respecter le périmètre. Nous devons appliquer des priorités sur les fonctionnalités avec notre client pour choisir ce qui peut-être fait avec son budget.

L’exercice est de définir un planning de release selon les conditions inhérentes au triangle du projet.  Nous pourrons réaliser un premier planning qui sera adapté et modifié selon les contraintes de ce triangle et ceci en relation avec notre client.

Remarque : Comme je l’ai déjà indiqué dans mes précédents billets, je n’utilise pas la notion de « vélocité » et de « user story » dans mes projets.  Ces deux éléments sont trop vagues pour réaliser un projet en mode forfait, ce qui représente 100% de notre activité de développement.

Les activités à réaliser pour créer notre planning de release sont les suivantes :

• Identifier les cas d’utilisation
• Sélectionner la longueur d’une itération
• Estimer la charge par cas d’utilisation
• Appliquer les priorités sur les cas d’utilisation
• Sélectionner les cas d’utilisation et les date de release

Identifier les cas d’utilisation

L’identification des différents cas d’utilisation est réalisée à partir d’un cahier des charges fourni par le client, d’une liste de fonctionnalités attendues dans le programme, etc.

La première démarche est de compartimenter en cas d’utilisation ou story (pour les non-techniques) les besoins fonctionnels et un cas d’utilisation transverse pour les éléments technique. Cette activité est réalisée par le product ower et le client. Ce sont les acteurs qui ont la vue fonctionnelle du projet.  La partie technique sera abordée lors de la constitution du planning des itérations par l’équipe du projet. Il est important de créer un cas d’utilisation tranverses qui prend en compte les besoins du client, car il peut impacter de manière importante sur le budget et le calendrier de projet.

Pour permettre une évaluation budgétaire réaliste du projet (et surtout éviter de s’en rendre compte au milieu ou à la fin du projet), nous essayons d’obtenir une bonne granularité de nos cas d’utilisation. C’est à dire une cinématique nominale pour chaque d’utilisation. Ce qui pourra se traduire sous la forme suivante :

Contexte :

Un utilisateur souhaite se connecter à l’application. Cet utilisateur possède un compte dans le référentiel de données.

Acteurs :

• Collaborateur : utilisateur référencé dans le référentiel de données
• Administrateur : Collaborateur ayant des droits d’administration.

Description du use case :

Ce mode d’authentification permet à un collaborateur de se connecter à l’application. Celui-ci accède à une page d’authentification où il saisit son couple identifiant/mot de passe. Le système vérifie les paramètres d’authentification auprès du référentiel de données.

Pré-requis :

L’utilisateur est enregistré dans lle référentiel de données.

Descriptif du cas d’utilisation

1. Le collaborateur ouvre son navigateur et accède à l’application
2. Le système demande son couple identifiant/mot de passe à l’utilisateur
3. L’utilisateur saisit son couple identifiant/mot de passe et valide
4. Le système vérifie les informations en relation avec le référentiel de données. En cas d’échec, on retourne à l’étape 2
5. Dans le cas d’une première authentification, le système initialise et crée un compte utilisateur dans le référentiel de données. L’application redirige l’utilisateur vers la page principale de l’application.

Post-conditions :

Un compte utilisateur a été créé (en cas de première authentification) dans le système. L’utilisateur est sur la page principale de l’application et peut commencer à l’utiliser.

A la fin de cette phase, nous avons identifier les différents cas d’utilisation. Nous passer à la phase suivante.

Sélectionner la longueur d’une itération

Comme je l’ai expliqué précédemment dans mon billet sur « le planning en méthode Agile », la longueur d’une itération est subjective, la majorité des projets agile utilise une longueur de 30 jours (quatre semaines). Cette période ne doit pas être considéré comme acquise, car elle peut à la finalité, nous poser des problèmes dans notre projet. Je conseille  de prendre le temps de bien choisir sa longueur lors de la conception du planning de release.

Certains éléments du projet doivent nous aider à définir la période d’une itération. Le premier point qui peut nous aider concerne la longueur du projet dans sa globalité, si nous travaillons sur un petit projet avec de nombreux cas d’utilisation ou story, il est plus intéressant de faire des itérations courtes pour que l’équipe en charge de l’intégration puisse les valider rapidement. Inversement, tous les projets n’ont pas la chance d’avoir une équipe d’intégration attitrée, le planning peut aussi dépendre de leur disponibilité.
Pour choisir la longueur d’une itération,  Je vous propose une petite liste de facteurs qui peuvent vous aider à la définir :

• La taille du projet
• Le nombre de cas d’utilisation
• Les priorités du client en terme de calendrier
• La flexibilité au changement
• L’implication du client dans cette méthode de projet
• La présence d’une équipe d’intégration spécifiquement sur ce projet
• La politique de l’entreprise sur le projet
• Le taux d’incertitude sur la mise en oeuvre de certaines fonctionnalités

Ce qu’il faut retenir :  Il faut choisir une longueur et la conserver tous au long du projet. Cette longueur correspond au rythme du projet et de l’équipe. L’équipe prend son tempo sur ce rythme et le conserve, un changement de longueur engendrerait une coupure dans ce rythme et perturberaient rapidement les équipes et le rendement du projet.

Estimer la charge par cas d’utilisation

Un planning de release est un planning avec une vision très macro à la différence d’un planning des itérations. Néanmoins, il ne faut pas penser que le travail de calcul des charges doit se faire à la légère. Dans mon précédent billet sur le planning poker, je vous avais présenté une méthode pour calculer les charges par cas d’utilisation. L’activité de planification est réalisée de la même manière pour calculer les charges par cas d’utilisation.

Le calcul de charge ne porte pas exclusivement sur le développement, mais aussi sur la partie spécification (conception) et intégration. Dans notre méthode de travail, nous calculons les charges en idéal days et non en vélocité. La vélocité est considérée comme trop floue par nos clients et les équipes.

Chaque cas fonctionnel est présenté à l’équipe projet par le product ower (par celui qui à la vision la plus fonctionnelle du projet), une première planification est réalisée par la méthode du planning poker.

Les charges pourront être réajustées après la réalisation du planning des itérations (identification des taches par cas d’utilisation). À la fin de ce travail, nous obtenons notre tableau des charges par cas d’utilisation :

Appliquer les priorités sur les cas d’utilisation

Un des points les plus importants du planning de release est d’appliquer une priorité sur chaque cas d’utilisation. En effet, cela permet de sélectionner les cas d’utilisation qui devront être développés en premier. Cette priorité est appliquée par le client et le responsable du projet, néanmoins, il est important de prendre en compte l’avis des développeur qui peuvent apporter une vision différente concernant la chronologie de réalisation des cas d’utilisation, ainsi que le risque afférent à chaque cas d’utilisation. .

À la fin de ce travail, nous obtenons notre tableau des priorités par cas d’utilisation :

Sélectionner les cas d’utilisation et les dates de release

Après toute cette activité que l’on peut quantifier au maximum sur 2 jours (selon la taille du projet et l’expérience des acteurs), nous avons les éléments suivants :

• La longueur d’une itération,
• Une liste des cas d’utilisation, avec leurs priorités et les charges.

Nous sommes fin prêts pour réaliser notre planning de release. Ce travail est maintenant assez simple, nous allons  associer les cas d’utilisation et les itérations. Pour ce faire, nous prenons les cas d’utilisation prioritaires, nous prenons leurs charges, nous les positionnons dans les itérations.

Nous avons sélectionné pour ce projet une longueur d’itération de 30 jours. Nous allons créer le planning suivant :

Nous avons dans notre exemple 2 itérations, nous pouvons proposer le planning de release suivant :

• La première livraison au bout de 30 jours comportant 3 cas d’utilisation
• Une deuxième livraison au bout de 60 jours avec l’ensemble du projet.

Il faudra prévoir d’autres livraisons après les retours du client à propos de la première livraison et ensuite lors de la deuxième livraison.

En méthode Agile, il existe deux types de plannings, le planning de release et le planning des itérations (ou sprint).

Planning release

Le planning release permet d’avoir une vision de la réalisation du projet dans sa globalité. Nous pouvons comparer un planning de release à une roadmap d’un projet.

L’exercice à réaliser dans un planning de release est d’évaluer grossièrement les fonctions qui seront livrées à une date donnée (date driven) ou choisir une date de livraison brute pour un lot de fonctionnalités (feature driven). Un planning de release est constitué de jalon qui représente le périmètre du projet à un moment donné.

Le but du planning release est d’avoir assez d’informations pour décider si le projet produira assez de ROI (Retour sur investissements) pour au moins le payer (et gagner de l’argent). Il permet de définir les fonctions que nous devrons développer en priorités (on n’oublie pas la règle des 80/20). Il indique au client, à l’équipe, à la communauté les différentes dates de livraisons.

C’est durant l’étape de définition, du planning release que l’on choisira la durée d’une itération. On parle souvent de sprint de 30 jours en Scrum, ce choix est assez arbitraire et ne se justifie pas, si ce n’est pour indiquer que cela doit être un maximum. Le choix de la longueur d’une itération doit être sélectionnée par rapport au planning de release global et les fonctionnalités du projet. Si le projet est constitué de nombreuses petites fonctionnalités sur un laps de temps court (3 à 4 mois de projet), il est peut-être plus intéressant de faire des itérations de 15 jours pour les faire tester par le client ou les bêta-testeur.

Un planning release est constitué de plusieurs itérations (ou sprint), qui elles-mêmes incluent les fonctionnalités du projet (backlog) au sens fonctionnel.

Planning des itérations

A la différence d’un planning de release qui est une vue de haut niveau du projet, le planning des itérations est une vue à court terme avec plus de détail. Un planning des itérations détail ce qui est nécessaire pour réaliser dans sa globalité une fonctionnalité (un cas d’utilisation).

Un planning d’itérations est constitué de cas d’utilisation (ou story) avec les tâches associées.

Lors de mon dernier billet sur le planning poker, je vous avez indiqué que je détaillerais la méthode (carte et attribution des points) pour bien mettre en œuvre cette technique. Me voila de nouveau pour clore ma présentation sur le planning poker.

Le Planning poker combine des opinions d’experts, des analogies et des échanges dans une ambiance agréable et ludique, qui permettent d’obtenir des estimations rapides avec des résultats fiables.

Les participants au planning poker inclus tous les développeurs de l’équipe. Rappelez-vous que le terme développeurs en méthode agile se réfère à tous les programmeurs, testeurs, ingénieur système, ingénieurs base de données, les architectes, concepteurs de l’interaction avec l’utilisateur, et ainsi de suite.

Sur un projet agile, qui ne dépasse pas généralement plus dix personnes. Si c’est le cas, il est généralement préférable de se séparer en deux équipes. Chaque équipe pourra alors faire une estimation de manière indépendante. Le directeur de produit participe à la planification, mais il ne fait d’estimation.

Au début de la planification, chaque participant reçoit un jeu de cartes. Chaque jeu de cartes distribué doit permettre de réaliser une estimation fiable. Chaque participant peut, par exemple, recevoir un jeu de cartes qui va de 0, 1, 2, 3, 5, 8, 13, 20, 40 à 100. Les cartes doivent être prêtes avant la réunion de planification et les nombres doivent être assez grands pour être vu de l’autre côté de la table.

Pour chaque cas d’utilisation ou fonction à estimer, un animateur lit le descriptif. Le modérateur est généralement le directeur de produit ou un architecte. Toutefois, le modérateur peut être n’importe qui, car il n’existe pas de privilège associé avec le rôle. Le directeur de produit répond à toutes les questions des participants. Néanmoins, tout le monde doit savoir qu’à un certain moment les discussions complémentaires ne conduisent pas à améliorer la précision. L’objectif avec le planning poker est de ne pas procéder à une estimation qui supportera toutes les futures fonctionnalités. Au contraire, l’objectif est de qualifier la première vue pour arriver sur la fin à une estimation fiable, d’où une première estimation peut être considérée à « bon marché ».

Après que toutes les questions ont trouvé des réponses (enfin, on essaye), chaque participant choisit une carte représentant son estimation. Les cartes sont montrées une fois que chaque participant a fait son choix. À ce moment-là, toutes les cartes sont retournées en même temps de manière à ce que tous les participants puissent voir chaque estimation individuelle.

Il est très probable à ce stade que les estimations diffèrent sensiblement. Il s’agit en fait d’une bonne nouvelle. Si les estimations diffèrent, les participants avec des valeurs hautes et des valeurs basses doivent expliquer la raison de leurs estimations. Il est important que cela ne fonctionne pas comme un reproche à l’intention des participants. Mais un échange sur des visions différentes.

A titre d’exemple, un participant avec une estimation haute peut dire: Eh bien, pour tester ce cas d’utilisation, nous devons créer une base de données avec des objets fictifs. Cela pourrait nous prendre un jour. Je pense aussi que l’algorithme de compression n’est pas bon, ce qui impliquerait d’en développer un nouveau plus efficace . Le participant qui a fait une faible estimation peut répondre : Je pensais que nous allions stocker les informations dans un fichier XML – ce qui serait plus facile qu’une base de données.

Le groupe peut discuter de nouveau sur le cas d’utilisation et de leurs estimations respectives quelques minutes de plus. Le modérateur peut prendre des notes qu’il pense utiles pour le développement et le test de ce cas d’utilisation. Après la discussion, chaque participant fait une nouvelle estimation en sélectionnant une carte. Les cartes sont une fois de plus gardées secrètes jusqu’à ce que tout le monde ait réalisé son estimation au cours de laquelle elles seront affichées en même temps.

Dans de nombreux cas, les estimations convergent déjà au second tour. Mais si cela n’est pas le cas, il faut continuer à répéter le processus. L’objectif pour les participants est de converger vers une seule estimation qui peut être utilisée pour le cas d’utilisation. Cela prend rarement plus de trois tours de scrutin, mais le processus doit continuer jusqu’à ce que les estimations convergent. Il n’est pas nécessaire que tout le monde dans la pièce retourne une carte avec exactement la même estimation. Si je suis un modérateur et sur le deuxième tour quatre participants proposent, 5, 5, 5 et 3, je vais demander au participant qui a fait la plus faible estimation, si il est OK si on décide d’une estimation à 5. Encore une fois, l’estimation ne nécessite pas une précision absolue, mais raisonnable.

Le droit à la discussion

Certaines discussions sur la conception préliminaire du cas d’utilisation sont nécessaires et appropriées, lors de l’estimation. Toutefois, dépenser trop de temps sur des discussions à propos de la conception est souvent un gaspillage d’efforts et de temps. Voici un moyen efficace d’encourager certains débats, mais assurez-vous qu’il ne va pas trop durer.

Acheter un sablier, et placez-le au milieu de la table de poker où la planification est en cours. Toute personne assistant à la réunion doit pouvoir voir le compte à rebours à tout moment. Lorsque le sablier est épuisé (environ deux minutes), la prochaine série de cartes est jouée. Si un accord n’est pas atteint, la discussion peut se poursuivre. Mais quelqu’un doit tourner immédiatement le sablier pour limiter la discussion à deux minutes. Le sablier n’a rarement besoin d’être utilisé plus de deux fois. Avec cette méthode, les équipes apprennent à estimer plus rapidement.

Les petites sessions

Il est possible de jouer au poker avec un sous-ensemble de l’équipe, plutôt que de tout le monde. Ce n’est pas idéal, mais cela est parfois une option raisonnable, surtout si l’équipe est nombreuse, s’il y a beaucoup de cas à estimer, comme cela peut se produire au début d’un nouveau projet.

La meilleure façon d’y parvenir est de scinder la plus grande équipe en deux ou trois petites équipes, dont chacun doit disposer d’au moins trois participants. Il est important que chacune des équipes de participant estime successivement.

Pour ce faire, commencer avec toutes les équipes ensemble dans une session de planification conjointe d’une durée d’une heure environ. Demandez-leur une estimation pour 10 à 20 cas d’utilisation. Ensuite, assurez-vous que chaque équipe a une copie des cas d’utilisation et leurs estimations et qu’ils les utilisent comme base pour estimer les cas d’utilisations qu’ils leur sont donnés à estimer.

Quand jouer au planning poker

Les équipes devront jouer au planning poker à deux moments différents. Tout d’abord, il sera généralement nécessaire de faire des estimations sur un grand nombre de cas d’utilisation avant que le projet ne commence officiellement ou au cours de sa première itération. Estimer une première série de cas d’utilisation avec l’équipe sous la forme de deux ou trois réunions allant d’une à trois heures chacune. Naturellement, cela dépendra du nombre de cas d’utilisation à estimer et de la taille de l’équipe, et si le directeur de produit a les capacités de préciser les exigences de manière succincte.

Deuxièmement, les équipes devront faire de nouveaux efforts à chaque nouvelle estimation de cas d’utilisation qui sont identifiés au cours d’une itération. Une façon d’y parvenir est de planifier une estimation sous la forme de réunion très courte vers la fin de chaque itération. Normalement, cela est tout à fait suffisant pour estimer les travaux qui sont à réaliser au cours de l’itération, et permet d’obtenir les priorités à appliquer à l’itération en cours.

Sinon, Kent Beck propose une enveloppe accrochée sur le mur avec tous les nouveaux cas d’utilisation positionnés dans l’enveloppe. L’équipe va récupérer un ou deux cas d’utilisation dans l’enveloppe et les estimer. Les équipes doivent établir une règle pour eux-mêmes, généralement que tous les cas d’utilisation doivent être estimés d’ici la fin de la journée ou à la fin de l’itération. J’aime bien l’idée d’accrocher une enveloppe sur le mur qui contient les cas d’utilisation non estimés. Toutefois, je préfère lorsque quelqu’un qui a un peu de temps consacre quelques minutes à faire une estimation, il trouve au moins une autre personne et ils font une estimation conjointe.

Pourquoi le planning poker fonctionne

Maintenant que je viens de décrire la mise en oeuvre du planning poker, je vous propose de passer un petit moment sur les raisons pour lesquelles il fonctionne si bien.

Tout d’abord, le planning poker rassemble de multiples expertises pour réaliser les estimations. Parce que ces experts forment une équipe pluridisciplinaire sur un projet de développement applicatif, ils sont le plus à même pour estimer une tâche que d’autres personnes. Après avoir réalisé un examen approfondi de la littérature sur les estimations des charges en développement, Jørgensen (2004) a conclu que les personnes les plus compétentes pour résoudre la tâche doivent l’évaluer .

Deuxièmement, un dialogue animé s’ensuit au cours de la planification, et les planificateurs sont appelés par leurs pairs pour justifier leurs estimations. Cela a été proposé pour améliorer la précision de l’estimation, en particulier sur les cas d’utilisation avec de grandes quantités d’incertitude (Hagafors et Brehmer 1983). Être invité à justifier les estimations a démontré que cela se traduit par une meilleure estimation pour compenser les informations manquantes (Brenner et coll. 1996). C’est d’autant plus important sur un projet agile parce que les cas d’utilisations sont souvent intentionnellement vagues.

Troisièmement, des études ont montré que la moyenne des estimations individuelles conduit à de meilleurs résultats (HOEST et Wohlin 1998) de même que des discussions de groupe de planificateurs (Jørgensen et Moløkken 2002). Le groupe de discussion est la base du planning de poker, et ces discussions aboutissent à une sorte de moyenne des estimations individuelles.

Finalement, le planning poker fonctionne parce que c’est amusant !

La définition des plannings est des charges associées à un projet sont un mélange d’expérience, d’échange et un peu de hasard. Je vous propose dans ce billet une méthode ludique et en équipe pour définir les charges d’activités sur les projets. Cette méthode découle des méthodes de gestion de projet Agile.

Le Planning Poker est l’un des outils de la méthode Scrum. Il permet à une équipe lors d’une réunion de planification de donner des cotations pour le développement d’une fonctionnalité. Lors de la réunion, le product owner (directeur de produit) représente le client, le commanditaire. Il donne l’ordre dans lequel doit s’effectuer les développements des nouvelles fonctionnalités. L’équipe a pour responsabilité de donner des quantifications au directeur de produit afin que celui-ci sache aussi que telle fonctionnalité coûte 10 unités et qu’une autre fonctionnalité ne coutera que 2 unités. A noter que je ne parle pas de jour/homme pour l’instant. Et c’est là qu’intervient le Planning Poker.

Mettons-nous en situation. Vous réunissez votre équipe de 5 personnes dans une salle. Vous demandez à tout le monde “combien de temps pour développer l’ajout de la fonction X sur mon logiciel ?” .

Mr A pense qu’il sait exactement ce qu’il faut faire, donc il pense 5 jours. Mr B et Mr C sont plus prudents. Mr D et E ne participent pas activement à la conversation et n’écoutent pas. Bref, c’est Mr A qui prend la parole et qui vous répond, “Je pense 5 jours“.

L’équipe est influencée par la première personne qui s’exprime. C’est un risque important, car en fait on voit que B et C pensaient que cette fonction demande plus de temps à développer. Nous risquons de perdre de l’information ici et leurs doutes doivent être exprimés.

Reprenons la même scène avec le planning poker. Le principe est de donner à chacun de vos équipiers un jeu de carte spécial, le fameux Planning Poker dont voici une photo :

Vous distribuez un jeu complet à chacun de vos équipiers.

Comme vous pouvez le constater, les cartes ne se suivent pas. Elles sont basées en partie sur la suite de Fibonacci afin de forcer les personnes à trancher. L’unité n’est pas le nombre de jours/homme, mais une unité arbitraire. Il est important de donner un jeu à chaque personne de l´équipe.

Ensuite voici comment se déroule la séance : refaisons l’évaluation. Le product owner (directeur de produit) dit :

L’équipe lui pose des questions afin d’affiner la demande pendant environ 5 mn. Ensuite commence la phase du vote. Chacun prend une des cartes et la pose devant lui face cachée. Cette fois-ci chacun pense librement et activement. Mr D et Mr E sont obligés aussi de participer. Une fois que tout le monde a sélectionné une de ses cartes, on retourne celle-ci en même temps et le résultat du premier vote est discuté par l´équipe.

Cette fois-ci nous voyons bien qu’entre Mr A et Mr C, une discussion s’impose à propos de l’histoire. Après quelques discussions, Mr A réalise qu’il a oublié une partie du développement et qu’il faut l’inclure. Mr C réalise qu’avec la proposition de Mr A en effet il est possible de réaliser plus rapidement la fonction et que donc son estimation est un peu trop pessimiste. Après 5 mn, toute l’équipe refait une estimation en reprenant les cartes, et en sélectionnant une nouvelle carte, ou la même s’ils n’ont pas changé d’avis.

Voilà maintenant une cotation réaliste et réalisable de la demande initiale. Les développeurs se sont parlé activement afin de présenter une vision sur la solution envisagée. Et tout le monde y a participé. Ce qui est aussi efficace en terme d’échanges et de communications.

Il existe quelques cartes spéciales:

• la carte 0 représente une fonction qui est déjà implémentée
• la carte ? représente le fait que vous n’avez vraiment aucune idée sur la question
• la carte “tasse de café” c’est le joker pour signaler que vous voulez faire un break

Ressources complémentaires:

Vous pouvez fabriquer un jeu de cartes avec quelques fiches cartonnées ou en acheter un à cette adresse CRISP

Vous retrouverez aussi la version en anglais (CRISP) de cet article que j’ai librement traduit à cette adresse et donc le crédit de cet article va en premier à Crisp SE. Merci à eux.

Je vous prépare pur la prochaine un billet qui décrit la valeur des cartes et l’attribution des unités.

J’ai évoqué plusieurs fois la méthode Lean Software Development, j’avais envie de vous la présenter cette technique pour mieux expliquer son but. Mais avant d’aller plus loin, commençons par les origines de la lean Thinging, cela nous permettra de comprendre la cible attendue par cette technique.

Dans les années 40, une petite société nommée Toyota avait l’intention de fabriquer des voitures au Japon. Mais il avait un problème. Puisque les gens n’avaient pas d’argent, les voitures devaient être bon marché. La production de masse était le moyen le moins cher de faire des voitures, mais la production de masse destinée à fabriquer des milliers de voitures du même type, et le marché japonais n’était tout simplement pas compatible, le marché était trop petit pour toutes ses voitures. Donc la question a été, comment Toyota pourrait faire des voitures en petites quantités tout en restant bon marché ?

De ce dilemme, le Toyota Production System a émergé pour former la base d’une toute nouvelle façon de penser la fabrication, la logistique, et finalement le développement produit. Le cerveau derrière cette nouvelle façon de penser était Taiichi Ohno, connu comme le père du Toyota Production System. Au cœur de la réflexion d’Ohno, il y a le principe fondamental de la lean thinging: éliminer les déchets.

Voir les déchets :

Apprendre à voir des déchets est la première étape dans le développement de la Lean Thinking. Si quelque chose n’apporte pas directement une valeur ajoutée telle qu’elle est perçue par le client, il constitue un déchet.

Shigeo Shingo, l’un des cerveaux de la Toyota Production System, a identifié sept types de déchets de fabrication. Sa liste a permis à de nombreux chef de fabrication de trouver les déchets où ils n’auraient jamais pensé à regarder. Pour faciliter le travail des responsables de projet de développement logiciels dans leur quête de trouver les déchets, la Lean Software Development à traduit les sept déchets de l’industrie manufacturière dans sept des déchets du développement qui sont :

* Travail partiellement terminé
* Processus complémentaire sans valeur ajoutée
* Caractéristiques supplémentaires sans valeur pour le produit
* Permutation de tâches
* Attente (entre deux tâches par exemple)
* Le mouvement (Aller quelque part pour rencontrer quelqu’un ou aller chercher quelque chose pour obtenir des informations)
* Les défauts, imperfection.

En complément de l’étude des déchets, il existe 6 autres grands domaines :

* Amplification de l’apprentissage par rétroaction. La meilleure approche pour améliorer un environnement de développement logiciel est d’amplifier l’apprentissage. L’accumulation de défauts doit être empêchée en réalisant des tests aussitôt que le code est écrit. Le processus d’étude est accéléré par l’utilisation de cycles itératifs courts.

* Décider le plus tard possible : L’idée est d’attendre ce que les auteurs de ce terme définissent comme « le dernier moment responsable » pour prendre une décision. C’est le moment où, si l’équipe ne prend pas de décision, la décision sera prise pour eux (ne rien faire est un choix). Les avantages en sont d’éviter ou de retarder les coûts du changement.

* Livrer le plus vite possible : C’est la base du développement itératif. Le pourcentage des exigences change des exigences originales de manières non linéairement et ceci plus le temps avance. Typiquement dans les projets de 9-12 mois il y a un changement de 25% (grossièrement) des exigences initiales. Cependant, le cout des exigences augmente par mois de seulement 1 à 2 %.

* Responsabiliser l’équipe : la qualité de l’équipe de développement est le facteur le plus important dans la réussite des projets. Afin d’amener les gens à assumer leur responsabilité, qu’ils soient motivés, et se voient comme une équipe, ils doivent être responsables des résultats et autorisés à en faire une réalité.

* Construire à l’intégrité – à la fois l’intégrité conceptuelle, et la perception de l’intégrité. Les auteurs font la distinction entre perceptions de l’intégrité et l’intégrité conceptuelle. La perception de l’intégrité est l’expérience du client avec votre logiciel. L’intégrité conceptuelle est de savoir comment bien construire de concert l’architecture et les composants du système pour aboutir à la perception d’intégrité. De toute évidence, les tests unitaires et d’intégration sont une partie importante de l’intégrité.

* Avoir une vision d’ensemble : il faut regarder les processus d’abord dans une vue d’ensemble ou de manière holistique, car si vous ne le faites pas, vous pouvez vous retrouver avec des sous-systèmes optimisés ou fragmentés et des solutions qui ne tiennent pas compte de l’ensemble du processus. La résolution habituelle à la résolution des problèmes est de les subdiviser en éléments constitutifs et d’optimiser chaque pièce. C’est suboptimisation, conduite à la «tragédie des biens communs. »

Le secret derrière Lean cela réside dans l’élimination des goulets d’étranglement dans les processus de développement sous-jacents et le renforcement de la rétroaction du cycle.

Un rapport menée par McKinsey baptisé «  »Applying Lean To Application Development And Maintenance,», explique que cette technique peut conduire à des gains de productivité de 20% et 40%, et que la qualité et la rapidité d’exécution peuvent s »améliorer sensiblement en l’espace de quelques mois. (Boost productivity with lean software development)

Évidemment cette article donne une vu très générale de cette méthode, si vous souhaitez approfondir votre connaissance de ce sujet, je vous recommande fortement l’ouvrage : Lean Software Development: An Agile Toolkit qui est l’ouvrage de référence.

Nous voici arrivés à la fin de nos dix principes Agile. Nous finissions sur un des principes que je trouve majeurs pour qui a mis Agile en oeuvre. Celui de la gestion de l’équipe projet.

Le développement Agile repose sur une étroite coopération et collaboration de tous les membres de l’équipe et des intervenants.

C’est une différence et même une divergence par rapport aux méthodes traditionnelles de gestion de projet, ou le chef de projet est celui qui décide et gouverne son projet et souvent de manière unilatérale. Le reste de l’équipe étant essentiellement des exécutants.

Dans un projet Agile, l’ensemble du projet est discuté et partagé avec l’équipe. Le responsable du projet reste néanmoins celui qui prend la décision finale après concertation avec son équipe.

Les principes du développement comprennent le respect des exigences et une documentation légère, et en reconnaissant que le changement est normal et acceptable dans le développement de logiciels.

Cette étroite collaboration rend particulièrement important de clarifier les exigences justes à temps et de garder tous les membres de l’équipe (y compris le produit propriétaire) « sur la même ligne » durant l’ensemble du développement.

Vous ne pouvez certainement pas aller très loin avec des spécifications importantes qui sont réalisées à l’avance et sans une étroite collaboration avec l’équipe. Cas que l’on retrouve trop souvent dans les projets en cascade. Il ne faut pas ensuite s’étonner que le projet ne ressemble pas aux spécifications et encore au réel besoin du client.

Mais contrairement à un projet en méthode traditionnelle, en développement Agile l’équipe travaille vers un objectif commun, créer un meilleur travail d’équipe, favoriser l’esprit d’équipe, et être plus fortes. À la finalité, satisfaire le besoin client.

Si vous travailler avec un responsable qui pense qu’il peut prendre toutes les décisions de manière unilatérale, qu’il possède la science infuse, il est temps de s’en séparer et de changer de méthode de projet !

Dans mes billets suivants, je vous présenterais, comment faire travailler une équipe ensemble avec Scrum