Aperçu du Framework

Nous Contacter

Cycle de vie Smart Project

  • Cycle de vie complet allant de l’initiation du produit jusqu’à sa mise en production et le support
  • En réponse aux nouveaux défis du « user centric » et de l’amélioration continue de l’entreprise dans son ensemble
  • Agilité au niveau de l’organisation, la culture, la gouvernance et  les Produits / Services

Framework Hybride

Une combinaison savante des Frameworks, méthodes, pratiques et stratégies ayant fait leurs preuves

  • Approche très innovatrice développée par la société GamaaSoft (www.gamaasoft.com)
  • Issue de plus de 20 ans d’expérience pratique en tant que chef de projet, directeur de projet et responsable assurance qualité
  • En réponse aux nouveaux défis du « user centric» et de l’amélioration continue de l’entreprise dans son ensemble

Structure Organisation Smart

Types de Product Delivery Team

  • Single => 1 Agile Delivery Team
  • Large => 2 to 5 Agile Delivery Teams
  • Huge => plus de 5 Agile Delivery Teams (décomposer en sous-produits et réorganiser en équipes  Larges / Singles)

Règles du Product Delivery Team

  • Un seul Product Backlog
  • Un Sprint Backlog par équipe Agile Delivery Team
  • Un Sprint à la fois pour toutes les équipes (sprint planning synchro)
  • Une DoD commune à toutes les équipes
  • Un Shippable Product Increment commun à la fin de chaque Sprint

Règles de Gouvernance (Agile IT)

  • Pas une structure hiérarchique mais des niveaux de gouvernance (Stratégique, Opérationnelle, Tactique)
  • Gouvernance Stratégique: 1 CoPil par Organisation / Portefeuille
  • Gouvernance Opérationnel: 1 CoOp par Portefeuille / Programme
  • Gouvernance Tactique: 1 PDT par Programme

Rôles et Respnsabilités

Rôles Product Delivery

Rôles Opérationnel

Rôles Stratégiques

Résultats

Coordination des équipes

Estimation en «Point» et Vélocité Équipe

Estimation en “Points”

Pourquoi ne pas prendre directement le «Temps» comme unité d’estimation relative?

  • Ce temps varie en fonction de la capacité et de l’expérience de l’équipe. Par exemple un développeur Junior peut estimer une tâche à 3 jours alors qu’un développeur avec plus d’expérience estimera la même tâche à 1 jour
  • Disposer d’une Mesure qui soit propre au Récit Utilisateur (indépendante des moyens mis en œuvre pour le réaliser) est donc nécessaire. Elle tient compte du volume, de la complexité,  du risque et de l’incertitude de l’article à estimer

Par exemple, combien de temps il faut pour aller d’un lieu « A » à un lieu « B »?

  • Par analogie le temps pour aller d’un lieu «A» à un lieu «B» dépend des moyens de transport et de sa vitesse (à pieds, à vélo, voiture, trottinette, etc.).
  • Pour avoir une réponse il faut donc une estimation de la distance (en analogie avec la valeur en «Point» d’un article). Ensuite il suffit de calculer le temps nécessaire en fonction de la vitesse du moyen de transport

Les valeurs relatives des articles de backlog seront donc déterminées en «Points» en se basant sur les nombres de Fibonacci adaptés (1, 2, 3, 5, 8, 13, 20, 40, 100)

Comment faire une estimation relative?

  • L’Equipe commence par choisir un ou plusieurs articles de références, les plus petits, en leur attribuant arbitrairement et de commun accord la valeur 1 chacune
  • Ensuite lors des réunions de chiffrage, l’équipe estime la valeur des articles relativement aux articles de références

Base commune pour une estimation en point

Capacité Équipe

La convention ci-dessous constitue une base commune pour une estimation en «Points» des articles d’un Backlog ainsi que de la capacité d’une équipe

  • 1 Equivalent Temps Plein (ETP) représente 1 jour idéal pour un développeur
  • Pour chaque membre d’une équipe DEV: 1ETP = 8Points
  • Rechercher l’article le plus petit du Backlog (0.5 heure de code et 0.5 heure de test, c’est-à-dire 0.125j de DEV) et lui assigner 1Point
  • Estimer tous les autres éléments du Backlog par rapport ce plus petit élément

Vélocité Équipe

