Gestion de projet, Scrum, Kanban, Agile, Méthode XP

• Génie logiciel
➢ La crise du logiciel
- Des logiciels sont mal conçus et se détériore rapidement.
- La demande pour du logiciel est toujours croissante
- Le logiciel se trouve en perpétuel ‘état de crise’, l’ingénierie du logiciel est une nécessité
- Causes majeures de la crise : Causes matérielles, Spécifications fausses, Erreurs de
programmation, Manque de tests, Mauvaise utilisation.
- Quatre types de maintenance : corrective (correction des bugs), évolutive (modification des
spécifications initiales), adaptative (nouvel environnement), perfective (améliorer les
performance).
- Les 3 types de tests :
• Tests unitaires : Vérifier qu'une entité individuelle (classe, module, composant) se
comporte correctement
• Tests d'intégration : Vérifier que l'assemblage d'entités (classes, modules,
composants) se comporte correctement ! Phase essentielle avant la recette du système
• Tests de non-régression : Vérifier qu'une modification n'a aucun effet négatif sur le
fonctionnement global du système
➢ Génie logiciel
- Le Software Engineering est ensemble de : méthodologies, méthodes, techniques, D’outils :
tendant à rationaliser la production du logiciel et son suivi.
- Objectif du GL : Augmenter la qualité du logiciel et la productivité des équipes de
développements, gagner la confiance des clients, délivrance en respectant les termes et la qualité
à la fois.
- Facteurs de qualité du logiciel : Validité (définition du cahier des charges), Fiabilité
(fonctionne dans des cas anormales), Extensibilité (facilité de la maintenance), Réutilisabilité,
Compatibilité (Combinaison avec d’autres logiciels), Efficacité (Utilisation optimales des
ressources), Vérifiabilité (Facilité de préparation des procédures de test), Intégrité (aptitude à
protéger le code et les données), Facilité d’emploi.
➢ Cycle de vie d’un logiciel
- Cycle de vie : Etapes du développement d’un logiciel, de sa conception à sa disparition.
- Partitionnement de la réalisation des logiciels : Incrémental (par lots), Itératif (Par
couches), Incrémental & Itératif (Par lots et par couches), Scrum (Par sprints & releases)
- Activités du cycle de vie :
• Définition des objectifs : Définir la finalité du projet.
• Analyse des besoins et faisabilité : (cahier de charge / Requirements).
• Spécifications : fonctionnelles (Les fonctions rendus par le système User case d'UML),
non-fonctionnelles (Facteurs de qualité, Conditions d’implémentation, de déploiement,
de maintenance, d’exploitation).
• Conception générale (architecturale) : architecture générale (décomposition en
modules), Diagrammes UML (packages, composants, déploiement).
 • Conception détaillée (technique) : Concevoir/documenter le code qui va être produit,
Diagrammes UML (Classes, Objets, Structure composite, séquence, communication,
Activité, État-transition).
• Codage : Traduction de la conception en code.
• Test unitaires : Test de chaque module individuellement.
• Tests d’intégration : Test de la composition de plusieurs modules (sous-systèmes)
• Validation : Test du système final par rapport aux spécifications
• Recette : Test que le système est conforme aux besoins exprimés.
• Documentation : pour l’utilisation du logiciel / des développements ultérieurs.
• Mise en production : C’est le déploiement sur site du logiciel.
• Maintenance : maintenance corrective et maintenance évolutive sur le logiciel.
• Gestion de projet :(temps, coûts, équipes, relations clients)
- Cycle de vie en cascade
- Chaque phase se termine à une date précise, On ne passe à la phase suivante que s’ils
sont jugés satisfaisants ...
- Problèmes : Vérification très tardive du bon fonctionnement du système – Facile à
planifier mais c'est difficile à respecter le plan.
- Cycle de vie en V
- Toute description d’un composant est accompagnée de tests qui permettront de la
valider. Permet d’éviter d’énoncer lors de la spécification une propriété impossible à
vérifier objectivement après la réalisation.
- Problèmes : Vérification améliorée mais trop tardive du bon fonctionnement du
système+ Manque de réactivité vis-à-vis du changement en cours du développement
- Cycle de vie itératif en spirale
- Chaque cycle de la spirale se déroule en quatre phases : Détermination des objectifs,
Analyse des risques, Développement et vérification, Revue des résultats.
-Caractéristiques : étude détaillée sur tout le système dès les premiers cycles, accepte
le changement mais sa correction peut être tardive, Facilite la réutilisation,
l’intégration du client, l’évolution des spécifications
- Modèle par incrément : décomposé en composants développés séparément et intégrés
à la fin du processus.
▪ Avantages : Dév moins complexe, Livraison possible après chaque
intégration…
▪ Inconvénients → incapacité d’intégrer un incrément
- Résumé : Les méthodes classiques nécessitent des conditions rarement atteintes :
Communication et compréhension parfaite, Choix parfaits dès le départ…
• Agile
- Agile : Approche adaptive, réactive et itérative d’organisation de travail. Elle est Focalisée
sur la fonctionnalité et satisfaction client. Construit en adéquation avec les capacités et limites
humaines.
 - Manifeste Agile : Texte rédigé en février 2001 aux USA, Réunion de 17 spécialistes pour
unifier les méthodes « Agile » → « Notre plus haute priorité est de satisfaire le client à travers
des livraisons tôt et continues de logiciels de grande valeurs ».
- Manifeste agile donne importance à : Petites équipes autogérées, Garder un rythme de travail
soutenable, Avancement par itération …
- 12 Principes d'Agile :
▪ Client : Satisfaction des clients, Accepter le changement du besoin, Livraison
fréquentes, Travail client -développeurs.
▪ Equipe : Motivation des équipes, Le dialogue face à face, Opérationnel sinon rien,
Rythme soutenable.
▪ Produit / Processus : L’excellence technique, La simplicité, Equipes auto -organisées,
Amélioration continue.
- Méthodes agile : RAD(Rapid Application Development), XP(Extreme programming), ASD
(Adaptive software development), Scrum.
• Scrum
- C'est un cadre méthodologique Agile la plus utilisée, qui s’adapte à la réalité des projets et sur
l'expérience du terrain de développement logiciel. Révolu la manière dont on gère le projet et
permet de délivrer / modifier un projet, produit ou une fonctionnalité très rapidement.
- Les projets Scrum sont organisés en courtes itérations (sprints), au cours desquelles l'équipe
planifie, exécute et révise le travail. Chaque sprint ajoute une valeur incrémentielle à
l'objectif final
→ Scrum projects are organized in short iterations (sprints), during which the team plans,
executes and reviews work. Each sprint adds incremental value to end goal
- Scrum est :
▪ Incrémental : Un sprint est une itération qui produit un incrément.
▪ Itératif : Chaque incrément produit peut être enrichi dans un sprint suivant
▪ Adaptatif : Chaque incrément peut être modifié dans un sprint suivant.
- Principe de Scrum : Transparence, Inspection, Adaptation
- Objectifs de Scrum : Produire le max de valeur pour le min de coût, objectifs très clairs pour
l’équipe, L’équipe s’organise d’elle-même et il délivre régulièrement les parties finies du
logiciel, L’équipe et le management communique honnêtement sur le progrès et les risques.
- Sprint : Bloc de temps fixé non extensible, aboutissant à créer un incrément du produit
potentiellement livrable. Le résultat d'un sprint est appelé incrément.
- Release : C'est une période de temps constituée de plusieurs sprints (de durée fixe ou variable).
- Activités pendant les sprints → SACT : S (spécification), A (Architecture = conception),
C(Codage), T(test = intégration & recette).
- Valeurs Scrum :
▪ OPENNESS (ouverture) : visualisez votre travail, vos échéances, vos problèmes
▪ FOCUS (concentration) : Se concentrer sur l'essentiel, l’équipe travaillent dans la
même direction.
▪ COMMITMENT (engagement) : Respect du contenu d'une mission tel qu’il a été
convenu.
▪ RESPECT (respect) : Les membres de l’équipe se respecte mutuellement, et respecte
l’indépendance de chacun…
 ▪ COURAGE (courage) : considérer l’échec comme une occasion d'apprendre.
Maintenir un cycle d'amélioration continue.
- Composants de Scrum :
▪ Acteurs → Scrum Team, Product Owner, Scrum Master
▪ Artéfacts → Product Backlog, Sprint Backlog, Burndown Chart
▪ Activités → Sprint Planning, Daily Scrum Meeting, Sprint Review, Sprint
Retrospective
• Scrum Team : Inclue-le : Product Owner, Scrum Master, Développeurs (programmeurs, testeurs,
architectes,), (5 à 9 personnes)
• Caractéristique du Scrum Team : Autogérée, Réunie physiquement, Pluridisciplinaire…
• Product Owner : Porteur de la vision globale du produit, définit les spécifications fonctionnelles et
liste des priorités qu'ils faut développés. PO Accepte ou Rejette les livrables.
• Scrum Master (maître SCRUM) : Coach (Gardien des pratiques de Scrum), Élimine les obstacles,
Facilitateur (Serviteur de l’équipe mais pas un chef de projet). Garant du respet du processus Scrum,
il s'assure une bonne communication entre les membres de l'équipe
• Product Backlog (carnet de commande pour le produit) : Géré par le Product Owner (peut ajouter,
modifier ou effacer à n’importe quel moment du développement) → Liste de tout ce qui va entrainer
du travail pour l’équipe
• Parties d'un Backlog :
o Bac à sable des idées → permet à tous de déposer des propositions, et au PO de les
traiter(brainstorming)
o Bac d'affinage→ les épiques et les moins prioritaires…
o Bac de départ→ Contient les stories prêtes à être réalisées rangées en fil d'attente pour le
prochain sprint
• Element du Backlog: Feature / Thème, User Story, Epic
• Feature / Thème : Service/fonctionnalité du produit clair par les PP. Elle est réalisée à travers
plusieurs stories.
• User Story : petit morceau d'une fonctionnalité du produit développable pendant un sprint,
décoposé en Tasks, plusieurs types du Backlog (fonctionnelle, technique, Correction de bug).
• Caractéristiques d'une bonne User Story : Indépendante (vis-àvis des autres user stories),
Estimable (facilement chiffrable), Valorisable (valeur métier), Suffisamment petit (réalisable sur
un sprint), Testable.
• Epic : backlog en attendant qu'elle soit décomposée en plusieurs stories
• Task : ce sont des petites taches
• Story point : montre comment le nombre de tâches non terminées diminue avec le temps. Peut
signaler des problèmes dans le processus

Feature / Thème → Epic → User Story → Task

• Sprint Backlog (carnet d’itération) : Réalisé au début du sprint pendant le Sprint Planning, c’est
un Carnet présentant les détails des engagements de l’équipe pendant une itération.
• BurnDown Chart (graphique d'avancement) : le nombre d’heures () restant à effectuer d’ici la
fin de l‘itération, Une itération est considérée réussie quand le temps restant est égal à zéro/ tâches
supplémentaires peuvent influencer sur le graphique. Scrum Master tient un Burn down Chart qui
décrit l'évolution du projet, à la fin de la réunion, on mis à jour le burn down
• Visualisation de l'état du projet en tableau : Les tâches à faire (To Do), Les tâches en cours
(Doing), les tâches terminées (Done).
• Sprint Planning (Planification de sprint) : Réunion de l’équipe, animé par le Scrum Master :
décisions collectives, pour définir un objectif principal pour le sprint
• Affinage du backlog : Approvisionner (le bac de départ en stories), Décomposer (les stories
épiques), Alimenter (le bac d'affinage par des idées), Estimer (les éléments du bac d'affinage),
Réordonner (le bac d'affinage), Purger les bacs
• Daily Scrum Meeting (mêlée quotidienne) : 15 minutes- tous les jours, 3 questions pour chacun
(Qu’avez-vous fait hier, Qu’allez-vous faire aujourd’hui, Quels sont vos problèmes), Mettre à jour
le Burndown chart et le tableau d'affichage
• Sprint meeting Review : Rappel de l'objectif du sprint et Présentation des stories finies,
Acceptation ou non du livrable ! Décision du PO, Récupérer le feedback Parties prenantes → Les
participants (Product owner, Scrum master, Scrum team, Parties prenantes)
• Sprint Retrospetive : Constat de ce qui a bien ou moins bien marcher dans l’organisation, Décider
des actions à entreprendre, Uniquement l’équipe (Scrum Master + Scrum Team)
• Versions de Scrum : Scrum 1.0, Scrum 2.0, Scrum 3.0
• Scrum 3.0 → Remplacer le Product Owner par: Business Owner (BO),
• SCRUM de SCRUM : Projet trop gros divisé et distribué à plusieurs équipes,
• Méthodes Xp
- Méthode la plus agile, Orientée sur l'aspect technique de la réalisation d'une application, elle est
développée par Kent Beck.
- Valeurs XP :
▪ Communication : directe et le contact humain pour Avoir une vision commune
▪ Simplicité : Eviter la complexité inutile dans le code
▪ Retour d’information (Feedback) : Boucles de feedback (l’état du projet) pour réduire les
risques, Rectifier le tir si nécessaire
▪ Courage : Accepter de remanier une portion du code devenue complexe.
- Principes XP
▪ L’équipe met en place des tests automatiques pour chaque fonctionnalité développée
▪ Les livraisons s’enchaînent pour obtenir un feedback maximal et L’équipe s’organise elle-
même pour atteindre ses objectifs … etc.
- Equipe et Rôles XP
▪ Programmeur : A la fois : codeur, testeur, concepteur et analyste (rôle central)
▪ Client : (des utilisateurs) Description simplifiée informelle d’une fonctionnalité ou d’une
interaction avec l’utilisateur.
▪ Testeur : Définit et automatise les tests de recette et Conseille le client sur la testabilité
d’une fonctionnalité
▪ Trackeur : Suit les tâches en cours d’itération et le respect du temps de réalisation et
Détecte les problèmes avant qu’il ne soit trop tard
▪ Manager : Supérieur hiérarchique des programmeurs, Chef du service auquel appartient
l’équipe (fait pas partie de l’équipe), Il s’occupe matériellement de l’équipe
▪ Coach : Garant du processus et Vérifie que chaque rôle est respecté
- Pratique XP
 ▪ Equipe : Rythme durable, Standards de codage (code bien fait, règle de nommage…),
Intégration continue (code source soit partagé, intégrer les modification, tests …),
Responsabilité collective du code (code appartient au projet, et non aux développeurs),
Métaphore (description générale du fonctionnement)
▪ Individuel : Programmation en binôme (moins de bugs, Finir les taches plus rapidement),
Développement piloté par les tests (tests unitaires sont automatisables), Remaniement
(Améliorer la structure interne d’un logiciel), Conception simple (Implémenter le strict
nécessaire)
▪ Organisation : Jeu de planification (Livraisons, itérations), Tests par le client (Client
disponible pour apporter ses compétences métier) Petites livraisons (livraisons doivent être
aussi proches que possible).
➢ Jeu de planification :
▪ Exploration → Définir les scénarios client, À partir des cas d’utilisation.
▪ Engagement → Dure quelques heures, Trier les scénarios par priorité (client) et par
risque (programmeurs)
▪ Pilotage →Dure jusqu’à la date de livraison, Réalisation des tâches, Suivre les tests
de recette, Gérer les défauts
▪ Livraison →Respect de la date de livraison, Reporter les scénarios manquants
▪ Stand up meeting →15 minutes au début de chaque jour, Chacun décrit (Ce qu’il
a fait hier, Ce qu’il compte faire, Quels obstacles il trouve)
• Kanban
- Introduite chez Toyota dans les années 50, Le moyen qui permette de produire : le produit
demandé, au moment où il est demandé, dans la quantité demandée. La méthode Kanban visait
à améliorer la production en se basant sur le juste-à-temps et sur des processus évolutifs.
Aujourd'hui, elle est à la fois une méthode de gestion de projet et un outil, guidée par deux
principes : le visuel et le temps-réel.
- La méthode Kanban se base sur l’approche Lean, c'est-à-dire sur l'amélioration continue des
processus de production afin de permettre une gestion de la production sans gaspillage. La
méthode Lean est fondée sur quatre principes évidents : Réduire les coûts de production,
Eviter la surproduction, Diminuer les délais, Produire avec la meilleure qualité possible.
- La méthode Kanban est basée sur quatre principes :
▪ Commencez par ce que vous faites actuellement (processus déjà en place et
encourage de les améliorer).
▪ Acceptez d’appliquer des changements progressifs
▪ Respectez le processus actuel, les rôles, les responsabilités et les titres.
▪ Leadership à tous les niveaux (tous les actes de leadership doivent être encouragés).
- Dans la méthode Kanban, on distingue cinq bonnes pratiques : La visualisation, limitation du
nombre de tâches en cours, gestion du flux…
• TDD :
- Test-Driven Development (TDD), ou Développements Pilotés par les Tests en français, en
écrivant chaque test avant d'écrire le code source et en remaniant le code continuellement.
- Il s'agissait simplement d'écrire les tests avant de coder, et cela s'appelait Test First
Design → Vous ne pouvez pas écrire de code de production tant que vous n'avez pas écrit
un test unitaire qui échoue
- Les étapes du TDD :
Le processus préconisé par TDD comporte cinq étapes :

1. Écrire un seul test qui décrit une partie du problème à résoudre ;

2. Vérifier que le test échoue, autrement dit qu'il est valide, c'est-à-dire que le code se
rapportant à ce test n'existe pas ;
3. Écrire juste assez de code pour que le test réussisse ;
4. Vérifier que le test passe, ainsi que les autres tests existants ;
5. Puis remanier le code, c'est-à-dire l'améliorer sans en altérer le comportement.
Ce processus est répété en plusieurs cycles, jusqu'à résoudre le problème d'origine dans son intégralité. Ces
cycles itératifs de développement sont appelés des micro-cycles de TDD.
-