Agilité : une main de fer dans un gant de velours

Agilité:
Une main de fer
dans un gant de velours…
Marc BURLEREAUX, marc.burlereaux@pmi-fr.org
Release Manager Européen auprès d’une banque suisse
PMP, PMI-RMP, PgMP, ITIL V3

Sylvain GAUTIER, sylvain@sygit.ch
Consultant Agile / ITIL / BPMN société SYGIT, Suisse

Christine RIEU, christine.rieu@univ-savoie.fr
Maître de Conférences en Informatique, Laboratoire LISTIC,
Université de Savoie, Annecy
14/11/2012 1

Introduction

Expertise bancaire
privée,
Program &
Release
Manager, Recherche universitaire,
PMI Gestion des
compétences, PMI

Expertise Agile,
ITIL, BPMN

14/11/2012 2

Sommaire

Introduction

1. Principes de base Agile

2. Bonnes pratiques pour le cadrage et le
développement de projet en mode Agile

3. Challenges de la mise en production

4. Valoriser le facteur humain

Conclusion
14/11/2012 3

1. Principes de base Agile

Tout type de projet

Alternative aux méthodes traditionnelles

Processus de développement itératif &
incrémental

Mode collaboratif qui met l’accent sur le
facteur humain

Pilotage par les cas d’utilisation
SOA

Démarche d’architecture d’entreprise
Approche Référentiel
Pilotage par les risques processus d’entreprise
’

14/11/2012 4

1. Principes de base Agile suite

Des méthodes pragmatiques, partant du principe que les besoins
évoluent

Grande importance des retours utilisateurs

Le changement n’est plus considéré comme une perturbation,
mais est intégré dans l’organisation du projet

Un feedback permanent, rapide et concret

Une simplicité assumée : se focaliser sur l’essentiel et maximiser
la quantité de travail à ne pas faire

Objectifs : gagner du temps et de l’évolutivité

14/11/2012 5

2.1. Bonnes pratiques pour
le cadrage d’un projet
Trois notions fondamentales:
• Backlog des fonctionnalités
• Notion de cas d’utilisation
• Notion d’activités d’un processus business

Analyse des risques métiers

Identifier les principales exigences non fonctionnelles
• Utiliser un référentiel d’exigences
• Exprimer les exigences par une phrase claire, courte

Planning poker: atelier le plus stratégique
• Chiffrer le projet
• Se mettre d’accord sur le sujet traité

14/11/2012 6

Cas d’utilisation (Use case ou UC)
Les cas d’utilisation ne sont pas seulement une technique pour
gérer les exigences, ils permettent de relier toutes les activités
à l’intérieur d’un projet Ivar
Jacobson

Use case y Use case z

<<fragment>>
spécifié par réalisé par Implémenté par distribué par vérifié par
Modèle des cas
d’utilisation : le
’
cœur du projet

Modèle
d’analyse
’

Modèle de
conception
Modèle
d’implémentation
’

Modèle de
déploiement
Modèle de tests

14/11/2012 7

2.2 Bonnes pratiques pour le
développement d’un projet
Le processus d’itération : SPRINT !
construire un incrément fonctionnel du produit

2 à 4 semaines

Itérations synchrones entre tous les projets

Scrum Master = coordinateur des itérations du projet

Product Owner : pilote les itérations par les risques

Seulement 2 itérations planifiées maximum

14/11/2012 8

Processus : Conduire une itération

9H00 Game Over
Début Evènement
SCRUM Master

d’itération majeur
Ajuster le périmètre
Démonstration
Mêlée quotidienne
Mêlée Backlog
Cérémonie du
Quotidienne ajusté Rétrospective
Planning d’itération effectuée Démonstration
effectuée
Plan d’action
rédigé
Scribe

Backlog Tâche Clôture de
Saisie du plan
d’itération réalisée Saisie de
d’itération L’itération
déterminé Plan l’avancement Avancement
d’itération
saisi
saisi
Equipe projet

Non Mise à jour
Itération
Oui Des livrables
clôturée
Analyse Agile
CPU

Game
Over ?
Livrables
Test MOA Agile
À jour

Fin d’itération
Modélisation – 4 Jours

Itération
Conception terminée
CPI

Développement
Revue de Backlog Revue technique

Backlog
projet Test MOE
ajusté Suite du discours

