methodes agiles

algorithmique/cours/annexes/agile.txt

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

algorithmique/cours/annexes/scrum.txt

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