methodes agiles

This commit is contained in:
gwen 2017-03-18 07:00:18 +01:00
parent e9b0afe3ee
commit a723cce565
3 changed files with 332 additions and 1 deletions

View File

@ -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

View File

@ -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).

View File

@ -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