14/11/2012 9

ID du Processus xxxxxxxxx Lien vers les documents de référence
Résumé du processus Gérez votre projet de manière Agile
Link 1
Propriétaire du processus Agile
Version 0.1 Link 2
Statut Draft / à valider / validé / communiqué
Link 3
Revue par Carine et Hermann
Date du statut 08/11/2011 Link 4

Enoncé de mission
Itération : période de quelques semaines durant laquelle l’équipe construit un incrément fonctionnel du produit

Objectifs du processus
1. Une itération débute par une réunion de planification, et se termine par une revue du produit et une rétrospective
2. L’équipe est « protégée » durant l’itération, le traitement des nouvelles demandes est repoussé à l’itération suivante
3. Pour donner le rythme au projet, et pouvoir comparer les itérations entre elles, toutes doivent avoir la même durée pour un projet donné

Meilleures pratiques :
1. Les engagements donnent lieu à des livrables avec un niveau de qualité convenu, comme un exécutable passant les tests unitaires, des spécifications acceptables pour le
développement, etc.
2. En fin d’itération, on analyse formellement les résultats sur la base de faits et de livrables tangibles.
3. Les conclusions sont rassemblées dans un bilan d’itération avec des recommandations d’actions correctives, pour éviter que les mêmes erreurs ne se répètent.
4. Les objectifs d’itération restent stables au cours de l’itération.
5. Les objectifs de l’itération ne sont pas revus en cours d’itération, aucun objectif supplémentaire n’est ajouté.
6. Les changements seront demandés sur l’itération suivante, sauf cas vraiment exceptionnels.
7. Un changement des objectifs ne peut que déresponsabiliser les équipes sur les engagements en cours.
8. On doit créer un véritable esprit « projet » et un objectif commun où chacun participe depuis son point de vue et depuis son domaine de responsabilité.
9. Chaque objectif / tâche est un engagement personnel, non contraint, de la part de chaque contributeur, qui s’engage pleinement sur sa capacité à livrer.
10. La fiabilité de l’engagement est d’autant plus forte que le contributeur s’engage uniquement sur le mois à venir, donc sur le futur proche.
11. L’itération se termine à sa date de fin, et non pas quand tous les objectifs sont atteints. On constate à la date de fin d’itération si les objectifs ont été atteints et les causes
précises des retards ou impossibilités.
12. Le Scrum Master est le coordinateur des itérations du projet. Ils s’assurent que chaque contributeur impliqué dans le projet a les moyens de travailler correctement.

Home Suivant
14/11/2012 10


Objectifs du processus
Bonnes pratiques sur la façon de mener la phase Elaboration

1. Faire des itérations par les risques
2. Dès la première itération, concevoir, implémenter et tester les cas d’utilisation prioritaires
3. Concevoir, implémenter et tester les parties centrales et risquées de l’architecture; l’architecture est construite en implémentant itérativement les cas d’utilisation
structurant du point de vue de l’architecture
4. S’adapter à chaque itération en fonction des résultats des tests, et des feedbacks des utilisateurs & développeurs
5. On n’a que deux itérations planifiées devant soi, au delà c’est imprévisible.
6. Ne pas produire trop de spécifications à l’avance : La MOA doit dégager du temps pour assister la MOE (l’objectif est de disposer de 80% des spécifications à la fin de la
phase d’élaboration).

7. Le Scrum Master est le dépositaire de la méthode.
8. La première priorité du Scrum Master est de lever les obstacles, qui se dressent devant son équipe.
9. Le terme « Sprint » qui est donné au déroulement d’une itération est impropre :
1. On réalise en fait une course de fond.
2. Une itération = un tour de piste.
3. Dès qu’une itération est terminée, on en commence immédiatement une autre, il n’y a pas de pause.
4. Le Scrum Master ménage ses troupes.

Facteurs de succès

1. L’atteinte des objectifs est confirmé par la démonstration
2. L’équipe projet est motivée

Home Précédent
14/11/2012 11

Tâche : Cérémonie du Planning d’itération
ID de la tâche xxxxxxxxx Lien vers les documents de référence
Résumé de la tâche Construisez votre « Cocon » de travail pour le mois à venir Link 1
Outil principal utilisé Manuel Link 2
Risque à mal faire Probabilité 10% Impact Stratégique Link 3

