Matière : Ateliers avancés de Génie Logiciel TD : 04

Exercice 1 :

1. Que sont les méthodes agiles en général ? Pourquoi ont-elles été développées ?
 Les méthodes agiles sont des méthodes de développement logiciel basées principalement
sur la flexibilité et l’adaptation.
 Elles ont été développées pour faciliter, accélérer et adapter le développement du logiciel
en se basant sur une implication forte du client, une auto-évaluation continue de la part de
l’équipe de travail, et une organisation avancée du personnel et de la méthode de travail.
2. Expliquez les termes suivants dans le cadre de la méthode XP :

pair-programming : travail en binôme (cours diapo 34),

egoless programming : est un style de programmation dans lequel les facteurs personnels sont
minimisés de façon à améliorer la qualité du travail. (democtratic teams),
keep it simple : les meilleurs solutions sont généralement les plus simples .c’est aussi valable pour le
code.
constant refactoring : la technique qui consiste à améliorer le code sans changer les fonctionnalités
(pour avoir un code plus simple)
test first, test-driven development : est une technique de développement logiciel qui consiste à écrire le
contenu du test avant la fonction à tester. ( le but de cette pratique connue en xp est d’indiquer à quoi
s’exposera le code avant même d’être écrit).
sustainable development, signifie qu’on ne doit pas surcharger les développeurs de travail parce que
c’est une stratégie gagnante à moyen et à long terme
Implication du client : représentant de clients (cours diapo 34)

3. Comment des techniques classiques comme les use-cases, les tests de régression, le développement
itératif et les revues sont incluses dans XP ?

 Les use-cases sont utilisés à travers la notion des scénarios pour guider le développement
d’une itération.
 L’implication du client aide à comprendre l’enjeu du scénario et à valider son
implémentation.
 Le développement itératif, on implémente un seul scénario à la fois (grand nombre
d’itérations très courtes).
 Les tests de régression : après l'intégration (et peut-être la correction), vous devriez ré-
exécuter vos tests unitaires. Il s'agit de tests de régression pour s'assurer que d'autres
modifications n'ont pas affecté les unités déjà testées. (les autres types de tests sont définis
dans le cours)
 Les revues sont effectuées là encore constamment par le biais du pair-programming (contrôle
du codage) et du constant refactoring (remise en question du code). Les revues sont facilitées
par l’idée d’egoless programming. Par rapport au cycle en V, les revues ne sont pas effectuées
par une équipe extérieure, et ne sont pas formalisées et effectuées une seule fois à la fin.

4. Quels sont les avantages et inconvénients de XP ?

  Les principaux avantages de XP :
- Flexible et adaptable dans le cas des spécifications peu claires ou risquent de changer en
cours de route
- Codage accéléré grâce au pair programming
- Test et réorganisation du code continus
- coût peu élevés pour ce type de projets (pas de surcoût par des processus lourds)
 En contrepartie, XP rencontre des problèmes dans les cas suivants :
- trop grosses équipes (surcoût de communication trop important),
- projets trop complexes (le manque de conception initiale entraine des surcoûts),
- programmeurs peu aptes à communiquer,
- client peu apte à s’impliquer aussi fortement,
- .

Exercice 2 :

1. En scrum, qui valide les user-stories pour qu’elles passent de « test » à « done » ?

[ ] le scrum master
[ ] le product owner
[ X] l’équipe de développement
[ ] toute l’équipe

 L’équipe de développement est 100% responsable de fournir des user-stories « done »

potentiellement livrable.

2. L’équipe de développement peut-être composée :

[X] de développeurs front et de développeurs back

[X] de développeurs, d’un business analyst et d’un testeur
[X] d’un testeur et de développeurs

 Toutes les réponses sont bonnes. L’équipe de développement ne veut pas dire équipes de
« développeurs » mais équipe de réalisation. Tous ceux qui ne sont pas « product owner » ou
« scrum master » et qui participe à la réalisation du produit font partie de l’équipe de
développement.

3. Quels artefacts existent en scrum ?

[X] definition of done

[ ] definition of ready
[X] sprint backlog
[ ] increment backlog

 La definition of ready est une pratique répandue mais non reconnue par le scrum guide.
L’increment backlog n’existe pas ; il ne faut pas confondre avec l’artefact « increment ».
L’increment est l’ensemble des éléments en « done » du sprint ajouté à l’incrément du sprint
précédent. Il n’y a aucune notion de backlog dans cet artefact.
4. Le product owner est responsable :

