La gestion même du projet peut sembler se complexifier au regard des ajustements continuels entre les contraintes de délais et de budget. Les risques se multiplient, du fait même de cette gestion, et alimentent les difficultés du Chef de Projet.

C’est dans ce cas précis que la philosophie « agile » prend tout son sens. C’est une approche où le changement et les adaptations sont intrinsèques à l’organisation. Ils sont donc acceptés et mis en œuvre plus facilement par les acteurs du projet.

Dans le domaine informatique par exemple, le rapport CHAOS, publié en 2015 par le « Standish Group » (rapport réalisé à partir de 50 000 projets de développement logiciel à travers le monde.), celui-ci confirme que le taux de réussite des projets « agiles » atteint 39% (toutes tailles de projets confondues) contre 11% de réussite pour les projets en méthode « classique ».

https://www.infoq.com/fr/articles/rapport-chaos-2015

Le travail collaboratif et les itérations réalisées tout au long du projet permettent de rectifier les erreurs au plus tôt dans le projet et plus régulièrement que dans le cadre d’une gestion de projet « classique ».

On favorisera les équipes de petite taille (10 personnes environ) ayant si possible un profil polyvalent. L’expertise de chaque intervenant du projet est un des éléments essentiels et nécessaires pour la réussite d’un projet « complexe ». On conservera si possible la même équipe tout au long du projet.

Autres facteurs impactant les délais

Les erreurs ou omissions dans la définition des objectifs, la disponibilité des ressources, le pilotage des réalisations, etc., sont autant de facteurs de risque menaçant les projets. La première cause de dérive des projets est l’extension des limites du projet au fur et à mesure de sa réalisation : lorsque les limites du projet n’ont pas été correctement fixées, des tendances d’extensions continuelles se manifestent sans que l’on puisse les écarter, faute d’avoir défini des frontières contractuelles claires et précises. La gestion quantitative des ressources ne dispense pas d’intégrer les facteurs humains dans la conduite de projet.

L’approche Agile correspond à un ensemble de bonnes pratiques dont le fondement s’appuie sur des études scientifiques ou plus simplement sur des retours d’expérience acquis au fil des années par les communautés de gestionnaire de projets.

Time box

Cyril Northcote Parkinson, après une longue expérience dans l’administration anglaise, déduit en 1958, qu’un travail tend à se « dilater » pour occuper tout le temps disponible. D’où la nécessité de se fixer un objectif temps (réaliste) pour réaliser une tache et de s’imposer des dates limites de fin de réalisation : le time box.

Se fixer un time box c’est se donner une contrainte de réalisation « au mieux » d’un ou plusieurs objectifs dans un cadre de temps immuable et de préférence le plus court possible. C’est pourquoi une itération doit avoir une durée limitée et fixe dans le temps. Cette approche est fondée sur la prise en compte du caractère subjectif de la détermination qu’un travail est effectivement fini : comme on peut toujours tout améliorer, alors on risque de ne jamais rien finir.

Le principe : la date fixée ne bouge pas, le contenu de l’itération est la variable ajustable (on peut par exemple retirer des taches à réaliser dans l’itération n et les passer en n+1). Si le travail n’est pas terminé dans l’itération n comme prévu alors on fait une rétrospective afin et on corrige le tir pour ne pas recommencer la fois suivante. C’est contraignant au départ mais cela oblige à hiérarchiser les objectifs et donne une cadence à l’équipe mais aussi des repères, des deadlines claires.

Le time boxing peut également aider à :

1. Maîtriser le perfectionnisme : en définissant des objectifs SMART à accomplir avant que le temps alloué ne soit terminé, cela permet de prioriser les choses essentielles, d’éviter de se focaliser sur les détails.
2. Augmenter l’efficacité : on se donne une pression saine et suffisante afin d’effectuer le travail demandé dans un laps de temps réduit.

Planification au fil de l’eau

Au démarrage d’un projet, l’incertitude est grande : elle décroit au fur et à mesure que le travail avance. La Figure 11 donne une idée de son évolution au fil du temps : c’est le cône d’incertitude, popularisé par Steve Mc Connell.

En effet, les estimations sont fausses car elles reposent sur des hypothèses, pas des faits. Or, dans les faits, le contexte d’exécution du projet change souvent. Les proportions dans lesquelles cette erreur peut varier est très importante.

Mc Connell1 a travaillé chez Microsoft au redressement des projets en difficulté. Il a tiré de son expérience une observation : plus le projet approche de sa finalisation, plus les estimations qu’on réalise deviennent proches de la durée finale réelle. Le corollaire de cette évidence, c’est qu’au début d’un projet les estimations sont très éloignées de ce que sera la réalité.

Mc Connell a établi des coefficients montrant les variations de l’écart dans le temps du projet, entre les estimations les plus optimistes et les plus pessimistes. Au début du projet, les estimations sérieuses oscillent en 4 fois et 0,25 fois la durée que le projet prendra réellement.