Objectifs de la tâche
• « En tant qu’équipe, nous planifions l’itération à venir en fonction des priorités et de notre capacité, afin de pouvoir nous engager sur le périmètre à réaliser. »
• Planifier l’itération immédiatement à venir = détailler les tâches à réaliser.
• Sélection des fonctionnalités à réaliser, identification des tâches, finalisation des critères d’acceptation, et ce à partir du Backlog de produit : fonctionnalités priorisées et
estimées (points).
Opérations de la tâche / procédure
1. Préparation
• La MOA révise le Backlog de produit, ajoute, supprime et modifie des stories, modifie les priorités si nécessaire. Product Backlog
2. Planification
• La MOA présélectionne les stories à développer dans l’itération, et présente la liste à la MOE
• La MOE identifie les stories additionnelles (défauts à corriger, travaux techniques, etc.)
• On ne traite pas formellement les dépendances des tâches d’une itération : on traitera cet aspect au jour le jour, tous les matins lors de l’attribution des tâches
(Mêlée quotidienne).
3. Déterminer le niveau de finition attendu pour l’itération
• La définition de « fini » est établie ou revue, et validée conjointement C’est quoi C’est quoi
• Les objectifs de l’itération sont précisés une une
4. Déterminer la capacité de l’équipe « bonne » « bonne »
• Capacité calendaires : CC = (effectif X durée de l’itération) - congés prévus - autres engagements story? tâche ?
• Capacité planifiée : CP = CC X facteur de focalisation (estimé)
5. Décomposition
• Pour chaque UC ou composant, l’équipe imagine les tâches à accomplir (spécification, conception, codage, métier, codage interface données, codage d’IHM, tests
unitaires, tests techniques, tests d’intégration, documents et manuels, etc.)
6. Estimation
• Chaque tâche est estimée par les « spécialistes » de l’équipe. Une valeur consensuelle est retenue.
• Note : l’estimation d’une tâche varie de 0,25 à 2 « jours idéals ». Si une tâche requiert 2 personnes, multiplier par 2 !
7. Contrôler les comptes…
• Totaliser les estimations de tâches et comparer avec la capacité calculée. Contrôler la faisabilité en fonction de la nature des tâches et des compétences des
personnes présentes sur la période
8. Négocier…
• La MOA et la MOE négocient une réduction (ou une augmentation !) du périmètre de l’itération en cas de sous- ou surcapacité.
9. S’engager
• Collectivement, l’équipe donne son sentiment sur la faisabilité du plan…
• Obtenir l’engagement de chacun sur les tâches qui lui sont attribuées, y compris les tâches reportées de l’itération précédente.
Home
14/11/2012 12

Product Backlog

Cas
nominal
Story 1
Tâche
1
Tâche
2 … Tâche
n

Story 2
Use
Variante 1
Case Story 3
• Pas plus d’ ½ itération
• Démontrable

Exigence
Exigence
1 Variante 2
Exigence
2
3
Exigences non
fonctionnelles
Story n
Tâche
1
Tâche
2 … Tâche
n

Précédent
14/11/2012 13

Tâche : Mêlée quotidienne
Résumé de la tâche Réunion de coordination d’équipe Link 1
Risque à mal faire Probabilité 40% Impact Sensible Link 3

Chaque jour, une réunion, permet à l'équipe et au Scrum Master de suivre les progrès sur les tâches et les difficultés rencontrées.
Réunion de 15 minutes maximum : le Daily Scrum.
Présents : Le Scrum Master, le coach Agile, et les contributeurs.

1. S’assurer de nommer le « scribe » en début de séance.
2. Chaque membre répond à trois questions :
1. Qu'est ce que j'ai fait hier ?
2. Qu'est-ce que je vais faire aujourd'hui ?
3. Quels sont les défis / difficultés que je rencontre ?
3. Le tour de parole doit être strictement respectée afin d'éviter toute dérive.
4. Les activités peuvent se dérouler en parallèle: analyse, conception, codage, intégration, tests, etc.
5. Le choix de traiter une tâche avant une autre est effectué ici (dépendances, compétences, …).
6. Le choix de suspendre une tâche bloquée par des difficultés techniques est effectué lors de cette séance.
7. Si une tâche s’avère non réalisable, on peut la replacer dans la Backlog.