Les règles ci-dessous constituent une base commune pour une estimation en points de la vélocité d’une équipe

  • Le FocusFactor (ou Productivité) représente le pourcentage de temps réellement passé par l’équipe pour coder et tester leur produit
  • Les activités qui ne font pas partie du développement pure en sont exclues:
    • Activités de gestion de projets et gouvernance (ex. rituels SCRUM)
    • Les activités non planifiées mais nécessaires pour la réalisation du produit
    • Toutes les réunions internes et externes
    • Préparation, déploiement, tests et support de releases
    • Etc.
  • Vélocité Equipe = Capacité * FocusFactor
  • Productivité = (Vélocité réelle Equipe) / (Capacité Equipe)
  • La Vélocité réelle sera calculée par la suite en fonction des résultats de l’équipe en fin de sprints
    • Vélocité réelle = ∑(1^n) Size O f (completed user stories in sprinti)/n

Exemple Capacité et Vélocité Equipe en Points

Exemple de définition de la capacité et vélocité Initial pour un Sprint de 2 semaines (10 jours)

Capacité / Vélocité Equipe

NB: Après quelques sprints, la productivité (ou FocusFactor réel) est calculée sur la base de  la moyenne des vélocités de l’équipe sur les sprints précédents

Backlog Produit

Modèle de Priorisation WSJF

Comment calculer le WSJF

WSJF (Weighted Shortest Job First) est un modèle d’ordonnancement des articles d’un Backlog

  • WSJF = (Coût du retard) / (Durée de réalisation)
    • La durée de réalisation sera remplacée par la taille relative en Points de l’article
  • WSJF =  (Coût du retard) / (Taille article)

Exemple de priorisation WSJF

  • Déterminer la valeur relative de chacune des 3 paramètres pour chaque article
  • Evaluer les articles colonne par colonne, commencer par déterminer l’article avec la plus petite valeur en lui attribuant la valeur 1 puis évaluer le reste des articles relativement au plus petit. Chaque colonne à donc une valeur 1 servant de référence.
  • Les articles de plus grande taille doivent être décomposés en en articles de taille raisonnable.
  • Noter bien que l’estimation de la taille d’un article  ne concerne que le reste à faire de cet article

Risque

Définition

Qu’est-ce qu’un risque?
Un risque est défini en gestion de projet comme une situation ou un évènement pouvant impacter la réussite de votre initiative.  Différents types de risques peuvent être identifiés:

  • Les risques associés aux parties prenantes externes: clients, consommateurs, fournisseurs …
  • Les risques internes: membres de l’équipe de projet, l’exécutive …
  • Les risques associés aux projets: besoins technologiques, logistiques…
  • Les risques associés aux évènements: économiques (ex: crise financière), sociopolitique (ex: embargo)

Qu’est-ce que la criticité d’un risque?
La criticité d’un risque c’est le produit de la probabilité qu’un évènement se produise et son impact (l’importance que ces conséquences peuvent avoir sur les critères de succès):

  • Probabilité = {0,1,2,3}
  • Impact = {0, 1, 2, 3}
  • Criticité = Probabilité * Impact
  • Un Obstacle (Impediment en anglais) est un risque avéré (Probabilité = 3)

Qu’est-ce que le Niveau de Risque (ou Risk Exposure en anglais)?
Le Niveau de risque c’est la somme des criticités de tous les risques (Rj) identifiés à un instant donné.  RE = ∑Criticité (Rj)

Analyse et Stratégie

Qu’est-ce que la matrice de priorité?
La matrice de priorité des risques vous permet de classer les risques en fonction de leurs probabilités et de leurs degrés d’impact

  • Les risques majeurs (identifiés par la couleur rouge): vous devez gérer ces risques en priorité, car ils ont une forte probabilité de survenir et/ou leurs conséquences seraient particulièrement néfastes pour votre initiative
  • Les risques intermédiaires (identifiés par la couleur jaune): ces risques sont gérables à condition d’avoir un bon niveau de connaissance à leur sujet
  • Les risques mineurs (identifiés par la couleur verte):  ces risques sont négligeables, soit parce que leur probabilité est trop faible, soit parce que vous pourrez gérer facilement leurs conséquences

Stratégie pour faire face aux risques
L’analyse des priorités implique de porter une attention particulière aux risques identifiés par la couleur rouge:

  • Accepter le risque: vous ne prenez aucune action sur ce risque. Vous jugez que la probabilité qu’il survienne est faible et/ou que vous serez en mesure de gérer les conséquences sur le projet
  • Éviter le risque: faire en sorte que sa probabilité devienne nulle (ex: éviter un outil jugé non fiable)
  • Transférer le risque à une tierce partie (ex: avoir recours à une assurance ou des garanties)
  •  Utiliser des mesures préventives pour réduire les probabilités que l’évènement se produise ou des mesures contingentes qui limitent l’impact du risque

« Nos experts travaillent avec vos équipes sur vos projets pour vous accompagner et aider à sécuriser vos engagements quel que soit votre niveau de maturité Agile. Nous vous aidons à mettre en place écosystème et conditions d’amélioration continue de votre Organisation.  Voir nos services »

Nous Contacter