[ ] de valider que les items (tasks) sont bien « done »

[X] de la gestion du product backlog
[X] que l’équipe de développement comprenne bien les items(user-stories)
[ ] de rendre transparent le sprint backlog

 Le product owner est responsable du product backlog et de sa compréhension. En

revanche, il n’a aucune responsabilité sur le sprint backlog ; ce dernier est 100% sous
la responsabilité de l’équipe de développement. Le product owner n’est pas
responsable des développements. Seule l’équipe de développement doit mettre en
place des exigences de qualités et vérifier par elle même que ces critères sont
respectés à 100% avant de mettre l’item (task) en « done ».

5. Le scrum master doit :

[ ] avoir des connaissances avancées sur la gestion d’un product backlog

[X] travailler avec les autres scrum master de l’entreprise

[X] coacher l’équipe de développement si nécessaire

6. Quelles sont les phrases qui sont vraies autour du sprint review

[X] le product owner y invite l’équipe scrum et les principales parties prenantes
[X] l’équipe discute des problèmes rencontrés et comment ils ont été résolus
[X] l’équipe y démontre le travail « fini »
[X] la revue des délais et des budgets doit être faite.

7. Le scrum :

[X] est un cadre de travail

[X] est une méthode agile

[X] est un cadre léger

8. Le scrum permet dans des cas exceptionnels d’annuler un sprint. Quelles phrases sont
vraies ?

[X] l’équipe de développement peut demander au product owner d’annuler un sprint

[X] seul le product owner est autorisé à annuler un sprint

[ ] seul le scrum master est autorisé à annuler un sprint

 En scrum, seul le product owner est autorisé à prendre la décision d’annuler un sprint (soit
d’y mettre fin). Cependant l’équipe de développement peut parfaitement influencer pour aller
vers cette annulation. En revanche après un travail de fermeture de ce sprint annulé, l’équipe
recommence directement un nouveau sprint.

9. Quelles affirmations sont vraies concernant la sprint planning ?

[X] tous les items (tasks) choisis en sprint planning ne sont pas forcément finalisés.
[X] seule l’équipe de développement valide sa capacité de faire le nombre d’items (tasks) du
sprint
[X] un sprint planning peut durer jusqu’à 8h
[X] l’équipe de développement doit définir comment elle va réaliser les items (tasks)

 Si un feedback très important ressort de la sprint review, le scrum team pourra mettre
le ou les items (tasks) qui permettent de prendre en considération ce feedback dans le
prochain sprint backlog.

Exercice 3 :

Donner, sous la forme « numéro : nom », le nom du processus de développement d’un logiciel qui
correspond à chacune des descriptions suivantes :
1) Un processus qui présente l’inconvénient de l’effet tunnel. En cascade
2) Un processus séquentiel qui a introduit la planification des tests dès le début du cycle de vie du
logiciel. En V
3) Un processus IID qui a introduit principalement une phase d’analyse des risques. En spirale
4) Un processus qui a introduit le principe de programmation par binôme. XP
5) Un processus qui combine les principes du processus XP et du processus UP. AUP
6) Un processus qui présente une pratique d’attribution d’une note à chaque besoin fonctionnel en
utilisant la suite de Fibonacci. Scrum (diapo 39)

Exercice 4 :

Donner, sous la forme « numéro : nom », le nom du processus de développement d’un logiciel qui
peut être appliqué pour chacun des projets suivants :
1) Un projet simple où les besoins du client sont très clairs et bien déterminés dès le début
(séquentiel), et ne nécessitant pas de prototypage (pas W). En V ou cascade
2) Un projet non maitrisé qui présente des risques énormes et qui peut durer des années (non agile).
Spiral (ou UP)
3) Un projet qui nécessite une modélisation très détaillée du logiciel à développer en se basant sur les
différents types des diagrammes UML. UP
4) Un projet qui nécessite plusieurs itérations de développement avec une livraison fréquente
d’incréments au client et une prise en considération continue des changements proposés par le client.
Itératif + incremental+adaptatif : méthode agile : XP ou AUP ou SCRUM
5) Un projet qui nécessite un codage accéléré et bien géré avec un partage d’expertise. XP
6) Un projet qui nécessite une gestion avancée de l’équipe de travail en lui permettant de s’auto-
organiser à travers des réunions fréquentes. SCRUM