initial commit

This commit is contained in:
Guillaume-Sanchez
2026-05-26 13:56:03 +02:00
parent 4c720637a1
commit ff4bb12d22
539 changed files with 12415 additions and 0 deletions
+191
View File
@@ -0,0 +1,191 @@
# Revision NFE114
## Agil
>origine USA, en 2001
### Les étapes dun projet classique
- besoin
- analyse des besoins
- etude de faisabilité
- expression des besoins
- cahier des charges
- expression fonctionnel
- etude
- modelisation
- dev
### Faiblesses méthode classique :
- peu dadaptation aux changement du client
- peu de relation avec le client
- faible gestion de lincertitude et du risque
### Objectif de lagilité :
- trouver un compromis entre minimum de méthode tout en restant adaptable et créatif
- accepter le changement des besoins et être capable dy répondre
- privilégier le code plutôt que la documentation
### Les moyens :
- utiliser un dev iteratif et incrémental
- decouper le besoin et prioriser
- decouper la réalisation : livrer fréquemment des incrément de produit, accepter les changement
-controler régulièrement lavancement avec les parties prenantes
Def partie prenante : `personne qui est intéressé dune façon ou dune autre par le produit réalisé par l équipe`
### Manifeste Agile
- Individus et interactions -plutot-que-> Procédures et outils
- Un logiciel fonctionne -plutot-que-> Documentation exhaustive
- Collaboration avec le clien -plutot-que-> Négociation du contrat
- Adaptation au changement -plutot-que-> Exécution d'un plan
![tradicionelVSAgil](./tradicionelVSAgil.png)
### Facteurs de succès des méth. agiles
- Le client / lutilisateur (ou son représentant) est impliqué quotidiennement
- Le management intermédiaire soutient l’équipe
- L’équipe est auto-organisée
- Les pratiques sont adaptées au mode incrémental
- "Des tests automatisés : rejoués souvent
- Code compréhensible car va être sans doute modifié
- Code collectif
### Attentes et bénéfices des Méth Agiles
#### Attentes
1. Accélérer la livraison des logiciels et leur mise sur le marché (75%)
2. Bien gérer les changements de priorité dans les besoins des utilisateurs (64%)
3. Accroître la productivité des équipes (55%)
4. Mieux aligner les attentes du Métier et de la DSI (49%)
5. Améliorer la qualité du code produit (46%)
#### Bénéfices
1. Bien gérer les changements de priorité dans les besoins des utilisateurs (71%)
2. Avoir une bonne visibilité des projets
3. Mieux aligner les attentes du Métier et de la DSI (65%)
4. Accélérer la livraison des logiciels et leur mise sur le marché (62%)
5. Accroître la productivité des équipes (61%)
## Scrum
### ROLES SCRUM
- PRODUCT OWNER
- Définit les caractéristiques du produit
- Décide de la date de livraison et du contenu
- Responsable du retour sur investissement du produit
- Priorise les fonctions conformément à leurs valeurs business
- Ajuste les priorités pour chaque sprint
- Accepte ou rejette les résultats
- SCRUM MASTER
- Responsable de la mise en œuvre des valeurs et des pratiques de SCRUM
- Eliminer les obstacles
- Sassurer que l’équipe est fonctionnelle et productive
- Permettre la bonne coopération entre les divers rôles et fonctions
- Protéger l’équipe de toute intervention extérieure
- EQUIPE DE DÉVELOPPEMENT
- Entre 5 et 9 personnes
- Pluridisciplinaire
- Dédiée au projet
- Auto organisée
- PARTIES PRENANTES
- Personne, ou groupe de personnes qui a des intérêts sur un projet et qui est concerné par les résultats obtenus
- Exemple de parties prenantes :
- Marché
- Client final / utilisateur
- Stratégie dinnovation
- Autres équipes de lentreprise
- UTILISATEURS
- Expert
- Source dinformation privilégiée pour
- Priorité
- Détails des fonctionnalités
### CÉRÉMONIES
![sprint](./sprint.png)
#### SPRINT PLANNING : PARTIE 1
Role : PRODUCT OWNER, SCRUM MASTER, EQUIPE DE DÉVELOPPEMENT, PARTIES PRENANTES
Temps : 90 min
- Présentation de lobjectif du sprint
- Présentation des stories
- Construction du backlog de sprint
- Engagement de l’équipe
#### SPRINT PLANNING : PARTIE 2
Role : SCRUM MASTER, EQUIPE DE DÉVELOPPEMENT
Temps : 60 min
- Conception en équipe
- Découpage en tâche
- Estimation des tâches
#### MÊLÉE QUOTIDIENNE
>C'est un daily
Role : SCRUM MASTER, EQUIPE DE DÉVELOPPEMENT
Temps : 15 min, tout les jours
- Quai-je fait hier ?
- Que vais-je faire aujourdhui ?
- Est-ce que je rencontre des obstacles ?
#### DÉMONSTRATION
Role : PRODUCT OWNER, SCRUM MASTER, EQUIPE DE DÉVELOPPEMENT, PARTIES PRENANTES, UTILISATEURS
Temps : 90 min
- Chacun présente ce quil a fait
- Le PO accepte ou rejette les résultats
- Le PO note les retour
#### RÉTROSPECTIVE
- Mise en condition
- Revue des précédentes actions
- Rassembler les données
- Chercher des idées
- Plan daction
## USER STORIES
`« En tant que, j'aimerai, afin de »`
![userstories](./userstories.PNG)
| En tant que | je voudrais | afin de |
|:--|:--|:--|
| Invité | pouvoir me créer un compte | créer un compte |
| Technicien | pouvoir ajouter des tickets à mon tableau | pouvoir accéder à mes tickets |
| Technicien | pouvoir ajouter des tickets à mon tableau | pouvoir tracer les interventions |
| Technicien | pouvoir modifier mes tickets | rectifier et décrire lavancée dun ticket |
| Technicien | pouvoir organiser mes tickets | d’être organisé |
| Technicien | pouvoir créer plusieurs tableaux Kanban | séparer les différents projets |
| Technicien | pouvoir mauthentifier | daccéder à lapplication |
| Technicien | pouvoir ajouter des images à un ticket | ajouter des détails à mon ticket |
| Technicien | pouvoir rechercher mes tickets | retrouver mes anciens tickets |
| Chef d’équipe | pouvoir assigner des tickets | mieux gérer la résolution de ticket |
| Chef d’équipe| pouvoir mauthentifier | accéder à lapplication |
| Chef d’équipe | pouvoir faire tout ce quun technicien peut faire | accès aux mêmes fonctionnalités |
| Administrateur | pouvoir gérer les rôles des utilisateurs | attribuer la bon rôle au bon utilisateur |
| Administrateur | je veux pouvoir mauthentifier | accéder à lapplication |