L’écart entre l’hypothèse la plus optimiste et l’hypothèse la plus pessimiste traduit le niveau de risques que l’on prend en compte : un projet se déroule rarement de manière complètement catastrophique, et jamais idéalement non plus.

On notera que pour un projet estimé à 100 jours homme, la durée réelle pour un projet réussi au final peut se situer entre 25 et 400 jours homme, soit un rapport de 1 à 16. Ainsi, la fin du projet de d’une durée minimale de cinq semaines peut intervenir entre cinq semaines et un an et demie.

L’approche agile prend en compte cette réalité et s’y adapte en planifiant des itérations sur le modèle du PDCA de Deming. On avance pas à pas, on ne planifie que l’étape à venir et, en fonction des résultats de cette étape et des enseignements tirés, on planifie l’étape suivante.

La roue de Deming est un moyen mnémotechnique qui permet de repérer avec simplicité les étapes à suivre pour améliorer la qualité dans une organisation. La méthode comporte quatre étapes, chacune entraînant l’autre, et vise à établir un cercle vertueux.

Sa mise en place doit permettre d’améliorer sans cesse la qualité d’un produit, d’une œuvre, d’un service, etc.

1. Plan : préparer, planifier;
2. Do : développer, réaliser, mettre en oeuvre;
3. Check : contrôler, vérifier ;
4. Act (ou Adjust): agir, ajuster, réagir.

Le fait de procéder par étapes présente l’avantage de ne consacrer l’effort de planification qu’à l’étape qui démarre, sans perte inutile de temps pour élaborer un planning détaillé à long terme totalement hypothétique.

La différence entre une gestion de projet Agile et une approche basée sur une planification traditionnelle peut être représentée sous forme graphique.

Comparaison des approches : Agile et traditionnelle

Remarque importante : l’estimation d’une enveloppe globale est indispensable.

Un projet « compliqué » fait référence à une situation où plusieurs éléments simples sont combinés. Il est nécessaire de pouvoir identifier les composants du projet pour comprendre la situation et ainsi être en mesure de lever ou surmonter les obstacles.

Un projet « complexe » désigne en revanche un ensemble d’éléments dont un ou plusieurs ne sont pas maîtrisés. La situation est alors difficile à appréhender, à analyser et donc à restituer. La perception du projet est alors subjective et le partage de l’analyse n’en est que plus difficile.

Ce qui définit un projet « complexe » est la combinaison de 2 facteurs.

Le facteur humain : il sera plus ou moins impactant en fonction du nombre d’acteurs sur le projet, de leur niveau d’intervention mais aussi des intérêts qu’ils portent au projet. Il est facilement concevable qu’il soit plus difficile de coordonner les contributions de chacun, de réaliser le reporting associé, de suivre les charges et surtout d’anticiper les réactions en fonction du nombre de contributeurs sur le projet, des attentes qu’ils ont du projet, etc.

Le facteur technique : les technologies utilisées dans le projet ne sont pas figées. Il est alors indispensable de s’adapter et accepter que le projet puisse évoluer au fur et à mesure de son avancée. Ce sont ces deux facteurs combinés qui rendent un projet « complexe », instable et donc difficilement prévisible.

Le niveau d’incertitude est l’un des deux principaux éléments de différenciation des projets. Ralph Stacey de l’Université de Hertfordshire a mis au point une matrice qu’il nomme « The Stacey Matrix ». Cette matrice permet de prendre connaissance du degré de complexité d’une situation selon le niveau d’incertitude et le niveau d’accord face à la situation. Selon la matrice de Stacey, le degré de complexité est fonction du niveau d’incertitude et d’accord face à la situation.

La figure ci-dessous donne une présentation simplifiée de la matrice de Stacey.

Quatre états sont identifiés dont un est nommé « complexe ». Il représente la situation où il y a plus d’éléments inconnus que d’éléments connus.

Les 4 états s’énumèrent de la façon suivante :

• Simple : tout est connu,
• Compliqué : il y a plus de connus que d’inconnus,
• Complexe : il y a plus d’inconnus que de connus,
• Chaos : très peu d’éléments connus.

L’axe des X montre le niveau d’incertitude où, à la gauche, il y a peu d’incertitude tandis qu’il y aura de plus en plus d’incertitude lorsqu’on s’éloigne vers la droite. Sur l’axe des Y, on évaluera le niveau d’accord entre les parties prenantes du projet. Plus on se rapproche de l’origine, plus le niveau d’accord est fort tandis que plus on s’éloigne de l’origine, plus on devient en désaccord sur un sujet.

En définitive, c’est le niveau de complexité du projet qui permet d’estimer si la gestion en mode « agile » du projet est adaptée ou non, notamment au travers du cadrage du projet qui demeure essentiel pour en évaluer sa complexité. La complexité d’un projet étant en perpétuelle évolution, la méthode Agile apparaît comme une solution pour réduire l’impact de l’incertitude.

L’expérimentation est ainsi une clé dans la création de valeur, l’essai peut entraîner l’échec, mais celui-ci est permis afin de s’améliorer face à la complexité.