Bonnes pratiques :
1. Si possible, l'équipe travaille dans la même pièce.
2. Si le besoin s'en fait sentir, la discussion peut alors être prise librement, après le Daily Scrum.
3. Cette réunion est un point de synchronisation pour l'équipe et ne doit pas être considéré comme un rapport d'activité.

Exceptions

1. Problème grave détecté : en référer immédiatement au CMPU/CMPI et tracer le problème dans le rapport hebdomadaire de la semaine en cours

Home
14/11/2012 14

Tâche : Démonstration
Résumé de la tâche Démontrer l’incrément produit Link 1
Risque à mal faire Probabilité 40% Impact Critique Link 3

1. L’équipe présente les nouvelles fonctionnalités aux parties prenantes et recueille le feedback = Revue du produit (qualité de la conception / code ….).


1. Effectuer la démonstration de l’incrément de produit réalisé lors de l’itération qui se termine :
1. L’incrément produit est vérifié, démontré et validé
2. Les défauts constatés sont notés pour être saisis comme tâches de la story « correction de bugs » de l’itération suivante
2. Faire la revue des tâches de l’itération précédente :
1. Fait / pas fait.
2. Nombre de défauts constatés.
3. Reporter le non fait sur l’itération suivante (nouvelles tâches).
4. Reporter les défauts sur l’itération suivante (nouvelles tâches), avec une priorité 1.
5. Calculer l’état d’avancement : Exemple : 70% des points sont démontrés (% d’un statut du processus de fabrication).
3. Ecrire le résumé de l’itération et mesures d’amélioration dans le rapport hebdomadaire.

Exceptions

1. …

Home
14/11/2012 15

Tâche : Rétrospective
Résumé de la tâche Analyser le processus, Rechercher les causes, Proposer des améliorations Link 1

1. En tant que participants au projet, nous analysons régulièrement notre processus et nos procédures de travail afin d’améliorer notre efficacité.
2. L’équipe fait le bilan méthodologique, outil et humain de l’itération qui se termine = Revue du processus (efficacité, efficience).

• Durée : 1 à 3 heures
• La rétrospective est une cérémonie de fin d’itération, dont l’objectif est d’optimiser le processus. Toute l’équipe (MOA, MOE) participe
1. Les bonnes pratiques et les pratiques à faire évoluer sont identifiées
2. Les décisions sont prises pour optimiser le processus
• Déroulement
1. Initialisation (15’)
• Un membre de l’équipe résume ce qui a été livré, l’état du reste à faire en fin d’itération (planifié non fait), et fait le point sur les décisions prises à la
rétrospective précédente.
2. Identification des points positifs et négatifs (20’ – 30’)
• Chaque membre du projet liste les points positifs et négatifs de l’itération (seul ou en binôme)
3. Analyse (60’ – 90’)
• Les membres de l’équipe exposent leurs idées, et le groupe recherche les causes des dysfonctionnements ou les facteurs qui ont permis de bons
résultats.
• L’équipe sélectionne les éléments les plus significatifs

4. Décisions (30’ – 60’)
• L’équipe décide du plan d’action pour :
1. améliorer certaines pratiques
2. reconduire les pratiques qui ont eu des effets positifs
5. Clôture
• Engagement de l’équipe

Exceptions

1. …

Home
14/11/2012 16

Tâche : Ajuster le périmètre
Résumé de la tâche Modifier le Backlog de l’itération en cours, en cas de force majeure Link 1
Outil principal utilisé Redmine / RTC ... Link 2
Risque à mal faire Probabilité 20% Impact Faible Link 3

Modification des objectifs de l’itération, les items les moins prioritaires sont éventuellement exclus

1. Retirer une story du Backlog d’itération, et la replacer dans le Backlog de projet
2. Déplacer une tâche d’une story de l’itération vers une story de l’itération suivante
3. Pratiquer le change for free
4. Tracer les déplacements de story / tâche dans le rapport hebdomadaire de la semaine en cours

Exceptions

Home
14/11/2012 17

Tâche : Revue de Backlog
Résumé de la tâche Préparer l’itération suivante Link 1
Outil principal utilisé Redmine / RTC ... Link 2

