Upload
marc-burlereaux
View
778
Download
0
Embed Size (px)
DESCRIPTION
Citation preview
114/11/2012
Agilité: Une main de fer
dans un gant de velours…
Marc BURLEREAUX, [email protected] Manager Européen auprès d’une banque suiss ePMP, PMI-RMP, PgMP, ITIL V3
Sylvain GAUTIER, [email protected] Agile / ITIL / BPMN société SYGIT, Suis se
Christine RIEU, [email protected]ître de Conférences en Informatique, Laboratoire LISTIC, Université de Savoie, Annecy
214/11/2012
Introduction
Expertise bancaire privée,Program & ReleaseManager,PMI
Recherche universitaire,Gestion des compétences, PMI
Expertise Agile, ITIL, BPMN
314/11/2012
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
414/11/2012
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
� Démarche d’architecture d’entreprise
� Pilotage par les risquesApproche
processus
SOA
Référentiel
d’’’’entreprise
514/11/2012
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é
614/11/2012
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é
714/11/2012
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
Modèle
d’’’’analyse
Modèle de
conception
spécifié par réalisé par Implémenté par distribué par vérifié par
Modèle de
déploiement
Modèle de tests
Modèle
d’’’’implémentation
Use case y Use case z
<<fragment>>
Ivar
Jacobson
Modèle des cas
d’’’’utilisation : le cœur du projet
814/11/2012
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
914/11/2012
Processus : Conduire une itérationE
quip
e pr
ojet
SC
RU
M M
aste
rS
crib
e
Mêlée quotidienneCérémonie du
Planning d’itération
Débutd’itération
Backlogd’itérationdéterminé Plan
d’itérationsaisi
MêléeQuotidienne
effectuée
Avancementsaisi
CP
UC
PI
Analyse
Modélisation
Test MOA
Revue technique
Conception
Développement
Test MOE
Saisie du plan
d’itérationSaisie de
l’avancement
Tâcheréalisée
Ajuster le périmètre
Revue de Backlog
9H00 Game Over
Plan d’actionrédigé
Clôture de
L’itération
Itérationterminée
Fin d’itération– 4 Jours
Backlogprojetajusté
Evènementmajeur
Backlogajusté
Itérationclôturée
Mise à jour
Des livrables
Agile
LivrablesAgileÀ jour
Démonstrationeffectuée
Démonstration
Rétrospective
Game Over ?
Oui
Non
Suite du discours
1014/11/2012
Processus : Conduire une itération
ID du Processus xxxxxxxxx
Résumé du processus Gérez votre projet de manière Agile
Propriétaire du processus Agile
Version 0.1
Statut Draft / à valider / validé / communiqué
Revue par Carine et Hermann
Date du statut 08/11/2011
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.
Lien vers les documents de référence
Link 1
Link 2
Link 3
Link 4
Home Suivant
1114/11/2012
Processus : Conduire une itération
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
PrécédentHome
1214/11/2012
Tâche : Cérémonie du Planning d’itération
ID de la tâche xxxxxxxxx
Résumé de la tâche Construisez votre « Cocon » de travail pour le mois à venir
Outil principal utilisé Manuel
Risque à mal faire Probabilité 10% Impact Stratégique
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.
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
• Les objectifs de l’itération sont précisés
4. Déterminer la capacité de l’équipe
• Capacité calendaires : CC = (effectif X durée de l’itération) - congés prévus - autres engagements
• 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.
Lien vers les documents de référence
Link 1
Link 2
Link 3
C’est quoi
une
« bonne »
tâche ?
C’est quoi
une
« bonne »
story?
Product Backlog
Home
1314/11/2012
Product Backlog
Précédent
Use
Case
Variante 2
Variante 1
Cas
nominal
Cas
nominal
• Pas plus d’ ½ itération
• Démontrable
Exigence
3
Exigence
2
Exigence
1
Story 2Story 2
Story 3Story 3
Tâche
1
Tâche
1Story 1Story 1
Tâche
2
Tâche
2
Tâche
n
Tâche
n…
Exigences non
fonctionnelles
Tâche
1
Tâche
1Story nStory n
Tâche
2
Tâche
2
Tâche
n
Tâche
n…
1414/11/2012
Tâche : Mêlée quotidienne
ID de la tâche xxxxxxxxx
Résumé de la tâche Réunion de coordination d’équipe
Outil principal utilisé Manuel
Risque à mal faire Probabilité 40% Impact Sensible
Objectifs de la tâche
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.
Opérations de la tâche / procédure
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
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
1514/11/2012
Tâche : Démonstration
ID de la tâche xxxxxxxxx
Résumé de la tâche Démontrer l’incrément produit
Outil principal utilisé Manuel
Risque à mal faire Probabilité 40% Impact Critique
Objectifs de la tâche
1. L’équipe présente les nouvelles fonctionnalités aux parties prenantes et recueille le feedback = Revue du produit (qualité de la conception / code ….).
Opérations de la tâche / procédure
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. …
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
1614/11/2012
Tâche : Rétrospective
ID de la tâche xxxxxxxxx
Résumé de la tâche Analyser le processus, Rechercher les causes, Proposer des améliorations
Outil principal utilisé Manuel
Risque à mal faire Probabilité 40% Impact Critique
Objectifs de la tâche
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).
Opérations de la tâche / procédure
• 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. …
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
1714/11/2012
Tâche : Ajuster le périmètre
ID de la tâche xxxxxxxxx
Résumé de la tâche Modifier le Backlog de l’itération en cours, en cas de force majeure
Outil principal utilisé Redmine / RTC ...
Risque à mal faire Probabilité 20% Impact Faible
Objectifs de la tâche
Modification des objectifs de l’itération, les items les moins prioritaires sont éventuellement exclus
Opérations de la tâche / procédure
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
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
1814/11/2012
Tâche : Revue de Backlog
ID de la tâche xxxxxxxxx
Résumé de la tâche Préparer l’itération suivante
Outil principal utilisé Redmine / RTC ...
Risque à mal faire Probabilité 20% Impact Sensible
Objectifs de la tâche
• « 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.
Opérations de la tâche / procédure
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.
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
1914/11/2012
Tâche : Revue Technique
ID de la tâche xxxxxxxxx
Résumé de la tâche S’assurer du respect des standards qualité au fil de l’eau
Outil principal utilisé RSA, ….
Risque à mal faire Probabilité 40% Impact Sensible
Objectifs de la tâche
Effectuer des revues sur les livrables de l’ensemble des outils utilisés
Opérations de la tâche / procédure
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
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
2014/11/2012
Tâche : Tests MOE
ID de la tâche xxxxxxxxx
Résumé de la tâche Tester la story
Outil principal utilisé Poste de travail socle standard + environnement de test
Risque à mal faire Probabilité 40% Impact Sensible
Objectifs de la tâche
S’assurer que les stories sont développées selon la conception et la modélisation validées
Opérations de la tâche / procédure
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
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
2114/11/2012
Tâche : Tests MOA
ID de la tâche xxxxxxxxx
Résumé de la tâche Tester le Use Case et ses exigences
Outil principal utilisé Poste de travail socle standard + environnement de test
Risque à mal faire Probabilité 40% Impact Sensible
Objectifs de la tâche
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).
Opérations de la tâche / procédure
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
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
2214/11/2012
Tâche : Modélisation
ID de la tâche xxxxxxxxx
Résumé de la tâche Un bon modèle vaut mieux que 100 pages de documentation
Outil principal utilisé Visual Paradigm, PowerAMC, RSA, IDA, ARIS
Risque à mal faire Probabilité 40% Impact Stratégique
Objectifs de la tâche
La MOE ainsi que les architectes réalisent les modèles de conception nécessaires, utilisant les outils idoines.
Opérations de la tâche / procédure
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
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
2314/11/2012
Tâche : Conception
ID de la tâche xxxxxxxxx
Résumé de la tâche Décrire la cinématique entre les modèles
Outil principal utilisé …..
Risque à mal faire Probabilité 40% Impact Sensible
Objectifs de la tâche
Ecrire les spécifications techniques, les diagrammes explicatifs associés, indiquant la logique de conception de la solution
Opérations de la tâche / procédure
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
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
2414/11/2012
Tâche : Analyse
ID de la tâche xxxxxxxxx
Résumé de la tâche Rédiger les spécifications fonctionnelles
Outil principal utilisé RRC
Risque à mal faire Probabilité 40% Impact Critique
Objectifs de la tâche
Ecrire les spécifications fonctionnelles, au sein du référentiel d’entreprise RRC.
Rester succin, non ambiguë et clair.
Opérations de la tâche / procédure
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
Lien vers les documents de référence
Link 1
Link 2
Link 3
Home
2514/11/2012
C’est quoi une « bonne » tâche ?
Précédent
� C’est une tâche limitée dont la réalisation est lim ité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 intelligibl e, 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
2614/11/2012
C’est quoi une « bonne » story ?
� C’est une fonction métier compréhensible et utilisa ble par un utilisateur (ou par un informaticien si c’est une fonction techniqu e 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/fr agment 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
2714/11/2012
� 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
3. Challenges de la mise en production Contexte
2814/11/2012
� 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écur ité dès l’origine– Remise en cause tardive des livrables – Création de dette technique
� Manque d’implication des équipes d’intégration et i nfrastructure� Manque d’implication des équipes de déploiement et support
Résultats : • Production gérée par les équipes projet (voire le f ournisseur)• Instabilité de la production et mauvais service ren du au client• Dette technique coûteuse • Pérennité de la solution amoindrie• Image de marque de l’IT écornée• Etc …
3. Challenges de la mise en production Ecueils dus à l’agilité
2914/11/2012
� 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ég rant les préceptes ITIL
3. Challenges de la mise en production Conseils
3014/11/2012
� 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
3. Difficultés de la mise en production Gouvernance
3114/11/2012
4. Valoriser le facteur humain
� Changement de rôle du chef de projet
� 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 empiriqu e� 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
Manager
gestionnaire
Leader
inspirateur et
facilitateur
!
3214/11/2012
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