Le livre de Daniel Pink « La vérité sur ce qui nous motive, ISBN 978-2-84899-454-3 » examine les mécanismes de cette motivation en donnant des exemples concrets et en proposant des techniques et des idées pour l’améliorer.

Durant les années 90 Microsoft publia une encyclopédie appeler Encarta qui mobilisa des ressources importantes de l’entreprise afin de créer et mettre à jour son contenu. Au début des années 2000 une initiative démarra sur le Web afin de de créer une encyclopédie gratuite et dont le contenu était enrichi par des bénévoles : elle s’appelait Wikipédia. Qui aurait pu croire qu’une encyclopédie développée par une entreprise aussi puissante que Microsoft serait détrônée en quelques années seulement par un groupe anonymes de volontaires travaillant gratuitement. Il fallait bien qu’il y ait une source de motivation importante pour générer un tel résultat. Voir : https://www.youtube.com/watch?v=rrkrvAUbU9Y

Pourquoi des entreprises de la nouvelle économie comme Google proposent elles à leurs salariés du temps libre pour travailler sur des projets de leur choix une partie non négligeable de leur temps (il faut savoir que de certains outils de chez Google ont ainsi vu le jour : Google translate, Google talk pour ne citer que ceux là).

En matière de motivation, la pratique des entreprises n’est pas en phase avec ce que la science nous apprend. Seules un petit nombre d’entreprises pionnières mettent en œuvre ce nouveau style de management. Pourtant depuis plusieurs dizaines d’années, les spécialistes du comportement si tu dis la dynamique de cette troisième motivation et explique son importance (Harry Harlow, Edward Deci, Mihaly Csikszentmihalyi, …).

La première source de motivation est d’ordre biologique : la faim, la soif et le désir sexuel. Un deuxième type de motivation est constitué par les récompenses et les punitions. Depuis le milieu du XXe siècle, des chercheurs on découvert qu’il existait un troisième type de motivation et l’on appelé motivation intrinsèque (en opposition avec les récompenses ou les punitions qui sont considérées comme des motivation extrinsèques).

Le premier système de motivation est adapté à un mode de survie. Au fils du temps il a peu à peu été remplacé par  un deuxième système fondé sur les récompenses et les punitions extérieures, ce qui était efficace pour les taches routinières dans les organisations au XXe siècle. Aujourd’hui, les entreprises modernes demandent à leurs salariés de résoudre des problèmes complexes, de concevoir des produits à haute valeur ajoutée. Le système de motivation traditionnel n’est plus adapté.

On découvre ainsi dans quelles circonstances la carotte et le bâton sont efficaces (exécution de taches répétitives, rébarbatives) et celles ou ils deviennent contre productifs, en particulier dans des environnement où l’on encourage la créativité (ce qui devient incontournable avec la numérisation de l’activité économique).

Les fondements d’une motivation fondée sur des désirs extrinsèques repose sur trois éléments essentiels : l’autonomie, la maitrise et la finalité. Cela correspond à un profond désir de diriger notre propre vie, d’accroître et de diversifier nos capacités et de donner un sens à notre vie.

L’autonomie : les gens ont besoin d’être autonomes dans leur tâche (dans ce qu’ils font), en terme d’équipe (avec qui ils le font) et par rapport à la technique (comment il le font). Les entreprises qui permettent à leurs salarié d’être autonome sont plus performantes que leurs concurrents.

La maîtrise : c’est l’implication qui permet d’acquérir la maîtrise, c’est-à-dire de devenir meilleur dans un domaine important. C’est un élément important de la motivation qui est devenu essentiels pour réussir dans un système économique. C’est un état d’esprit qui suppose des efforts dans un environnement de travail dans lequel les taches ne sont ni trop difficiles ni trop faciles (1)  et qui nécessite une pratique délibérée et continue.

La finalité : il est dans la nature humaine de rechercher la finalité, c’est-à-dire de trouver un sens à ce que l’on fait. Il s’exprime sous forme d’objectifs dans lesquels le profit est un moyen, sous forme de discours dans lequel l’accent est mis sur autre chose que l’intérêt personnel et sous forme de mesures pour permettre aux salariés de trouver eux même du sens à ce qu’il font.

(1) Voir la théorie des flows : http://www.mbaknol.com/modern-management-concepts/theory-of-flow/

Daniel Pink, « La vérité sur ce qui nous motive, ISBN 978-2-84899-454-3 »

Parmi les différente méthode d’organisation personnelles,  GTD a pris une part importante mais peut être parfois longue et laborieuse a mettre en oeuvre. Voici a mon sens les 6 concepts fondamentaux d’une organisation optimale, a mettre en place de toute urgence!

Le choix du système
Dans un premier temps il est important de choisir un système, quel qu’il soit (papier, Iphone,…), et surtout de s’y tenir! Le moins de temps passé dans le système, le plus d’actions on accomplit.Plus sérieusement, la multitude et la diversité des possibilités d’implementation de la méthode GTD ou de liste de tâches quelles qu’elles soient nous donnent parfois l’impression que passer du temps a nous organiser nous rend productif. C’est tout le contraire. Il faut un vrai système, fiable et qui fonctionne. Point. Pas besoin de le mettre a jour toute les deux semaines parcequ’une nouvelle appli est sortie.

