Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Introduction aux méthodes agiles Saber BHAR RT4 - 2020 Objectifs du module Pre

Introduction aux méthodes agiles Saber BHAR RT4 - 2020 Objectifs du module Prendre connaissance des principes de l’agilité Découvrir les méthodes agiles Scrum surtout Point de vue Développeurs et peu Gestion de Projet Les mettre en œuvre sur un mini-projet Préparation une “petite bonne” certification Evaluation du module Présentation du mini-projet (fin de module) QROC (DS? + Examen) QROC : Question à Réponses Ouvertes et Courtes Plan de cette séance C’est quoi, être agile ? Introduction aux méthodes agiles (ce petit support) Introduction à SCRUM La vision et le backlog Produit Le mini-projet Présentation, planning Pour vous c’est quoi, être agile ? Un effet de mode ? C’est quoi, être agile ? Plusieurs réponses possibles, suivant le prisme choisi, la plupart complémentaires : Agilité Bien-être et valeurs (Autonomie, responsabilité, sens, bien-être) … … Faire les bonnes choses (satisfaction client) … … Faire les choses efficacement (productivité) Génie Logiciel : le constat Années 2000, un postulat : les méthodes de GL ne sont pas satisfaisantes Les utilisateurs ne savent vraiment ce qu’ils veulent qu’après avoir vu une première version de l’application • Agile : origine USA, en 2001, 17 consultants, sur la production de logiciels Faiblesses des méthodes classiquesPeu d’adaptationauxchangements duclientSuivre un plan prévisionnelrefus duchangementPeu derelationavec leClient(effettunnel)Faible gestiondel’incertitude(et durisque) Méthodes Classiques Les Objectifs de l’agilité Trouver un compromis entre le minimum de méthode permettant de mener à bien les projets, tout en restant adaptable et créatif Accepter le changement des besoins et être capable d’y répondre de façon rapide et souple Privilégier le code plutôt que la documentation Les moyens ?DEF? Utiliser un développement itératif et incrémental Découper le besoin Prioriser Découper la réalisation Livrer fréquemment des incréments de produit Accepter les changements Contrôler régulièrement l’avancement avec les parties prenantes L’accent devrait être mis sur POURQUOI nous faisons quelque chose. Edwards Deming Définition: Partie prenante C’est une personne qui est intéressée d’une façon ou d’une autre, par le produit réalisé par l'équipe : Les utilisateurs, les clients, des représentants des utilisateurs Mais aussi des sponsors, des gens du marketing ou du commerce Aussi les managers, des personnes impliquées dans l’infrastructure, dans la qualité, le service des membres d'autres équipes, etc. Le « Manifeste Agile » 2001 : 4 valeurs de l’Agilité (Privilégier les éléments de gauche bien que ceux de droite aient une certaine valeur) Procédures et outils Individus et interactions Documentation exhaustive Un produit opérationnel Négociation du contrat Collaboration avec le client Suivi d'un plan Adaptation au changement Plutôt que Comparatif dirigé par le PLAN dirigé par la VALEUR L’agilité en 2 slides (1/2) Expression des besoins Conception Développement Tests, recette & debugging En développement classique, phases séquentielles À mi parcours, le client ne voit statistiquement que 10% de son application 10% du développement achevé s Conception Dével o ppeme n t gage Tests, recette & debgu Ex p res io n de be s oi n s i1 i2 i3 in i5 i4 Backlog, user stories Codage, refactoring TDD, acceptance Demos, reviews En développement agile : itérations À chaque itération, on a un incrément de produit 100% fonctionnel À mi parcours, on a déjà 80% des fonctionnalités importantes du logiciel(phases deSCRUM) Facteurs de succès des méth. agiles Le client / l’utilisateur (ou son représentant) est impliqué quotidiennement Le management intermédiaire soutient l’équipe L’équipe est auto-organisée Les pratiques sont adaptées au mode incrémental Des tests automatisés : rejoués souvent Code compréhensible car va être sans doute modifié Code collectif Principaux freins à l’agilité Résistance au changement Parfois on a de belles paroles, de beaux discours sur Scrum... Et en final les comportements, les structures et les processus demeurent inchangés Un manque de lâcher-prise du management Accepter de faire confiance à l’équipe Taux de réussite 11% 29% 60% Approche Traditionnelle Succès Echec Mitigé 39% 9% 52% Approche Agile Succès Echec Mitigé Source : the Standish Group, « Chaos Report 2015 » 3x plus de projets réussis 3x moins d’échecs Agile vs. Classique Profils des projets Si nécessaire... ANNEXES Considérer l’organisation dans sa globalité Accepter le collectif La puissance de l’équipe Cycle complet du Dév Logiciel DEV TESTS QUALIF PROD (étape vue à l’IUT) (le reste dans la vraie vie) Définition du besoin Affinage intégration livraison par des testeurs (svt des dév) par le client et des users limités (retour utilisateurs) Serveur de développement Serveur de qualification Serveur de production Chacune de ces 3 étapes peut prendre du temps... Parfois autant que le DEV... Le cycle peut ainsi être long avant qu’on découvre que les utilisateurs finaux sont mécontents... L’agilité vise à rapprocher au mieux le VRAI besoin. Cycles courts, itérations, adaptation Test unitaire vs. Test d’intégration Je retiens : Constat d’échec des approches classiques Les objectifs des Méthodes Agiles (MA) Les moyens proposés Les 4 valeurs des MA Le taux réussite par rapport aux appr classiques Comprendre les schémas des profils MA vs. Appr classique uploads/Ingenierie_Lourd/ cours1-1-introma-2020-sb.pdf