Rapport de veille technologique
|
|
- Gautier Labrie
- il y a 8 ans
- Total affichages :
Transcription
1 Centres de compétences TIC Région wallonne, BE Rapport de veille Réalisé par Vivansa s.p.r.l. ( Simply because you need results.
2 [Page blanche pour impression recto-verso] Réalisé par : Vivansa ( 18-Jan-2010 Page : 2 of 89
3 IDENTIFICATION PROJET REFERENCE CONTRAT CSC-2009 CLIENT Centres de compétences TIC PROGRAMME Veille CONTRACTUEL Oui NOM, FONCTION DATE SIGNATURE Écrit par : Saïd Eloudrhiri, IT Consultant 13/01/10 Revu par : Pierre Halin, IT Consultant 16/01/10 Approuvé par : Vivien Monti, Manager 18/01/10 RESUME MOTS CLES : Le présent rapport se penche sur les méthodes agiles de gestion de projet et de développement logiciel. Le besoin en agilité conduit les entreprises à considérer les méthodes agiles comme le moyen de réduire le time-to-market et à obtenir des solutions métiers répondant aux attentes. Face aux valeurs et principes agiles, les entreprises ont le défi de revoir leur méthode de travail et leur système ancré dans le modèle hiérarchique. Des sacrifices que les entreprises seront contraintes de considérer au risque de les voir échouer dans la conquête de nouveaux marchés. Méthodes agiles, SCRUM, XP, agile CARACTERISTIQUE DU DOCUMENT NOMBRE DE PAGES NOMBRE DE FIGURES LANGUE DESTINATAIRE FR N/A Réalisé par : Vivansa ( 18-Jan-2010 Page : 3 of 89
4 Versions Ed. Rév. Date Description Action(*) Paragraphes /10/09 Préparation du document M Tous /10/09 Table des matières finalisée I Tous /01/10 Corps du document finalisé I/M Tous /01/10 Corrections mineures I/M Tous /01/10 Revue qualité Q Tous /01/10 Version finale pour livraison M Tous (*) Action : I = Insertion, R = Remplacement, M = Mise à jour, S = Suppression, Q = Revue Qualité Réalisé par : Vivansa ( 18-Jan-2010 Page : 4 of 89
5 Table des matières 1 GLOSSAIRE 10 2 INTRODUCTION 11 3 CONVENTIONS MESSAGES D'INFORMATION DÉFINITION SOURCES NOMS DE MARQUE 12 4 CONTEXTE PRÉAMBULE LES PROJETS IT DANS LE MONDE LES CAUSES POSSIBLES D'ÉCHECS LES MÉTHODES AGILES : LEVIER DU SUCCÈS? 15 5 APPROCHE TRADITIONNELLE PRÉAMBULE QUELQUES MÉTHODES MODÈLE EN CASCADE MODÈLE EN V ILLUSTRATION DES PRINCIPES CONTRACTUALISATION PLAN DE PROJET SPÉCIFICATIONS DES BESOINS DÉVELOPPEMENT ÉVOLUTION DES BESOINS TESTS LIVRAISON DE LA SOLUTION MÉTHODES TRADITIONNELLES ET ARCHITECTURE IT OBSERVATIONS 26 6 APPROCHE AGILE PRÉAMBULE COLLABORATION ITÉRATIF ET INCRÉMENTAL ADAPTATIF QUELQUES MÉTHODES SCRUM EXTREME PROGRAMMING (XP) AGILE VS TRADITIONNEL CONTRACTUALISATION 42 Réalisé par : Vivansa ( 18-Jan-2010 Page : 5 of 89
6 6.3.2 ACTEURS DU PROJET LA COLLABORATION Équipes locales Équipes distantes AMÉLIORATION CONTINUE LA TRANSPARENCE MÉTHODES AGILES ET ARCHITECTURE IT ARCHITECTURES ORIENTÉES SERVICES (SOA) CLOUD COMPUTING OBSERVATIONS 48 7 TENDANCES DU MARCHÉ ATTENTES DE L'AGILE LOCALISATION DES ÉQUIPES MÉFIANCE DE L'AGILE MÉTHODES AGILES ADOPTÉES RETOURS D'EXPÉRIENCE SUCCÈS DE MISE EN ŒUVRE RAISONS DES ÉCHECS MÉTIERS IMPACTÉS ET PROFIL SALARIAL TENDANCES EN BELGIQUE 62 8 MÉTHODES AGILES ET OUTILS OUTILS DE GESTION DE PROJET OUTILS DE RÉALISATION TECHNIQUE 64 9 LES DÉFIS ET LES OPPORTUNITÉS OPPORTUNITÉS DÉFIS FORMATIONS FORMATION DE BASE CONTEXTE EXEMPLE DE SUJETS FORMATION AVANCÉE : PILOTAGE DU PROJET CONTEXTE EXEMPLE DE SUJETS FORMATION AVANCÉE : RÉALISATION DU PROJET CONTEXTE EXEMPLE DE SUJETS CONCLUSION RÉFÉRENCES RAPPORTS DE VEILLE SITES GÉNÉRAUX 85 Réalisé par : Vivansa ( 18-Jan-2010 Page : 6 of 89
7 12.3 L'AGILE EN BELGIQUE OUVRAGES ARTICLES SONDAGES LIVRES BLANCS RETOUR D'EXPÉRIENCE OUTILS 89 Réalisé par : Vivansa ( 18-Jan-2010 Page : 7 of 89
8 Table de Figures Figure 4-1 : Project Resolution (source CHAOS Summary 2009 [REF33])...14 Figure 5-1 : Modèle en cascade...17 Figure 5-2 : Modèle en V...18 Figure 5-3 : Établissement du contrat...19 Figure 5-4 : Plan de projet...20 Figure 5-5 : Production des spécifications...20 Figure 5-6 : Équipe de développement...21 Figure 5-7 : Besoin de changements fonctionnels...23 Figure 5-8 : Impact des changements...24 Figure 5-9 : Livraison de la solution...25 Figure 5-10 : Évolution des besoins...25 Figure 6-1 : Relation entre le client et le fournisseur...28 Figure 6-2 : Métaphore de la poule et du cochon (source [REF20])...28 Figure 6-3 : Itératif et incrémental...30 Figure 6-4 : Zoom d'une itération...31 Figure 6-5 : Adaptabilité...34 Figure 6-6 : Scrum Artefacts...37 Figure 6-7 : Les pratiques d'xp (source xprogramming.com)...39 Figure 6-8 : Cycle de l'extrême Programming (source extremeprogramming.org)...41 Figure 6-9 : Intégration continue (source Octo Technology [REF43])...41 Figure 6-10 : Établissement du contrat agile...42 Figure 6-11 : Identifier les acteurs...43 Figure 6-12 : Acteurs du projet agile...43 Figure 6-13 : Équipes distantes...46 Figure 7-1 : Motivations d'adoption de l'agile (source [REF34])...51 Figure 7-2 : Motivations d'adoption de l'agile par le Scrum User Group France (source [REF37])...51 Figure 7-3 : Distribution des membres de l'équipe IT (source [REF36])...52 Figure 7-4 : Projets externalisés...52 Figure 7-5 : Préoccupations organisationnelles (source [REF34])...53 Figure 7-6 : Obstacles d'adoption (source [REF34])...54 Figure 7-7 : Scrum User Group France (source [REF37])...55 Figure 7-8 : VersionOne (source [REF34])...55 Figure 7-9 : Succès des projets agiles (source [REF34])...57 Figure 7-10 : Échecs d'implémentation (source [REF34])...57 Réalisé par : Vivansa ( 18-Jan-2010 Page : 8 of 89
9 Figure 7-11 : Ventilation des réponses (source [REF38])...58 Figure 7-12 : Nombre d'années d'expérience IT (source [REF38])...59 Figure 7-13 : Age des répondants (source [REF38])...59 Figure 7-14 : Profil des répondants (source [REF38])...60 Figure 7-15 : Certifications (source [REF38])...61 Figure 7-16 : Taille des entreprises (source [REF38])...61 Figure 7-17 : Profil des entreprises en Europe (source [REF38])...62 Réalisé par : Vivansa ( 18-Jan-2010 Page : 9 of 89
10 1 Glossaire DoD... DSDM... FDD... IT... Java EE... KISS... MOA... MOE... PME... QA... RAD... ROI... SOA... TDD... XP... Definition of Done Dynamic Systems Development Method Feature Driven Development Information Technology (technologie de l'information) Java Enterprise Edition Keep IT Stupid Simple Maîtrise d'ouvrage Maîtrise d'œuvre Petites et Moyennes Entreprises Quality Assurance Rapid Application Development Return On Investment Service Oriented Architecture Test Driven Development extreme Programming Réalisé par : Vivansa ( 18-Jan-2010 Page : 10 of 89
11 2 Introduction Membres du réseau des Centres de Compétences de la Région wallonne, les centres Technifutur (Liège - http :// TechnofuturTIC (Charleroi - http :// Technocité (Mons - http :// et Techno.bel (Ciney - http :// sont chargés de la mise en œuvre d un projet de sensibilisation, d information et de formation de haut niveau dans le domaine des Technologies de l Information et des Télécommunications (TIC). Dans ce cadre, ils conduisent une activité de veille ciblée sur l évolution des métiers et des qualifications dans ce secteur. Ces centres fédèrent leurs moyens afin de mener cette démarche de veille de façon commune et en réseau. La société Vivansa (http :// par l intermédiaire de son unité Recherche & Développement, a été sollicitée pour participer à l animation continue de cette veille et à la rédaction d un rapport bisannuel. Afin d utiliser les ressources disponibles de façon optimale, cette veille se concentre sur un thème choisi conjointement. L'agilité est un thème récurrent dans les rapports de veille (voir [REF1] et [REF2]). Ce rapport s'intéresse aux pratiques agiles qui permettent d'élaborer des solutions IT en visant le succès du projet. Car c'est bien de succès ou d'échecs dont il s'agit. Les projets IT ressemblent de plus en plus à des travaux pharaoniques qui engloutissent du temps et de l'argent. Sans oublier que le stress agit négativement sur la motivation des personnes et donc la qualité du projet. Les entreprises IT peinent à reconsidérer l'usage des méthodes de développement dites traditionnelles tant les principes fondateurs sont profondément ancrés dans la culture de l'entreprise. L'agressivité du marché globalisé, les nouveautés s, les mutations du métier et les besoins très précis des utilisateurs conduisent à rendre particulièrement inefficaces les méthodes traditionnelles considérées comme trop rigides. Les méthodes agiles semblent être la solution pour modifier les pratiques de travail en se fondant sur des valeurs plus humanistes et des principes qui répondent aux besoins de qualité et d'agilité qu'impose le marché. Le rapport est subdivisé comme suit : Section 3...Convention Section 4...Contexte Section 5...Approche traditionnelle Section 6...Approche agile Section 7...Tendances du marché Section 8...Méthodes agiles et outils Section 9...Les défis et les opportunités Section 10...Formations Section 11...Conclusion Section 12...Références Réalisé par : Vivansa ( 18-Jan-2010 Page : 11 of 89
12 3 Conventions 3.1 Messages d'information Lorsque nous souhaitons attirer le lecteur sur un sujet précis, nous utiliserons les mises en évidence suivante : Ceci est une information jugée intéressante. Ceci est une information utile pour l'organisation de formations. 3.2 Définition Fournisseur IT Client Solution Produit Projet Agiliste Le Fournisseur IT représente l'équipe informatique en charge de développer la Solution (Maîtrise d'oeuvre ou MOE). Cette équipe peut-être issue d'un prestataire externe ou du département informatique interne à l'entreprise du Client. Le Client représente l'acteur qui sollicite la Solution informatique (Maîtrise d'ouvrage ou MOA). Nous utiliserons indépendamment les termes Solution, Produit ou Projet pour définir le besoin métier à développer par le Fournisseur IT pour le Client. La personne qui pratique une démarche agile. 3.3 Sources Certains liens mènent à des sources d'information rédigées en anglais. Le lecteur qui souhaite traduire ces informations pourra utiliser le service de traduction en ligne Google Translate 1 disponible gratuitement sur Internet. 3.4 Noms de marque L'ensemble des marques et logo mentionné dans ce document reste la propriété de leurs ayants droit. 1 Google Translate : http ://translate.google.com Réalisé par : Vivansa ( 18-Jan-2010 Page : 12 of 89
13 4 Contexte 4.1 Préambule La crise financière d'octobre 2008 s'est largement étendue à l'économie réelle en n'épargnant aucun pays. Il faudra attendre encore de nombreuses années avant de voir les effets de la crise s'estomper. En espérant qu'un nouvel évènement ne vienne encore secouer l'économie toujours très fragile. En Belgique, et plus particulièrement en Région wallonne, le tissu économique est essentiellement composé de PME. Celles-ci ont subi de lourdes pertes et on ne compte plus les faillites et restructurations entraînant de nombreuses pertes d'emploi. Cette morosité économique incite les sociétés à revoir leur stratégie pour ajouter plus d'agilité dans leur mode de fonctionnement et leur prise de décision. En effet, les entreprises trop rigides ont du mal à réagir efficacement face à des évènements imprévisibles de grande ampleur. Dans ce contexte, les entreprises qui souhaitent ne pas disparaître doivent fidéliser leurs clients tout en se distinguant de la concurrence. D'après une étude menée en Belgique par le fournisseur d informations Kluwer et la société de consultance Möbius (voir [REF32]), il ressort que les cadres supérieurs estiment que l'agilité de leur entreprise leur permettra de sortir renforcés de la crise actuelle. L'agilité au sein de l'entreprise agit comme un effet de levier pour : réagir promptement aux changements ; établir et maintenir une relation solide avec ses clients ; constituer une solide culture d'entreprise ; promouvoir l'innovation en bénéficiant de l'usage des nouvelles technologies ; obtenir une grande flexibilité de ses collaborateurs tout en maintenant leur motivation. Pour cela les entreprises ont besoin de solutions informatiques qui soutiennent leur métier en dynamisant leur stratégie et en s'adaptant souplement aux défis internes ou externes. 4.2 Les projets IT dans le monde Le constat des cabinets-conseils montre la difficulté croissante des entreprises à obtenir une solution informatique qui respecte le budget initial, le planning des livraisons et surtout les besoins fonctionnels du client. Depuis la moitié des années 1990, le groupe américain Standish élabore un rapport qui met en lumière le taux de succès et d'échecs des projets informatiques dans le monde. Réalisé par : Vivansa ( 18-Jan-2010 Page : 13 of 89
14 Dans la figure suivante (Figure 4-1), on remarque que l'année 2008 a vu une croissance des projets IT en échecs : 32 % des projets ont été un succès (Succeded) : livré à temps, dans le budget imparti et avec les fonctionnalités attendues. 24 % ont échoué (Failed) : projet annulé ou jamais utilisé. 44 % ont été renégociés (Challenged) : livré en retard, dépassant le budget initial et/ou avec moins de fonctionnalités promises. Figure 4-1 : Project Resolution (source CHAOS Summary 2009 [REF33]) Le constat que l'on peut en tirer est que le ROI (retour sur investissement) est loin d'être garanti pour les clients. Et même s'il faut tempérer ces chiffres, il nous faut admettre que ceux-ci sont loin d'être irréalistes. La presse et les nombreux retours d'expérience sont là pour confirmer cette tendance. En Belgique, on se souvient de l'échec retentissant du projet Phénix dont l'objectif était d'informatiser le département de la Justice. Les retards et le manque de qualité ont été les griefs du gouvernement à l'encontre du fournisseur IT. Au final, une rupture de contrat et quelque 28 millions d'euros (voir [REF28]) dépensés sans que les utilisateurs disposent d'une solution qui réponde à leurs attentes. 4.3 Les causes possibles d'échecs Parmi les nombreuses causes qui entraînent les projets IT vers l'échec, on peut citer les suivantes : une mauvaise définition des besoins ; des problèmes de priorisation des tâches ; Réalisé par : Vivansa ( 18-Jan-2010 Page : 14 of 89
15 de mauvaises estimations de charge ; des cycles de développement trop long ; des équipes sous pression qui entraînent du stress et de la démotivation ; un manque de transparence pour le client ; une incapacité d'intégrer des changements fonctionnels en cours de projet. Ces causes sont en grande partie imputables aux méthodes de développement traditionnelles jugées trop rigides et qui peinent à s'adapter aux défis économiques qui requièrent de la part des entreprises plus d'agilité. 4.4 Les méthodes agiles : levier du succès? Les méthodes agiles ont élaboré des pratiques de gestion de projet et d'ingénierie logicielle en les expérimentant sur le terrain. Ces pratiques révolutionnent le développement de projets IT en apportant des valeurs et des principes qui encouragent l'intelligence collective, la recherche de la qualité, la collaboration, la communication, la transparence et l'intégration du client comme partenaire à part entière de l'élaboration de la solution. Nous allons montrer comment et pourquoi les méthodes agiles provoquent cet engouement croissant et les valeurs ajoutées qu'elles peuvent apporter au fonctionnement des entreprises et des individus. Mais avant cela, rappelons les principes qui caractérisent les méthodes traditionnelles et les limites de cette approche face aux attentes du marché. Réalisé par : Vivansa ( 18-Jan-2010 Page : 15 of 89
16 5 Approche traditionnelle 5.1 Préambule Depuis plus de trente ans, les méthodes traditionnelles de développement font le quotidien de la majorité des projets informatiques. Ces méthodes ont peu évolué et le fossé se creuse chaque jour entre la rigidité des pratiques de développement traditionnelles et les attentes du marché (réactivité, agilité). Dans une majorité de cas, les projets informatiques ne répondent plus aux besoins des utilisateurs ou sont purement abandonnés. En quelques mots, une approche traditionnelle tend à cadrer et spécifier en amont tous les aspects de la solution avant d'aborder le cycle de développement, des tests et de livraison. Autant dire que la route qui mène à un résultat visible et palpable pour le client est très longue. Et comme les tests sont en bout de route, le projet a de grandes chances de buter sur des problèmes de qualité technique ou fonctionnelle. Nous allons rappeler ce qui caractérise les approches (ou méthodes) traditionnelles pour mieux comprendre les contraintes qu'elles imposent. 5.2 Quelques méthodes Sans chercher à être exhaustifs, nous allons brièvement présenter les principales méthodes de développement traditionnelles. Le lecteur, soucieux d'approfondir l'une ou l'autre méthode de travail, trouvera dans ce document une liste d'ouvrage et de sites de référence (voir 12). Les formations devront rappeler les grands principes des méthodes traditionnelles afin de souligner les contraintes et mieux amener la discussion vers les méthodes agiles Modèle en cascade Le modèle de développement en cascade est la méthode classique la plus utilisée depuis plus de 30 ans. Réalisé par : Vivansa ( 18-Jan-2010 Page : 16 of 89
17 Figure 5-1 : Modèle en cascade Le modèle en cascade est également connu sous le nom de "plan-driven development" (ou développement piloté par le plan). Le plan est au coeur de cette méthode qui, dès le démarrage du projet, ne souhaite rien laisser au hasard. D'où l'appellation de méthode "prédictive". L'approche est séquentielle et chaque discipline (capture des besoins, spécifications, etc.) est exécutée et documentée dans le détail avant de passer le relais à la discipline suivante. Cette notion de détail explique la profusion de documentation qui caractérise ce modèle de développement. Les changements fonctionnels en cours de projet sont assez mal accueillis, car ils risquent de fortement perturber le plan initial ou remettre en cause les cahiers de spécifications (fonctionnelles et techniques) qui ont été élaborés. D'autre part, les tests qui arrivent assez tard dans le processus peuvent révéler des incohérences tant fonctionnelles que techniques. Du côté de la conception de la solution, l'ingénierie des équipes de développement est peu mise à contribution. Les développeurs sont souvent relégués à la codification de ce qui a déjà été largement spécifié. Ce mode de travail a tendance à engendrer une certaine frustration de la part du développeur qui s'isole dans son travail et n'a pas l'impression de participer activement à la réalisation du projet. Réalisé par : Vivansa ( 18-Jan-2010 Page : 17 of 89
18 Le client doit prendre son mal en patience avant de voir les premiers éléments tangibles de la solution. Le risque est donc grand que la solution livrée soit mal accueillie par le client qui ne retrouve pas la qualité attendue ou les besoins initiaux qui ont été exprimés. On attribue la paternité de l'approche en cascade au Docteur Winston W. Royce qui le premier décrivit en 1970 le principe de fonctionnement (voir [REF13]). Mais au lieu de promouvoir cette approche, le Dr Royce en montrait les limites et les risques. Malgré tout, durant plus de trente ans, les méthodes en cascade ont été appliquées dans de larges projets informatiques confirmant trop souvent l'analyse du Dr Royce Modèle en V Le modèle en V est une évolution du modèle en cascade dans lequel chaque discipline, bénéfice d'un alter ego en charge de tester sa cohérence. L'objectif étant de relever assez tôt les incohérences dans les phases d'analyse pour livrer une solution la plus proche possible des besoins exprimés. Figure 5-2 : Modèle en V Malgré tout, ce modèle reste encore assez lourd à mettre en oeuvre, les documents produits sont encore très nombreux et l'application ne reste visible qu'assez tard dans le processus de développement. 5.3 Illustration des principes Nous allons illustrer quelques principes en suivant les principales étapes d'un projet informatique. Réalisé par : Vivansa ( 18-Jan-2010 Page : 18 of 89
19 Pour pointer les limites des méthodes traditionnelles, nous allons volontairement illustrer une situation avec des sources de problèmes Contractualisation Entre le client et le fournisseur informatique, un contrat est établi pour définir : le périmètre de la solution et les livrables (en anglais «deliverables») ; l'enveloppe financière ; la date et les modalités de la livraison finale ; les pénalités de retard. Figure 5-3 : Établissement du contrat En règle général, ces contrats sont très contraignant et ne procurent que peu ou pas de souplesse pour adapter l'une ou l'autre clause Plan de projet Il est déjà temps de produire le plan de projet qui va détailler chaque activité en y posant les principaux jalons (en anglais «milestones»). Par ce plan de projet, le fournisseur s'engage sur les activités à réaliser. Il est courant de voir les charges des activités estimées par des personnes autres que celles qui seront impliquées dans leur réalisation. Ceci peut amener bien des surprises au moment où l'activité devra être concrètement réalisée. Le stress des personnes impliquées et les retards de délais seront inévitablement au rendez-vous. Dès que le plan est accepté, celui-ci sert de feuille de route pour la réalisation du projet. Ce caractère «immuable» du plan de projet sera la source de bien des soucis pour le chef de projet et les collaborateurs pour tenir leur engagement vis-à-vis du client. Réalisé par : Vivansa ( 18-Jan-2010 Page : 19 of 89
20 Figure 5-4 : Plan de projet En effet, chaque aménagement du plan de projet devra être motivé et âprement négocié avec le client. À ce stade, on perçoit déjà que le projet ne démarre pas sous les meilleurs auspices Spécifications des besoins Après la récolte des besoins métier, le fournisseur documente de manière très détaillée les spécifications fonctionnelles et techniques. Ces documents seront validés par le client, mais qui pourra éprouver des difficultés à visualiser les principes. La validation sera souvent longue et incomplète. Figure 5-5 : Production des spécifications Le contrat et le plan projet viennent cadrer l'ensemble des livrables à produire. Cela amène à des situations où des documents sont tout de même écrits même si leur pertinence n'est plus aussi grande. Ces situations entraînent une perte de temps et donc d'argent pour le client. Réalisé par : Vivansa ( 18-Jan-2010 Page : 20 of 89
21 5.3.4 Développement Place maintenant au développement proprement dit. Dans la plupart des cas, les développeurs découvrent le projet et doivent assimiler un ensemble de spécifications auxquelles ils n'ont pas participé. Comme le plan projet est déjà bien avancé, le mot d'ordre donné aux développeurs est de suivre scrupuleusement ce qui est spécifié pour éviter toute dérive du planning. Ce qui ferme toute porte à l'émergence de nouvelles idées ou à la détection de problèmes potentiels. Le développeur est enfermé dans les tâches qu'il doit réaliser conformément au plan et dans un délai imposé. Cette situation provoque des frustrations et une démotivation croissante qui auront pour effet d'impacter la qualité du projet et les délais de livraison. Stress au travail Selon une étude de Test-Achats (voir [REF39]), le stress au travail occasionne annuellement plus de 9 millions de jours d'absentéisme en Belgique. Des facteurs tels que les cadences de travail effrénées, un manque de collaboration et de communication ou un manque de reconnaissance sont des sources de stress. Ces absences coûtent cher aux entreprises et, dans le cas qui nous occupe, impacte négativement la dynamique du projet informatique. Il est donc dans l'intérêt des entreprises de prendre ce problème très au sérieux et de chercher à y remédier. La collaboration entre les individus est également perfectible, chaque individu travaillant sur son îlot. Figure 5-6 : Équipe de développement Réalisé par : Vivansa ( 18-Jan-2010 Page : 21 of 89
22 Pour le client, le cycle de développement est très frustrant. Un effet «tunnel» s'installe et le client perd le contact avec le projet par manque de visibilité. Le mécontentement et la méfiance du client grandissent à mesure que l'effet tunnel perdure. Effet Tunnel L'effet tunnel (voir [REF31]) en informatique n'est pas à confondre avec le même terme employé en physique quantique. En informatique, l'effet tunnel traduit le laps de temps durant lequel le client perd le contact avec le fournisseur qui est occupé à développer la solution Évolution des besoins Pendant que le fournisseur développe la solution, les besoins du client ne se figent pas pour autant. Le client sera sollicité par des évènements qu'il ne devra pas ignorer, par exemple : des pressions économiques imposant une réactivité plus grande face à la concurrence en réduisant le time-to-market (le temps nécessaire à la mise sur le marché d'un produit) ; une nouvelle directive imposant d'adapter les processus métiers ; de nouveaux besoins exprimés par les utilisateurs ; des évolutions s que l'on souhaite intégrer pour se différencier de la concurrence. Réalisé par : Vivansa ( 18-Jan-2010 Page : 22 of 89
23 Figure 5-7 : Besoin de changements fonctionnels Tout naturellement, le client va souhaiter étudier avec le fournisseur IT l'opportunité d'intégrer ces changements dans la solution en cours d'élaboration, et si possible sans impacter le budget initial et le délai de livraison. Mais cela n'est pas si simple! Pour le fournisseur, ces changements ont un sérieux impact sur les développements en cours ainsi que sur les spécifications fonctionnelles et techniques. Le fournisseur n'est pas très enthousiaste pour revoir ce qui a été si durement produit. D'autant qu'on lui demande de respecter autant que possible le budget et le délai de livraison. Le réflexe habituel est de voir le fournisseur refuser poliment les nouvelles demandes en se basant sur le contrat et le plan de projet. Réalisé par : Vivansa ( 18-Jan-2010 Page : 23 of 89
24 Figure 5-8 : Impact des changements Cette situation va indéniablement entraîner une frustration du côté du client qui pointe un manque de flexibilité (autrement dit «d'agilité») de son fournisseur Tests La fin des développements annonce la phase des tests techniques et fonctionnels. Comme cette phase arrive assez tard dans le cycle du projet, le volume d'erreurs détecté accroît le risque de délai dans le planning. Le risque de glissement est plus grand si les erreurs sont de type fonctionnel et compromettent les fondements des spécifications. Dans ce cas de figure, il sera très difficile de déterminer qui du client ou du fournisseur IT est dans son bon droit. Le fournisseur IT reprochera au client de mal avoir exposé les besoins et le client reprochera au fournisseur IT qu'il était de sa responsabilité de valider l'ensemble des problèmes potentiels et de lever les alarmes suffisamment tôt. D'autant que le client n'a pas été en mesure de tester les versions intermédiaires de la solution (effet tunnel). Des tests tardifs et un manque de feed-back des utilisateurs du client peuvent être très dommageables dans la réussite du projet. Réalisé par : Vivansa ( 18-Jan-2010 Page : 24 of 89
25 5.3.7 Livraison de la solution Le fournisseur IT a remplit ses engagements et livre la solution à son client dans les délais fixés. Comme le projet a manqué de transparence, le client a des appréhensions quant au produit livré : la qualité est-elle au rendez-vous? les besoins métiers ont-ils été compris et intégrés? sera t'il possible d'installer et d intégrer le produit sans encombre? On peut dire que dans bien des cas, le client reçoit un "chat dans un sac"! Figure 5-9 : Livraison de la solution D'autant que la solution, même si elle a été développée conformément aux besoins initiaux, risque de ne plus répondre aux attentes du client qui entre-temps ont évolué. Le produit a peut-être été livré à temps, mais il n'est plus en adéquation avec les besoins du métier qui ont pourtant été exprimés en cours de projets et refusés par manque d'agilité dans la méthode de travail. Figure 5-10 : Évolution des besoins Les utilisateurs sont frustrés de ne pas bénéficier d'une solution répondant aux besoins du moment et menacent de ne pas l'adopter. Ils estiment, à juste titre, n'avoir pas été suffisamment impliqués dans l'élaboration et la validation de la solution. Réalisé par : Vivansa ( 18-Jan-2010 Page : 25 of 89
26 Le fournisseur IT estime pour sa part avoir respecté les termes du contrat, mais le client lui reproche son manque d'agilité. Les ajouts fonctionnels devront faire l'objet d'un nouveau contrat, mais le client réfléchit à la pertinence du renouvellement de sa confiance au fournisseur IT. 5.4 Méthodes traditionnelles et architecture IT Les méthodes traditionnelles n'encouragent pas la mise en oeuvre d'une architecture informatique qui soit plus souple et plus agile aux changements. Par exemple, les méthodes actuelles ne répondent pas aux attentes d'une démarche d'architecture orientée services ou SOA (voir section dans [REF1]). Ainsi, le développement traditionnel va perpétuer le syndrome des silos applicatifs. 5.5 Observations La méthode traditionnelle offre certes l'avantage de cerner dans ses moindres détails les besoins fonctionnels, mais son manque de souplesse restreint les possibilités d'intégrer des changements en cours de projet. Pourtant l'expérience des récents évènements économiques, nous montre qu'il est plus habile d'être agile face au changement que d avoir la prétention de prévoir des situations qui sont souvent hors de notre contrôle. En résumé, qui doit-on blâmer? Le client, d'avoir changé en cours de route les besoins fonctionnels? En partie non, car il est de son plein droit de disposer d'une solution qui répondra amplement à ses besoins et aux défis qui l'attendent. Mais le contrat imposé au fournisseur laissait peu de place à une certaine forme d'agilité. Le fournisseur IT d'avoir livré une solution qui n'est plus en phase avec les nouveaux besoins? En partie non, car le logiciel a été livré dans les temps en respectant les clauses contractuelles. Mais la méthode choisie n'a pas permis d'intégrer souplement les nouveaux changements fonctionnels et d offrir la transparence nécessaire vis-à-vis du client. Nous allons voir que les méthodes agiles apportent des éléments de réponse pour pallier aux problèmes que nous avons illustrés. Réalisé par : Vivansa ( 18-Jan-2010 Page : 26 of 89
25/12/2012 www.toubkalit.ma
25/12/2012 www.toubkalit.ma 1 Définition Exemple des méthodes agiles Valeurs Principes Le cycle itératif et incrémental (Itération/Sprint) Schéma de travail Méthode Scrum. Méthode XP (Extreme programming).
Plus en détailGestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique»
Gestion de projet Agile Module 4.2 - «Gérer et organiser un projet informatique» Sommaire Introduction Principes et méthodes Agiles Scrum 2 Introduction Gestion de projet : démarche structurante assurant
Plus en détailSoyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique
Soyez agile Dans l industrie du logiciel, la gestion de projet est confrontée à de nombreux défis. Le principal est de pouvoir assurer l adéquation d un produit et de ses fonctionnalités avec les besoins
Plus en détailMéthodes Agiles et gestion de projets
Méthodes Agiles et gestion de projets Eric LELEU Consultant Solutions Collaboratives Contact ericleleu@nordnet.fr Site Personnel http://home.nordnet.fr/~ericleleu Blog http://ericleleu.spaces.live.fr La
Plus en détailRègles d engagement. Présentation Diapositives Bibliographie Questions Les vertus de la marche
Règles d engagement Présentation Diapositives Bibliographie Questions Les vertus de la marche Plan Rappels sur l agilité Scrum : une implantation de l agilité Scrum ou XP? Conclusion Historique sélectif
Plus en détailMéthodes de développement
1 / 9 Méthodes de développement Méthodes agiles 1 - Introduction... 2 2 -Le manifeste agile et les méthodes agiles... 2 2.1 Le manifeste agile... 2 2.2 Les méthodes agiles... 3 3 - Caractéristiques communes
Plus en détailCertification Scrum Master
avec Jeff Sutherland Les méthodes Agiles représentent indéniablement une approche nouvelle et différente dans la conduite de projets. Au lieu de suivre un plan à la lettre en assignant des tâches à une
Plus en détailGESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET
GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php PLAN Objectif et
Plus en détailConduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS
Conduite de projets SI Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Agilité : de quoi parle-t-on? Agilité de l entreprise Urbanisme Architectures SOA Agilité du SI ERP Plateformes applicatives agiles
Plus en détailRetour d expérience implémentation Scrum / XP
Retour d expérience implémentation Scrum / XP Bruno Orsier Octobre 2008 p.1 Bruno Orsier, Agile Tour 2008 Grenoble Plan Qui sommes nous? Pourquoi Scrum/XP? Historique de la mise en œuvre Bilan Sondage
Plus en détailYassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES
Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES Quelques constats Etude du Standish Group Seul 1/3 des projets informatiques sont qualifiés de succès 50 % sont livrés et opérationnels, mais sont sortis du
Plus en détailAgile 360 Product Owner Scrum Master
Agile 360 Product Owner Scrum Master Lead Technique Equipe Agile Conception Agile Leadership Agile Software Craftmanship Test Driven Development Catalogue 2013 Liste des formations Formation Agile 360
Plus en détailScrum Une méthode agile pour vos projets
Avant-propos 1. Objectif du livre 17 2. Notre démarche 17 3. Structure du livre 18 4. Remerciements 20 Scrum, une méthode agile avant tout 1. Le grand départ 21 2. La gestion de projet informatique 22
Plus en détailMéthodes agiles. www.businessinteractif.com CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS. Jean-Louis Bénard jlb@businessinteractif.
Méthodes agiles www.businessinteractif.com Jean-Louis Bénard jlb@businessinteractif.fr CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS 0 20 mai 2002 Sommaire Méthodes agiles : une réponse à un malaise?
Plus en détailEXIN Agile Scrum Master
Guide de préparation EXIN Agile Scrum Master Édition de juillet 2015 Copyright 2015 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing
Plus en détailLes méthodes Agiles Introduction. Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008
Les méthodes Agiles Introduction Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008 Les méthodes Agiles Le contexte Le Manifeste Agile Une tentative de définition
Plus en détailbacklog du produit Product Owner
Méthodes agiles : Définition: selon Scott Ambler «Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées
Plus en détailMaîtrise d ouvrage agile
Maîtrise d ouvrage agile Offre de service Smartpoint 17 rue Neuve Tolbiac 75013 PARIS - www.smartpoint.fr SAS au capital de 37 500 - RCS PARIS B 492 114 434 Smartpoint, en quelques mots Smartpoint est
Plus en détailTopologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM
Méthodes agiles & SCRUM 1/ Pourquoi les méthodes agiles? Définition d une méthode agile. Fondamentaux. Quand les utiliser? 2/ SCRUM En quoi est-ce une méthode agile? Sprints et releases. Le Product Owner.
Plus en détailXP : plus qu'agile. Extreme Programming v2 et Développement Responsable. Thierry Cros
XP : plus qu'agile Extreme Programming v2 et Développement Responsable Thierry Cros Retrouvez cette présentation sur le site http://thierrycros.net Licence CC-BY-NC-SA XP : plus qu'agile Pourquoi XP Installer
Plus en détailJean-Pierre Vickoff www.vickoff.com
Techniques du futur Agile Communication - Architecture - Méthode Vers une approche Agile de 3 ème génération Jean-Pierre Vickoff www.vickoff.com Protocole de séance : Précisions techniques immédiates possibles
Plus en détailProgrammation Agile Mise en oeuvre via Scrum et l'extreme Programming (XP)
Programmation Agile Mise en oeuvre via Scrum et l'extreme Programming (XP) B. Mermet 2010 Plan La programmation Agile et L'artisanat du logiciel Mise en œuvre avec Scrum Mise en œuvre avec l'extreme Programming
Plus en détailLes méthodes itératives. Hugues MEUNIER
Les méthodes itératives Hugues MEUNIER INTRODUCTION. Toute les méthodes ont le même but : la maîtrise du budget, du planning et de la qualité des projets de développement informatique Plusieurs approches
Plus en détailGuide de Préparation. EXIN Agile Scrum. Foundation
Guide de Préparation EXIN Agile Scrum Foundation Édition Décembre 2014 Droits d auteur 2014 EXIN Tous droits réservés. Aucune partie de cette publication ne saurait être publiée, reproduite, copiée, entreposée
Plus en détailSéance 1 Méthodologies du génie logiciel
Séance 1 Méthodologies du génie logiciel Objectifs : Histoire du développement du logiciel. La crise du logiciel. Explorer les différentes méthodologies de développement. Comprendre l importance d adopter
Plus en détailModèle de changement d organisation. Leanpizza.net présente. Petit Guide Rapide du jeu de cartes Modèle de Changement d Organisation
Guide rapide Leanpizza.net présente Petit Guide Rapide du jeu de cartes Modèle de Changement d Organisation v1.0 Rédacteur : Olivier Lafontan Traduction : Yannick Quenec hdu Date : 29 juin 2010 - Guide
Plus en détailLes méthodes Agile. Implication du client Développement itératif et incrémental
Les méthodes Agile Simon ALEXANDRE - CETIC Plan Overview Agile ne signifie pas Agile signifie Objectifs poursuivis Pourquoi les méthodes Agile apparaissent-elles? Principales causes des échecs de projets
Plus en détailLa solution IBM Rational pour une ALM Agile
La solution IBM pour une ALM Agile Utilisez votre potentiel agile Points clés Adopter l'agilité à votre rythme Supporter une livraison multiplateforme Intégrer la visibilité Démarrer rapidement Que votre
Plus en détailMéthode Agile de 3 ème génération. 2008 J-P Vickoff
PUMA Essentiel Méthode Agile de 3 ème génération 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Quelques principes Agiles Principales pratique Agile de pilotage Structure
Plus en détailAgile Maroc 24 Novembre 2010. Méthodes agiles. Thierry Cros. http://etre-agile.com. Agile Maroc 24 novembre 2010
Agile Maroc 24 Novembre 2010 Méthodes agiles Thierry Cros 1 Thierry Cros 10 ans déjà... 2010 Création Extreme Programming France 2009 SigmaT Les Agilistes Toulousains 2010 Membre de «Fédération Agile»
Plus en détailScrum + Drupal = Julien Dubois
Pourquoi j aime Scrum Pourquoi Scrum et Drupal sont faits pour s entendre Scrum + Drupal = Julien Dubois Happyculture.coop De quoi allons-nous parler? 1. Que sont les méthodes agiles? 2. Présentation de
Plus en détailIntroduction Les processus traditionnels extreme Programming Conclusion. extreme Programming. vers plus d agilité. F. Miller francois.miller@inpg.
vers plus d agilité F. Miller francois.miller@inpg.fr FC INPG Octobre 2008 - version 1.0 Introduction Contexte Le monde bouge économie des moyens (humains, financier,...) ; recherche de plus d efficacité
Plus en détailFeature Team Primer. par Craig Larman et Bas Vodde. Version 1.2
ÉQUIPE FEATURE par Craig Larman et Bas Vodde Version 1.2 Les Équipes Feature 1 et les Domaines Fonctionnels 2 sont des éléments essentiels pour dimensionner le développement en mode agile et lean. Ces
Plus en détailLe rôle du coach Agile et son apport pour le projet
Le rôle du coach Agile et son apport pour le projet Franck Beulé Soirée du 4 novembre 2013 Chez Google 45 Sommaire Qu est- ce qu un coach Agile? Que s interdit- il? Ce qu il fait Ses points d anenoon Des
Plus en détailCours Gestion de projet
Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA
Plus en détailDéveloppement itératif, évolutif et agile
Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie
Plus en détail1. Considérations sur le développement rapide d'application et les méthodes agiles
Chapitre 1 Introduction 1. Considérations sur le développement rapide d'application et les méthodes agiles 1.1 Rappel Longtemps les méthodes en cascade ou en V ont été opposées aux démarches empiriques
Plus en détailScrum et l'agilité des équipes de développement
NormandyJUG Scrum et l'agilité des équipes de développement Par Dimitri Baeli & Nicolas Giard 23 Février 2010 Présentation des intervenants Dimitri Baeli http://twitter.com/dbaeli VP Quality Enterprise
Plus en détailCours Ephec Niv. 2 : Technique et gestion de projet. Par Monsieur Bertieaux Année Académique 2014-2015. Quelles sont les 4 valeurs Agiles?
Cours Ephec Niv. 2 : Technique et gestion de projet Par Monsieur Bertieaux Année Académique 2014-2015 Réponse aux questions du cours, slide Cours 2_2_Scrum Quelles sont les 4 valeurs Agiles? 1. «Les personnes
Plus en détailSCRUM BUT, LE LIVRE BLANC. De la problématique de mener un projet AGILE dans une organisation classique
SCRUM BUT, LE LIVRE BLANC De la problématique de mener un projet AGILE dans une organisation classique Résumé Alors que les demandes de conduite de projet en AGILITE sont de plus en plus fréquentes, les
Plus en détailXEBIA DÉVELOPPEMENT OFFSHORE DISTRIBUÉ EN MÉTHODES AGILES. CAS CLIENT : CoachClub
XEBIA DÉVELOPPEMENT OFFSHORE DISTRIBUÉ EN MÉTHODES AGILES CAS CLIENT : CoachClub Le métier de CoachClub CoachClub est le premier site vidéo de Coaching Sportif personnalisé. Mis au point par des professionnels
Plus en détailScrum. ... pour des projets informatiques agiles. Pascal Lando Certified Scrum product owner
Scrum... pour des projets informatiques agiles Pascal Lando Certified Scrum product owner e-merchant Laboratoire Mis IUP Miage d Amiens pascal.lando@u-picardie.fr 2 octobre 2013 Ceci n est pas un cours
Plus en détailINF2015 Développement de logiciels dans un environnement Agile Examen final hiver 2015
INF2015 Développement de logiciels dans un environnement Agile Examen final hiver 2015 Question #1 Quelle technique de mise sous test devons-nous utiliser si nous voulons simuler le comportement d'une
Plus en détailDéveloppement d'un projet informatique
Développement d'un projet informatique par Emmanuel Delahaye (Espace personnel d'emmanuel Delahaye) Date de publication : 27 janvier 2008 Dernière mise à jour : 25 avril 2009 Cet article présente un certain
Plus en détailA-t-on le temps de faire les choses?
A-t-on le temps de faire les choses? A-t-on le temps de faire les choses? Un parcours de 25 ans dans le domaine des Systèmes d'information de 6 grandes entreprises Consultante depuis 19 ans Mission / contrats
Plus en détailNom-Projet MODELE PLAN DE MANAGEMENT DE PROJET
Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET Glossaire La terminologie propre au projet, ainsi que les abréviations et sigles utilisés sont définis dans le Glossaire. Approbation Décision formelle, donnée
Plus en détailEstimer et mesurer la performance des projets agiles avec les points de fonction
Estimer et mesurer la performance des projets agiles avec les points de fonction Radenko Corovic, MBA radenko.corovic@rsmtechno.ca 1. Introduction Les méthodes agiles de développement des systèmes ont
Plus en détailJean-Pierre Vickoff. 2008 J-P Vickoff
Agilité étendue Jean-Pierre Vickoff 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Le mouvement Itératif-Incrémental (Agile) Agilité étendue au SI et PUMA Essentiel Entreprise
Plus en détailLA MÉTHODE AGILE VS LE CYCLE EN V UNE RÉVOLUTION DANS LA GESTION DE PROJET. Franck BEULÉ
LA MÉTHODE AGILE VS LE CYCLE EN V UNE RÉVOLUTION DANS LA GESTION DE PROJET Franck BEULÉ 18 avril 2012 Bienvenue L'hôte de ce soir Franck BEULÉ Chef de Projet senior Chez Vision IT Group depuis 2 ans Actuellement
Plus en détailTuesday, October 20, 2009. Nantes
Tuesday, October 20, 2009 Nantes Retour d'expérience SCRUM/XP dans un contexte CMMI-DEV niveau 2 SM CMM Integration, IDEAL, and SCAMPI are service marks of Carnegie Mellon University. Capability Maturity
Plus en détailFormation agile. Formation agile Created on 24 janv. 2012 Edited on 29 févr. 2012. Page 1 sur 16
Formation agile Page 1 sur 16 1. Qui sommes-nous?... 3 1.1. Pierre-Emmanuel Dautreppe... 3 1.2. Norman Deschauwer... 3 1.3. L association DotNetHub... 3 2. Introduction... 5 3. Agile Manifesto... 6 4.
Plus en détailL'appel public à l'épargne, pour quel besoin de financement? (2/3)
L'appel public à l'épargne, pour quel besoin de financement? (2/3) Lors d'une précédente analyse, nous avions présenté deux outils d'appel public à l'épargne qui bénéficient d'un régime légal favorable
Plus en détailScrum. Description. Traduit en langue française par Bruno Sbille et Fabrice Aimetti - Avril 2014 - Trad FR v1.1
Scrum Description Traduit en langue française par Bruno Sbille et Fabrice Aimetti - Avril 2014 - Trad FR v1.1 V 2012.12.13 2014 Scrum Alliance,Inc 1 Les principes de Scrum Les Valeurs du Manifeste Agile
Plus en détailExtreme Programming. Le projet social. Angèle Batanero Thierry Cros. http://etre-agile.com. Agile Tour 2010 : XP, le projet social
Extreme Programming Le projet social Angèle Batanero Thierry Cros 1 Qui sommes-nous? Angèle Batanero Développeur Thierry Cros C++ Java Coach depuis 10 ans 2 Agenda XP, qu'es aco? Valeurs, principes Pratiques
Plus en détailLes méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum
Les méthodes Agiles Introduc)on aux méthodes Agiles Exemple : Scrum Défini)on de base Les méthodes Agiles sont des procédures de concep)on de logiciel qui se veulent plus pragma)ques que les méthodes tradi)onnelles
Plus en détailPlan. 1 Cycles de développement. 2 Méthodes agiles, principes généraux. 3 Comment se passe un Sprint?
Plan nitiation au Génie Logiciel Cours 5 ntroduction au π développement agile T. Genet (genet@irisa.fr) (STC/RSA) GEN-5 1/ 28 T. Genet (genet@irisa.fr) (STC/RSA) GEN-5 2/ 28 Bibliographie Plan L informatique
Plus en détailMinistère de l intérieur --------
Ministère de l intérieur -------- Examen professionnel d ingénieur principal des systèmes d information et de communication du ministère de l intérieur Session 2013 Meilleure copie Sujet n 1 - Réseaux
Plus en détailCATALOGUE)FORMATION)2015)
CATALOGUE)FORMATION)2015) Intitulé(de(formation( Code( Agiliser)vos)processus) F010$ Fondamentaux)du)Lean) F021$ Résolution)de)problème) F022$ Lean)Six)Sigma) F023$ Mesures)et)indicateurs) F030$ Assurance)qualité,)vérification,)validation)
Plus en détailComment mettre en oeuvre une gestion de portefeuille de projets efficace et rentable en 4 semaines?
DOSSIER SOLUTION Package CA Clarity PPM On Demand Essentials for 50 Users Comment mettre en oeuvre une gestion de portefeuille de projets efficace et rentable en 4 semaines? agility made possible CA Technologies
Plus en détailGestion Projet. Cours 3. Le cycle de vie
Gestion Projet Cours 3 Le cycle de vie Sommaire Généralités 3 Séquentiel 7 Itératif/Incrémental 17 Extreme Programming 22 Que choisir? 29 Etats Transverse 33 Cours 3 2006-2007 2 Généralités Cours 3 2006-2007
Plus en détailL'agilité appliquée à nous-mêmes. Philippe Krief, PhD Development Manager IBM France Lab
L'agilité appliquée à nous-mêmes Philippe Krief, PhD Development Manager IBM France Lab Agenda Où en était l équipe RPP il y a 24 mois Réorganisation de l équipe et du projet autour de Scrum et de RTC
Plus en détailPrésentation UBO 12/2008 Présentation des méthodes agiles
Gestion de projet Vers les méthodes agiles Des approches prédictives aux méthodes agiles appliquées avec SCRUM Présentation UBO 12/2008 Présentation des méthodes agiles Partie 1 : La société Altran Altran
Plus en détailLes méthodes agiles UM2 2011-2012. 2011-2012 Les méthodes agiles S. Mathon
Les méthodes agiles UM2 2011-2012 1 2 Sommaire Introduction L origine des Méthodes Agiles Le déroulement d un projet Scrum Au démarrage d une version Au démarrage d une itération/sprint Le déroulement
Plus en détailXP : ce célèbre inconnu
XP : ce célèbre inconnu Extreme Programming Thierry Cros http://etre-agile.com 1 XP : plus qu'agile Pourquoi XP Installer XP Rôles et Cycle de Vie Pratiques : Coder et livrer Développement Responsable
Plus en détailREX Scrum Master du terrain
REX Scrum Master du terrain Ludovic Larché Agile Tour 2012 à Rennes le 4 octobre 2012 Qui suis je? Ludovic LARCHE Agile Scrum / Kanban Consultant Scrum Master depuis 2008 Accompagnement de Product Owner
Plus en détailCritères de choix pour la
LIVRE BLANC Critères de choix pour la mise en œuvre d un CRM Un guide pas à pas pour sélectionner le bonpartenaire d intégration de CRM adapté à vosbesoins. INTRODUCTION Vous avez fait votre travail, recherché,
Plus en détailFormation pour Product Owner
2 jours +33 6 08 34 63 55 laurent@morisseauconsulting.com SARL unipersonnelle au capital de 3500 - N SIRET : 508 068 590 00019 Code APE 6202A Sommaire 1 Contexte de la formation... 3 2 Le formateur...
Plus en détailExtrait du site de l'oseo (ex.anvar) http://www.anvar.fr/projlanc.htm. Reste à déterminer les points incontournables
Extrait du site de l'oseo (ex.anvar) http://www.anvar.fr/projlanc.htm Notez que vous trouverez les fiches citées à chaque étape sur le site (Normalement, les liens ont été conservés et fonctionnent) Reste
Plus en détailCHAPITRE 3 : LES METHODES AGILES?
CHAPITRE 3 : LES METHODES AGILES? UE Gestion de Projet Master 1 STIC 2014/2015 Céline Joiron 2 Introduction Après avoir présenté les cycles de vie «classiques» de la gestion de projet L objectif de ce
Plus en détailLES tests d'acceptation
dans la série : b.d. agile! Idée et dessins par Anis berejeb : www.berejeb.com LES tests d'acceptation reflexions, experimentations... réussites et échecs... apprentissage et amelioration. à Partager avec
Plus en détailEn outre 2 PDD sont impliqués dans le développement de politiques locales destinées à favoriser l'insertion des personnes handicapées.
PHOES Version : 2.0 - ACT id : 3813 - Round: 2 Raisons et Objectifs Programme de travail et méthodologie Dispositions financières Dispositions organisationnelles et mécanismes décisionnels Procédures de
Plus en détailCINEMATIQUE DE FICHIERS
ANDRE ANTHONY BRUNEAU Vincent JOUANNIN ROMAIN MAZEAUD MARINE RIOCHET Tony Groupe 609 CINEMATIQUE DE FICHIERS Mini-projet: Gestion de Ventes d'articles Enseignant: MONCEAUX Laura Année 2011 / 2012 TABLE
Plus en détailERP open source une solution pour les entreprises. 17/02/2010 Page: 1
ERP open source une solution pour les entreprises 17/02/2010 Page: 1 Sommaire Définition d'un ERP Les grands modules d'un ERP Retour sur investissement Les avantages d'un ERP open source Ou peut on envisager
Plus en détailAlignement avec les métiers par le test fonctionnel et d acceptation en projets agiles
Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles Laurent PY CEO, Smartesting Laurent.py@smartesting.com @py_laurent www.smartesting.com Guillaume Coquelle Testeur,
Plus en détailConseil opérationnel en organisation, processus & système d Information. «Valorisation, Protection et Innovation de votre Patrimoine Numérique»
"Innovation, Valorisation et Protection du Patrimoine Numérique!" Conseil opérationnel en organisation, processus & système d Information «Valorisation, Protection et Innovation de votre Patrimoine Numérique»
Plus en détailLes mécanismes d'assurance et de contrôle de la qualité dans un
Les mécanismes d'assurance et de contrôle de la qualité dans un projet Agile SPIN de Montréal - ETS 5 mars 2012 Qui sommes nous? mathieu boisvert Coach Agile Chargé de cours Co auteur d un livre avec Sylvie
Plus en détailIntroduc)on à l Agile
Introduc)on à l Agile 1 D où je viens Études M2 info : Paris Diderot (2009) MS Management de Projets Technologiques : ESSEC / Telecom Paris (2010) Aujourd hui Consultant à OCTO Technology (Conseil en SI)
Plus en détailGestion de Projet Agile
Gestion de Projet Agile Planification et Estimation Sprint 0 Tianxiao.Liu@u-cergy.fr Université de Cergy-Pontoise Master SIC/ISIM 2 ième Année Plan Introduction Motivation : pourquoi planifier & estimer?
Plus en détailConservatoire national des arts et métiers - Centre de Marne la Vallée L'ITIL : Un référentiel pour la qualité des systèmes d'information
Conservatoire national des arts et métiers - Centre de Marne la Vallée L'ITIL : Un référentiel pour la qualité des systèmes d'information Mémoire d'examen probatoire en informatique soutenu le vendredi
Plus en détailConduite et Gestion de Projet - Cahier des charges
Conduite et Gestion de Projet - Cahier des charges 1 Introduction Sophie Toulouse LIPN - Université Paris 13 +33.1.49.40.40.73 99 av. Jean-Baptiste Clément toulouse@lipn.univ-paris13.fr 93430 Villetaneuse
Plus en détailINF2015 Développement de logiciels dans un environnement Agile. Examen intra 20 février 2014 17:30 à 20:30
Examen intra 20 février 2014 17:30 à 20:30 Nom, prénom : Code permanent : Répondez directement sur le questionnaire. Question #1 5% Quelle influence peut avoir le typage dynamique sur la maintenabilité
Plus en détailFormation Scrum. 2 jours
2 jours +33 6 08 34 63 55 laurent@morisseauconsulting.com SARL unipersonnelle au capital de 3500 - N SIRET : 508 068 590 00019 Code APE 6202A Sommaire 1 Contexte de la formation... 3 2 Le formateur...
Plus en détailDÉVELOPPEMENT INFONUAGIQUE - meilleures pratiques
livre blanc DÉVELOPPEMENT INFONUAGIQUE MEILLEURES PRATIQUES ET APPLICATIONS DE SOUTIEN DÉVELOPPEMENT INFONUAGIQUE - MEILLEURES PRATIQUES 1 Les solutions infonuagiques sont de plus en plus présentes sur
Plus en détailAPPEL A PROPOSITION ET CAHIER DES CHARGES. Mise en œuvre de la Préparation Opérationnelle à l'emploi Collective
APPEL A PROPOSITION ET CAHIER DES CHARGES Mise en œuvre de la Préparation Opérationnelle à l'emploi Collective POEC CONSULTANT D ENTREPRISE EN PORTAGE SALARIAL Une opération cofinancée par le FPSPP Date
Plus en détailAgile @ Germe Grenoble 4 22/06/2012. Intervenant: Bruno Sbille
Agile @ Germe Grenoble 4 22/06/2012 Intervenant: Bruno Sbille 1 Agile @ Germe 2 Bruno Sbille Blog Agile: http://brunosbille.com Coach & Formateur Blog Coaching Personnel: http://brunosbille.com/coachdevie
Plus en détailArchitecture pragmatique pour la gestion du cycle de vie des applications (ALM)
Architecture pragmatique pour la gestion du cycle de vie des applications (ALM) Concepts Agile appliqués à l architecture et à la conception Jean-Louis Maréchaux jl.marechaux@ca.ibm.com Jean-Louis Maréchaux
Plus en détailEnquête 2014 de rémunération globale sur les emplois en TIC
Enquête 2014 de rémunération globale sur les emplois en TIC Enquête 2014 de rémunération globale sur les emplois en TIC Les emplois repères de cette enquête sont disponibles selon les trois blocs suivants
Plus en détailLe Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer
Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de
Plus en détailPEPI GPI (Gestion de Projet Informatique) - Note de Cadrage décembre 2010 -
I N S T I T U T N A T IO N A L D E L A R E C H E R C H E A G R O N O M I Q U E Pepi Gestion de Projets Informatiques PEPI GPI (Gestion de Projet Informatique) - Note de Cadrage décembre 2010-1 Préambule...
Plus en détailGESTION DE PROJET : LA METHODE AGILE
GESTION DE PROJET : LA METHODE AGILE Le SCRUM est une méthode de gestion de projet. Elle a pour but d améliorer la productivité des équipes. Ce terme est inspiré du terme Scrum en rugby qui désigne une
Plus en détailContact: Yossi Gal, yossi.gal@galyotis.fr, Téléphone: 06 8288-9494
3a-Agiles Gestion de Projet Contact: Yossi Gal, yossi.gal@galyotis.fr, Téléphone: 06 8288-9494 Yossi Gal, Sep/2011 Agiles, Page: 1 Méthodologies Agiles Yossi Gal, Sep/2011 Agiles, Page: 2 Les Méthodes
Plus en détailSEP 2B juin 20. Guide méthodologique de calcul du coût d une prestation
SEP 2B juin 20 12 Guide méthodologique de calcul du coût d une Sommaire Préambule 3 Objectif et démarche 3 1 Les objectifs de la connaissance des coûts 4 2 Définir et identifier une 5 Calculer le coût
Plus en détailITIL V2. La gestion des incidents
ITIL V2 La gestion des incidents Création : novembre 2004 Mise à jour : août 2009 A propos A propos du document Ce document de référence sur le référentiel ITIL a été réalisé en 2004 et la traduction des
Plus en détailLes entreprises qui adoptent les communications unifiées et la collaboration constatent de réels bénéfices
Une étude personnalisée commandée par Cisco Systems Les entreprises qui adoptent les communications unifiées et la collaboration constatent de réels bénéfices Juillet 2013 Déploiement d'une large gamme
Plus en détailLes Méthodes Agiles. description et rapport à la Qualité. Benjamin Joguet Rémi Perrot Guillaume Tourgis
Les Méthodes Agiles description et rapport à la Qualité Benjamin Joguet Rémi Perrot Guillaume Tourgis 1 Plan Présentation générale d'agile Qu'est ce qu'une méthode Agile? Le manifeste Les valeurs Les principes
Plus en détailLe management de projet
Le management de projet Agile SCRUM, extreme Programming, Les certifications PMI PMP, CAPM, PMI-ACP, La maîtrise d ouvrage, les utilisateurs 1 Pourquoi choisir Delf... 3-4 Le management de projet...5 Gérer
Plus en détailFiche méthodologique Rédiger un cahier des charges
Fiche méthodologique Rédiger un cahier des charges Plan de la fiche : 1 : Présentation de la fiche 2 : Introduction : les grands principes 3 : Contenu, 1 : positionnement et objectifs du projet 4 : Contenu,
Plus en détailScrum et itk : adaptation de la méthode au développement d OAD. D après Henrik Kniberg Scrum et XP depuis les tranchées
Scrum et itk : adaptation de la méthode au développement d OAD D après Henrik Kniberg Scrum et XP depuis les tranchées LES MÉTHODES AGILES Méthodes classiques client IKK!! #@??? client IK K Définition
Plus en détailERP5. Gestion des Services Techniques des Collectivités Locales
Gestion des Services Techniques des Collectivités Locales Cte 1 2 P 3 s tio T 4 m ilg h trc c n p.o 5 re u fe ro a le tio c M S tw u aa c e O 2 Relation Citoyen Interventions Patrimoine Core Ressources
Plus en détail