32
1 14/11/2012 Agilité: Une main de fer dans un gant de velours… Marc BURLEREAUX, [email protected] Release Manager Européen auprès d’une banque suisse PMP, PMI-RMP, PgMP, ITIL V3 Sylvain GAUTIER, [email protected] Consultant Agile / ITIL / BPMN société SYGIT, Suisse Christine RIEU, [email protected] Maître de Conférences en Informatique, Laboratoire LISTIC, Université de Savoie, Annecy

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

Embed Size (px)

DESCRIPTION

 

Citation preview

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

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

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

214/11/2012

Introduction

Expertise bancaire privée,Program & ReleaseManager,PMI

Recherche universitaire,Gestion des compétences, PMI

Expertise Agile, ITIL, BPMN

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

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

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

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

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

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é

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

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é

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

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

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

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

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

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

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

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

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

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

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

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

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

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…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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é

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

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

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

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

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

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

!

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

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