• « En tant qu’équipe, nous maintenons le Backlog de Produit à jour afin d’avoir une vision réaliste du reste à faire et des priorités, et pour planifier la prochaine itération. »
• Tenir compte de ce qui a été modifié dans le Backlog du projet
• Préparer l’itération suivante, faciliter la planification, et rendre ainsi la cérémonie de planning d’itération à venir plus efficace et moins longue.


Durée : deux à 4 heures. Cette durée supplémentaire en réunion est largement amortie par la diminution de celle de planification et par le temps gagné sur le travail
préparatoire de la prochaine itération.

1. La Revue de Backlog est un travail d’équipe, mené par les CPU / CPI, assistés de membres du projet selon le besoin. Il n’est pas nécessaire que toute l’équipe participe (sauf
en cas de ré-estimation de stories)
2. S’assurer que les Stories couvrent l’ensemble des besoins
1. Tous les UC et fragments sont représentés par des Stories
2. Des Stories peuvent être créées pour des activités de formation, construction de plateforme de développement, etc.
3. Vérifier les estimations en points
1. Toutes les stories sont estimées en points
2. Les estimations sont cohérentes (avec les connaissances du moment…)
3. Les nouvelles stories sont estimées
4. Revoir les priorités
1. ≈ 20% de stories à réaliser : priorité Elevée
2. ≈ 30% de stories à réaliser : priorité Moyenne.
3. ≈ 50% de stories à réaliser : priorité Faible
5. Décomposer les Stories prioritaires en Stories de taille appropriée
1. Choisir un ou plusieurs axes de décomposition
2. Créer les stories identifiées, les décrire, planifier, estimer en points
3. Supprimer la story décomposée ( obsolète), ou lier les stories subdivisées à la story d’origine ( lien parent)
4. Mettre à 0 la charge de la story décomposée

Exceptions

1. Si suffisamment d'éléments sont prêts à être inclus dans la prochaine itération, la réunion n'est pas utile.

Home
14/11/2012 18

Tâche : Revue Technique
Résumé de la tâche S’assurer du respect des standards qualité au fil de l’eau Link 1
Outil principal utilisé RSA, …. Link 2

Effectuer des revues sur les livrables de l’ensemble des outils utilisés

1. Relecture de code entre pairs.
2. Revue des « logs » des outils utilisés (gestion de versions, SGBD, CMDB) : lister les items qui ont effectivement été créés, modifiés, supprimés, par qui et quand.
3. Vérification de la bonne application des normes et standards des outils utilisés.
4. Créer les tâches de réajustement nécessaires dans une story « Réajustement qualité / standards » au sein de l’itération suivante.
1. Créer les tâches de réajustement nécessaires dans une story « Payer la dette technique » en fonction de la définition de « fini » établie conjointement en début d’itération.
Cette story sera réalisée vers la fin de la phase de construction.

Exceptions

Home
14/11/2012 19

Tâche : Tests MOE
Résumé de la tâche Tester la story Link 1
Outil principal utilisé Poste de travail socle standard + environnement de test Link 2

S’assurer que les stories sont développées selon la conception et la modélisation validées

1. Tester ce qui est produit, selon ce qui a été décrit dans les documents de conception et de modélisation.
2. Faire corriger immédiatement ce qui peut l’être.
1. Reporter les défauts non immédiatement corrigeables sur l’itération suivante (nouvelles tâches), au sein d’une story de priorité 1.

Exceptions

Home
14/11/2012 20

Tâche : Tests MOA
Résumé de la tâche Tester le Use Case et ses exigences Link 1
Outil principal utilisé Poste de travail socle standard + environnement de test Link 2

S’assurer que l’incrément développé est en ligne avec les spécifications de Use Cases spécifiés (ainsi que les exigences et règles de gestion associées).

1. Tester ce qui est produit, selon les spécifications (Use cases, fragments, variantes, exigences, règles de gestion), si possible au fil de l’eau du développement et de sa
concrétisation sur l’environnement de test.
2. Reporter les bugs ainsi que le non alignement des spécifications avec le code et / ou la conception lors du Daily Scrum du lendemain.

Exceptions

Home
14/11/2012 21

Tâche : Modélisation
Résumé de la tâche Un bon modèle vaut mieux que 100 pages de documentation Link 1
Outil principal utilisé Visual Paradigm, PowerAMC, RSA, IDA, ARIS Link 2
Risque à mal faire Probabilité 40% Impact Stratégique Link 3

