methodes agiles
This commit is contained in:
gwen
parent
1bb3ebca56
commit
60b1491067
|
|
@ -0,0 +1,83 @@
|
||||||
|
bilan agile
|
||||||
|
============
|
||||||
|
|
||||||
|
mode itératif
|
||||||
|
-------------
|
||||||
|
|
||||||
|
- livrer des versions successives et utilisables qui convergent vers
|
||||||
|
la version finale
|
||||||
|
|
||||||
|
- ne pas perdre d'énergie à maintenir des specs détaillées non nécessaires
|
||||||
|
|
||||||
|
- de nouvelles orientations fonctionnelles sont possibles, même tard
|
||||||
|
|
||||||
|
- les specs détaillées sont écrites "juste à temps"
|
||||||
|
|
||||||
|
|
||||||
|
planification agile
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
- chaque livraison est un projet qui est planifié en tant que tel
|
||||||
|
- utiliser l'expérience acquise pour affiner les estimations
|
||||||
|
- préservation de l'écologie du projet au quotidien (code, tests...)
|
||||||
|
|
||||||
|
confiance, feedback
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
- livraisons régulières
|
||||||
|
- progrès visibles par tous (pas d'effet tunnel)
|
||||||
|
- pilotage du projet par choix du contenu des livraisons
|
||||||
|
- investissement du Product Owner
|
||||||
|
- chercher la collaboration plutôt que la confrontation
|
||||||
|
|
||||||
|
agilité
|
||||||
|
---------
|
||||||
|
|
||||||
|
- le projet n'est pas joué d'avance
|
||||||
|
- cultiver la souplesse
|
||||||
|
- révolution douce
|
||||||
|
- sortir de la confrontation, jouer le "nous collectif"
|
||||||
|
mettre tout le monde sur le mme pont et amener tout le monde à bon port
|
||||||
|
|
||||||
|
outils agiles
|
||||||
|
--------------
|
||||||
|
|
||||||
|
- planification par itérations de 4 semaines
|
||||||
|
- entrepot de source partagé
|
||||||
|
- intégration continue
|
||||||
|
- tests automatisés
|
||||||
|
- pair programming sur points cruciaux
|
||||||
|
- sprints
|
||||||
|
- extranet :
|
||||||
|
|
||||||
|
- hitoires utilisateurs
|
||||||
|
- test cases
|
||||||
|
- gestion du backolog et des tickets
|
||||||
|
- suivi de l'avancement
|
||||||
|
- documentation
|
||||||
|
|
||||||
|
le product owner
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
idéalement,
|
||||||
|
|
||||||
|
- connaissance du métier à informatiser
|
||||||
|
- fibre projet
|
||||||
|
- dispo à 100%
|
||||||
|
|
||||||
|
tests
|
||||||
|
-----
|
||||||
|
|
||||||
|
- automatiser
|
||||||
|
- viser l'exhaustivité
|
||||||
|
- tester une cible mouvante
|
||||||
|
- migrer les tests d'une release à l'autre
|
||||||
|
|
||||||
|
questions importantes
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
- quelle durée d'itération ?
|
||||||
|
- comment découper en itérations ?
|
||||||
|
- que faire lorsque le product owner se retrouve sur le chemin critique ?
|
||||||
|
- la planification est faite en mode "juste à temps" et "juste assez"
|
||||||
|
- on ne s'échine plus à blâmer, au contraire on cherche à gagner ensemble
|
||||||
|
|
@ -0,0 +1,174 @@
|
||||||
|
scrum
|
||||||
|
=====
|
||||||
|
|
||||||
|
scrum
|
||||||
|
|
||||||
|
Scrum est une méthode agile pour la gestion de projets
|
||||||
|
Le terme Scrum est emprunté au rugby et signifie mêlée.
|
||||||
|
Ce processus s'articule en effet autour d'une équipe soudée,
|
||||||
|
qui cherche à atteindre un but, comme c'est le cas en rugby
|
||||||
|
pour avancer avec le ballon pendant une mêlée.
|
||||||
|
|
||||||
|
|
||||||
|
Scrum définit trois rôles principaux :
|
||||||
|
|
||||||
|
- le responsable de produit -- Product Manager,
|
||||||
|
- le faciliteur -- ScrumMaster
|
||||||
|
- le développeur
|
||||||
|
|
||||||
|
et bien sûr, l'équipe (auto-gérée).
|
||||||
|
|
||||||
|
Des intervenants peuvent s'intégrer également au projet
|
||||||
|
de façon plus ponctuelle.
|
||||||
|
|
||||||
|
responsable de produit
|
||||||
|
|
||||||
|
Le responsable de produit (Product Manager) est le représentant des
|
||||||
|
clients et utilisateurs.
|
||||||
|
C'est lui qui définit l'ordre dans lequel les fonctionnalités
|
||||||
|
seront développées et qui prend les décisions importantes
|
||||||
|
concernant l'orientation du projet.
|
||||||
|
|
||||||
|
Le terme responsable n'est d'ailleurs pas à prendre au sens hiérarchique
|
||||||
|
du terme, mais dans le sens de l'orientation.
|
||||||
|
|
||||||
|
équipe, développement
|
||||||
|
|
||||||
|
outes les décisions sont prises ensemble et personne ne donne d'ordre
|
||||||
|
à l'équipe sur sa façon de procéder
|
||||||
|
|
||||||
|
facilitateur
|
||||||
|
|
||||||
|
est chargé de protéger l'équipe de tous les éléments perturbateurs
|
||||||
|
|
||||||
|
planification
|
||||||
|
--------------
|
||||||
|
|
||||||
|
Scrum utilise une planification à trois niveaux :
|
||||||
|
|
||||||
|
- release/projet
|
||||||
|
- sprint
|
||||||
|
- quotidien -- ScrumMeeting
|
||||||
|
|
||||||
|
quotidien
|
||||||
|
|
||||||
|
Au quotidien, une réunion, le ScrumMeeting (pas plus de 15 min)
|
||||||
|
permet à l'équipe et au ScrumMaster de faire un point d'avancement sur
|
||||||
|
les tâches et sur les difficultés rencontrées.
|
||||||
|
répondre à trois questions :
|
||||||
|
* Qu'est-ce que j'ai fait hier ?
|
||||||
|
* Qu'est-ce que je compte faire aujourd'hui ?
|
||||||
|
* Quelles difficultés est-ce que je rencontre ?
|
||||||
|
|
||||||
|
sprint
|
||||||
|
|
||||||
|
Scrum est un processus itératif : les itérations sont appelées des sprints
|
||||||
|
et durent en théorie 30 jours calendaires.
|
||||||
|
En pratique, les itérations durent généralement entre 2 et 4 semaines.
|
||||||
|
Chaque sprint possède un but et on lui associe une liste d'items
|
||||||
|
de fonctionnalités à réaliser.
|
||||||
|
Ces items sont décomposés par l'équipe en tâches élémentaires
|
||||||
|
de quelques heures, les items de fonctionnalités de sprint.
|
||||||
|
|
||||||
|
Pendant un sprint, les items de fonctionnalités de sprint à réaliser
|
||||||
|
ne peuvent pas être changés.
|
||||||
|
Les changements éventuels seront éventuellement réalisés
|
||||||
|
dans les sprints suivants.
|
||||||
|
|
||||||
|
releases
|
||||||
|
|
||||||
|
pour améliorer la lisibilité du projet,
|
||||||
|
on regroupe généralement des itérations en releases.
|
||||||
|
En effet, comme chaque sprint doit aboutir à la livraison
|
||||||
|
d'un produit partiel, une release permet de marquer la livraison
|
||||||
|
d'une version aboutie, susceptible d'être mise en exploitation
|
||||||
|
|
||||||
|
gestion des besoins
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
tâches (backlog de sprint)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Lorsqu'on démarre un sprint, on choisit quels items des fonctionnalités
|
||||||
|
seront réalisés dans ce sprint.
|
||||||
|
|
||||||
|
L'équipe décompose ensuite chaque item en liste de tâches élémentaires
|
||||||
|
(techniques ou non), chaque tâche étant estimée en heures
|
||||||
|
et ne devant pas durer plus de 2 jours.
|
||||||
|
On constitue ainsi le backlog de sprint.
|
||||||
|
|
||||||
|
Les items de backlog de produit sont les fonctionnalités qui deviendront
|
||||||
|
les items du baclog d'un sprint.
|
||||||
|
Ces fonctionnalités sont estimées en points relatifs, sans unité.
|
||||||
|
|
||||||
|
planning poker
|
||||||
|
|
||||||
|
façon ludique et efficace de produire des estimations
|
||||||
|
sur la complexité des fonctionnalités à développer
|
||||||
|
|
||||||
|
pour évaluer les scénarios utilisateurs (user stories)
|
||||||
|
du carnet de produit (product backlog).
|
||||||
|
|
||||||
|
à la fin d'un sprint :
|
||||||
|
|
||||||
|
- revue de sprint
|
||||||
|
- rétrospective de sprint
|
||||||
|
|
||||||
|
comprendre ce qui n'a pas bien marché dans le sprint,
|
||||||
|
les erreurs commises et de prendre des décisions pour s'améliorer
|
||||||
|
|
||||||
|
mise en oeuvre
|
||||||
|
--------------
|
||||||
|
|
||||||
|
Scrum peut être mis en pratique avec trois fois rien : deux listes suffisent.
|
||||||
|
La liste des items du backlog de produit et la liste des items du backlog
|
||||||
|
de sprint. La saisie et la mise à jour des données est simplement
|
||||||
|
un peu moins agréable.
|
||||||
|
|
||||||
|
glossaire
|
||||||
|
---------
|
||||||
|
|
||||||
|
Directeur de produit (Product Owner) (responsable produit)
|
||||||
|
|
||||||
|
personne responsable de produire et maintenir à jour le backlog de produit.
|
||||||
|
C'est lui qui en détermine les priorités et qui prend les décisions
|
||||||
|
concernant l'orientation du projet.
|
||||||
|
|
||||||
|
ScrumMaster (facilitateur)
|
||||||
|
|
||||||
|
membre de l'équipe dont l'objectif principal est de la protéger
|
||||||
|
des perturbation extérieures.
|
||||||
|
Il est complètement transparent pour la communication entre l'équipe
|
||||||
|
et les clients et n'a aucun pouvoir hiérarchique sur l'équipe.
|
||||||
|
C'est en revanche un facilitateur pour les problèmes non techniques
|
||||||
|
de l'équipe.
|
||||||
|
|
||||||
|
Backlog de produit (Product Backlog) (fonctionnalités)
|
||||||
|
|
||||||
|
liste des fonctionnalités qui devront être réalisées par le logiciel.
|
||||||
|
|
||||||
|
Backlog de sprint (Sprint Backlog) (tâches)
|
||||||
|
|
||||||
|
liste des tâches à accomplir pendant un sprint.
|
||||||
|
Elles correspondent à la réalisation des items de backlog
|
||||||
|
du produit affectés au sprint.
|
||||||
|
|
||||||
|
Mêlée quotidienne (Daily Scrum) (quotidien)
|
||||||
|
|
||||||
|
réunion quotidienne de 15 minutes qui a pour but de faire le point
|
||||||
|
sur ce qui a été fait depuis la dernière mêlée,
|
||||||
|
ce qui est prévu de faire jusqu'à la prochaine
|
||||||
|
et quelles sont les embûches rencontrées durant le travail.
|
||||||
|
|
||||||
|
Sprint (sprint)
|
||||||
|
|
||||||
|
nom d'une itération dans Scrum.
|
||||||
|
Cette itération dure 30 jours calendaires en théorie,
|
||||||
|
mais en pratique on utilise plutôt entre 2 et 4 semaines.
|
||||||
|
Pendant une itération, l'équipe doit développer une liste d'items
|
||||||
|
du backlog de produit qui a été définie au début de ce sprint.
|
||||||
|
|
||||||
|
Graphique d'avancement (Burndown Chart) (avancement)
|
||||||
|
|
||||||
|
graphique qui montre la tendance du reste à faire total de jour en jour
|
||||||
|
(pour les sprints) ou de sprint en sprint (pour les releases).
|
||||||
|
|
@ -49,8 +49,66 @@ Il y a dualité entre ces deux modèles.
|
||||||
**La combinaison des deux paradigmes offre de nouvelles extensibilités pour les
|
**La combinaison des deux paradigmes offre de nouvelles extensibilités pour les
|
||||||
traitements et les données.**
|
traitements et les données.**
|
||||||
|
|
||||||
|
Structuration et sûreté d'exécution
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
La preuve de programme
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Le niveau maximum de sûreté d'exécution d'un programme est la preuve. Qu'est-ce que la preuve
|
||||||
|
formelle d'un programme ? Selon la définition de Wikipédia, ce sont "des techniques permettant de
|
||||||
|
raisonner rigoureusement, à l'aide de logique mathématique, sur des programmes informatiques ou
|
||||||
|
du matériel électroniques, afin de démontrer leur validité par rapport à une certaine
|
||||||
|
spécification." Bref c'est un raisonnement logique sur un programmme qui permet d'être sûr que le
|
||||||
|
programme est valide et ne va pas planter.
|
||||||
|
|
||||||
|
La preuve de programme est très peu utilisée dans l'industrie, car très coûteuse et très
|
||||||
|
difficile à mettre en place. Elle quand même utilisée, mais dans des secteurs où le risque doit
|
||||||
|
absolument être évacué et où il n'y a aucun droit à l'erreur. Par exemple, le secteur médical
|
||||||
|
(informatique en bloc opératoire), militaire (peu d'informations nous parviennent dans ce
|
||||||
|
domaine), l'aviation civile (le logiciel Astrée pour Airbus), la fusée Ariane (depuis le bug qui
|
||||||
|
avait fait crasher Ariane 5 ces questions sont prises très au sérieux), et le milieu bancaire
|
||||||
|
(surtout le domaine des décisions boursières : un programme chargé de lancer des décisions
|
||||||
|
d'achat ou de vente à la bourse qui comporte un bug peut en quelque centièmes de secondes faire
|
||||||
|
perdre des millions, voire des milliards d'euros à une banque. Le programme ne doit tout simplement pas
|
||||||
|
bugger).
|
||||||
|
|
||||||
|
Le model checking
|
||||||
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Le model checking, l'analyse statique et l'interprétation abstraite procèdent d'une méthodologie
|
||||||
|
moins lourde de validation des programmes. Ces méthodes analysent exhaustivement l'évolution du
|
||||||
|
système lors de ses exécutions possibles et permetent de dire si globalement, dans un contexte
|
||||||
|
donné, le programme va fonctionner correctement. Encore très lourdes, ces techniques ne sont
|
||||||
|
utilisées que dans un contexte industriel de haute sécurité.
|
||||||
|
|
||||||
|
|
||||||
|
Les tests d'acceptation
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
C'est sont les tests unitaires et fonctionnels
|
||||||
|
|
||||||
|
|
||||||
|
Très utilisés dans l'industrie, les tests unitaires et fonctionnels ne testent que certaines
|
||||||
|
parties du programme et permettent de dire que le programme va marcher grosso-modo à peu près.
|
||||||
|
Beaucoup moins coûteux à installer, ce sont des éléments cléfs des méthodes agiles.
|
||||||
|
|
||||||
|
|
||||||
|
la dette technique
|
||||||
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Au bout d'un moment le code devient du code spaghetti et les techniques sont obsolètes.
|
||||||
|
Les tests permettent de solder la dette technique plus facilement.
|
||||||
|
|
||||||
|
**avoir le courage de payer une dette technique, et affronter une dette technique
|
||||||
|
sinon il peut y avoir un coût à payer qui sera pohibitoire.**
|
||||||
|
|
||||||
|
On solde la dette technique parce que à un moment ça va devenir beaucoup trop
|
||||||
|
cher à payer.
|
||||||
|
|
||||||
|
|
||||||
Les méthodologies agiles
|
Les méthodologies agiles
|
||||||
-------------------------
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
La manière dont le code est produit importe énormément. Par exemple, une
|
La manière dont le code est produit importe énormément. Par exemple, une
|
||||||
méthodologie ou le **refactoring** (réécriture de code) est permis et même conseillé
|
méthodologie ou le **refactoring** (réécriture de code) est permis et même conseillé
|
||||||
|
|
@ -67,5 +125,21 @@ méthodes de travail les plus en vogue aujourd'hui, elles mettent l'accent sur :
|
||||||
- La simplicité est essentielle (il est facile de faire, il est
|
- La simplicité est essentielle (il est facile de faire, il est
|
||||||
difficile de faire simple)
|
difficile de faire simple)
|
||||||
|
|
||||||
|
Le principe de base de la méthodologie Scrum par exemple est de focaliser l'équipe de façon
|
||||||
|
itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe de une
|
||||||
|
à quatre semaines, appelées **sprints**. Chaque sprint possède un but à atteindre, défini par le
|
||||||
|
responsable de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce
|
||||||
|
sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce
|
||||||
|
temps, le facilitateur a la charge de réduire au maximum les perturbations extérieures et de
|
||||||
|
résoudre les problèmes non techniques de l'équipe.
|
||||||
|
|
||||||
|
|
||||||
|
Les Outils de linting (validation)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
- vérifications syntaxiques
|
||||||
|
- vérification sémantiques
|
||||||
|
- vérification sur les imports inutiles ou mal formés (imports croisés
|
||||||
|
|
||||||
|
Exemple en python : pylint
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue