Open Agile

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.

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

Bienvenue sur Open Agile ! Je voulais un peu plus d’espace et pouvoir gérer mon site. Je quitte le blog de LNG pour gérer le mien.