La MOE ainsi que les architectes réalisent les modèles de conception nécessaires, utilisant les outils idoines.

1. Organiser des ateliers
2. Réaliser les modèles (Diagrammes de classes, de séquences, modèles de données, architecture des composants ….).
3. Reformuler les modèles
4. Remonter les modèles aux architectes
5. Corriger les modèles selon les remarques émises par les architectes

Exceptions

Home
14/11/2012 22

Tâche : Conception
Résumé de la tâche Décrire la cinématique entre les modèles Link 1
Outil principal utilisé ….. Link 2

Ecrire les spécifications techniques, les diagrammes explicatifs associés, indiquant la logique de conception de la solution

1. Ecrire les spécifications techniques complémentaires aux modèles.
2. Décrire comment collaborent les modèles entre eux.
3. Décrire le comportement des composants logiciels.
4. Etablir le ou les schéma explicatifs nécessaires, en utilisant les outils de référence, dans la mesure du possible.

Exceptions

Home
14/11/2012 23

Tâche : Analyse
Résumé de la tâche Rédiger les spécifications fonctionnelles Link 1
Outil principal utilisé RRC Link 2

Ecrire les spécifications fonctionnelles, au sein du référentiel d’entreprise RRC.
Rester succin, non ambiguë et clair.

1. Décrire précisément les Use Cases (cas nominal et variantes)
2. Décrire clairement les règles de gestion associées aux use cases
3. Décrire les enchainement d’écrans
4. Réaliser les maquettes d’IHM
5. Se coordonner et échanger avec les autres MOA afin d’éviter les chevauchements de fonctionnalités entre les PAC (Le partage d’accès en lecture aux zones de projets RRC
est une aide importante pour traiter ce point).
6. Exporter les spécifications RRC dans un document MS-WORD partageable et archivable.

Exceptions

Home
14/11/2012 24

C’est quoi une « bonne » tâche ?
C’est une tâche limitée dont la réalisation est limitée dans le temps (2 jours)
– Pour supprimer l’effet tunnel et détecter au plus tôt les dépassements liés à des difficultés
• L’effort pour une tâche est donc compris entre 2 et 12 heures « idéales » en général
– Attention aux tâches planifiées pour une exécution en binôme (on multiplie l’effort par 2 !)

Le résultat attendu est décrit de façon intelligible, précise et quantifiée
– Exemples : un document, du code, la description de 3 scénarios de test, déploiement d’un outil, …
– Permet de dire « c’est fini »

C’est une tâche qui concours aux objectifs de l’itération en cours …
– Développement d’une story (de la spécification à l’intégration)
– Tâches techniques : « tester l’environnement de développement », …
– Montée en compétence : formation, travail en binôme senior/junior

… ou qui permet d’obtenir un indicateur d’avancement réaliste
– Congés et autres absences planifiées (ne pas créer après coup de tâche pour absence imprévue !)

Et c’est quoi une « pas bonne tâche »
– Les tâches récurrentes et obligatoires du processus ne sont pas planifiées (planning, démo, etc.)
– Les tâches de type « là je me garde 10 heures au cas ou j’aurais un problème, on ne sait jamais »
– Les réunions de pilotage de projet

Précédent
14/11/2012 25

C’est quoi une « bonne » story ?

C’est une fonction métier compréhensible et utilisable par un utilisateur (ou
par un informaticien si c’est une fonction technique du socle)
– Ceci est nécessaire pour que l’avancement du projet soit basé sur des fonctionnalités
livrées (avec le niveau de finition et de qualité attendus)

C’est un UC, ou un fragment, ou une partie de UC/fragment dont :
– Les tâches de la conception à la démonstration peuvent être réalisées au cours d’une et
une seule itération
– La « bonne » durée de réalisation tourne autour d’1/2 itération
• Pour limiter l’effet tunnel
• Faciliter l’ordonnancement des travaux
• Pour maximiser le nombre de stories terminées en fin d’itération

En synthèse :
– Un Cas d’utilisation est strictement une vue fonctionnelle ou utilisateur
– Une story est une vue fonctionnelle qui prend en compte les nécessités d’ingénierie
(découpage du UC en de multiples stories qui peuvent être implémentées en 1 itération)

Précédent
14/11/2012 26