La collecte des idées
C’est un concept important de la méthode GTD. Parcequ’elle permet « l’esprit sur l’eau », et il est vrai que rien ne vaut un esprit tranquille, liberé pour se focaliser sur l’action en cours. Il faut donc pouvoir, en toutes circonstances, se liberer l’esprit avec un système de collecte a portée de main.

Le traitement des idées
Parce que les idées collectées ne constituent pas forcément des actions réalisables en l’état, il faut organiser ces idées. Une revue quotidienne peut suffire.Certaines idées peuvent constituer des  habitudes a prendre, des pensées positives ou des choses a faire un jour mais pas réalisables en l’état. Les checklistes sont bien adaptées pour cela.Pour les actions réalisables, le principe des contextes est imteressant car il permet de créer des listes d’actions réalisables au moment et a l’endroit ou nous sommes.

Commencer à agir
Maintenant! Tout de suite! Parcequ’il ne sert à rien d’aller vers de la micro organisation, une fois pleinement organisé on n’a plus envie d’agir.A ce stade, les idées collectées permettent déjà d’avoir des listes d’actions pour chaque contexte.Chaque jour, on peut identifier les 2-3 tâches essentielles de la journée, et commencer la journée par celles là. Tout de suite!

Organiser les projets
Parceque finalement beaucoup de tâches nécessitent plusieurs actions a réaliser, et d’ailleurs parfois dans des contextes différent, il est important de revoir régulièrement les tâches qui constituent des projets.Certains doivent être appréhendés de manière séquentielle (la tâche A doit être réalisée pour pouvoir commencer la tâche B)D’autres de manière parallèle, car il est essentiel dès que possible de pouvoir grouper les tâches du même ordre.

La revue des altitudes
C’est le recul nécessaire à la priorisation et l’organisation des objectifs. Elle permet régulièrement de se refocaliser sur ce qui importe dans nos vie, et d’organiser nos actions quotidiennes en fonction.Si tu suis ces concepts fondamentaux, tu verras ton efficacité doubler très rapidement. Je te parle bien d’efficacité, pas de productivité. Inutile d’avoir l’air occupé pour se donner bonne conscience. Ici, il est vraiment question de se concentrer sur l’essentiel, d’avoir une vision d’ensemble et une méthode d’organisation quotidienne qui te permette de t’approcher au mieux de tes objectifs.Nous avons trop souvent tendance a remettre au lendemain certaines choses qui peuvent être réaliséesbien plus facilement qu’on ne le croit, simplement parcequ’on en minimise l’importance ou qu’on ne croit pas a vraiment à l’atteinte d’un objectif.
S’organiser au quotidien, prendre du recul et prioriser l’essentiel, c’est aussi assurer une motivation quotidienne pour l’accomplissement de ce qui nous tient à coeur, et une source de satisfaction incroyable.Avec un peu de pratique, tu verras que pratiquement rien n’est impossible, qu’il faut savoir apprécier au juste ses objectifs.

Organisation

Rôles

Product Owner

Le Product Owner est le représentant du client, il :

• Définit les fonctionnalités du produit.
• Décide des dates de livraison et de leur contenu.
• Est responsable de la rentabilité du produit (ROI).
• Priorise les fonctionnalités en fonction de la valeur métier.
• Ajuste les fonctionnalités et leur priorité avant chaque planification d’itération.
• Accepte ou rejette les fonctionnalités réalisées.
• Anime la réunion de planification de sprint.

Le rôle du Product Owner est assuré par un membre de l’équipe métier (MOA) et au besoin une assistance (AMOA).

Equipe d’assistance au Product Owner

Elle assiste le Product Owner et à ce titre peut intervenir dans le cadre des activités associées aux responsabilités de ce dernier.
Plus concrètement, elle :

• Alimente et maintient le Product Backlog, et pré priorise les éléments de ce dernier.
• Ajuste les fonctionnalités prioritaires du Product Backlog (candidates au périmètre du prochain sprint) et s’assure que les pré-requis aux développements associés seront disponibles en temps voulu (exemples : décisions métier, jeux de données du SI amont,…).
• Rédige les User Stories associées aux fonctionnalités prioritaires et dessine au besoin des maquettes d’écran.
• Répond aux questions soulevées par l’équipe de développement en cours de Sprint et complète au besoin les User Stories associées.
• Vérifie en cours de Sprint la bonne couverture du besoin des fonctionnalités terminées en collaboration avec l’équipe de développement.
• Rédige les plans de tests.
• Participe à la réunion de revue de sprint au cours de laquelle, elle aide le Product Owner à accepter ou rejeter les fonctionnalités présentées.
• Teste avant mise en production la conformité du produit dans son ensemble.

Scrum Master

Le Scrum Master appartient à l’équipe de développement (MOE), il :

