Catégorie : Les notions agiles

  • Concept : La vision plutôt qu’un plan de réalisation

    Concept : La vision plutôt qu’un plan de réalisation

    Souvent, pour évoquer l’agilité on parle de la vision et du développement par étape.

    L’erreur la plus commune, comme dans l’exemple de construction incrémentale (étape par étape) de « la joconde » allant d’un point de départ a une finalité de produit. Mais cet exemple est trompeur, car il est important de prendre en compte les changements d’orientations en cours de réalisation et de se reposer les questions sur les orientations choisies.

    Exemple commenté entre la joconde et un tableau de Picasso.

    Un plan de développement incrémentale

    Dans les 3 cas de gauche, il y a un point commun ; la finalité . Tous les déroulements, certes différentes mais il converge tous vers la même définition de « la Joconde ».

    Les plans de réalisation démontrent qu’il est possible de :

    • Dans le cas 1, le travail est fait par région. Celles qui avaient le plus de valeur pour le peintre/le public en premier ?
    • Dans le cas 2, par affinage successif de la qualité du rendu.
    • Dans la cas 3, de manière linéaire haut à gauche vers en bas à droite.

    Mais, ils manquent d’agilité les uns comme les autres car tous arrivent au même résultat, c’est dire qu’elles ont suivi le plan initial.

    Dans ces trois cas on est dans du « Vrum » (cycle en V fait en Scrum), c’est à dire, la réalisation d’une prédiction précise. c’est l’un des pièges les plus courant que l’on rencontre le plus souvent dans les trains qui démarrent.

    Une vision par itération successive

    Dans le cas de droite, on montre les différentes étapes de construction du produit (ici la peinture) et chaque étape (innovation) peut être considéré comme une œuvre à part entière.

    A chaque itération, on passe d’un bouquet de rose, à poisson, une poule, un masque, des ombres qui dansent …

    On comprend du coup, qu’il n’y a pas de plan final détaillé et connu d’avance. Les incertitudes de l’artiste guide la réalisation, sans plan final, avec sa capacité à orienter, pivoter et décider de clore ou pas son œuvre.

    On laisse la place a un monde complexe, rempli d’incertitudes, terrain de jeu favori de l’agilité.

    Il n’y a que la réalisation suivi d’une visualisation (la démo 😁) qui permettra à l’artiste d’affiner et de faire évoluer son œuvre.

    En peinture, les analyses aux rayons X d’un grand nombre de tableaux ont montré des constructions similaires, par couches ou itérations successives parfois très différentes du résultat final.

    Voici la vidéo réalisée lors de la création de l’œuvre de Picasso qui démontre les changements d’orientations en cours de réalisation.

  • Concept : la business Value

    C’est quoi ?

    Afin de faciliter la compréhension de la valeur business, il faut comprendre que l’on donne un poids à chaque fonctionnalité (feature) des équipes , du train ou du portefeuille.

    Ce poids correspond à l’importance d’un sujet par rapport un autre dans le fonctionnement pour le produit. Plus le poids est important, plus les éléments évalués sont nécessaires au produit, aux commanditaires ou aux clients finaux.

    Toutefois, il ne faut pas confondre « business value » et priorité. La « business value » définit l’importance et la priorité elle définit dans quel délai je dois réaliser la fonctionnalité.

    Comment définir simplement cette valeur, la valeur métier reflètes les éléments les importants pour les clients, sponsors, partie prenantes, entreprises.

    La valeur peut suivre la suite de Fibonacci et n’est pas limitée en valeur.

    Ce qui nous donne la suite suivante : 0, 1, 2, 3, 5, 8, 13, 21, …

    Par exemple, voici un cas concret dans une équipe projet.

    Ce cas vous donne la méthode pour construire votre référentiel et le partager avec votre équipe ou le communiquer avec vos sponsors.

    Graduellement les apports de fonctionnalités ou action de maintien de niveau de service du produit (redimensionnement de plateforme, patch de sécurité, mise à jour progiciel, renouvellement de l’obsolescence, …) sont valorisés.

    A l’inverse, toutes les actions qui n’impactent pas l’utilisateur (ex: obsolescence matériel ou d’OS, test de PRA, mise à jour de serveurs, …) sont moins valorisées.

    Chaque PO, peut se constituer un tableau de valeur qui est propre à son périmètre :

    Type de Features / USFibonacci 
    Maintient en Condition Opérationnel pour l’utilisateur avec dégradation de service34
    Apport de nouveaux usages innovant ou bénéfique pour l’entreprise 21
    Apport de nouveaux usages client13
    Modification d’usage client existant8
    Maintient en Condition Opérationnel pour l’utilisateur sans dégradation de service (Test de PRA, Patch de sécurité, Automatisation de déploiement)5
    Recherche d’apport pour l’utilisateur (Chantier d’innovation, POC, MCO)3
    Sans apport pour l’utilisateur (Cadrage, Etude de marché, Réunion en dehors du cadre agile) 2
    RIP on le fera sans doute jamais ou le sujet est loin d’être « sec »1

  • Concept : mesurer l’effort

    C’est quoi ?

    Il existe plusieurs méthodes pour mesurer l’effort. Elles ont chacune leur avantage et leur inconvénients.

    L’effort peut être traduit par plusieurs effets comme le temps, la pénibilité, la montée en compétence , la complexité,…

    Les Jours Hommes

    Cette méthode est la méthode la plus ancienne, elle hérité du développement en cycle en V.

    Les jours hommes ont fait leur preuve et sont pratiques lorsqu’il faut appliquer une facturation derrière une fonctionnalité. Toutes fois, elle a un inconvénients lors qu’il faut chiffrer de petites taches car on arrondit souvent à la demi journée supérieure. Du coup plus on multiplie les petites tâches et moins on est précis.

    La taille de T-shirt

    On compare l’effort a une taille de t-shirt, plus le t-shirt est grand plus l’effort est important et inversement. Chaque taille constitut un silo dans lequel on vient ranger les fonctionnalités. La suite de valeur est classique XS, S, M, L, XL, XXL et facile à appréhender. On ne dépassera pas la valeur XL car il vaut mieux découpé en fonctionnalité réduite. Elle souffre d’un défaut majeur, c’est que la notion n’est pas mathématique et donc on ne peut pas faire de somme par exemple.

    Le Système de Points ❤

    Le système de point associés à la suite de Fibonacci (1,2,3,5,8,13,21,…) permet finalement de se rapprocher des tailles de T-Shirt tout en étant compatible avec les notions mathématiques. Le nombre de point ne doit pas excéder 8, au-delà, il faudra songer à découper.

  • Concept : la priorisation

    C’est quoi ?

    En fonction du cadre de travail utilisé, la priorisation n’aura pas la même signification. Scrum s’applique à une équipe unique, la priorisation donnera le tempo de l’équipe. Dans SAFe, la priorisation donnera le périmètre minimum à réaliser.

    Scrum ou SAFe Scrum : l’équipe de développement / Product Owner

    Cette notion traduit le « Quand ? », elle induit la notion délais de rapidité d’exécution à partir de la planification.

    La priorisation définit le dessus de la pile de travail.

    Plus la priorisation est grande et plus vite le sujet sera traité le moment venu.

    Plus la priorisation est petite, le délai de réalisation est souple (+X Jours).

    Attention, la réalisation devra tout de même être faite dans l’itération. Seul le PO peut modifier la planification ou annuler la réalisation.

    La priorisation est souvent exprimée en niveau qu’il soit en français ou en anglais, par exemple :

    • Très basse
    • Basse
    • Normal
    • Haute
    • Très haute

    SAFe : Product manager / Solution manager / Business Owner

    A ce niveau, la priorisation prend une autre dimension. La temporalité est secondaire à l’échelle du train et la question est plutôt « que fait-on en priorité ? ».

    Une des solutions lors de la priorisation du backlog est de répartir avec la règle des 80% / 20%. On sélectionnera les fonctionnalités les plus intéressantes (80%) représentant le cœur des fonctionnalités voulues, le reste est du bonus si possible.

    L’un des outils les plus adaptés est la méthode MoSCoW.

    La méthode Moscow traduit la priorité en 4 catégories :

    • Must have : Obligatoire. Le projet n’échoue pas si cette partie est réalisée.
    • Should have : Souhaité. Le projet est réussi si cette partie est réalisée.
    • Could have : En bonus. Le projet est au delà des espérances si cette partie est réalisée.
    • Won’t have : Hors périmètre.