18/09/2017

Gestion de projets
Agilité

Alouane Sonia

1
 18/09/2017

Incrémentation et Itération
3

• Incrémentation

• Itération

Méthodologies Agiles

2
 18/09/2017

Caractéristiques des méthodologies

agiles
5

Agilité : réponse rapide et flexible aux

changements
Plusieurs méthodologies existent, mais ont
des caractéristiques communes
• Itérations à durée fixe
• Développement évolutif
Raffinement progressif des besoins et de la
conception
• Planification adaptative
• Livraisons incrémentales

Le manifeste agile
6

La notion de méthode agile est née à travers

un manifeste signé en 2001 par 17
personnalités du développement logiciel
Ce manifeste prône quatre valeurs fondamentales

3
 18/09/2017

Le manifeste agile
7

« Personnes et interactions plutôt que processus et outils » :

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 développeurs
moyens, plutôt qu’une équipe composée d’individualistes, même
brillants. La communication est une notion fondamentale.

Le manifeste agile
8

« Logiciel fonctionnel plutôt que documentation complète

» : il est vital que l’application fonctionne. Le reste, et
notamment la documentation technique, est secondaire,
même si une documentation succincte et précise est utile
comme moyen de communication. La documentation
représente une charge de travail importante et 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).

4
 18/09/2017

Le manifeste agile
9

« Collaboration avec le client plutôt que négociation de contrat »

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 feedback continu sur l’adaptation du logiciel à ses
attentes.

Le manifeste agile
10

«Réagir au changement plutôt que suivre un plan»:

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 releases du logiciel vont souvent
provoquer des demandes d’évolution.

5
 18/09/2017

Les principes agiles

11

Notre plus grande priorité est de satisfaire le client

en livrant rapidement et régulièrement des
fonctionnalités à grande valeur ajoutée
Accueillez positivement les changements de
besoins, même tard dans le projet. Les processus
Agiles exploitent les changements pour donner un
avantage compétitif pour le client

Les principes agiles

12

Livrez fréquemment un logiciel opérationnel avec

des cycles de quelques semaines à quelques mois et
une préférence pour les plus court
Les utilisateurs ou leurs représentants et les
développeurs doivent travailler ensemble
quotidiennement tout au long du projet

6
 18/09/2017

Les principes agiles

13

Réalisez les projets avec des personnes motivées.

Fournissez-leur l’environnement et le soutien dont
ils ont besoin et faites leur confiance pour atteindre
les objectifs fixés
La méthode la plus simple et la plus efficace pour
transmettre de l’information à l’équipe de
développement et à l’intérieur de celle-ci est le
dialogue en face à face

Les principes agiles

14

Un logiciel opérationnel est la principale mesure

d’avancement
Les processus Agiles encouragent un rythme de
développement soutenable. Ensemble les
commanditaires, les développeurs et les utilisateurs
devraient être capables de maintenir indéfiniment
un rythme constant

7
 18/09/2017

Les principes agiles

15

Une attention continue à l’excellence technique et à

une bonne conception renforce l’Agilité
La simplicité - c’est à dire l’art de minimiser la
quantité de travail inutile - est essentielle

Les principes agiles

16

Les meilleures architectures, spécifications et

conceptions émergent d’équipes autoorganisées
À intervalles réguliers, l’équipe réfléchit aux
moyens de devenir plus efficace, puis règle et
modifie son comportement en conséquence

8
 18/09/2017

Priorités du mouvement agile

17

Communication et rétroaction
Dans l’équipe et avec le client
Individus et équipe
Le développement est une activité humaine
Des développeurs heureux sont plus productifs
Simplicité
Processus et outils
Processus empirique
Modifié dynamiquement en se basant sur des mesures
État d’esprit
Le développement agile est plus qu’un processus

Les méthodes agiles en pratique

18

La recherche montre que les projets ayant le plus

de succès possèdent certaines caractéristiques
favorisées par les méthodes agiles :
Cycle de vie itératif
Intégration quotidienne
Beaucoup de rétroaction et de participation des
utilisateurs/clients
Courte durée / taille du projet
Livraisons incrémentales

9
 18/09/2017

Méthodologies agiles
19

Extreme Programming (XP)

Scrum
Crystal clear
Test Driven Development
Et bien d’autres.

20

EXTREME
PROGRAMMING

10
 18/09/2017

La programmation extrême
21

La programmation extrême (eXtreme

Programming, XP) est une méthodologie agile très
répandue
Idée principale : pousser à l’extrême les bonnes
pratiques et valeurs de développement
Par exemple les tests sont utiles donc :
Les tests seront effectués chaque jour
Les tests seront développés avant de coder
XP utilise un modèle de développement itératif
avec itérations très courtes (1-3 semaines)

Pratiques
22

Client membre de l’équipe

Jeu de la planification / histoires d’utilisateurs
Programmation en paires
Développement piloté par les tests
Réusinage fréquent
Propriété collective du code
Intégration continue
Et quelques autres pratiques

11
 18/09/2017

