1. Méthodes Agile
Pour la gestion de projets
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
2. Les valeurs
1. Personnes et interaction Vs processus et
outils
2. Logiciel fonctionnel Vs documentation
complète
3. Collaboration avec le client Vs négociation
de contrat
4. Réagir au changement Vs suivre un plan
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
3. Personnes et interaction plutôt que processus et outils
L'équipe: Dans l'optique agile, l'équipe est bien
plus importante que les moyens matériels ou les
procédures. Il est préférable d'avoir une équipe
soudée et qui communique composée de
éléments moyens plutôt qu'une équipe composée
d'individualistes, même brillants. La
communication est une notion fondamentale.
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
4. Logiciel fonctionnel plutôt que documentation complète
L'application: Il est vital que l'application fonctionne.
Le reste, et notamment la documentation technique, est
secondaire, sachant qu'une documentation succincte et
précise est utile comme moyen de communication. La
documentation représente une charge de travail
importante, mais peut être néfaste si elle n'est pas à jour.
Il est préférable de commenter abondamment le code lui-
même, et surtout de transférer les compétences au sein
de l'équipe (on en revient à l'importance de la
communication).
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
5. Collaboration avec le client plutôt que négociation de contrat
La collaboration: Le client doit être impliqué
dans le développement. On ne peut se
contenter de négocier un contrat au début du
projet, puis de négliger les demandes du
client. Le client doit collaborer avec l'équipe
et fournir un "feed-back" continu sur
l'adaptation du logiciel à ses attentes.
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
6. Réagir au changement plutôt que suivre un plan
L'acceptation du changement : La
planification initiale et la structure du logiciel
doivent être flexibles afin de permettre
l'évolution de la demande du client tout au
long du projet. Les premières versions du
logiciel vont souvent provoquer des demandes
d'évolution.
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
7. Les principes
4 valeurs => 12 principes
1- Notre première priorité est de satisfaire le
client en livrant tôt et régulièrement des
logiciels utiles.
2- Le changement est bienvenu, même
tardivement dans le développement. Les
processus agiles exploitent le changement
comme avantage compétitif pour le client.
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
8. Les principes
3- Livrer fréquemment une application
fonctionnelle, toutes les deux semaines à deux
mois, avec une tendance pour la période la
plus courte.
4- Les gens de l'art et les développeurs doivent
collaborer quotidiennement au projet.
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
9. Les principes
5- Bâtissez le projet autour de personnes
motivées. Donnez leur l'environnement et le
soutien dont elles ont besoin, et croyez en
leur capacité à faire le travail.
6- La méthode la plus efficace de transmettre
l'information est une conversation en face à
face (ou les moyens de e-communication).
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
10. Les principes
7- Un logiciel fonctionnel est la meilleure
unité de mesure de la progression du projet.
8- Les processus agiles promeuvent un rythme
de développement soutenable.
Commanditaires, développeurs et utilisateurs
devraient pouvoir maintenir le rythme
indéfiniment.
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
11. Les principes
9- Une attention continue à l'excellence
technique et à la qualité de la conception
améliore l'agilité.
10- La simplicité - l'art de maximiser la
quantité de travail à ne pas faire - est
essentielle.
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
12. Les principes
11- Les meilleures architectures,
spécifications et conceptions sont issues
d'équipes qui s'organisent seules.
12- À intervalle régulier, l'équipe réfléchit aux
moyens de devenir plus efficace, puis accorde
et ajuste son comportement dans ce sens.
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
13. La méthode alors c'est quoi?
Itérative, incrémentale et adaptative; dans un
esprit de collaboration avec un minimum de
formalisme.
Ceci a donné (Annual survey of agility 2008) des produits de
haute qualité tout en tenant compte des
besoins (en évolution continue) du client et de
l'environnement
14. Des méthodes et processus
Les plus utilisés
1. Scrum la plus encienne
2. Kanban
3. Lean (SCRUMBAN)
Pascal Fares - ISAE Cnam Liban
(c) Creative Common Share
Alike
15. Les bases de SCRUM
Scrum est une méthode agile dédiée à la
gestion de projet.
Cette méthode de gestion à pour principal
objectif d’améliorer la productivité de
l'équipe.
16.
17. Répartitions des rôles dans Scrum
● Trois rôles
○ Scrum Master (Facilitateur modérateur)
●
○ Team (Tous les membre de l'équipe ou du goupe)
●
○ Product owner (Celui qui souhaite le produit)
18. Le Scrum Master
● S’assure que les principes et les valeurs de
Scrum sont respectés
● Facilite la communication au sein de l’
équipe
● Cherche à améliorer la productivité et le
savoir faire de son équipe
19. L’équipe ou membre du goupe
● Pas de rôle bien déterminé : architecte,
développeur, testeur
● Tous les membres de l’équipe apportent
leur savoir faire pour accomplir les tâches
Fonctionne pour des groupes de 6 à 10
personnes en général et pouvant aller jusqu’à
200 personnes
20. Le Product Owner
● Expert métier, définit les spécifications
fonctionnelles
● Établit la priorité des fonctionnalités à
développer ou corriger
● Valide les fonctionnalités développées
● Joue le rôle du client potentiel
22. Les éléments du processus
● Le product backlog
● Le sprint
● Le sprint backlog
● Les stories
● Le Sprint meeting
● Le daily meeting (la mélée)
● BurnDown Chart
23. Le product backlog
Liste de stories:
Le référentiel des exigences initiales est
dressé et hiérarchisé avec le client. Il
constitue ce que l’on nomme le "product
backlog". Il ne doit pas nécessairement
contenir toutes les fonctionnalités attendues
dès le début du projet, il va évoluer durant le
projet en parallèle des besoins du client.
24. User Story
Liste des fonctionnalités demandés par le
client, dans la terminologie utilisée par le
client. Une User Story ou Story contient:
● ID – un identifiant unique
● Nom – un nom court
● Importance – priorité
● Estimation – La charge de travail
● Demo – test de validation.
● Notes – clarifications, références documentaires…
La storie dans java.net sera une issue "open"
25. Sprint, Sprint backlog
Le cycle de vie Scrum est rythmé par des
itérations de courte durée. Chaque itération
est nommée le sprint.
Le sprint backlog:
un sous ensemble du product backlog.
Le sprint backlog représente ce qui doit être
fait durant l'itération sprint.
26. Le sprint planning meeting
Avant chaque sprint, une réunion de planification,
le sprint planning meeting est organisé.
○ Le planning sélectionne dans le product backlog les
stories les plus prioritaires
○ Elles seront développées, testées et livrées au client à
la fin du sprint.
○ Elles constituent le sprint backlog, un sous ensemble du
product backlog.
Equipe virtuelle(en ligne) => Visio conférence ou
forum
27. La mélée, Daily Scrum Meeting
Chaque jour, une point d’avancement, chaque
membre répond au 3 questions:
● Ce que j’ai fait hier et les éventuels problèmes
rencontrés
● Ce que je vais faire aujourd’hui
● Est ce que j’ai des difficultés pour continuer mon
travail.
A la fin le Scrum master produit le BurnDown
Chart (suivi du reste à faire)
En Equipe virtuel un mail chaque matin dans la mailing list +
post dans forum, mise à jour des issues
