diff --git a/algorithmique/cours/annexes/agile.txt b/algorithmique/cours/annexes/agile.txt new file mode 100644 index 0000000..3329ff2 --- /dev/null +++ b/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 diff --git a/algorithmique/cours/annexes/scrum.txt b/algorithmique/cours/annexes/scrum.txt new file mode 100644 index 0000000..13d035b --- /dev/null +++ b/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). diff --git a/algorithmique/cours/modularite.txt b/algorithmique/cours/modularite.txt index d7b58b9..d102a7f 100644 --- a/algorithmique/cours/modularite.txt +++ b/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 +