• S’assure que l’équipe est pleinement opérationnelle et productive.
• Établit une collaboration étroite entre l’ensemble des rôles et fonctions.
• Supprime les obstacles rencontrés par l’équipe de développement.Protège l’équipe des interférences extérieures.
• Assure le suivi du processus.

Equipe de développement

L’équipe de développement :

• Réalise les fonctionnalités du produit.
• Présente au Product Owner les résultats de son travail sous forme de démonstrations.
• Maintient à jour les spécifications détaillées du produit.
• Package et livre le produit.

Processus

Processus global

Vue d’avion du processus global

Zoom sur le processus Scrum (sources des icônes des personnages : Mike Cohn)

Résumé

Le processus itératif et incrémental du projet structure le développement du produit en cycles de travail appelés « Sprints ». La durée de ces sprints est fixée à 2 semaines dans le cadre de ce projet. L’objectif générique associé à chaque sprint consiste à transformer les exigences constituant le périmètre de ce dernier en fonctionnalités utilisables.

Juste avant de démarrer un sprint, l’équipe de développement sélectionne les éléments de la liste ordonnancée des exigences (Product Backlog) qu’elle pense pouvoir réaliser dans le délais associé au sprint. Au cours de ce dernier, le Product Owner et l’équipe de développement collaborent étroitement pour atteindre les objectifs fixés. Chaque jour, l’équipe de développement se coordonne et mesure son avancement. A la fin du Sprint, elle présente les résultats de son travail au Product Owner et aux utilisateurs finaux sous la forme d’une démonstration des nouvelles fonctionnalités réalisées. Les feedbacks sont recueillis.

Juste après le Sprint, l’équipe de développement se réunit afin de tirer les leçons du sprint écoulé et étudie les moyens de s’améliorer. S’enchaine ensuite la planification du sprint suivant.

Processus détaillé

Le paragraphe suivant décrit dans l’ordre chronologique les étapes du processus.

Préparation

Avant le démarrage d’un Sprint, le Product Owner doit s’assurer que le Product Backlog (Liste des exigences attendues) est correctement ordonnancé en fonction de la valeur métier et du coût de chaque exigence. Pour les exigences dépourvues de coût, il peut solliciter l’équipe de développement afin de procéder à des séances d’estimation. Il participe à ces séances – assisté par son équipe – en répondant aux questions de l’équipe de développement. Il doit également s’assurer que le besoin associé aux exigences prioritaires du Product Backlog (candidates au périmètre du prochain Sprint) est suffisamment mûr (décisions métiers structurantes prises, besoin formalisé sous forme de User Stories,…).

Planification de Sprint

Le Product Owner et l’équipe de développement se réunissent afin de partager ou repartager ensemble la vision du projet ainsi que les objectifs associés aux éléments du Product Backlog. L’équipe de développement sélectionne ensuite les éléments du Product Backlog en commençant par le haut (exigences prioritaires) en fonction de sa capacité à faire. Enfin l’équipe de développement, découpe chaque exigence en tâches et estime le temps nécessaire à la réalisation de chacune d’entre elles. Ces tâches sont enregistrées dans le Sprint Backlog.

Sprint

Le sprint englobe les activités d’analyse, de conception, de test et de développement. Au cours de ce dernier l’équipe de développement soulève des questions métiers. L’AMOA répond aux questions (se retourne vers d’autres acteurs tels que la MOA si nécessaire) et complète les User Stories associées. L’AMOA vérifie en cours de sprint la bonne conformité de la fonctionnalité développée, émet au besoin des feedbacks qui permettront d’adapter la fonctionnalité.

L’équipe de développement se réunit chaque jour lors de la mêlée quotidienne afin d’évoquer le travail réalisé la veille, celui de la journée et soulever les obstacles rencontrés. Chaque membre de l’équipe actualise son « Reste A Faire » sur ses tâches en cours de manière à actualiser le graphique d’avancement du sprint. Ce point est limité à 15 minutes, d’autres acteurs du projet peuvent être présents mais seuls les membres de l’équipe de développement ont la parole.

Revue de Sprint

A la fin du sprint, l’équipe de développement présente au Product Owner accompagné par l’AMOA (et autres acteurs intéressés) les nouvelles fonctionnalités produites sous la forme d’une démonstration. Le Product Owner – avec l’aide de l’AMOA – accepte ou rejette les fonctionnalités présentées. Les feedbacks sont notés. En fonction des résultats présentés, le Product Owner peut demander une livraison du produit pour réaliser des tests de l’ensemble du produit en prévision d’une mise en production. Auquel cas, quelques jours de consolidation du produit en fonction des résultats de ces tests peuvent être nécessaires. Si le Product Owner ne demande pas de livraison, une nouveau sprint est planifié (cf. paragraphe « Planification de Sprint »).

Rétrospective de Sprint

Après la revue du Sprint, l’équipe de développement ainsi que le Product Owner se réunissent afin d’identifier les adaptations susceptibles d’augmenter sa productivité. Les choses qui fonctionnent, celles qui ne fonctionnent pas ainsi que les améliorations à apporter, sont identifiées dans cette réunion. Elle s’inscrit dans une démarche d’amélioration continue. Les idées de chacun sont mises à profit.