Contexte
Domaine bancaire

Cycle de Release
– Mise en Production des Changements par Release Mensuelle et Hebdomadaire
– Changements : « Livrables de projets et / ou d’évolutions mineures »
– Release corrective Mensuelle pour certains produits

Taille des livraisons
– 100 à 150 projets par an
– 100 à 150 évolutions mineures par an

Contexte Méthodologique
– Méthodologie classique (« waterfall ») avec gestion des risques
– Quelques projet agiles sur certaines applications
– Volonté d’introduire de l’agilité à commencer par le processus des « Release »

Hors du cadre
– Corrections des incidents (ITIL niveaux 1, 2 et 3)
– Interventions et changements infrastructure sans besoins de tests utilisateurs

14/11/2012 27

Ecueils dus à l’agilité
Livraisons trop fréquentes
– Tous les acteurs ont du mal à suivre, y compris les utilisateurs :
– Test
– Formation / Support de cours
– Coordination de mise en place des changements
– Visibilité partagée amoindrie -> risque de « louper » des dépendances
– Risque de déstabilisation de la production
Manque d’implication des architectes et de la sécurité dès l’origine
– Remise en cause tardive des livrables
– Création de dette technique
Manque d’implication des équipes d’intégration et infrastructure
Manque d’implication des équipes de déploiement et support

Résultats :
• Production gérée par les équipes projet (voire le fournisseur)
• Instabilité de la production et mauvais service rendu au client
• Dette technique coûteuse
• Pérennité de la solution amoindrie
• Image de marque de l’IT écornée
• Etc …
14/11/2012 28

Conseils
Impliquer tous les acteurs dès l’initiation du projet et la première itération
– Architectes
– Equipes de sécurité
– Equipes d’intégration, infrastructures et déploiement

Aligner tous les acteurs sur le niveau d’exigences requis (qualité et homologation)
– Remise en cause tardive des livrables
– Création de dette technique

Engager tôt les équipes de test et travailler sur l’automatisation des tests

Impliquer à temps les équipes de déploiement et support

Résister à la tentation de livrer trop fréquemment en production

Attacher de l’importance aux exigences Non Fonctionnelles

Garantir la bonne transition en production en intégrant les préceptes ITIL

14/11/2012 29

3. Difficultés de la mise en production
Gouvernance
Assurer l’initiation des projets en phase avec la stratégie métier

Mettre en place une intégration continue

Soigner la réception et l’homologation
– Acceptation fonctionnelle par les utilisateurs
– Acceptation non fonctionnelles par les équipes techniques et de support

Veiller à la bonne transition en production par un processus de mise en
production rigoureux
– Partager les informations décrivant le changement et les phases de mise en
œuvre
– Vérifier le respect de la qualité requise
– S ’assurer de la dépendances des changements
– Tenir compte des contraintes de ressources et contraintes externes
– Gérer le risque de la mise en production

14/11/2012 30

4. Valoriser le facteur humain
Changement de rôle du chef de projet
Leader
Manager
inspirateur et
gestionnaire
facilitateur
Acteur de la production de la valeur
Coach, rôle « protecteur »
Autogestion des équipes
Redonner envie de travailler ensemble
Favoriser l’apprentissage par une approche empirique
Capitaliser l’expérience
Privilégier la performance à long terme
Qualité = objectif commun
!
Faire mieux n’est pas synonyme de faire plus ou faire trop :
attention au STRESS
L’intelligence collective ne doit pas freiner la capacité créative des
individus

14/11/2012 31

Conclusion

Méthodes Agile = philosophie de développement (pas une boîte à
outils!)

Pas de démarche universelle mais panachage conseillé

Prendre le « bon » et laisser les lourdeurs

Gestion du risque

Exemple de PMI Project Management Institute qui intégre l’Agilité
• Nouvelles certification PMI-ACP (Agile Certification Practitioner)
• Prise en compte des méthodes Agiles dans le PMBOK 5th Ed. 2012

14/11/2012 32

Agilité : une main de fer dans un gant de velours

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (13)

Ähnlich wie Agilité : une main de fer dans un gant de velours

Ähnlich wie Agilité : une main de fer dans un gant de velours (20)

Mehr von HSBC Private Bank

Mehr von HSBC Private Bank (9)

Agilité : une main de fer dans un gant de velours