Client membre de l’équipe

23

Le client est considéré comme un membre de

l’équipe à part entière
Le client est ultimement la personne qui devra utiliser le
système
Un représentant du client devrait être disponible en tout
temps pour répondre aux questions
Rôles du client
Écrire les histoires d’utilisateurs
Écrire les tests d’acceptation
Choisir les histoires lors du jeu de la planification

Histoires d’utilisateurs
24

XP exprime les besoins sous forme d’histoires

d’utilisateurs
Les histoires ne contiennent que suffisamment
d’information pour pouvoir estimer l’effort requis pour
développer une fonctionnalité
L’estimé est produit rapidement pour permettre à
l’équipe de prendre des décisions
Les histoires sont généralement inscrites sur des
cartes qui peuvent être manipulées et placées sur
un mur ou un tableau

12
 18/09/2017

Exemple – Carte d’histoire utilisateur

25

Enr egist r ement ! avec! comp r ession 8 ! hr s

Pr ésent ement ,! les! op t ions! de! comp r essions

se! t r ouvent ! dans! une! b oî t e! de! dialogue!
sub séquent e! à! celle! de! la! sauvegar de.! Il! f aut ! les!
dép lacer ! ver s! le! dialogue! d'enr egist r ement ! lui-
même.

Exemple – Disposition des cartes

26

R+) (<1F&Ñ1*3&' 1<ÖJ&iOL3(1; 1&M(+>(7; ; /*>&OL=87/*15F&O; K(7<1&P] 7*>1j J&W55/2+*"{ 1281I &$##X:&

13
 18/09/2017

Jeu de la planification
27

Pour une itération

But : choisir les histoires à implémenter, planifier et
allouer les tâches à effectuer
Le client choisit les cartes pour la prochaine
itération, les développeurs créent les tâches
Une tâche qui est estimée à durée > 2 jours est
divisée à nouveau

Jeu de la planification
28

Pour la livraison d’une version du logiciel

But : définir la portée de la prochaine version
opérationnelle
Typiquement, le client écrit les histoires et les
développeurs en font l’estimation au cours d’un atelier
d’une demi-journée
Les cartes peuvent être choisie en fonction d’une date
fixe, ou la date peut être déterminée en fonction des
cartes sélectionnées

14
 18/09/2017

Programmation en paires
29

Tout le code est écrit par une paire de programmeurs

travaillant ensemble sur une même machine
Un programmeur écrit le code et les tests pendant que l’autre observe
dans le but d’identifier les erreurs et les améliorations potentielles
Les rôles sont inversés fréquemment
Les paires sont redistribuées fréquemment(ex. une fois par
jour)
Cette pratique permet de distribuer les connaissances du code
rapidement à travers l’équipe
En pratique le code produit contient moins d’erreur sans
affecter la productivité de façon mesurable

Développement piloté par les tests

30

Le code de production est écrit de façon à faire réussir des

tests unitaires
Avant d’implémenter une fonctionnalité, un test est ajouté. Ce test
échoue lorsque la fonctionnalité n’est pas présente
Le code qui fait réussir le test est écrit
Le code est développé en itérations successives d’écriture de tests et
de code
L’utilisation d’outils de test automatisés est essentielle à la réussite
de cette approche
Résultat
Un jeu de test unitaires très complet est développé pour le système
entier
Très peu de code inutile est développé

15
 18/09/2017

Réusinage fréquent
31

But : améliorer le code sans changer sa fonctionnalité

Idéalement effectué à l’aide d’outils automatisés
Les tests existants permettent de vérifier que le comportement
observable demeure inchangé
Exemple de réusinage : restructurer la hiérarchie des classes,
éliminer la duplication
Motivation : la conception est plus efficace lorsque effectuée
près de son utilisation
Résultat : le système demeure plus simple et plus facile à
développer pour une longue période

Propriété collective du code

32

Une paire de programmeur peut travailler sur

n’importe quelle partie du code et l’améliorer
Les développeurs ne sont pas responsables d’un ou de
plusieurs modules en particulier
Motivation : si une partie du code est défectueuse, elle devrait
être corrigée le plus tôt possible
Attention aux risques !
Cette pratique est à éviter si l’équipe n’a pas encore
développé une responsabilité collective
Un membre de l’équipe ne doit pas modifier du code sans se
soucier de celui qui aura à le modifier et le maintenir

16
 18/09/2017

Intégration continue
33

Diviser, régner et intégrer : tous les changements

doivent être testés et intégrés fréquemment
Fréquemment = plusieurs fois par jour
Peut nécessiter la résolution de conflits si plusieurs programmeurs
ont modifié le même code
Deux stratégies
Intégration asynchrone : les tests sont exécutés après un
changement ou à intervalles réguliers , les programmeurs sont
avisés si leurs changements causent des régressions
Intégration synchrone : les programmeurs exécutent eux mêmes les
tests et attendent les résultats avant de passer à la prochaine étape
(permet de conserver le contexte, favoriser la communication)

17