Synthèse des réunions

NB : les comités de pilotage ne sont pas décrits dans cette organisation. Ils diffèrent généralement assez peu d’une approche traditionnelle (exemple : comité de suivi hebdo et comité de pilotage mensuel). Il peut cependant être intéressant de se caler sur le rythme des sprints, voire de mutualiser les revues de sprint avec un comité de pilotage par exemple.

Planification de sprint

• Objectif(s) : définir le périmètre et les objectifs du sprint puis découpage en tâches de développement.
• Responsable : Product Owner.
• Participants : Product Owner, ScrumMaster, équipe de développement.
• Fréquence : Avant le sprint.
• Durée maximale : 4 heures.
• Document(s) en entrée : Product Backlog priorisé.
• Document(s) en sortie : Sprint Backlog.

Mêlée quotidienne

• Objectif(s) : coordination de l’équipe de développement, identification des obstacles qu’elle rencontre, mesure de l’avancement du Sprint.
• Responsable : ScrumMaster.
• Participants : équipe de développement, ScrumMaster, Product Owner/AMOA (optionnel).
• Fréquence : quotidienne.
• Durée maximale : 15 minutes.
• Document(s) en entrée : Sprint Backlog.
• Document(s) en sortie : Sprint Backlog et graphique d’avancement mis à jour.

Revue de Sprint

• Objectif(s) : présentation des fonctionnalités produites au cours du Sprint au Product Owner et utilisateurs finaux, réception des feedbacks.
• Responsable : Equipe de développement.
• Participants : équipe de développement, Product Owner, ScrumMaster, utilisateurs finaux, invités.
• Fréquence : A la fin du Sprint.
• Durée maximale : 2 heures.
• Document(s) en sortie : Liste des feedbacks.

Rétrospective de Sprint

• Objectif(s) : améliorer la productivité (vélocité) de l’équipe de développement.
• Responsable : ScrumMaster.
• Participants : équipe de développement, ScrumMaster, Product Owner/AMOA (optionnel).
• Fréquence : Après la revue de Sprint.
• Durée maximale : 1h30.
• Document(s) en sortie : compte rendu de réunion (bilan de Sprint + plan d’actions).

Artefacts

Product Backlog

Le Product Backlog centralise la liste des exigences attendues (fonctionnalités, exigences non fonctionnelles, défauts à corriger). Le Product Owner s’approprie ce Product Backlog et priorise ses éléments en fonction de la valeur métier et du coût estimé de chacun. L’unité de coût est le « point ». Le choix d’une telle unité permet d’éviter la confusion entre délais et coût, souligne le caractère « estimatif » (imprécis) et facilite la planification de release et de sprint. Ces estimations sont réalisées dans un premier temps à partir d’un besoin peu détaillé, il peut être révisé au cours de la planification d’itération en cas d’écart par rapport aux hypothèses établies lors de la première estimation.

Sprint Backlog

Le Sprint Backlog comporte la liste des tâches du Sprint (son périmètre donc) ainsi que la charge de travail associée à ces dernières. Chaque jour, le Reste A Faire de chaque tâche est actualisé par l’équipe de développement afin de tracer le graphique d’avancement de Sprint.

Tableau des tâches

Ce tableau comporte la liste des tâches du Sprint Backlog, il permet à l’équipe de développement de se coordonner. Il comporte généralement 4 colonnes : « A faire », « En cours », « A vérifier », « Terminé ». Il est mural et simple à interpréter, permettant à n’importe quel acteur du projet de connaître en un coup d’œil l’avancement « temps réel » du Sprint.

Graphique d’avancement de Sprint

Tout au long du Sprint, n’importe quel acteur du projet peut consulter la progression de l’équipe de développement grâce au graphique d’avancement actualisé quotidiennement. Ce graphique indique l’évolution du Reste A Faire (généralement exprimé en heures) en fonction du temps.

Spécifications

Introduction

Partant des constats suivants :

• Les besoins ne sont pas complètement connus tant qu’un projet n’a pas débuté
• Les utilisateurs savent ce qu’ils veulent uniquement après avoir vu une première version du logiciel (Principe d’incertitude du besoin de Humphrey).
• Les besoins changent souvent durant le processus de développement du logiciel (Principe d’incertitude de Hadar Ziv – 1996)
• Spécifier intégralement un système interactif est impossible (Lemme de Peter Wegner – 1995)

L’approche du projet, concernant les spécifications, consiste à lisser le travail de rédaction des spécifications tout au long du projet et à leur accorder une valeur contractuelle faible. Privilégiant plutôt la réalisation au plus tôt d’un logiciel qui fonctionne à la fin de chaque sprint grâce à une collaboration client/fournisseur (métier/technique, MOA/MOE) étroite.

Liste des besoins

