methodes agiles
This commit is contained in:
gwen
parent
e9b0afe3ee
commit
a723cce565
|
|
@ -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
|
||||
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
|
||||
-------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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é
|
||||
|
|
@ -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
|
||||
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