2. Plan
1 3 5 7
2 4 6 8
Manifeste Les valeurs Les exemples DSDM
Description Les Principe L’historique RAD
3. Les méthodes agiles caractérisent un mode de gestion des
projets informatiques privilégiant le dialogue entre toutes
les parties prenantes, clients, utilisateurs, développeurs et
autres professionnels du projet, la souplesse en cours de
réalisation, la capacité à modifier les plans et la rapidité de
livraison.
Description de méthode
Agile
4. Le Manifeste Agile
L'approche Agile propose au contraire de réduire considérablement
voire complètement
cet effet tunnel en donnant davantage de visibilité, en impliquant le
client du début à la fin
du projet et en adoptant un processus itératif et incrémental. Elle
considère que le besoin ne
peut être figé et propose au contraire de s'adapter aux changements de
ce dernier
5. Les Principes Agiles
Prioriser la
satisfaction
client
Exploiter le
changement
pour donner
un avantage
compétitif
au client
Livrer
fréquemment
de la valeur
avec des
cycles de
quelques
semaines ou
mois
Faire
collaborer
quotidienne
ment toutes
les partie
prenantes
Réaliser les
projets
avec des
personnes
motivées
02
03
04
05
Privilégier le
dialogue en
face à face
06
01
6. Les Principes Agiles
Mesurer
l’avancement
par la valeur
livrée
Maintenir
un rythme
soutenable
et constant
Porter une
attention
continue à
l'excellence
technique et
la bonne
conception
Simplifier et
minimiser la
quantité de
travail inutile
S’auto
organiser
pour faire
émerger
les
meilleures
solutions
07
08
09
10
11
À intervalles
réguliers,
réfléchir en
équipe aux
moyens de
devenir plus
efficace, puis
régler et
modifier son
comporteme
nt en
conséquence
12
7. Les valeurs Agile
Les individus et
leurs interactions
sont plus importants
que les processus et
les outils.
Un logiciel
fonctionnel est plus
important qu'une
documentation
exhaustive.
L'adaptation au
changement est plus
importante que
l'exécution d'un
plan.
La collaboration
avec les clients est
plus importante que
la négociation
contractuelle.
8. Historique Agile
≈ 1970 1986 1991 1996 1999 2001 2011
Création du
mode projet
et des
modèles en
cascade
(cycle « V »)
Développement
de la première
approche de
gestion de projet
de
développement
itératif (Japon)
Publication de Rapid
Application
Development (RAD),
première méthode
basée sur un
processus
incrémenta
Ken Schwaber et
Jeff Sutherland
publient SCRUM,
méthode de gestion
de projet générique
n’incluant pas les
pratiques
d’ingénierie
logicielle
Kent Beck and Ron
Jeffrie formalisent
l’eXtrem
Programming (XP)
Method
17 personnalités du
développement
logiciel discutent de
l'unification des
méthodes SCRUM,
XP, RAD, etc. C'est la
naissance du
Manifeste Agile et
du terme «Agile»
Création de la
première
certification Agile
par le Project
Management
Institute (PMI)
9. Adaptative Software Développent (ASD)
eXtreme Programming (XP)
Rapid Application Développement (RAD)
Lean Startup
Scrum
Des Exemple Agiles
Dynamic systems development method (DSDM)
10. Description:
Le développement rapide d’applications (RAD)
cette méthode d’agile se base sur la rapidité
d’exécution des projets, ce qui en fait un choix
intéressant pour les développeurs travaillant dans
un environnement où le rythme est soutenu.
la méthode RAD s’attache à minimiser la phase
de planification et à maximiser le développement
du prototype.
Méthode RAD
11. Phase 1 : planification des besoins
❖ Analyse du problème actuel
❖ Définition des exigences du projet
❖ Finalisation des exigences et approbation par chaque partie
prenante
Phase 2 : design utilisateur
❖ Les utilisateurs interagissent avec les développeurs pour
produire et valider des prototypes.
❖ Il s’agit presque d’un développement de logiciel personnalisé
où les utilisateurs peuvent tester chaque prototype du
produit, à chaque étape, pour s’assurer qu’il répond à leurs
attentes.
12. Phase 3 : construction rapide
❖ Préparation pour une construction rapide
❖ Développement du programme et de l’application
❖ Écriture du code
❖ Tests individuel, d’intégration et système
❖ Le client peut encore donner son avis tout au long du processus. Il
peut suggérer des modifications, des changements ou même de
nouvelles idées
Phase 4 : finalisation
❖ Il s’agit de la phase de mise en œuvre durant laquelle le produit fini
est lancé. Elle comprend la conversion des données, les tests et le
passage au nouveau système, ainsi que la formation des utilisateurs.
❖ Toutes les modifications finales sont déployées. En parallèle, les
programmeurs et les clients continuent à rechercher les bogues dans
le système
13.
14. Méthode DSDM
Description:
Le DSDM (dynamic systems Development method) est apparue
en 1994 pour dispenser au RAD d’une certaine discipline.
Le DSDM est un framework Agile très peu connu ,qui a évolué
avec le temps ; il se concentre plutôt sur une approche de
gestion de projet et de livraison que sur une façon de faire du
code.
15. Les principes fondateurs du DSDM:
Implication des utilisateurs : ils doivent être présent tout au long du développement du projet
Autonomie : L’équipe est autonome sur le développement et doit avoir un droit de décision
imparable sur l’évolution des besoins.
Visibilité du résultat : Livraison fréquente de l’application afin d’obtenir des feedback
fréquents.
Adéquation : L’application livrée doit être en adéquation avec le besoin des utilisateurs.
Développement itératif et incrémental : Le produit doit constamment s’améliorer avec le
feedback des utilisateurs.
Réversibilité : En cas de besoin, tout développement doit pouvoir revenir en arrière.
Synthèse : Un schéma directeur fixe le projet dans son ensemble que ce soit au niveau vision ou
au niveau objectifs
Tests : Automatisation de tests fréquent afin de garantir une non régression au sein de
l’application.
Coopération : L’ensemble de l’équipe ou parties prenantes sur le projet doivent accepter d’
éventuelles modifications des fonctionnalités demandées
16. Tests : Automatisation de tests fréquent afin de garantir une non régression au sein de
l’application.
Coopération : L’ensemble de l’équipe ou parties prenantes sur le projet doivent
accepter d’éventuelles modifications des fonctionnalités demandées
Développement itératif et incrémental : Le produit doit constamment s’améliorer
avec le feedback des utilisateurs.
Réversibilité : En cas de besoin, tout développement doit pouvoir revenir en arrière.
Synthèse : Un schéma directeur fixe le projet dans son ensemble que ce soit au niveau
vision ou au niveau objectifs
Tests : Automatisation de tests fréquent afin de garantir une non régression au sein de
l’application.
Coopération : L’ensemble de l’équipe ou parties prenantes sur le projet doivent
accepter d’éventuelles modifications des fonctionnalités demandées
18. Executive Sponsor / Project Champion : Cette personne est habilité à prendre
des décisions. Il va aussi engager des fonds et des ressources.
Le visionnaire : Cette personne a la responsabilité d’initier un projet en
assurant que les exigences essentielles sont présentes dès le début du projet. Il a
la vision la plus précise des objectifs business du projet ; il devra également
bien vérifier que les développements vont toujours dans le bon sens de la vision.
L’ambassadeur : Cette personne apporte les connaissances nécessaires venant
des utilisateurs de l’application pendant le projet ; il assure aussi un maximum
de feedback de ceux-ci tout au long du projet.
Un conseiller : cette personne est un utilisateur qui peut apporter de bonnes
connaissances quotidiennes au projet..
Project Manager : cette personne vient de l’équipe IT et a pour but de manager
le projet dans ses grandes lignes.
19. Technical Co-ordinator : Cette personne est responsable dans la définition
de l’architecture technique et le contrôle de la qualité technique.
Team Leader : cette personne est un leadeur d’équipe qui assurera que le
travail de l’équipe est efficace dans son ensemble.
Solution Developer : cette personne interprète les exigences du système et de
modélisation. Il fera également le développement des codes livrables et la
construction des prototypes..
Solution Tester : cette personne testera l’application en tentant de trouver des
bugs et documentera l’ensemble de ses trouvailles.
Scribe : cette personne sera responsable de rassembler et d’enregistrer les
exigences, les accords et les décisions prises au cours des workshop.
Facilitateur : cette personne sera là pour animer les workshop et s’assurer de
leur bon déroulement.
Rôles spécialisés : Business Architect, Quality Manager, System Integrator,
etc.
21. Étude de faisabilité : déterminer s’il est opportun de faire le projet en question.
Evaluation des coûts et de la valeur ajoutée attendue. Dans cette étape, on produit
un Rapport de Faisabilité ainsi qu’un Plan Global de Développement. On
développe parfois un prototype afin de démontrer la faisabilité technique.
Étude business (ou analyse fonctionnelle) : définition des spécifications
fonctionnalités que l’application doit apporter, priorisation de celles-ci, dans un
document appelé Définition du Domaine Industriel, mais aussi quels types
d’utilisateurs sont concernés par l’application, de manière à pouvoir les impliquer.
On définit également l’architecture du système, dans un document
appelé Définition de l’Architecture Système. Enfin, à partir du Plan Global de
Développement, on définit un Plan Global de Prototypage.
Modèle fonctionnel itératif et Conception et réalisation itératives : travailler
techniquement de façon itérative.
Mise en œuvre : mise en production de l’application afin de mettre l’ application à
disposition des utilisateurs types ; ceci permettra d’avoir des feedback rapides de
ceux-ci et d’incrémenter le produit d’améliorations.