Le Product Owner établit et maintient la liste des exigences attendues (fonctionnalités, exigences non fonctionnelles ou défauts à corriger). A ce stade, le niveau de précision du besoin est faible. Chaque exigence peut se résumer à 1 à 3 phrases en moyenne. La liste des exigences vient alimenter le Product Backlog.

Besoins prioritaires

Avant la planification d’un nouveau Sprint, le Product Owner approfondit le besoin associé aux fonctionnalités prioritaires (en tête de liste du Product Backlog). Une bonne pratique consiste à rédiger pour chaque fonctionnalités attendue une User Story (le verso décrit le besoin et le recto énumère les conditions ou test d’acceptation permettant de vérifier la couverture du besoin). A l’issue de la réunion de planification de Sprint, le périmètre de ce dernier est fixé. Il correspond à la liste d’exigences sélectionnées par l’équipe de développement matérialisées par un ensemble de User Stories.

Conception/Développement

Une fois le Sprint démarré, le développeur s’approprie la User Story qui servira de support de communication entre lui et le rédacteur de la User Story (Product Owner, AMOA ou utilisateur). Au fil des questions soulevées et des réponses apportées, la User Story se complètera jusqu’à la fin des développements associés.

Mise à jour des spécifications

A l’issue du Sprint, l’équipe de développement, met à jour la documentation du produit.

Gestion des changements

Le besoin peut changer tout au long du projet (y compris tardivement).
Notamment dans les cas de figure suivants :

• Découverte d’un nouveau besoin correspondant une nouvelle fonctionnalité à réaliser.
• Modification d’une fonctionnalité déjà réalisée.
• Retrait d’un besoin finalement inutile ou infaisable.

Principe de troc

Principe de troc d’exigence pour la gestion des changements

Pour rappel, le Product Backlog centralise l’ensemble des exigences (ou besoins) attendues du projet. Chaque élément de ce dernier comporte une estimation de coût en points. La somme des estimations permet donc de déterminer le coût du projet (estimation).

Si les contraintes de budget voire de délais du projet sont fortes ; en cas de découverte d’un nouveau besoin ou de modification d’une fonctionnalité déjà réalisée ; un nouvel élément est ajouté au Product Backlog en échange du retrait d’un autre de même coût et de valeur métier plus faire (cf. bas de la liste). Inversement dans le cas d’une disparition d’un besoin finalement inutile, l’élément associé est retiré du Product Backlog libérant ainsi une provision pour de nouveaux besoins ou futures modifications.

Changement pendant un Sprint

Le périmètre d’un sprint fixé à l’issue de la réunion de planification ne doit pas changer. En cas de force majeure, le Product Owner peut annuler le Sprint en cours, ce qui peut engendrer des conséquences coûteuses. Les développements en cours sont stoppés, l’équipe de développement est coupée dans son élan. Un nouveau sprint doit alors être planifié.

Gestion des défauts

Processus de gestion des défauts

Un défaut qui n’a pas pu être corrigé pendant le Sprint est enregistré dans le « Bug Tracker » par le testeur. L’AMOA et l’équipe de développement qualifient ensemble les défauts constatés afin de savoir si une correction et réellement nécessaire et possible en fonction des informations renseignées par le testeur.

Les défauts confirmés sont ensuite priorisés par le Product Owner assisté par l’AMOA. Le Product Owner identifie la liste des défauts à corriger dans le prochain sprint. Il communiquera cette liste à l’équipe de développement lors de la réunion de planification de sprint au même titre que les exigences prioritaires à réaliser. Les défauts critiques (bloquant le travail de test AMOA ou présentant un risque majeur dans l’utilisation du produit prochainement mis en production) peuvent être ajoutés au besoin au périmètre du sprint en cours.

Processus de gestion des incidents de production

Les incidents de production peuvent être pris en compte par l’équipe de développement dans le Sprint en cours.

Planning

Macro planning Agile : « Une Release par trimestre »

Le projet est piloté par la valeur et les délais. Chaque année compte 4 releases de 3 mois afin de créer un rythme régulier, favoriser la naissance des automatismes projet, réduire l’effort de planification du projet et de coordination des acteurs internes et partenaires du projet. Ce principe de release de même durée permet également de construire des indicateurs plus facilement comparables afin d’améliorer régulièrement le processus de développement et l’organisation.

Les releases peuvent donc être considérées comme des trains partant et arrivant à heure fixe sans décalage possible. Le périmètre est donc la seule variable d’ajustement, afin de sécuriser la qualité, le budget et les délais.

Bonnes pratiques

Planning Poker

Le Planning Poker est une technique d’estimation de coût d’exigences. Cette technique se pratique en équipe et permet de procéder à des estimations rapides et aussi précises que possible selon le niveau de précision du besoin disponible.

Au cours des séances d’estimation, le Product Owner (assisté de l’AMOA au besoin) soumet une à une à l’équipe de développement les exigences dont il souhaite connaître l’estimation de coût. Il répond aux questions de l’équipe de développement qui en cas d’absence de réponse (besoin encore flou) établie des hypothèses. Les estimations de coût (dont l’unité est le point) ainsi obtenues viennent alimenter le Product Backlog et aideront le Product Owner à prioriser ses exigences. La technique de Planning Poker peut également être utilisée pour estimer en équipe (Product Owner, AMOA, utilisateurs, marketing,…) la valeur métier en points des exigences du Product backlog.

