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

algorithmique/cours/modularite.txt

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