Agilité:                         Une main de fer                     dans un gant de velours…             Marc BURLEREAUX,...
Introduction     Expertise bancaire     privée,     Program &     Release     Manager,             Recherche universitaire...
Sommaire             Introduction             1.   Principes de base Agile             2.   Bonnes pratiques pour le cadra...
1. Principes de base Agile             Tout type de projet             Alternative aux méthodes traditionnelles           ...
1. Principes de base Agile suite             Des méthodes pragmatiques, partant du principe que les besoins             év...
2.1. Bonnes pratiques pour                                               le cadrage d’un projet             Trois notions ...
Cas d’utilisation (Use case ou UC)                                     Les cas d’utilisation ne sont pas seulement une tec...
2.2 Bonnes pratiques pour le                                   développement d’un projet             Le processus d’itérat...
Processus :                        Conduire une itération                                                                 ...
Processus : Conduire une itération      ID du Processus                       xxxxxxxxx                                   ...
Processus : Conduire une itération      Objectifs du processus      Bonnes pratiques sur la façon de mener la phase Elabor...
Tâche :                     Cérémonie du Planning d’itération      ID de la tâche                                xxxxxxxxx...
Product Backlog                                Cas                              nominal                                   ...
Tâche :                   Mêlée quotidienne      ID de la tâche                             xxxxxxxxx                     ...
Tâche :                   Démonstration      ID de la tâche                             xxxxxxxxx                         ...
Tâche :                      Rétrospective      ID de la tâche                               xxxxxxxxx                    ...
Tâche :                    Ajuster le périmètre      ID de la tâche                            xxxxxxxxx                  ...
Tâche :                    Revue de Backlog      ID de la tâche                                xxxxxxxxx                  ...
Tâche :                    Revue Technique      ID de la tâche                             xxxxxxxxx                      ...
Tâche :                   Tests MOE      ID de la tâche                             xxxxxxxxx                             ...
Tâche :                    Tests MOA      ID de la tâche                              xxxxxxxxx                           ...
Tâche :                    Modélisation      ID de la tâche                            xxxxxxxxx                          ...
Tâche :                    Conception      ID de la tâche                               xxxxxxxxx                         ...
Tâche :                       Analyse      ID de la tâche                             xxxxxxxxx                           ...
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)    ...
C’est quoi une « bonne » story ?       C’est une fonction métier compréhensible et utilisable par un utilisateur (ou      ...
3. Challenges de la mise en production                                                   Contexte             Domaine banc...
3. Challenges de la mise en production                                      Ecueils dus à l’agilité             Livraisons...
3. Challenges de la mise en production                                                   Conseils             Impliquer to...
3. Difficultés de la mise en production                                              Gouvernance             Assurer l’ini...
4. Valoriser le facteur humain             Changement de rôle du chef de projet                                           ...
Conclusion             Méthodes Agile = philosophie de développement (pas une boîte à             outils!)             Pas...
Prochain SlideShare
Chargement dans…5
×

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

1 388 vues

Publié le

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 388
Sur SlideShare
0
Issues des intégrations
0
Intégrations
29
Actions
Partages
0
Téléchargements
43
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. 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, Annecy14/11/2012 1
  2. 2. Introduction Expertise bancaire privée, Program & Release Manager, Recherche universitaire, PMI Gestion des compétences, PMI Expertise Agile, ITIL, BPMN14/11/2012 2
  3. 3. 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 Conclusion14/11/2012 3
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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 tests14/11/2012 7
  8. 8. 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 maximum14/11/2012 8
  9. 9. 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 saisiEquipe 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
  10. 10. Processus : Conduire une itération 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 Suivant14/11/2012 10
  11. 11. 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 Home Précédent14/11/2012 11
  12. 12. 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. Home14/11/2012 12
  13. 13. 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édent14/11/2012 13
  14. 14. Tâche : Mêlée quotidienne ID de la tâche xxxxxxxxx Lien vers les documents de référence Résumé de la tâche Réunion de coordination d’équipe Link 1 Outil principal utilisé Manuel Link 2 Risque à mal faire Probabilité 40% Impact Sensible Link 3 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. Quest ce que jai fait hier ? 2. Quest-ce que je vais faire aujourdhui ? 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 sen 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 dactivité. 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 Home14/11/2012 14
  15. 15. Tâche : Démonstration ID de la tâche xxxxxxxxx Lien vers les documents de référence Résumé de la tâche Démontrer l’incrément produit Link 1 Outil principal utilisé Manuel Link 2 Risque à mal faire Probabilité 40% Impact Critique Link 3 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. … Home14/11/2012 15
  16. 16. Tâche : Rétrospective ID de la tâche xxxxxxxxx Lien vers les documents de référence Résumé de la tâche Analyser le processus, Rechercher les causes, Proposer des améliorations Link 1 Outil principal utilisé Manuel Link 2 Risque à mal faire Probabilité 40% Impact Critique Link 3 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. … Home14/11/2012 16
  17. 17. Tâche : Ajuster le périmètre ID de la tâche xxxxxxxxx Lien vers les documents de référence 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 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 Home14/11/2012 17
  18. 18. Tâche : Revue de Backlog ID de la tâche xxxxxxxxx Lien vers les documents de référence Résumé de la tâche Préparer l’itération suivante Link 1 Outil principal utilisé Redmine / RTC ... Link 2 Risque à mal faire Probabilité 20% Impact Sensible Link 3 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 nest pas utile. Home14/11/2012 18
  19. 19. Tâche : Revue Technique ID de la tâche xxxxxxxxx Lien vers les documents de référence 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 Risque à mal faire Probabilité 40% Impact Sensible Link 3 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 Home14/11/2012 19
  20. 20. Tâche : Tests MOE ID de la tâche xxxxxxxxx Lien vers les documents de référence Résumé de la tâche Tester la story Link 1 Outil principal utilisé Poste de travail socle standard + environnement de test Link 2 Risque à mal faire Probabilité 40% Impact Sensible Link 3 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 Home14/11/2012 20
  21. 21. Tâche : Tests MOA ID de la tâche xxxxxxxxx Lien vers les documents de référence 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 Risque à mal faire Probabilité 40% Impact Sensible Link 3 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 Home14/11/2012 21
  22. 22. Tâche : Modélisation ID de la tâche xxxxxxxxx Lien vers les documents de référence 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 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 Home14/11/2012 22
  23. 23. Tâche : Conception ID de la tâche xxxxxxxxx Lien vers les documents de référence Résumé de la tâche Décrire la cinématique entre les modèles Link 1 Outil principal utilisé ….. Link 2 Risque à mal faire Probabilité 40% Impact Sensible Link 3 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 Home14/11/2012 23
  24. 24. Tâche : Analyse ID de la tâche xxxxxxxxx Lien vers les documents de référence Résumé de la tâche Rédiger les spécifications fonctionnelles Link 1 Outil principal utilisé RRC Link 2 Risque à mal faire Probabilité 40% Impact Critique Link 3 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 Home14/11/2012 24
  25. 25. 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édent14/11/2012 25
  26. 26. 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édent14/11/2012 26
  27. 27. 3. Challenges de la mise en production 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 utilisateurs14/11/2012 27
  28. 28. 3. Challenges de la mise en production 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
  29. 29. 3. Challenges de la mise en production 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 ITIL14/11/2012 29
  30. 30. 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 production14/11/2012 30
  31. 31. 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 individus14/11/2012 31
  32. 32. 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. 201214/11/2012 32

×