-
Intérêt des méthodes agiles pour la conduite des projets
d'intégration
Retour d'expériences d’un projet mené par
pour
-
Agenda
• Vistali
• L’Orchestration des Systèmes d’Information
• Spécificités d’un projet EAI
• CDC - Déroulement du projet et pratiques
• CDC - Points clefs
• Mes influences
• Éléments retenus des approches agiles
• Gains potentiels
• Conditions d’application et limites
• Bilan du projet CDC - Gains réels
• Prochaines étapes …
-
Avertissement
Des convictions mais pas de dogmes
Provoquer… la réflexion
Simplicité de l’exposé
Démystification des termes
Quelques diapositives en anglais
-
Vistali - vocation
Vistali est le cabinet spécialiste de l’Urbanisation et de
l’Orchestration deSystème d’Information
Vistali définit et construit les solutions permettant à
l’entreprise d’être plus agileau sein de son environnement
Conseiller les entreprises dans l’urbanisation de leur système
d’information,
Construire et implémenter les solutions d’orchestration
transverses aux organisations
Garantir la conduite du changement en apportant les réponses
organisationnelles et méthodologiques pour supporter l’évolution du
SI
Notre savoir-faire est capitalisé dans , la Méthodologie de
référence dédiée aux démarches d’urbanisation et projets
d’Orchestration de SI
-
Vistali - des clients prestigieux
http://www.lafarge.com/lafarge/lafargeV2.nsf/all/homepage2us?opendocumenthttp://candidats.manpower.fr/manpoprod_bin/web_grhsomoff
-
L’Orchestration des Systèmes d’Information
-
Traduction des besoins métier
Ce que veut le métier:
• Le bon processus, la bonne information, accessibles et
maîtrisables
• La cohérence• L’Agilité, absence d’inertie
…. au moindre coût
Modèle illusoi
re
En regard, un SI composé d’îlots applicatifs:
• Hétérogènes & indépendants• Construits pour l’efficacité «
locale » • A longue durée de vie
Décomposition qui devrait être imperceptible à l’exécution du
métier:
• 1 processus îlot unique• 1 information îlot unique• 1
utilisateur îlot unique
-
Les freins portés par le SI
La réalité
de nombreux processus ou informations sont transverses, répartis
sur plusieurs îlots, sans propriétaire unique
Conséquence architecturale
Pour permettre a minima l’exécution de ces processus transverses
et la diffusion des informations transverses, des échanges très
nombreux :
•Moins performants que les îlots eux-mêmes•Créant un couplage
fort •Délicats à maîtriser pour chaque projet ou évolution•Aux
coûts d’évolution parfois rédhibitoires
Manque de co
hérence du
SI perçue par
le métier,
dégradation d
e la qualité
de service et d
e la
performance
Manque
d’agilité du SI
et de ses
composants Coût
d’évolution
élevé
-
Les propositions de l’Orchestration
Objectifs.• Capacités d’interopérabilité• Couplage lâche•
Normalisation des services
Modèles & Solutions. • SOA, ESOA, EDA• EAI, ESB
Orchestration des composants du SI
Enjeux.l’agilité des îlots du SI entre euxcomplexité perçue des
îlots coût et délais d’évolutions
Objectifs.• Masquer les contraintes d’un SI en îlots…Là où c’est
utile, et seulement là.• Minimiser les impacts îlots à chaque
évolution
Modèles & Solutions. • S’appuie sur l’architecture de
services• BPM, BAM, MDM, Portail..
Orchestration des composants métier
Enjeux.cohérence des services métiers transverses du SIcapacités
d’évolutionscoût et délais d’évolutions
Agilité et
cohérence
architecturale
Agilité et
cohérence
fonctionnelle
Eviter d’être
contraint
d’arbitrer e
ntre agilité
et cohérenc
e du SIC
ouches
d’Orchestrat
ion =
Couches d’a
daptabilité
du SI
-
EAI - Marché
Offre d’infrastructure
« type serveurs d’exécution
+ Atelier développement »
(ex : IBM, Microsoft, BEA)
Offre des éditeurs issus des marchés EAI et ESB
« type progiciel »S’exécutant sur des serveurs
d’application
(ex : webMethods, Seebeyond)
Offres de niche sur les différentes briques
(ex : Actional, iWay, Intalio, Systar, IDS Sheer, Plumtree…)
-
Spécificité d’un projet d’EAI
• Projets stratégiques ou tactiques
• Périmètre fonctionnel
• Contexte politique
• Nombre d’intervenants
• Multiplicité des technologies
• Connectivité
• Testabilité
• Volume (scalabilité)
-
Le projet CDC
Caisse des dépôts et consignations• Une première mission de
conseil
• Un projet pilote réaliste « PLATON »
• En mode forfait
320 jours sur 3 mois 8 personnes Profils
DP,CP,AF,AT,AL,TL,D1,D2
• Un deuxième projet « SALSA »
Régie estimée à 180 jours
-
CDC - Déroulement du projetHistoire
-
CDC – Pratiques 1
PROJET SALSABACKLOG
Item Charges Qui Itération Fin RealiseCanonique Emp 3 1Lecture
Format1 (CN) 3 1Acquisition GEO 2 1Info GEO 4 1Mapping F2 ->
EmpCN 2 2Filtrage Planet 2 2Filtrage Adressage 2 3Filtrage Fact,
Param 2 3Transco (? Par flux ?) 8 2Supervision (tableau de bord) 4
2Gestion des erreurs 4 4Mapping EmpCN -> Gisst 2 3Mapping EmpCN
-> Planet 2 2Mapping EmpCN -> Adressage 2 3Mapping EmpCN
-> Paramètres 2 3Mapping EmpCN -> Facturation 2 4Creation
Fichier Gisst 1 3Creation Fichier Planet 1 2Creation Fichier
Adressage 1 3Creation Fichier Paramètres 1 3Creation Fichier
Facturation 1 3Livraison Gisst 1 4Livraison Planet 1 2Livraison
Adressage 1 4Livraison Paramètres 1 4Livraison Facturation 1
4Remonté des alertes 4 4
Total Dev 60
-
CDC – Pratiques 2
Backlog donne 60 jours dev (dev + tests unitaires)Charge cible
du projet 180Décomposition des jours en activitéLes % ont été
établis par RDR sur la base du profil du projet.
180 180DP 3,00% 5,4Management 11,00% 19,8Requirements 11,00%
19,8Design 10,00% 18Archi technique 5,00% 9Dev 20,00% 36test
unitaires 10,00% 18test d'integration 5,00% 9suivi de qualification
10,00% 18Livraison applicative 2,00% 3,6Environnement 5,00% 9Mise
en service 8,00% 14,4
100,00% 180
-
CDC – Pratiques 3
Activite Responsable Estimation180
RDR 25Suivi DP 5PAQ 1Suivi equipe 10Suivi externe 9
RDR 21AnalyseBesoins-Doc-Specification
11AnalyseBesoins-Doc-ContratsDeService
8AnalyseBesoins-Doc-NormesProjet 2
RDR 27AnalyseBesoins-Doc-ArchitectureTechnique
7AnalyseBesoins-Doc-ArchitectureLogicielle 20
Implementation SGN 54DEV-Doc-ConceptionDetaillee 12DEV-codeEAI
52
Qualification RDR 27AnalyseBesoins-Doc-DossierQualification
5Integration 10Recette 12
Envi RDR 12Environnements 8Livraisons 4
Mise en Service 14
Management
Analyse des besoins
Conception générale
-
CDC – Pratiques 4
Projet SALSARDR - 21/10/04
Analyse des resources41 42 43 44 45 46 47 48 49 50 51
11-oct 18-oct 25-oct 01-nov 08-nov 15-nov 22-nov 29-nov 06-déc
13-déc 20-décLancement Itération 1 Itération 2 Itération 3
Intégration / Assemblage Recette
DP 5 0 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5CP 20 1 1 2 2 2 2 2 2
2 1 1ArchiFonct 17 0 3 4 3 3 4 0AchiLogiciel 14 0 2 3 3 3
3ArchiTechnique 12 0 3 2 2Dev Lead 35 2 2 2 2 3 3 3 4 4 3Dev 1 58 3
5 5 4 4 4 5 5 5 5 4Dev 2 24 1 2 3 3 3 3 3 3 3
Total 180 4 14 21 19 19 19 13 13 14 13 8
-
CDC – Pratiques 5
Macro planning 41 42 43 44 45 46 47 48 49 50 5111-oct 18-oct
25-oct 01-nov 08-nov 15-nov 22-nov 29-nov 06-déc 13-déc 20-déc
Lancement Itération 1 Itération 2 Itération 3 Intégration /
Assemblage RecetteOrganisation Lancement Analyse des besoins
ConceptionImplémentation Qualification Mise en service
Tests / corrections Tests / correct - PAQ- Plan projet- Normes-
Début du Plan de qualification- Spécifications pour itération 1 --
périmètres -- Contrats de services -- Elements structurants --
Principes du filtrage / routage- Démarrage architecture
- Architecture logicielle 1Réalisation- 1/2 flux entrant
banalisé- Routage et Filtrage V0- Canonique- 1/2 flux sortant 1-
Gestion des erreurs- Specifications pour itération 2
- Architecture logicielle 3- 1/2 flux sortant 3, 4, 5- 1/2 flux
entrant 4- remontée d'alerte- tableau de bord
- Architecture logicielle 2- 1/2 flux sortant 1,2- 1/2 flux
entrant 2,3- Connecteur GEO
- Specifications pour itération 3
-
CDC - Déroulement du projetHistoire
-
CDC – Pratiques 6
Suivi des pratiques du projet PLATON
A garder A essayer
Itérations de 2 semainesPrésentation du design en début
d'itérationGestion de configuration pendant les devindiquer la
version package webM dans le commentaire PVCScheck-out des éléments
sur lesquels on travailleNotre gestion d'anomalie
P1- Intégrer plus souvent sur le serveur de consolidation avant
l'intégration en fin d'itérationP2- rédiger un guide '1/2 journée
d'intégration dans le projet' sorte de survival guide donné à tout
nouveau.
Problèmes
P1-Nombreuses erreurs lors de l'intégrationP2-Non respect des
conventions de nommage par non connaissance des docs
-
CDC – Pratiques 7
Suivi des livrables applicatifs du projet 01-juil 16-juil
30-juil 13-août 27-août 10-sept
Prévu 113 96 74 50 22 0Itération1 113 104Itération2 104
72Itération3 85 60Itération4 45 20 0
-
CDC – Pratiques 8
0
20
40
60
80
100
120
01/07
/2004
08/07
/2004
15/07
/2004
22/07
/2004
29/07
/2004
05/08
/2004
12/08
/2004
19/08
/2004
26/08
/2004
02/09
/2004
09/09
/2004
PrévuItération1Itération2Itération3Itération4
-
CDC - Pratiques 9
Suivi classique des documents
• Liste conforme au PAQ et METEOR
• Date prévisionnel
• Etat non commencé, en rédaction, livré, en correction,
approuvé
• Rédacteur
• Tableau de bord
Synthèse des livrables_Developpement.xls
-
CDC - Déroulement du projetHistoire
-
CDC - Déroulement du projetPoints clefs (1/4)
Arrivé chez CDC, le projet était déjà évalué en charge (318 j) à
partir d’un cahier des charges. L’équipe était constituée. Chacun
avait suivi le kick-off et la phase d’analyse des besoins et
conception générale était commencée sous l’égide de Pierre
Bougeret.
J’ai réuni l’ensemble de l’équipe pour que chacun donne sa
compréhension et sa vision du projet ainsi que sa confiance ou ses
interrogations concernant le staffing, les compétences de chacun,
les technologies utilisées, les fonctionnalités wM nécessaires, les
besoins exprimés, la relation avec le client, le planning.
Il est ressorti de cet état des lieux
- une confiance globale de pouvoir faire le projet en temps
- des éléments à surveiller tel que la clarté des besoins, ou le
fait que les 2 développeurs étaient débutants.
A partir du cahier des charges, j’ai validé l’estimation de
charge faite en amont en établissant une liste des éléments à
développer et une charge pour chaque élément. Cette charge de
développement (plus test) me donnait une charge globale en
appliquant une distribution standard (dev = 30% du tout).
J’ai validé ensuite les délais annoncés en effectuant un plan de
charge sur la période prévue.
Je proposais ensuite à l’équipe de découper la durée estimée du
projet en 5 fois 2 semaines ce qui nous donnerait 5 points de
contrôle pour évaluer ce qui serait développé et testé.
Une condition était d’obtenir chaque 2 semaines de nouveaux
éléments enregistrés dans PVCS.
360°
Macro planning
Itérations
SourceControl
-
CDC - Déroulement du projetPoints clefs (2/4)
ProductBacklogEarlyVictory
ItérationDébut
ItérationDesign
Avec Sebastien, nous avons alors ordonné la liste des éléments à
développer.
Les premiers éléments ont été choisis pour avoir rapidement un
cas nominal et en fonction des éléments qui nous semblaient assez
clair dans le cahier des charges.
Cette première liste nous a également permis d’orienter l’effort
de spécification puis de conception pour que soit clarifiés les
éléments à implémenter lors des 2 premières semaines de
développement.Une fois les éléments nécessaires spécifiés et
l’architecture logicielle globale conçue, le développement a
commencé.
Au début d’un cycle de développement, nous revoyions la liste
des éléments à développer avec 2 questions
Avons-nous le niveau d’information et de compréhension suffisant
?Les développeurs pensent-ils réalistes de réaliser l’ensemble en 2
semaines ?
Les développeurs étant débutants, il leur était difficile de
répondre à cette dernière question.
L ’architecte logicielle présente alors la cinématique du flux
concerné et l’inter-action des différents composants. Lors de cette
présentation, le nom des packages, le nom des service et leur
signature sont définis.
Chaque développeur comprends alors le rôle de chaque élément
dans l’ensemble.
-
CDC - Déroulement du projetPoints clefs (3/4)
Chaque jour, une discussion informelle me permet de savoir si
chacun peut progresser normalement.
Etant tous dans le même local, les interrogations sont souvent
immédiatement levées.(incompréhension de spécification, détail de
design, savoir faire wM).
Des problèmes sont justement rencontrés un peu plus tard lorsque
les architectes fonctionnel et logiciel sont moins présents. Des
questions soulevées ne trouvent pas de réponse.Je me permets alors
de prendre des décisions de design pour faire avancer le
développement mettant alors en situation difficile l’AL.
De temps à autre, nous mettons à jour la liste des pratiques de
travail commun.Par exemple, les développeurs demandent de
systématiser la présentation par l’architecte logiciel en début de
cycle de développement.
Au bout de 2 semaines, une demi-journée est consacrée à la
livraison des éléments de PVCS vers l’environnement de
consolidation (ou intégration) et quelques tests.
Je mets alors à jour la liste des éléments à développer en
indiquant la date de finalisation, produisant un graphique montrant
la progression des livraisons.
Je félicite l’équipe pour avoir tenu ses engagements.
Le diagramme d’avancement est affiché dans la pièce.
DailyMeetingOsmoticComm.
Réflexion
Livraison
BurnChart
Infor.Radiators
-
CDC - Déroulement du projetPoints clefs (4/4)
6-8 personnes Livraisons fréquentes
Analyse critique des pratiques (réflexion)‘Osmotic
Communication‘
Focus (priorities,time) Time boxing
Configuration ManagementExploratory 360°
Early Victory Incremental Rearchitecture
Information Radiators Daily stand-up meeting
Burn charts
-
Mes influences
• Gestion de projet ‘classique’
– Recommended Approach to Software Developmentdu Software
Engineering Institute (SEL).
– Etc.
• Expérience personnelle
• Méthodes Agiles
– AgileManifesto.org
– Crystal ClearA Human-Powered Methodology for Small Teams
– Agile development with SCRUM
• METEOR V3
http://agilemanifesto.org/principles.html
-
Méthodologies (1/2)
Ce que j’attends d’une méthodologie
• Travailler ensemble
Language et pratiques communesAider chacun à trouver sa place
dans l’équipe
• Savoir quoi faire
Feuille de route du projetBonne pratiques
• Comment travailler
Guide de survieCapitalisation
d’expérienceAccélérateursFormation
-
Méthodologie (2/2)
Ce que d’autres peuvent en attendre
• Argument commercial
• Avantage concurentiel
• Garantir la réussite des projets
• Permettre d’utiliser des personnes moins talentueuses
-
Influences des méthodes Agiles –Éléments retenus
Produire de la valeur au plus tôt et de manière fiable
• produire de manière itérative et incrémentale un système
opérationnel
• renforcer la collaboration avec le client
S’adapter au problème
• réflexion continue
• raccourcir le temps séparant une prise de décision de
l’évaluation de ses conséquences
-
Influences des méthodes Agiles –Éléments retenus
Priorités : efficacité, habitabilité et sécurité
• Attention particulière aux individus et leurs interactions
• Coût de circulation de l’information
Contôle
• Time-boxing
• Contrôler la conformité à un résultat acceptable
Design
• Design permanent
• Re-factoring
-
Influences – Agile Alliance (1/4)
Agilemanifesto.org/principles.html
We are uncovering better ways of developing software [products]
by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools Working
software over comprehensive documentation
Customer collaboration over contract negotiation Responding to
change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.
-
AgileManifestoÉléments retenus
People
• Business people and developers must work together daily
throughout the project.
• Build projects around motivated individuals.
• Give them the environment and support they need, and trust
them to get the job done
-
AgileManifestoÉléments retenus
Iterations
• Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software
• Deliver working software frequently, ( a couple of weeks)
• Working software is the primary measure of progress.
-
AgileManifestoÉléments retenus
Design
• Continuous attention to technical excellence and good design
enhances agility.
• Simplicity--the art of maximizing the amount of work not
done--is essential.
-
Crystal Clear
Crystal Clear
A Human-Powered Methodology For Small Teams,
including The Seven Properties of Effective Software
Projects
Alistair Cockburn
Humans and Technology
copyright 1998-2004, A. Cockburn
-
Crystal : Propriétés (1/2)
Itérations et livraisons fréquentes• Avez-vous livré du code
testé et utilisable à la communauté
des utilisateurs au moins deux fois dans les 2 derniers mois
?
Communication de proximité• Pouvez-vous accéder à la bonne
personne en moins de 30
secondes pour répondre à vos questions ? Captez-vous
régulièrement de l’information utile en entendant simplement une
conversation entre membres de l’équipe ?
Réflexion• Avez-vous consacré du temps au cours des trois
derniers
mois pour discuter des habitudes de travail, analyser ce qui
fonctionne, ce qu’on peut faire pour s’améliorer ?
Accès aux utilisateurs/experts• Est-ce que cela prend moins de
trois jours en moyenne pour
obtenir un expert pouvant répondre à vos questions ? Pouvez-vous
obtenir la réponse en quelques heures ?
-
Crystal : Propriétés (2/2)
Focalisation• Tout le monde connait-il ses deux principales
priorités ?
• Chacun bénéficie-t-il d’une période ininterrompue d’au moins
deux heures de travail chaque jour ?
Citoyenneté de développement• Pouvez-vous exprimer en réunion un
désaccord sur le
planning avec votre responsable ?
• Les personnes de l’équipe peuvent-elles terminer un débat en
état de désaccord amical ?
Environnement technique de tests automatisés• Pouvez-vous lancer
les tests d’une seule commande et les
laisser dérouler sans intervention physique ?
intégration fréquentes et de gestion de configuration• Chacun
des développeurs met-il fréquemment son code à
jour dans un gestionnaire de configuration ? Le système est-il
intégré au moins deux fois par semaine ?
-
Crystal Clear - pratiques
Une sélection de pratiques
• Strategy 1.Exploratory 360°
• Strategy 3. Walking Skeleton
• Strategy 4. Incremental Rearchitecture
• Strategy 5. Information Radiators
• Technique 9. Burn Charts
-
Gains possibles
Gains client• Possibilité de réduction des coûts
• Couverture des besoins réels
• Profit et Cashflow
Gains mutuels• Qualité des décisions
• Visibilité Contrôle/ gestion des risques
• Moral
• Relation WIN-WIN
Gains Vistali• Relation client
• Facturation
• Faire preuve de sa capacité opérationnelle à délivrer
-
Gains Client – Couverture des besoins réels
compréhension & qualité de l’information
StartObjectif Plannifié
Résultat traditonnel
Ce qu’il faut en réalité
-
Gains Client – Profit (1/2)
reto
ur s
ur in
vest
isse
men
t
profit
temps
inve
stis
sem
ent
point d’équilibre
Cycle de vie économique d’un système
temps
€
-
Gains Client – Profit (2/2)
temps
temps
Profit total avec déploiement phasé
Profit phase 1Profit phase 2
€
Le phasage du déploiement améliore le cash flow et augmente le
profit.
€
-
Gains Client – temps de développement
Temps
Intégration & Test
Construction
Analyse, conception
Spécification
Com
plét
ude,
Sta
bilit
é
Le développement concurrent prend moins de temps, coûte plus
qu’un développement séquentiel parfait… qui est rarement
réalisable.
-
Gains Mutuels – qualité de décision
Mieux décider• Réduire le temps entre une décision et la mesure
de ces
conséquences
• Décider sur des données récentes
• Repousser les limites temporelles pour décider
Mieux contrôler• Contrôle vs Prédictibilité
• Prédictibilité = Conformité à un planle résultat final doit
être peu différent de celui défini à l’origine en terme de
périmètre des exigences, du coût et du délai.
• Contrôle = Conformité à un résultat acceptable. Le résultat de
chaque itération est visible et acceptable par les sponsors du
projet qui peuvent influencer le résultat final.
-
Gains Mutuels –WIN-WIN
• Customer collaboration over contract negotiation
• Un modèle de facturation mixte (fonctions et taux journalier)
peut être mis en place
Une alternative au forfait qui fige des spécifications
imcomplètes
• Meilleur analyse et négociation
Coût / Qualité / Durée / Périmètre fonctionnel
-
Gains Vistali
• Faire preuve de sa capacité opérationnelle à délivrer (et
séparer les variables délivrer/prédir)
• Inclure le client dans le partage de risque pour la
prédiction
• Présence client
• Favoriser l’apparition des sponsors
• Qu’est ce qu’un succès
• Un parallèle sonore …
-
Conditions / limites
Qualité du design
• Decouplage et Encapsulation
• Capacité de Re-factoring
• Design permanent
Rôles
• ‘Architects also implement’
• Accès aux experts
• Rôle du chef de projet
-
Conditions / limites
Zone favorable• Client favorable
• Taille du projet
Outillage• Tests automatiques
• Gestion de version
Compétences• Les Programmeurs sont des Professionnels
Responsables
• Formalisme, processus, documentation ne sont pas des
substituts à la discipline, au savoir-faire et à la
compréhension
-
Bilan du projet PLATON
Respect des engagements
• Périmètre fonctionnel respecté
• Livraison dans les délais
Qualité
• Aucune anomalies en production en 3 mois
Relation client
• Confiance établie avec le client
Equipe
• Une sérénité tout au long du projet
-
Bilan des Gains réels
Gains client
• Possibilité de réduction des coûts - non expérimenté
• Couverture des besoins réels - oui
• Profit et Cashflow - non expérimenté
Gains mutuels
• Qualité des décisions - oui partiel
• Visibilité Contrôle/ gestion des risques - oui
• Moral - oui
• Relation WIN-WIN - oui
Gains Vistali
• Relation client - oui
• Facturation - non expérimenté
• Faire preuve de sa capacité - ouiopérationnelle à délivrer
-
Vision
2 centres d’intérêts• Le client
• Les solutions logicielles
4 variables• Coût / Qualité / Durée / Périmètre fonctionnel
1 constat• La mise en oeuvre des méthodes « traditionnelles
»
conduit à deux grands perdants la qualité et le périmètre
fonctionnel
1 alternative• Utiliser les méthodes agiles pour rétablir un
équilibre
dans le contrôle des 4 variables
-
Questions
Raphaël DERBIERDirecteur de Projet
Espace 2131, place Ronde92986 Paris La Défense
[email protected]
mailto:[email protected]
AgendaAvertissementVistali - vocationVistali - des clients
prestigieuxL’Orchestration des Systèmes d’InformationTraduction des
besoins métierLes freins portés par le SILes propositions de
l’OrchestrationEAI - MarchéSpécificité d’un projet d’EAILe projet
CDCCDC - Déroulement du projetHistoireCDC – Pratiques 1CDC –
Pratiques 2CDC – Pratiques 3CDC – Pratiques 4CDC – Pratiques 5CDC -
Déroulement du projetHistoireCDC – Pratiques 6CDC – Pratiques 7CDC
– Pratiques 8CDC - Pratiques 9CDC - Déroulement du
projetHistoireCDC - Déroulement du projetPoints clefs (1/4)CDC -
Déroulement du projetPoints clefs (2/4)CDC - Déroulement du
projetPoints clefs (3/4)CDC - Déroulement du projetPoints clefs
(4/4)Mes influencesMéthodologies (1/2)Méthodologie (2/2)Influences
des méthodes Agiles – Éléments retenusInfluences des méthodes
Agiles – Éléments retenusInfluences – Agile Alliance
(1/4)AgileManifesto Éléments retenusAgileManifesto Éléments
retenusAgileManifesto Éléments retenusCrystal ClearCrystal :
Propriétés (1/2)Crystal : Propriétés (2/2)Crystal Clear -
pratiquesGains possiblesGains Client – Couverture des besoins
réelsGains Client – Profit (1/2)Gains Client – Profit (2/2)Gains
Client – temps de développementGains Mutuels – qualité de
décisionGains Mutuels –WIN-WINGains VistaliConditions /
limitesConditions / limitesBilan du projet PLATONBilan des Gains
réelsVisionQuestions