User Story

La User Story est une technique de spécification permettant de synthétiser le besoin lié à une fonctionnalité en quelques phrases courtes et simples utilisant exclusivement le vocabulaire métier (absence de connotation technique ou de description d’IHM). D’autre part, une User Story énumère les tests fonctionnels connus à date permettant de vérifier la couverture du besoin de la fonctionnalité associée.

Les avantages sont nombreux :

• Une User Story est compréhensible rapidement aussi bien par un développeur que par un utilisateur,
• Elle favorise les interactions entre développeur et rédacteur, favorisant ainsi une bonne compréhension du besoin (communication face à face),
• Les tests énumérés renforcent la qualité des développements.

Pratiques de développement

Intégration continue

L’intégration continue a pour rôle de détecter au plus tôt les défauts d’intégrité du code (plus un défaut est corrigé tôt moins il coûte cher).

Elle est matérialisée par un outillage logiciel récupérant le dernier code disponible sur le gestionnaire de version, compilant ce dernier et exécutant les tests unitaires existants. Il réalise cette tâche automatiquement à chaque modification du code soumise au gestionnaire de version ou plusieurs fois par jour. En cas de défaut détecté, une alerte est déclenchée (email, signal sonore ou visuel,…). Cet outil permet donc de renforcer la qualité des développements et de favoriser le travail indispensable de refactoring régulier du code.

Développements pilotés par les tests

Le développement piloté par les tests consiste à sensibiliser le développeur sur les tests en amont de ses développements. Concrètement, la User Story associée à une fonctionnalité à développer liste les tests qui permettrons de confirmer que cette fonctionnalité couvre effectivement le besoin. Cette approche limite les erreurs d’interprétation du besoin du développeur.

Programmation en binôme

La programmation en binôme consiste à rassembler deux développeurs sur un même poste de travail pour accomplir une même tâche de développement. Cette approche apporte plusieurs avantages :

• Permet de réaliser efficacement des développements pointus,
• Meilleure qualité du code (peu de défauts, uniformité, maintenabilité),
• Rapidité de développement,
• Rapidité de montée en compétences (cf. nouveaux développeurs, en particulier junior).

https://lejournal.cnrs.fr/billets/cogitez-si-vous-voulez-les-decisions-sont-irrationnelles .

Cet article du journal du CNRS bat en brèche une idée communément répandue : nous sommes persuadés que nous prenons nos décisions de manière rationnelle.

Cette croyance prend naissance en Occident au XVIIIe siècle, ou les mouvements intellectuels issus des Lumières s’appuient sur le raisonnement et la rationalité pour développer un mode de pensée Universel qui nous influence encore. 

Pourtant, des dizaines de travaux indiquent que les décisions des individus ne sont qu’exceptionnellement optimales.

Vers le milieu du XXe siècle, des études menées dans les domaines de l’économie ou de la psychologie ont  permis de remettre en cause la prédominance de la rationalité dans les prises de décision.

On constate par exemple que le comportement des agents économiques n’est pas toujours rationnels : il est soumis à d’autres facteurs qui influencent leur décision. On connaît l’importance de la psychologie dans les phénomènes boursiers, liés notamment à l’aversion au risque.

Parmi d’autres facteurs qui influencent nos décisions se trouvent la notion de dilemme et l’importance de la formulation du problème posé. Dans certaines situations la manière de poser un problème peut aboutir à des décisions diamétralement opposées (1).

Sans oublier l’importance de l’outil qui nous sert à prendre des décisions : le cerveau.  Le réseau de neurones qui constituent notre cerveau fonctionne sur des processus de type aléatoire dont l’évolution à intégrer un certain nombre de mécanismes comme l’aversion au risque. Cela a permis à l’espèce humaine de survivre et de s’adapter mais limite également notre capacité à fonctionner de manière rationnelle.

Cette part d’irrationalité est le revers de la médaille d’un mécanisme qui nous permet malgré tout de nous adapter et de garder une grande capacité d’adaptation.  

———————————————–

(1) Les expériences menées par le psychologue Daniel Kahneman (Prix Nobel d’économie en 2002).

Lorsqu’il confronte des sujets au dilemme suivant – être sûr de sauver uniquement 200 personnes sur 600, ou avoir une chance sur trois de sauver les 600 personnes –, ils choisissent majoritairement le sauvetage assuré de 200 personnes.

Si le même dilemme leur est formulé différemment – laisser mourir à coup sûr 400 personnes ou avoir deux chances sur trois de laisser 600 personnes mourir –, ils préfèrent cette fois laisser faire le hasard plutôt qu’être certains de sacrifier 400 personnes.

extrait de : https://lejournal.cnrs.fr/billets/cogitez-si-vous-voulez-les-decisions-sont-irrationnelles