Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS

Transcription

1 Conduite de projets SI Les méthodes «Agiles» N QUAL/1995/3660e ORESYS

2 Agilité : de quoi parle-t-on? Agilité de l entreprise Urbanisme Architectures SOA Agilité du SI ERP Plateformes applicatives agiles Développements agiles Agilité informatique Page N 2

3 Les méthodes de développement agiles Emergence au cours des années Rapid Application Development (RAD) Dynamic System Development Method (DDM) Extreme Programming (XP) Feature Driven Development (FDD) Test Driven Development (TDD) Behavior Driven Development (BDD) remise en cause du cycle en cascade et en V SCRUM Adaptive Software Development (ASD) Crystal Clear Page N 3

4 Une approche progressive et adaptative itératif incrémental Besoins Couverture fonctionnelle Planification Spécifications Evaluation Développement itérations Validation version version Un produit qui fonctionne Temps Page N 4

5 Les valeurs communes 2001 : Le manifeste agile un produit opérationnel plus qu'une documentation pléthorique la collaboration avec le client plus que la négociation de contrat l interaction avec les personnes plus que les processus et les outils Les valeurs agiles la réactivité face au changement plus que le suivi d'un plan Page N 5

6 Scrum et extreme Programing (XP) 2 méthodes qui se distinguent largement 2 méthodes complémentaires Quelles méthodes agiles suivez vous au plus prêt? Planification, suivi SCRUM Organisation de l équipe Processus de développement étude réalisée par VersionOne (2010), 4770 répondants Pratiques et méthodes de développement XP Page N 6

7 SCRUM : organisation de l équipe Product owner Représente les clients et les utilisateurs Détermine les caractéristiques du produit Définit les priorités en fonction de la valeur «métier» L équipe SCRUM Product Owner Scrum Master Scrum Master Veille à la mise en application de la méthode Scrum S'assure que l'équipe est complètement fonctionnelle et productive, résout des problèmes Protège l'équipe des interférences extérieures Membres de l équipe Les membres de l équipe Equipe jusqu à 10 personnes, regroupant tous les rôles traditionnels (Architecte, concepteur, développeur, spécialiste IHM, testeur, etc) Effectuent les estimations, développe le produit Autogérés, sans distinction du rôle de chacun a priori Engagés collectivement Page N 7

8 Quel taux de pénétration? Des enquêtes publiques relativement «flatteuses» Enquête Version one : State of agile survey 2010 (4770 participants de 91 pays) Enquête Forrester : Survey, Q (1298 participants) Contrastant avec ce que l on voit chez nos clients. Page N 8

9 Pourquoi peu de projets sont agiles? Conduite du changement, sponsoring. Présence de la MOA, capacité de décision. Cycles de décision de l entreprise. Sous-traitance et contractualisation. Critères d éligibilité et taille des projets. Maitrise des fondements techniques. Dépendance avec les autres projets (non-agiles). Déploiement et maintenance de la solution. Maîtrise des coûts. Page N 9

10 Annexes N QUAL/1995/3660e ORESYS

11 SCRUM : organisation de l équipe Product owner Représente les clients et les utilisateurs Dé termine les caractéristiques du produit Définit les priorités en fonction de la valeur «métier» L équipe SCRUM Product Owner Scrum Master Scrum Master Veille à la mise en application de la méthode Scrum S'assure que l'équipe est complètement fonctionnelle et productive, résout des problèmes Protège l'équipe des interférences extérieures Membres de l équipe L es membres de l équipe Equipe jusqu à 10 personnes, regroupant tous les rôles traditionnels (Architecte, concepteur, développeur, spécialiste IHM, testeur, etc) Effectuent les estimations, développe le produit Autogérés, sans distinction du rôle de chacun à priori Engagés collectivement Page N 11

12 SCRUM : processus de développement Construction du produit par une suite de sprints successifs : itérations de 2 à 4 semaines en «time boxing» User story : description courte d une fonctionnalité vue par l utilisateur Points d efforts (story points) : Mesure permettant de quantifier l effort nécessaire pour réaliser une User Story Backlog produit : liste priorisée des exigences produit. Backlog de sprint : liste des tâches (subdivision des exigences) à réaliser durant le sprint. Page N 12

13 SCRUM : déroulement d un sprint Rétrospective de sprint Sprint planning A l issue du Sprint planning. L ensemble de l équipe connaît et comprend l objectif du Sprint. Chaque besoin qui doit être adressé dans le Sprint, est décomposé en tâches élémentaires (<1 jour). revue de sprint Produit testé Sprint 2 à 4 semaines Scrum meeting (journalier) Backlog produit Backlog du sprint Durant le sprint Chaque membre de l équipe prend une et une seule tâche dans le pool de tâches les plus prioritaires et effectue celle-ci. Scrum meeting Chaque membre de l équipe indique ce qu il a fait, ce qu il va faire et les problèmes qu il a rencontrés. L objectif est de faire un statut, pas de résoudre les problèmes. Lors de la revue de sprint les besoins réalisés durant le Sprint sont montrés à travers l utilisation du logiciel. Rétrospective de Sprint. Permet de lister les points qui ont bien fonctionné, ceux qui peuvent être améliorés pour le prochain Sprint Page N 13

14 XP : un ensemble de pratiques Des pratiques tournées vers l ingénierie de développement. Client sur site Améliorer la communication Répondre rapidement aux questions Evaluer au plus vite ce qui est développé Développement piloté par les tests Le test est écrit d abord Pas de code fonctionnel sans test Exécution des tests inlassablement Pair programming Développer à deux sur un poste Permet de partager savoir et compétences Permet de se relire immédiatement Le jeu de la planification Le client exprime des besoins Les développeurs estiment les charges Le client priorise les tâches User de la métaphore Une invitation à être pédagogique S appuyer sur les références des interlocuteurs (utilisateurs) Éviter le jargon technocrate Intégration continue Livraison fréquentes par les développeurs Le travail de tous est consolidé et vérifié régulièrement (tous les soirs) Refactoring Commencer par faire le plus simple possible Ne pas hésiter ensuite à réécrire du code pour l optimiser ou le clarifier Rythme de travail continu Éviter les rushs en fin d itération ou de projet Pas d heure supplémentaire Proposer des plannings réalistes Itérations courtes L itération dure une à deux semaines Conception simple Pas d architecture ou de conception sans motivation évidente Implémentation la plus directe possible Propriété collective du code Chaque développeur peut intervenir Echanges réguliers nécessaires Permet de réduire l impact des turnovers Convention de codage Format partagé pour améliorer la lisibilité Utiliser l outillage (IDE, intégration continue) pour vérifier et formater Page N 14

15 XP : cycle de vie du projet Exploration Planning Itérations Tests Mise en production Page N 15

16 Valeurs Agiles Les valeurs et les principes des méthodes agiles - l interaction avec les personnes plus que les processus et les outils - un produit opérationnel plus qu'une documentation pléthorique - la collaboration avec le client plus que la négociation de contrat - la réactivité face au changement plus que le suivi d'un plan Planifier autrement Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles. Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet. L esprit d équipe Les experts métier et les développeurs doivent collaborer quotidiennement au projet. Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail. La méthode la plus efficace pour transmettre l'information est une conversation en face à face. Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'autoorganisent. Qualité et amélioration 2001 : Le manifeste agile Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens. Page N 16