Étude HERMES et agilité

Dimension: px
Commencer à balayer dès la page:

Download "Étude HERMES et agilité"

Transcription

1 Département fédéral des finances Unité de stratégie informatique de la Confédération USIC Étude HERMES et agilité Unité de stratégie informatique de la Confédération USIC Friedheimweg 14 CH-3003 Berne

2 Table des matières 1 Introduction But du présent document HERMES et l agilité Trois éléments de structuration Le principe de l agilité Agilité dans HERMES, à l exemple de Scrum Structure du chapitre Résultats Planification transparente Détection précoce des erreurs au niveau des exigences Répartition des exigences collectées Rôles Répartition claire des rôles dans le développement Démarche Agilité dans HERMES Conclusion /14

3 1 Introduction L agilité est un sujet toujours plus fréquent dans le développement du logiciel. Depuis les débuts du «mouvement Agile», de nombreux auteurs ont présenté des modèles de processus ou de démarche concrétisant les valeurs de base de ce courant de pensée. Quelques-uns de ces modèles sont entièrement nouveaux, d autres résultent de concepts existants, adaptés pour satisfaire au principe de «l agilité». En voici quelques-uns parmi les plus importants: Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), Agile Unified Process (AUP), Open Unified Process (OpenUP). Ces modèles se fondent tous sur le «Manifeste Agile» publié en 2001, dans lequel 17 auteurs ont résumé les valeurs centrales du développement agile de logiciels. Depuis, ce manifeste a été signé par des milliers de personnes. En outre, l application des démarches «agiles» est aujourd hui devenue réalité dans de nombreuses organisations, comme le montrent diverses études de sociétés spécialisées qui se sont penchées sur la question, telles que Gartner 1 ou Forrester 2. L agilité n est donc pas seulement un sujet à la mode, mais aussi une réalité concrète dans l univers de la gestion des projets informatiques. L enthousiasme des utilisateurs envers les démarches agiles 3 et l importante augmentation des taux de réussite dans les projets les appliquant sont autant d arguments en faveur d une confrontation approfondie de ces approches avec HERMES, en tant que méthode de conduite de projet. Les avantages de cette nouvelle manière de considérer un projet informatique devraient aussi profiter aux utilisateurs des méthodes dites «traditionnelles». 2 But du présent document Le but des initiateurs d un projet est toujours de pouvoir mener celui-ci à bon terme. La question principale ne varie pas: comment puis-je améliorer ma démarche afin d augmenter mes chances de succès? Une méthode de conduite de projet est un instrument efficace pour concevoir et optimiser le déroulement d un projet. Les nouveaux concepts apportés par l agilité dégagent un potentiel approprié d extension de la méthode HERMES. Considérant la multitude des méthodes agiles et désireux d utiliser une base méthodologique fondée, nous avons décidé de comparer HERMES essentiellement avec Scrum qui est une méthode agile très répandue aujourd hui et considérée comme particulièrement novatrice 4. Dans ce document, nous nous attacherons d abord à positionner HERMES par rapport à l agilité au niveau de la méthode. L analyse des «Leitmotive», c est-à-dire des principes directeurs de conception dans les deux «univers», permet de faire ressortir les points communs et les différences ainsi que d éliminer certains malentendus. Nous montrerons ensuite que l agilité peut être introduite de manière ciblée dans la méthode HER- MES, notamment si l on y intègre, aux endroits correspondants, les techniques de Scrum ayant fait leurs preuves et que l on adapte en conséquence l aménagement opérationnel des étapes de travail. 1 Par exemple, le document «Agile Success Factors» ( ) de Gartner, écrit par David Norton et Matthew Hottle, mentionne les principaux aspects de l introduction de démarches agiles dans de grandes entreprises. 2 Chez Forrester aussi, on accorde de l importance au principe de «l agilité» comme créateur de valeur, aussi par exemple pour mieux associer la conception de l architecture de la solution avec le processus de développement comme l explique l étude «Balance Architecture and Agility to Sustain Value Delivery» ( ) de Dave West. 3 Voir par exemple : The Agile Impact Report, QSMA Associates, en.wikipedia.org/wiki/scrum_(development) 3/14

4 Comme condition-cadre pour la comparaison concrète, nous partons du principe, dans le présent document, que la conduite de projet est planifiée selon HERMES, mais que les développeurs travaillent avec Scrum. Cela signifie que la planification et l exécution de toutes les autres activités décrites dans HERMES (p. ex. formation, gestion des risques, gestion du projet, etc.) restent nécessaires. Ce document s adresse par conséquent aux responsables ou aux bureaux de projet travaillant avec HERMES, mais souhaitant simultanément une plus grande souplesse de planification, qu ils trouveront dans les méthodes agiles. Pour comprendre les options de solutions proposées ici, le lecteur est supposé avoir des connaissances de base des approches agiles (Scrum ou XP) ainsi que de HERMES. 3 HERMES et l agilité 3.1 Trois éléments de structuration HERMES est considéré comme une méthode «traditionnelle», que l on dit aussi contenir une «abondance de règles», servant à réaliser des systèmes. Ainsi, HERMES est un représentant de «l ancien monde», alors que l agilité ouvre précisément une porte sur un «nouveau monde» en matière de méthodes de développement de systèmes et de logiciels. Ces deux mondes ne peuvent pas être comparés directement, HERMES étant en fin de compte une méthode, alors que l agilité correspond plutôt à une conception, ou à une manière de penser, que l on transpose ensuite dans certaines démarches appelées agiles. Trois éléments de structuration sont au cœur du concept de l agilité: les valeurs agiles, qui sont plutôt des attitudes orientées valeurs, les principes agiles qui en résultent, les pratiques agiles, comme niveau de mise en œuvre des valeurs et des principes. Cette structure sert de cadre de référence pour rapprocher HERMES et l agilité. Profitons-en pour tordre le cou à un malentendu: en effet, contrairement à l opinion bien répandue, il existe aussi dans HERMES un certain nombre de valeurs, dont sont aussi déduits des principes. Ces valeurs et principes sont à la base de la conception de la méthode 5. Ils ne sont toutefois guère connus en dehors du cercle des méthodologues, parce qu ils ne concernent que la «structure interne», ou l architecture, de HERMES en tant que méthode. Seul le résultat de ces «principes de conception», à savoir la méthode elle-même, est visible pour les utilisateurs de HERMES. Citons comme exemple de réalisation de la «compréhensibilité» recherchée les trois points de vue définis dans HERMES («Résultat - Démarche - Rôles») ainsi que leur rôle pour la structure du contenu du manuel. Le Manifeste Agile Figure 1: Comparaison des valeurs Le Manifeste Agile versus les valeurs de HERMES Nous mettrons donc d abord les «valeurs» en évidence. La figure 1 compare les valeurs de l agilité à celles de HERMES. 5 Cela signifie que les valeurs HERMES influencent concrètement la manière de travailler des méthodologues HERMES. Par contre, les attitudes prônées par le «manifeste agile» concernent la manière personnelle de penser des spécialistes développant des logiciels et, ainsi, leur attitude envers les démarches de ce développement dans son ensemble. 4/14

5 Ces valeurs représentent des affirmations de base sur la «manière» d aborder les questions de démarche, telles qu elles sont considérées comme «judicieuses» ou «adéquates» dans l un ou l autre de ces deux «mondes». Les autres niveaux de structuration, à savoir les principes et les pratiques, sont définis à partir des valeurs, tant pour les démarches agiles que pour HERMES. Le tableau ci-dessous montre à quoi servent ces niveaux dans les deux mondes lors de la conception des modèles de démarche: Agilité HERMES Quatre valeurs comme base de la manière de penser Constituent un élément central et sont explicitées volontairement pour favoriser la manière de penser; s adressent à des spécialistes praticiens, qui collaborent dans des équipes de développement. Douze principes comme leitmotive pour des conseils de démarche Guident les spécialistes dans leur travail quotidien de développement et lors de la définition de pratiques; doivent être adaptés en fonction de la situation aux circonstances spécifiques au projet. Pratiques nombreuses, détaillées Représentent le niveau concret de l application et sont les éléments essentiels des méthodes agiles. Niveau des «valeurs» Niveau des «principes» Niveau des «pratiques» Quatre valeurs comme base de la conception de la méthode Sont prises en compte de manière implicite dans la conception de la méthode, afin que l on puisse positionner et diffuser HERMES comme solution globale; s adressent aux méthodologues qui complètent et actualisent HERMES. Huit principes (formulés) comme lignes directrices pour des parties de la méthode Concrétisent les valeurs, afin que des lignes directrices claires existent pour l aménagement et la préparation des différents éléments de la méthode; agissent aussi sur l architecture de la méthode comme principes de structuration. Onze techniques de travail (DS et AS confondus) Plutôt «minces», concernent seulement certains aspects, alors que d autres manquent (p. ex. les techniques de planification). Mentionnons, comme particularité de HERMES, le fait que la méthode est structurée selon une architecture définie. Celle-ci se fonde sur un méta modèle 6 et prescrit les éléments, leur interdépendance et, donc aussi, la structure du contenu de HERMES. Cette architecture est indispensable pour garantir la mise en œuvre des principes de conception, qui se fondent sur les valeurs. Quelques-unes des principales bases des démarches agiles sont résumées dans le chapitre suivant. 3.2 Le principe de l agilité Dans le monde agile, le travail est organisé consciemment de manière à pallier les lacunes les plus connues des projets de développement de logiciels, telles que le manque de flexibilité, de transparence ou de communication. Les trois principes ci-après, qui ont été déduits des valeurs formulées dans le Manifeste Agile, correspondent le mieux au concept de l agilité: 1. L approche empirique: nous saluons les exigences variables, même si elles changent tardivement dans le projet. Les processus agiles permettent aux clients d utiliser les modifications comme avantages concurrentiels. 2. L itération: nous fournissons régulièrement du logiciel qui fonctionne, avec des intervalles allant de quelques semaines à quelques mois, en privilégiant les plus courts. 3. L incrémentation: un logiciel qui fonctionne constitue la mesure primaire de la progression. 6 Le «Software & Systems Process Engineering Meta-model (SPEM), qui est lui-même une norme ouverte de l Object Management Group et met ainsi directement en œuvre les valeurs «ouverture» et «standardisation». 5/14

6 En appliquant ces principes de base, la transparence accrue qui en résulte fait apparaître assez tôt tous les artefacts créateurs de valeur et permet un apprentissage et un feed-back continus. Cela tient compte de la nature empirique des projets logiciels. On travaille par itérations courtes afin de livrer au client, le plus souvent possible, un produit à même de fonctionner. Dans chacune de ces itérations est développé un incrément de produit entièrement fonctionnel. On mesure la valeur fournie au client, et non pas les étapes de travail terminées. Tant que cette valeur n est pas validée par le client, aucun progrès ne peut être comptabilisé. Les connaissances acquises grâce à la transparence accrue et à l inspection s appliquent au produit en cours de développement par l adaptation de ce qui reste à faire (backlog). Les méthodes agiles placent l équipe au centre, et non pas les dirigeants. Le principe classique «command and control» est remplacé par le principe «leadership and collaboration» dans l équipe s organisant elle-même. Celle-ci est en outre interdisciplinaire, ce qui signifie que les développeurs, les analystes commerciaux, les testeurs, etc. collaborent au sein d une seule équipe, de préférence au même endroit, et communiquent constamment. Des voies de communication courtes améliorent la qualité du produit de manière déterminante. En résumé, l agilité peut être décrite de la manière suivante: Ingénierie des bonnes pratiques Développement rapide de logiciels d une grande qualité Processus de gestion de projet Inspection et adaptation fréquentes Philosophie du leadership (leadership philosophy) Encouragement du travail d équipe et promotion de la responsabilité 4 Agilité dans HERMES, à l exemple de Scrum 4.1 Structure du chapitre Pour élaborer ce chapitre, nous nous sommes fondés sur les expériences et les constatations de collaborateurs de l Office fédéral de l informatique et de la télécommunication (OFIT). Ces utilisateurs travaillent tant dans le développement que dans la direction de projet (comme chef de projet côté mandataire). Entre autres, Daniel Stauffer dirige l équipe Architecture et conduite du développement et dispose de bonnes connaissances de la méthode HERMES. Ces spécialistes ont dressé la liste des difficultés usuelles qu ils rencontrent lorsqu ils déterminent le développement avec la direction du projet. Cette liste a été complétée par l ajout des situations problématiques les plus souvent évoquées et thématise les aspects suivants: planification transparente, détection précoce des erreurs, répartition des exigences, planification de la collaboration, partage clair des rôles dans le développement. Nous reprendrons ci-après les éléments de cette liste sous le titre «Situation dans HERMES», en montrant dans quelle mesure HERMES n aborde pas suffisamment ces thèmes. Dans la plupart des cas, quelques adaptations permettraient de trouver des solutions dans HERMES, car cette méthode est très détaillée. Le but est cependant de démontrer, avec l aide d un expert de la méthode agile, comment ces sujets sont traités dans le monde agile et d expliquer brièvement les pratiques pertinentes de Scrum. Nous avons structuré cette comparaison le long des trois points de vue de HERMES par rapport au travail de projet: quels sont les résultats, quels sont les rôles concernés, quelle est la démarche concrète. 6/14

7 4.2 Résultats Planification transparente Situation dans HERMES: planification dans la proposition de projet HERMES prescrit, au début du projet, l établissement d une proposition de projet qui «définit pour chaque projet une situation de départ permettant de décider de la suite des opérations» 7. Ce résultat central de la phase «Initialisation» consigne aussi de premières indications concernant la planification et l organisation du projet, avec également la définition de délais. Cette première planification sommaire est ensuite adaptée au fil du projet, dans le résultat «plan de projet». À cet instant, l estimation est malgré tout approximative. En fait, la seule démarche raisonnable pour la planification consiste à indiquer le temps que l on est prêt à investir dans le projet. Cela signifie que la planification en fonction du souhait est la planification la plus réaliste possible. Cette planification souhaitée représente une partie importante de la proposition de projet et sert de référence temporelle pour le reste du projet. Solution possible avec Scrum: planification flexible L ingénierie du logiciel est empirique, c est-à-dire qu une planification déterministe n est pas possible. Le produit final est un résultat élaboré sur la base d expériences et par essais successifs. Cela rend manifeste que la valeur du plan est très relative, mais que le processus de planification est d une grande importance. Ce processus doit servir de soutien à une démarche de recherche de solution pour obtenir le plus efficacement possible le produit final dont on a besoin. Que signifie «dont on a besoin»? Entre la solution souhaitée et la solution dont on a réellement besoin existe souvent une grande différence, qui est due à une mauvaise compréhension initiale. Si cette compréhension n est pas sans cesse affinée, ou «mieux focalisée», le développement correct du produit souhaité peut finalement malgré tout aboutir à un produit inadéquat. Cela signifie précisément qu un bonne démarche de recherche (de solution) doit être appliquée pour soutenir le processus de planification. La figure 2 montre un plan initial, dans un domaine de solutions possibles pour la «vision du produit». Après chaque itération, ce plan est adapté en fonction des nouvelles connaissances et informations acquises. Le but est de fournir le produit satisfaisant les besoins véritables en concordance avec la vision initiale. Ou autrement dit: s approcher continuellement du véritable but du projet en comprenant pas à pas plus clairement quel est ce but. Ce processus de recherche, justement, ne peut aboutir que si le processus permet un plan «apprenant» et qui se modifie, c est-à-dire un plan «agile», qui puisse être consulté ouvertement et compris par toutes les personnes impliquées dans le projet, afin qu il puisse être amélioré grâce à un feedback permanent. Dans le développement du logiciel, le «Deming cycle» PDCA (Plan - Do - Check - Act) trouve toujours plus d importance. On planifie quelque chose, on l exécute et on vérifie le résultat. Ce feed-back est analysé et les idées d amélioration qui en résultent sont appliquées proactivement dans le prochain cycle. Pour obtenir le plus de feed-back possible, le cycle PDCA est intégré dans des itérations. Cette démarche ouverte et itérative crée de la transparence dans le processus de planification et relativise l importance du plan en tant que tel. 7 HERMES DS, p.183 7/14

8 Figure 2: Du plan initial au résultat Dans la pratique des démarches agiles, diverses techniques ont fait leurs preuves pour le contrôle de la progression. La figure 3 illustre la progression du projet à travers onze itérations, avec finalisation planifiée à l itération 15. La ligne bleue correspond à la charge totale du projet (mesurée en «story points»). Les exigences ont augmenté et ont été adaptées au fur et à mesure, les projections de la planification ont également été actualisées après chaque itération. Lors de l itération 10, les exigences ont été réduites. Malgré cela, il est manifeste que, par la configuration instantanée des exigences, du temps restant et des ressources disponibles, l objectif final ne peut pas être atteint. Grâce à la démarche itérative, cela était déjà prévisible depuis l itération 3. Des mesures de gestion de projet doivent être prises pour corriger cette situation Scope (Story Points) Iterations (Number: End Date) Required to meet target Actuals Original Scope Target Scope Full Availability Projection Figure 3: Progress Tracking Graph 8/14

9 4.2.2 Détection précoce des erreurs au niveau des exigences Qu est-ce qu une erreur? Dans le domaine des marchés régulés, p. ex. en médecine, on parle de vérification et de validation. La validation garantit que ce qui a été spécifié a bien été implémenté et la vérification garantit que l implémentation fonctionne correctement. La cause des erreurs découvertes lors de la vérification peut être identifiée rapidement et elles sont, en règle générale, simples à corriger. Les erreurs découvertes lors de la validation sont plus complexes. Il est possible que l exigence ait été mal comprise, ou alors qu elle soit fausse en tant que telle. Les erreurs de ce genre (erreurs d exigence) ont un très grand impact sur la l utilisabilité et la qualité du produit final. D ordinaire, cellesci ne sont découvertes qu à la fin du développement. Elles sont alors extrêmement chères à corriger et retardent souvent de beaucoup la livraison du logiciel. Selon des études de Barry Boehm 8, les erreurs restant à la fin du développement sont 100 fois plus chères à corriger que si elles avaient été découvertes dans une phase antérieure. Situation dans HERMES: qualité des exigences Le sous-modèle «assurance de la qualité» de HERMES s applique dans toutes les phases. Il prescrit des activités et des résultats ainsi qu un cadre pour les contrôles, la validation et les tests dans le développement d un logiciel. Ce sous-modèle distingue entre les contrôles qui portent sur la qualité des déroulements et les tests qui vérifient la qualité du système. Malgré tout, la qualité des exigences, qui servent ensuite de base pour le plan AS, ne peut pas toujours être évaluée correctement et les erreurs se propagent alors dans tout le projet. Solution possible avec Scrum: gestion itérative des risques Pour réduire le nombre d erreurs et les coûts qui en résultent, il est nécessaire de vérifier et de valider les exigences immédiatement après leur implémentation. Les contrôles et les tests seront effectués à des intervalles plus courts. Les erreurs ainsi trouvées n entraîneront qu une petite charge de travail supplémentaire et permettront aussi une meilleure compréhension du domaine. Ce savoir acquis grâce à la correction des erreurs pourra ensuite être exploité de manière bénéfique dans la suite du projet. Une démarche itérative et incrémentielle, avec vérification et validation dans chaque itération, est donc extrêmement importante. Grâce à elle, les coûts d une correction d erreur dans les phases du projet interviennent chaque fois au point le plus bas de la figure 4, et ils augmentent à chaque nouvelle phase. Cette économie peut être importante. Les projets agiles ne sont normalement pas meilleur marché, mais restent très proches du budget initial. Les explosions de coûts sont rares. Dans le pire des cas, une itération supplémentaire est nécessaire, mais le projet se réoriente ensuite dans la bonne direction. La gestion itérative des risques est la clé de cette évolution positive. Un risque est un événement non prévisible ayant une certaine probabilité de survenue. Plus longtemps le risque existe (plus longue est la période Figure 4 : Coûts de correction après les phases de génération et de suppression de l erreur entrant en ligne de compte), plus grande est la probabilité que l événement survienne. Un risque qui se matérialise induit des surcoûts et des délais supplémentaires pour le projet. Dans un projet linéaire, 8 Barry Boehm : «Modern Tools To Support DoD Software Intensive System Of Systems Cost. Paperback, août /14

10 les véritables risques sont découverts à la fin du projet seulement. Les surcoûts et le temps nécessaire pour pallier ces risques sont alors directement proportionnels à la durée pendant laquelle ceux-ci n ont pas été évalués et, par conséquent, Répartition des exigences collectées Situation dans HERMES : collecte précoce des exigences envers le système Les exigences sont collectées au début du projet et ne sont pas suffisamment remises en question par la suite. Typiquement, les exigences envers le système sont collectées pendant l analyse préliminaire. «Elles sont acceptées tant par le donneur d ordre que par le mandataire du projet comme base de réalisation et de réception du futur système» 9. La période séparant la collecte des exigences du test du produit par le client peut être très grande. Il est possible que les spécifications initiales soient déjà oubliées avant que celui-ci soit de nouveau impliqué. En outre, les conditions-cadres peuvent s être modifiées avant cet instant, ce qui fait que les exigences ne concorderont plus avec la réalité. Solution possible avec Scrum: backlog de produit (Product backlog) Les meilleures connaissances sur le produit à développer ne sont disponibles dans tous les cas qu à la fin du projet. Il s agit d exploiter activement, en tant que plus-value, cette amélioration continue des connaissances. Cela signifie que l on débute consciemment le projet avec des exigences incomplètes, en les affinant et en identifiant de nouvelles au cours du projet. Cependant, pour piloter efficacement le processus de développement, il est nécessaire de disposer, au début du projet, d une vision du produit décrivant clairement et de manière compréhensible l objectif final, tout en laissant consciemment un espace suffisant pour la navigation. Au cours du processus de développement, cet espace sera complété avec les exigences apportant la meilleure plusvalue. La collecte des exigences et la fixation des priorités correspondantes ne s effectuent donc pas au début seulement (up-front), mais en continu, par l intégration précoce du client et d autres experts du domaine. Ainsi, des découvertes importantes peuvent encore être prises en compte même très tard dans le projet. De telles constatations apportent souvent la meilleure plus-value et sont importantes pour la réussite du projet. Figure 5: Backlog de produit: catalogue des exigences avec itérations Le catalogue complet des exigences peut donc être adapté ou même remplacé, en fonction des besoins, après chaque itération grâce au feed-back de l incrément de produit qui en résulte. Cette manière de procéder offre aussi l avantage que seules les exigences qui seront réellement implémentées seront spécifiées de manière complète. Cette réduction de la charge par une diminution du travail nécessaire permet de se concentrer sur les détails vraiment importants et crée une efficience accrue. 9 HERMES DS, p /14

11 La figure 5 montre le catalogue complet des exigences pour une itération donnée. Les exigences implémentées de manière complète sont représentées en vert. Les exigences en cours d implémentation sont en orange. On remarque aussi que le catalogue des exigences se modifie par suppression, modification ou ajout. Le volume total du projet (backlog) reste le même. Si une extension du projet devient nécessaire, le temps supplémentaire requis peut être évalué facilement d après la performance déjà connue. 4.3 Rôles Répartition claire des rôles dans le développement Situation dans HERMES: responsabilités dans la phase de développement Dans HERMES, les rôles sont décrits de manière très complète et sont souvent cités comme constituant un avantage essentiel. Toutefois, les rôles de HERMES ne fixent pas les responsabilités dans la phase de pur développement du projet, ce qui peut entraîner une légère sous-représentation du client. Il peut en résulter des erreurs dont la responsabilité n est pas clairement définie. Solution possible avec Scrum: propriétaire du produit Le «propriétaire du produit» (Product Owner, PO), qui est souvent une personne du marketing ou un expert de l application, se charge de fixer les priorités du backlog de produit et de l actualiser. L équipe Scrum prend, dans le backlog où les priorités sont fixées, toutes les user stories (histoires d utilisateurs) pour lesquelles elle peut réaliser le développement correspondant dans le prochain sprint. Ces éléments forment ce que l on appelle le backlog de sprint. Il est important que le PO soit une seule et même personne. Il peut ou doit s entretenir avec d autres parties prenantes. Dans l administration fédérale, le côté client pourrait être représenté par le chef de projet BP. Ce dernier décidera qui l assiste dans sa tâche et fera appel aux personnes appropriées, p. ex. l analyste des affaires ou le responsable des processus d affaires. Solution possible avec Scrum: le maître de Scrum Le maître de Scrum (Scrum Master) est responsable de faire respecter par son équipe les règles définies dans Scrum en ce qui concerne les droits et les obligations. Le maître de Scrum protège son équipe et s assure qu elle ne fasse pas trop de promesses pour un sprint. Le maître de Scrum organise toutes les réunions et élimine tous les obstacles préjudiciables au développement. Le rôle de maître de Scrum est usuellement occupé par un chef de projet ou par un responsable technique. Toutefois, chacun peut remplir ce rôle. Solution possible avec Scrum: l équipe Scrum L équipe Scrum (Scrum Team) est interdisciplinaire, c est-à-dire que développeurs, testeurs et autres spécialistes y collaborent pour atteindre l objectif du sprint. Usuellement, une équipe Scrum se compose de neuf (± deux) personnes. Si cela ne suffit pas pour un projet, on formera plusieurs équipes Scrum qui collaboreront via un Scrum de Scrums. Solution possible avec Scrum: les réunions (Scrum meetings) Dans Scrum, les réunions sont de très bons instruments pour améliorer la collaboration entre les développeurs et les utilisateurs. Planification de sprint Le propriétaire du produit, le maître de Scrum et l équipe participent à la réunion de planification du sprint. D autres personnes peuvent aussi y être invitées si nécessaire. Pendant la réunion, le propriétaire du produit décrit les principales fonctionnalités de celui-ci. L équipe a alors l occasion de poser des questions, afin de tout comprendre clairement. La réunion se termine quand l équipe est sûre d avoir rempli la capacité disponible avec les fonctionnalités à développer. De même, elle définit un objectif de validité générale pour le sprint, sur la base duquel on décidera si celui-ci est couronné de succès. Scrum quotidien (Daily Scrum) Le Scrum quotidien est une rencontre brève et informelle de l équipe. Elle ne devrait pas durer plus de 15 minutes et se passe debout devant le tableau des tâches (taskboard). Chaque participant répond aux trois questions suivantes. 1. Qu ai-je fait hier, 2. Que fais-je aujourd hui et 3. Y a-t-il quelque chose qui bloque ma progression. Le maître de Scrum actualise le tableau des tâches et se charge ensuite d éliminer les blocages. 11/14

12 Revue A la fin du sprint, le résultat est présenté au propriétaire du produit et aux autres parties prenantes. Cette réunion est informelle et concerne essentiellement les nouvelles fonctionnalités. C est pourquoi on ne devrait pas y utiliser de présentation Powerpoint. On y décide si l objectif du sprint, fixé lors de la planification du sprint, a été atteint et quelles fonctionnalités peuvent être acceptées. Rétrospective Lors de la rétrospective, les expériences découlant du dernier sprint sont discutées par l équipe et le maître de Scrum et on élabore les bases qui permettront de mieux procéder lors du prochain sprint. Aucun membre de la direction ne peut participer à cette réunion. 4.4 Démarche Agilité dans HERMES Situation dans HERMES: planification au sein de la phase de développement Dans une certaine mesure, le concept de l agilité est déjà contenu dans toute la démarche selon HERMES, et cela parce que tous les résultats se développent au fur et à mesure de l évolution du projet. Par exemple, le plan de projet est remanié et adapté aux besoins dans chaque phase. Les phases elles-mêmes ainsi que les activités doivent être répétées jusqu à ce que l objectif soit atteint. Toutefois, il n est prévu, dans le développement, aucune autre référence de planification que le rapport de projet, qui sert à faire périodiquement le point sur la progression du projet. En outre, la phase Introduction est très critique et comporte un risque élevé. Solution possible avec Scrum: intégrer l agilité dans HERMES On peut représenter les phases de HERMES en utilisant Scrum, si l on mesure la progression du projet non plus à l exécution de certaines activités dans les phases, mais aux exigences implémentées de manière complète, testées et acceptées par le client. Il ne faut toutefois pas supprimer toutes les phases, car l initialisation ou l analyse préliminaire peuvent fortement contribuer à la recherche de la vision. La liaison entre HERMES et Scrum est représentée à la figure 6. D abord, les phases Conception, Réalisation et Introduction sont réunies en une seule phase appelée Développement agile, qui se base sur le processus agile de Scrum. Ainsi, les restrictions dues à la séquence de ces phases disparaissent et des étapes de travail peuvent être exécutées à partir de n importe quelle phase, à chaque instant, de manière incrémentielle et itérative. Pour qu ils puissent être livrés, les résultats des phases HERMES sont intégrés dans la liste des tâches (qui est ici le backlog de produit). Cela signifie que les documents, les remises ou les autres activités sont couverts par des user stories. Comme la partie non encore traitée du backlog de produit peut être modifiée à tout instant, les «user stories des phases» (représentées en noir) se voient attribuer des priorités au bon moment dans le sprint qui convient. Le backlog de produit est disponible dès que l analyse préliminaire est terminée. A cet instant, il constitue la solution souhaitée, correspondant à la vision initiale, mais peut être adapté à volonté au fil des nouvelles constatations. Dans les premiers sprints ou itérations, on développe essentiellement l architecture, en plus des souhaits du client, afin de tenir compte des exigences non techniques (non functional requirements, NFR). Quand l architecture est stable et fiable, on peut clore la phase «Conception». 12/14

13 Figure 6: HERMES pour la conduite de projet Scrum pour le développement Une fois la phase «Conception» close, HERMES prévoit le passage à la réalisation. C est ici que l agilité joue le plus grand rôle, car c est dans cette phase que l on crée le plus de valeur. Grâce à la démarche itérative et incrémentielle, le processus de recherche de la solution se déroule sous la conduite du client. Celui-ci peut modifier à volonté le backlog de produit, de manière à disposer à la fin du meilleur produit possible, avec la plus-value maximale, tout à fait dans la ligne de l inspection et de l adaptation. Les phase HERMES «Conception», «Réalisation» et «Introduction» sont fusionnées pour permettre la réalisation de sprint au niveau du développement. Grâce au test continu en parallèle et à l intégration constante des composantes du produit, l introduction de ce dernier est théoriquement possible, selon Scrum, à tout instant. Le plus souvent, certains protocoles doivent toutefois être suivis et la documentation HERMES doit être livrée, ce qui peut être traité à cet endroit. Sur le plan conceptuel, les phases sont très judicieuses, mais apportent peu de garantie au succès du projet. Elles présentent plutôt un désavantage pour un travail qui imbrique les étapes et favorise les feed-backs pour adapter le résultat. Chacun des sprints constitue une étape de développement complète, avec des exigences, une analyse, une conception, une implémentation, un test et un déploiement ainsi que la fourniture d un incrément de produit opérationnel. Toutefois, les activités transversales liées à la gestion de projet (formation, gestion des tests, gestion des processus organisationnels,..) restent nécessaires et elles se déroulent en parallèle au développement informatique selon la démarche prévue par HERMES. 13/14

14 5 Conclusion Nous avons montré que la méthode HERMES et le concept de l agilité se complètent bien. Ainsi, on peut, d une certaine manière, prendre le meilleur de chacun des deux mondes; d une part, le développement bien documenté d un produit final et, d autre part, une flexibilité permettant de satisfaire de manière optimale les besoins du client. La force de HERMES réside dans la gestion du projet dans son ensemble, alors que Scrum s applique surtout au développement de logiciel proprement dit. Le point de vue de Scrum Scrum est une méthode qui doit être appliquée de manière très systématique. Si une équipe de développement décide d appliquer Scrum, chacun de ses membres doit s engager entièrement et des réunions Scrums quotidiennes (Daily Scrums), par exemple, doivent être tenues même si elles ne durent que trois minutes. La méthode fonctionne comme un système complet, dans lequel la réussite du projet dépend de tous les éléments. C est pourquoi une solution intermédiaire, combinant Scrum et HERMES, n est pas souhaitable selon la philosophie de Scrum. Le point de vue de HERMES La méthode HERMES, grâce au tailoring, est plutôt souple dans son application concrète. En conséquence, reprendre les pratiques de Scrum qui ont fait leurs preuves ne pose aucun problème pour HERMES. Ces pratiques peuvent être documentées et appliquées comme techniques de travail dans le déroulement du projet, sans que la base méthodologique ne soit influencée. Pour ne pas affaiblir la méthode, nous n avons consciemment introduit Scrum que pour les processus de pur développement de HERMES (voir chap. 4.2). Les autres comparaisons ne doivent être considérées que comme des incitations à la réflexion. Par conséquent, dans le modèle proposé ici, le développement informatique est réalisé selon Scrum, alors que le chef de projet gère son projet d après HERMES. Cette première étude vise à mettre en évidence les différences entre les deux méthodes, mais doit aussi servir d incitation à combiner les deux tendances. Elle sera utilisée comme base pour poursuivre le développement de la méthode HERMES, mais en continuant d affiner les constatations qu elle présente. 14/14

Développement itératif, évolutif et agile

Dé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étail

backlog du produit Product Owner

backlog 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étail

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Mars 2012 Pas à pas vers de bonnes exigences

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Mars 2012 Pas à pas vers de bonnes exigences Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 OutsourcINg Pas à pas vers de bonnes exigences Outsourcing 10 11 Pas à pas vers de bonnes

Plus en détail

Guide pour la réalisation de projets de cyberadministration

Guide pour la réalisation de projets de cyberadministration Comment Guide pour la réalisation de projets de cyberadministration dans les communes Six étapes pour réussir les projets de cyberadministration dans des petites et moyennes communes avec la méthode de

Plus en détail

Conduite 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 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étail

SCRUM en Bref. Système comprend trois sous-systèmes:a,b,c. S-Système A S-Système B S-Système C A1, B1, C2 A2, C1, A3 B2 B3 C3

SCRUM en Bref. Système comprend trois sous-systèmes:a,b,c. S-Système A S-Système B S-Système C A1, B1, C2 A2, C1, A3 B2 B3 C3 Rappels : étapes de développement de systèmes: 1. Étude des besoins 2. Analyse 3. conception 4. Implémentation 5. Test 6. Déploiement Planification Post-Mortem Système comprend trois sous-systèmes:a,b,c

Plus en détail

Fiche Contenu 18-1 : Exigences organisationnelles pour un système de gestion de la qualité

Fiche Contenu 18-1 : Exigences organisationnelles pour un système de gestion de la qualité Fiche Contenu 18-1 : Exigences organisationnelles pour un système de gestion de la qualité Définition Le terme organisation dans le contexte d un modèle de gestion de la qualité est utilisé pour indiquer

Plus en détail

1 PROCESSUS DE DEVELOPPEMENT : METHODOLOGIE SCRUM

1 PROCESSUS DE DEVELOPPEMENT : METHODOLOGIE SCRUM 1 PROCESSUS DE DEVELOPPEMENT : METHODOLOGIE SCRUM Scrum est une méthode agile pour la gestion de projets informatiques. C est une méthode itérative basée sur des itérations de courte durée appelées Sprints.

Plus en détail

Gestion de projet agile

Gestion de projet agile Véronique M e s s a g e r R o t a Préface de Jean T a b a k a Gestion de projet agile 3 e édition Groupe Eyrolles, 2007, 2009, 2010, ISBN : 978-2-212-12750-8 C Glossaire Backlog (product ou iteration ou

Plus en détail

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM

Topologie 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étail

Architecture pragmatique pour la gestion du cycle de vie des applications (ALM)

Architecture 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étail

HERMES 5.1. Méthode de gestion pour tous les projets MANUEL POUR MANAGER

HERMES 5.1. Méthode de gestion pour tous les projets MANUEL POUR MANAGER HERMES 5.1 Méthode de gestion pour tous les projets MANUEL POUR MANAGER ManagerHERMES_FR.indd 1 20.05.15 12:05 ManagerHERMES_FR.indd 2 20.05.15 12:05 «Ce qui dure, c est le changement» (Michael Richter,

Plus en détail

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS Méthode de tests MODE D EMPLOI Cette première partie est destinée à ceux qui débutent en tests et permet une approche progressive et simple de la méthodologie des tests. L introduction vous aura permis

Plus en détail

GESTION DE PROJET : LA METHODE AGILE

GESTION 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étail

25/12/2012 www.toubkalit.ma

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étail

Conseils pour l évaluation et l attribution de la note

Conseils pour l évaluation et l attribution de la note Entreprise formatrice Candidat/-e Téléphone: Téléphone: Ce document ne doit en aucun cas être montré au candidat après l attribution des points. Conseils pour l évaluation et l attribution de la note Documentation

Plus en détail

Eclipse Process Framework et Telelogic Harmony/ITSW

Eclipse Process Framework et Telelogic Harmony/ITSW Eclipse Process Framework et Telelogic Harmony/ITSW Boris Baldassari 1 Résumé Une introduction à Eclipse Process Framework (EPF) et au processus OpenUP, et comment tirer profit de ces initiatives dans

Plus en détail

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL 31 août 2004 Plate-Forme Opérationnelle de modélisation INRA ACTA ICTA http://www.modelia.org FICHE DU DOCUMENT 10 mai 04 N.Rousse - : Création : version de

Plus en détail

Une méthode de Gestion de projet SCRUM

Une méthode de Gestion de projet SCRUM Une méthode de Gestion de projet SCRUM PRÉSENTÉ PAR KAHINA BERKANI LUDOVIC BERUTTI LUDOVIC DEVILLERS ALEXANDRE GIORDANENGO M2 MIAGE Gestion de projet Sous la direction de Monsieur WINTER Introduction Plan

Plus en détail

Le livre de travail peut être élaboré sur Word et être complété par des photos et des graphiques

Le livre de travail peut être élaboré sur Word et être complété par des photos et des graphiques Employé/employée de commerce CFC Branche logistique et transports internationaux Le livre de travail Le livre de travail est un classeur avec les registres suivants (proposition): 1. Base de la logistique

Plus en détail

Pratique de logiciels de planification

Pratique de logiciels de planification Pratique de logiciels de planification MASTER TECHNOLOGIE & HANDICAP Université Paris 8 Sommaire Introduction Organisation d un projet Les principaux axes de la planification Gestion des tâches Gestion

Plus en détail

Experience N 52. Les expériences d ERNI dans l univers du management, des processus et des technologies. Mars 2012

Experience N 52. Les expériences d ERNI dans l univers du management, des processus et des technologies. Mars 2012 Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 MIGRATIONS Garder la maîtrise lors de migrations GARdER la maîtrise LORS de migrations Lors

Plus en détail

la phase exploratoire

la phase exploratoire V 1.00 la phase exploratoire élément facilitateur dans la réussite d un projet Agile A. MORVANT IT&L@BS Coach Agile aurelien.morvant@orange-ftgroup.com Page 1 Page 2 objet de la session > introduire la

Plus en détail

Méthodes Agiles et gestion de projets

Mé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étail

Agilitéet qualité logicielle: une mutation enmarche

Agilitéet qualité logicielle: une mutation enmarche Agilitéet qualité logicielle: une mutation enmarche Jean-Paul SUBRA Introduction : le manifeste Agile Manifeste pour le développement Agile de logiciels Nous découvrons comment mieux développer des logiciels

Plus en détail

pratiques. Nous avons abondamment illustré l'application correcte et efficace des nombreuses pratiques en assurance qualité par des cas pratiques.

pratiques. Nous avons abondamment illustré l'application correcte et efficace des nombreuses pratiques en assurance qualité par des cas pratiques. Cet ouvrage s inscrit dans le cadre d une problématique globale portant sur l amélioration de la qualité du logiciel pour des organismes qui ont atteint un certain niveau de maturité. Il cherche à rapprocher

Plus en détail

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Projet Informatique Philippe Collet Licence 3 Informatique S5 2014-2015 http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Réalisation d'un développement de taille conséquente? r Firefox? Ph.

Plus en détail

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Toucher juste. Mars 2012

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Toucher juste. Mars 2012 Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 RequIREments EngINEERINg Toucher juste TouchER juste L ingénierie des exigences: les bases

Plus en détail

ISTQB Agile Tester en quelques mots ISTQB Marketing Working Group

ISTQB Agile Tester en quelques mots ISTQB Marketing Working Group ISTQB Agile Tester en quelques mots ISTQB Marketing Working Group Mai 2014 Qu est-ce que l ISTQB? ISTQB : International Software Testing Qualifications Board (www.istqb.org): Association sans but lucratif

Plus en détail

CERTIFICATION Professional Scrum Developer (.NET)

CERTIFICATION Professional Scrum Developer (.NET) Durée 5 jours Description Le cours «Professional Scrum Developer» de Pyxis offre une expérience intensive unique aux développeurs de logiciels. Ce cours guide les équipes sur la façon de transformer les

Plus en détail

CONSEIL STRATÉGIQUE. Services professionnels. En bref

CONSEIL STRATÉGIQUE. Services professionnels. En bref Services professionnels CONSEIL STRATÉGIQUE En bref La bonne information, au bon moment, au bon endroit par l arrimage des technologies appropriées et des meilleures pratiques. Des solutions modernes adaptées

Plus en détail

MANDAT DU CONSEIL D ADMINISTRATION Approuvé par le conseil d administration le 13 novembre 2014

MANDAT DU CONSEIL D ADMINISTRATION Approuvé par le conseil d administration le 13 novembre 2014 OFFICE D INVESTISSEMENT DES RÉGIMES DE PENSION («INVESTISSEMENTS PSP») Approuvé par le conseil d administration le 13 novembre 2014 13 novembre 2014 PSP-Legal 1633578-1 Page 2 INTRODUCTION Le conseil d

Plus en détail

Services Professionnels Centre de Contacts Mitel

Services Professionnels Centre de Contacts Mitel Services Professionnels Centre de Contacts Mitel Débutez un voyage vers la modernisation et l évolutivité : Elevez le niveau de votre performance commerciale Pour moderniser votre centre de contact : Passez

Plus en détail

Livre Blanc. Optimiser la gestion et le pilotage des opérations. Août 2010

Livre Blanc. Optimiser la gestion et le pilotage des opérations. Août 2010 Livre Blanc Optimiser la gestion et le pilotage des opérations Août 2010 Un livre blanc édité par : NQI - Network Quality Intelligence Tél. : +33 4 92 96 24 90 E-mail : info@nqicorp.com Web : http://www.nqicorp.com

Plus en détail

Reddition de compte et Agilité. Présenté par Jean-René Rousseau Agile Québec Septembre 2011

Reddition de compte et Agilité. Présenté par Jean-René Rousseau Agile Québec Septembre 2011 Reddition de compte et Agilité Présenté par Jean-René Rousseau Agile Québec Septembre 2011 Qui suis-je Jean-René Rousseau jrrousseau@pyxis-tech.com Coach Agile à Pyxis www.pyxis-tech.com/accompagnement

Plus en détail

Le tableau de bord de la DSI : un outil pour mieux piloter son informatique.

Le tableau de bord de la DSI : un outil pour mieux piloter son informatique. Le tableau de bord de la DSI : un outil pour mieux piloter son informatique. Introduction Face à l évolution constante des besoins fonctionnels et des outils informatiques, il est devenu essentiel pour

Plus en détail

Conduite de projets agiles Management alternatif dans une équipe de développement agile

Conduite de projets agiles Management alternatif dans une équipe de développement agile Contexte 1. Introduction 11 2. Enjeu de Talentsoft 13 3. Objectifs de Talentsoft 17 4. L agilité comme remède miracle 18 4.1 Mise en place de l agile 18 4.2 Les problématiques actuelles 19 5. La solution

Plus en détail

Les principes et les thèmes PRINCE2

Les principes et les thèmes PRINCE2 31 Chapitre 3 Les principes et les thèmes PRINCE2 1. Les principes de la méthode PRINCE2 Les principes et les thèmes PRINCE2 Les principes de la méthode PRINCE2 définissent un cadre de bonnes pratiques

Plus en détail

Mise en place des sprints

Mise en place des sprints 101 Chapitre 4 Mise en place des sprints 1. Introduction Mise en place des sprints Afin de parvenir à une mise en place efficace de ses sprints, l équipe doit prendre en compte divers facteurs, qui vont

Plus en détail

Développement agile. Agile Manifesto. Développement agile Hafedh Mili 2012

Développement agile. Agile Manifesto. Développement agile Hafedh Mili 2012 Développement agile Hafedh Mili 2012 1 Développement agile Un ensemble de pratiques de développement logiciel qui mettent l'emphase sur: Le pragmatisme (vs dogmatise) La réactivité aux changements L'implication

Plus en détail

DEPARTEMENT D ETUDES EUROPEENNES ECONOMIQUES

DEPARTEMENT D ETUDES EUROPEENNES ECONOMIQUES DEPARTEMENT D ETUDES EUROPEENNES ECONOMIQUES GUIDE DES ETUDIANTS Ce guide est destiné à vous introduire au fonctionnement du Collège et du Département d études économiques européennes, en présentant les

Plus en détail

Pédagogie du projet?

Pédagogie du projet? Pédagogie du projet? Toute pédagogie qui place l intérêt des apprenants comme levier des conduites éducatives est appelée «pédagogie fonctionnelle». Ainsi, la pédagogie du projet peut rentrer dans cette

Plus en détail

Module 191 Conduire un projet partiel

Module 191 Conduire un projet partiel Page garde sur Canon : désactiver l option «utiliser les polices de l imprimante» sous Qualité, Détails. Module 191 Conduire un projet partiel Copyright IDEC 2008. Reproduction interdite. IDEC 2002-2006.

Plus en détail

Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES

Yassine 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étail

Livre Blanc Oracle Juin 2009. Gérer avec succès les risques des contrats pour établir une relation «gagnant-gagnant»

Livre Blanc Oracle Juin 2009. Gérer avec succès les risques des contrats pour établir une relation «gagnant-gagnant» Livre Blanc Oracle Juin 2009 Gérer avec succès les risques des contrats pour établir une relation «gagnant-gagnant» Préambule Ce livre blanc met en avant certains risques impliqués dans les travaux liés

Plus en détail

LES ORIGINES D ITIL Origine gouvernementale britannique 20 ans d existence et d expérience Les organisations gérant le référentiel :

LES ORIGINES D ITIL Origine gouvernementale britannique 20 ans d existence et d expérience Les organisations gérant le référentiel : La méthode ITIL plan Introduction C est quoi ITIL? Utilisation d ITIL Objectifs Les principes d ITIL Domaines couverts par ITIL Les trois versions d ITIL Pourquoi ITIL a-t-il tant de succès Inconvénients

Plus en détail

Méthode Agile de 3 ème génération. 2008 J-P Vickoff

Mé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étail

Qui est concerné par la qualité des données?

Qui est concerné par la qualité des données? INTRODUCTION Qui est concerné par la qualité des données? Plus que jamais, les entreprises sont confrontées à des marchés de plus en plus exigeants, réclamant une réponse immédiate et adaptée à des besoins

Plus en détail

Brevet + Diplôme fédéraux d Informaticienne / Informaticien

Brevet + Diplôme fédéraux d Informaticienne / Informaticien Brevet + Diplôme fédéraux d Informaticienne / Informaticien F i c h e d i n f o r m a t i o n 01.2008 1/8 Brevet fédéral: profil Développement Domaines de qualification Business Engineering Data Management

Plus en détail

Fiche PM300 - Préparer le planning d un projet. 1.Introduction : un outil en support...2. 2.Première étape : La création des ressources...

Fiche PM300 - Préparer le planning d un projet. 1.Introduction : un outil en support...2. 2.Première étape : La création des ressources... Fiche PM300 - Préparer le planning d un projet Table des matières 1.Introduction : un outil en support...2 2.Première étape : La création des ressources...3 3.Deuxième étape : Le canevas méthodologique

Plus en détail

Scrum 101. Communauté Agile de Sherbrooke M O H A M E D A R E Z K I ( M O A R E Z K I @ G M A I L. C O M ) J A N V I E R 2016

Scrum 101. Communauté Agile de Sherbrooke M O H A M E D A R E Z K I ( M O A R E Z K I @ G M A I L. C O M ) J A N V I E R 2016 Communauté Agile de Sherbrooke Scrum 101 M O H A M E D A R E Z K I ( M O A R E Z K I @ G M A I L. C O M ) J A N V I E R 2016 B L O G S U R A G I L E S H E R B R O O K E : H T T P : / / A G I L E S H E

Plus en détail

RÉSOLUTION 3/2009 MISE EN ŒUVRE DE LA STRATÉGIE DE FINANCEMENT DU TRAITÉ PARTIE I ANNEXE 4 DE LA STRATÉGIE DE FINANCEMENT

RÉSOLUTION 3/2009 MISE EN ŒUVRE DE LA STRATÉGIE DE FINANCEMENT DU TRAITÉ PARTIE I ANNEXE 4 DE LA STRATÉGIE DE FINANCEMENT RÉSOLUTION 3/2009 MISE EN ŒUVRE DE LA STRATÉGIE DE FINANCEMENT DU TRAITÉ L ORGANE DIRECTEUR, PARTIE I ANNEXE 4 DE LA STRATÉGIE DE FINANCEMENT Rappelant que la Stratégie de financement a pour objectifs

Plus en détail

AGILE, chantiers actuels, gestion des forfaits

AGILE, chantiers actuels, gestion des forfaits AGILE, chantiers actuels, gestion des forfaits État de l art et perspectives Jean-Pierre Vickoff On en parle beaucoup aujourd hui et on les pratique de plus en plus, mais les méthodes agiles, ce n est

Plus en détail

INTRODUCTION AUX METHODES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES

INTRODUCTION AUX METHODES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES INTRODUCTION AUX METHODES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et

Plus en détail

Gestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique»

Gestion 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étail

ARIES P O U R L I M P L É M E N TAT I O N R A P I D E D E S Y S T È M E S D E N T R E P R I S E PRÉSENTATION DE LA MÉTHODOLOGIE ARIES

ARIES P O U R L I M P L É M E N TAT I O N R A P I D E D E S Y S T È M E S D E N T R E P R I S E PRÉSENTATION DE LA MÉTHODOLOGIE ARIES ARIES ARCHITECTURE P O U R L I M P L É M E N TAT I O N R A P I D E D E S Y S T È M E S D E N T R E P R I S E PRÉSENTATION DE LA MÉTHODOLOGIE ARIES ARIES est une méthodologie permettant d implémenter rapidement

Plus en détail

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 1: La vision processus dans le management des organisations

Plus en détail

FILIÈRE METHODOLOGIE & PROJET

FILIÈRE METHODOLOGIE & PROJET FILIÈRE METHODOLOGIE & PROJET 109 Gestion de projet METHODOLOGIE ET PROJET Durée 3 jours Conduite de projet COND-PRO s Intégrer les conditions de réussite d une démarche de management par projet. Impliquer

Plus en détail

SOMMAIRE DE LA RÉPONSE DE LA DIRECTION

SOMMAIRE DE LA RÉPONSE DE LA DIRECTION SOMMAIRE DE LA RÉPONSE DE LA DIRECTION Rapport d évaluation final de l Initiative de la nouvelle économie (INÉ) Date : le 17 mars 2010 Programme de l INÉ : contexte Dans le cadre du plan du gouvernement

Plus en détail

Etude de cas. Porter l optimisation au plus haut niveau

Etude de cas. Porter l optimisation au plus haut niveau Etude de cas Porter l optimisation au plus haut niveau Après la mise en oeuvre du Quintiq Company Planner, Vlisco a réduit ses délais de production de 50%. L étape suivante, le déploiement du Scheduler,

Plus en détail

LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS

LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS LIVRE BLANC LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS Une collaboration entre homme et machine LIVRE BLANC LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS 2 A PROPOS Les hommes

Plus en détail

Pour en savoir plus sur le projet initial : www.qualicarte.ch

Pour en savoir plus sur le projet initial : www.qualicarte.ch Le projet QualiCarte a été initié par la Conférence suisse de la formation professionnelle en collaboration avec des organisations suisses du monde du travail, et plus particulièrement l Union suisse des

Plus en détail

De la story aux tests d acceptation

De la story aux tests d acceptation 14 De la story aux tests d acceptation À l occasion d un audit sur le processus de développement d une entreprise, j avais constaté que la documentation relative aux spécifications et aux tests était abondante

Plus en détail

FICHE TECHNIQUE. Le logigramme 1

FICHE TECHNIQUE. Le logigramme 1 FICHE TECHNIQUE Le logigramme 1 Le logigramme est une illustration, sous forme de réseau de symboles, d un processus de décision ou de transformation. Il permet de faire ressortir les étapes, les décisions-clés

Plus en détail

Témoignage client. Optimisation de la performance et gains de productivité

Témoignage client. Optimisation de la performance et gains de productivité Témoignage client Optimisation de la performance et gains de productivité performances Faciliter les revues de La réputation d Imec repose sur la qualité du travail de ses scientifiques, chercheurs, ingénieurs

Plus en détail

Schéma canadien d évaluation et de certification selon les Critères communs (SCCC) Guide-SCCC-006 Version 1.1

Schéma canadien d évaluation et de certification selon les Critères communs (SCCC) Guide-SCCC-006 Version 1.1 6 Schéma canadien d évaluation et de certification selon les Critères communs (SCCC) Guide-SCCC-006 Version 1.1 Contrôle technique de la continuité de l assurance d une TOE certifiée Août 2005 ii Version

Plus en détail

Un engagement envers la gestion exceptionnelle de nos portefeuilles

Un engagement envers la gestion exceptionnelle de nos portefeuilles Les processus de sélection et de surveillance des gestionnaires des portefeuilles de NEI : Un engagement envers la gestion exceptionnelle de nos portefeuilles LES FONDS COMMUNS VUS DIFFÉREMMENT..888.809.

Plus en détail

ORACLE PRIMAVERA PORTFOLIO MANAGEMENT

ORACLE PRIMAVERA PORTFOLIO MANAGEMENT ORACLE PRIMAVERA PORTFOLIO MANAGEMENT FONCTIONNALITÉS GESTION DE PORTEFEUILLE Stratégie d approche permettant de sélectionner les investissements les plus rentables et de créer de la valeur Paramètres

Plus en détail

EXIN Agile Scurm Foundation

EXIN Agile Scurm Foundation Exemple d examen EXIN Agile Scurm Foundation Édition Mars 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étail

Commandez un training TenStep et tirez pleinement partie

Commandez un training TenStep et tirez pleinement partie Commandez un training TenStep et tirez pleinement partie des capacités de votre équipe! TenStep France propose un grand nombre de cours de formation qui peuvent être dispensés aux personnels des compagnies

Plus en détail

UNE SOLUTION CRM CONÇUE POUR LA FORCE DE VENTE

UNE SOLUTION CRM CONÇUE POUR LA FORCE DE VENTE LIVRE BLANC UNE SOLUTION CRM CONÇUE POUR LA FORCE DE VENTE Comment choisir un CRM qui répondra à toutes les attentes de vos commerciaux www.aptean..fr LIVRE BLANC UNE SOLUTION CRM CONÇUE POUR LA FORCE

Plus en détail

BIBLIOTHÈQUE ET ARCHIVES CANADA PLAN D ÉVALUATION 2008-2009

BIBLIOTHÈQUE ET ARCHIVES CANADA PLAN D ÉVALUATION 2008-2009 BIBLIOTHÈQUE ET ARCHIVES CANADA PLAN D ÉVALUATION 2008-2009 Division du rendement et de l information institutionnels Direction générale de la gestion intégrée Présenté au : Comité d évaluation de Bibliothèque

Plus en détail

Plan de formation relatif à l ordonnance sur la formation professionnelle initiale de graphiste CFC Leçons B Resumé par semestre

Plan de formation relatif à l ordonnance sur la formation professionnelle initiale de graphiste CFC Leçons B Resumé par semestre Plan de formation relatif à l ordonnance sur la formation professionnelle initiale de graphiste CFC Leçons B Resumé par semestre 21 javier 2010 Legende Le plan de formation règle obligatoirement les objectifs

Plus en détail

QUATRE ÉLÉMENTS À NE PAS SOUS-ESTIMER DANS LE CONTEXTE D UNE TRANSMISSION D ENTREPRISE

QUATRE ÉLÉMENTS À NE PAS SOUS-ESTIMER DANS LE CONTEXTE D UNE TRANSMISSION D ENTREPRISE QUATRE ÉLÉMENTS À NE PAS SOUS-ESTIMER DANS LE CONTEXTE D UNE TRANSMISSION D ENTREPRISE Table des matières 1. Introduction... 1 2. Développement... 2 2.1. Droit successoral, réserve des héritiers... 2 2.2.

Plus en détail

Bienvenue dans le monde de la construction logicielle

Bienvenue dans le monde de la construction logicielle Chapitre 1 Bienvenue dans le monde de la construction logicielle Sommaire : 1.1 La construction logicielle, qu est-ce que c est? : page 3 1.2 Pourquoi la construction logicielle est-elle importante? :

Plus en détail

Dialogue sur le financement

Dialogue sur le financement CONSEIL EXÉCUTIF EB137/3 Cent trente-septième session 20 mai 2015 Point 5 de l ordre du jour provisoire Dialogue sur le financement Rapport du Secrétariat INTRODUCTION 1. Par la décision WHA66(8), l Assemblée

Plus en détail

3. FORMATION EN MILIEU PROFESSIONNEL INTERNATIONAL

3. FORMATION EN MILIEU PROFESSIONNEL INTERNATIONAL 3. FORMATION EN MILIEU PROFESSIONNEL INTERNATIONAL 3.1. CONCEPT La formation professionnelle doit être envisagée comme un moyen de fournir aux étudiants les connaissances théoriques et pratiques requises

Plus en détail

SEANCE D INFORMATIONS. Stagiaire MP 3+1 BIENVENUE!

SEANCE D INFORMATIONS. Stagiaire MP 3+1 BIENVENUE! SEANCE D INFORMATIONS Stagiaire MP 3+1 BIENVENUE! Programme Accueil Présentation du secrétariat central, Stages en Entreprise MP Branche S&A Questions 27.03.2014 2 Présentation de la Branche S&A La CIFC-JB

Plus en détail

Manuel sur l'etablissement de Systèmes de Gestion Durables des Inventaires Nationaux de Gaz à Effet de Serre

Manuel sur l'etablissement de Systèmes de Gestion Durables des Inventaires Nationaux de Gaz à Effet de Serre GROUPE CONSULTATIF D'EXPERTS SUR LES COMMUNICATIONS NATIONALES EMANANT DES PARTIES NON VISEES A L'ANNEXE I DE LA CONVENTION (GCE) Manuel sur l'etablissement de Systèmes de Gestion Durables des Inventaires

Plus en détail

Chapitre 0 : La gestion du temps Part I

Chapitre 0 : La gestion du temps Part I Chapitre 0 : La gestion du temps Part I I. Quelques citations "Plus on dispose de temps pour faire un travail, plus ce travail prend du temps". (Parkinson) "Quand il est urgent, il est déjà trop tard".

Plus en détail

Scrum + Drupal = Julien Dubois

Scrum + 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étail

L Agilité MODE PASSAGÈRE OU APPROCHE PÉRENNE? Sylvie Trudel. Mise en contexte: les acteurs d un projet logiciel. Cadres: Supervisent

L Agilité MODE PASSAGÈRE OU APPROCHE PÉRENNE? Sylvie Trudel. Mise en contexte: les acteurs d un projet logiciel. Cadres: Supervisent L Agilité MODE PASSAGÈRE OU APPROCHE PÉRENNE? Mise en contexte: les acteurs d un projet logiciel 2 Experts d affaires: Utilisent le service Personnel: Utilisent la solution Cadres: Supervisent Haute direction:

Plus en détail

Le Product Backlog, qu est ce c est?

Le Product Backlog, qu est ce c est? Le Product Backlog, qu est ce c est? Ludovic Larché Agile Tour 2012 à Rennes le 4 octobre 2012 Sommaire > Rappels théoriques : qu est ce qu un Product Backlog? > Le Product Backlog n est pas seul! > Techniques

Plus en détail

Le point sur la méthode SCRUM

Le point sur la méthode SCRUM Le point sur la méthode SCRUM Inspirée du privé et de la gestion des projets informatiques, la méthode SCRUM est devenue de nos jours de plus en plus adoptée dans les équipes de développement. Cette méthode

Plus en détail

LA CERTIFICATION ISO 9001. La charte qualité d HAWORTH

LA CERTIFICATION ISO 9001. La charte qualité d HAWORTH LA CERTIFICATION ISO 9001 La charte qualité d HAWORTH L ENTIERE SATISFACTION DE NOS CLIENTS : 1 ère RESPONSABILITE DE CHACUN Le groupe Haworth s'est engagé dans une démarche Qualité depuis 1991 car la

Plus en détail

DIRECTIVE DU COMMISSAIRE

DIRECTIVE DU COMMISSAIRE DIRECTIVE DU COMMISSAIRE SUJET: PROCESSUS INTERNE DE RÈGLEMENT DES DIFFÉRENDS N O: DC-12 DATE DE PUBLICATION: 10 AVRIL 2013 DATE D ENTRÉE EN VIGUEUR : 2 SEPTEMBRE 2013 INTRODUCTION Le gouvernement du Canada

Plus en détail

Modélisation des Systèmes d Information Jean-Yves Antoine

Modélisation des Systèmes d Information Jean-Yves Antoine Modélisation des Systèmes d Information Jean-Yves Antoine http://www.info.univ-tours.fr/~antoine Processus de développement logiciel Jean-Yves Antoine U. Bretagne Sud - UFR SSI - IUP Vannes année 2001-2002

Plus en détail

Lumesse Avis d expert. Agile Learning Etes-vous prêt au changement?

Lumesse Avis d expert. Agile Learning Etes-vous prêt au changement? Lumesse Avis d expert Agile Learning Etes-vous prêt au changement? Dans l univers sans cesse mouvant de la Gestion des Talents, nous observons un nouveau changement fondamental en matière de développement

Plus en détail

«Quick-Check Asset Management»

«Quick-Check Asset Management» 1 «Quick-Check Asset Management» Audit sur le positionnement des gestionnaires de réseau de distribution en matière de gestion d actifs Septembre 2012 D un régime actuel «Cost +» La plupart des GRD se

Plus en détail

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 4: l approche processus et le management du système d informations

Plus en détail

Certification Scrum Master

Certification 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étail

Gestion de projet. Epreuves. Examen modulaire SVF-ASFC. Durée de l examen: 60 minutes. Moyens auxiliaires autorisés: aucun

Gestion de projet. Epreuves. Examen modulaire SVF-ASFC. Durée de l examen: 60 minutes. Moyens auxiliaires autorisés: aucun Examen modulaire SVF-ASFC Edition Printemps 2009 Gestion de projet Epreuves Durée de l examen: 60 minutes Moyens auxiliaires autorisés: aucun Collez ici votre timbre d identification SVP! Points: Note:

Plus en détail

Jean-Pierre Vickoff. 2008 J-P Vickoff

Jean-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étail

Préparation à la Certification PMI- ACP

Préparation à la Certification PMI- ACP Catégorie :... Certification Durée :... 5 jours / 40 heures Méthode :... Formation Langue :... Dispensé en français ou en anglais, Support en anglais PDU :... 40 Code du cours :... PMIACP05FR Pré- requis

Plus en détail

FORMATION ET QUALITÉS REQUISES DES ADMINISTRATEURS ATTENTES ET MÉTHODOLOGIE D ÉVALUATION DE LA SOAD ET EXEMPLES DE STRATÉGIES DE MISE EN ŒUVRE

FORMATION ET QUALITÉS REQUISES DES ADMINISTRATEURS ATTENTES ET MÉTHODOLOGIE D ÉVALUATION DE LA SOAD ET EXEMPLES DE STRATÉGIES DE MISE EN ŒUVRE AVIS AU SECTEUR Novembre 2012 FORMATION ET QUALITÉS REQUISES DES ADMINISTRATEURS ATTENTES ET MÉTHODOLOGIE D ÉVALUATION DE LA SOAD ET EXEMPLES DE STRATÉGIES DE MISE EN ŒUVRE Objet La Société ontarienne

Plus en détail

L universalité des approches agiles; cycle de vie versus processus et méthodologie

L universalité des approches agiles; cycle de vie versus processus et méthodologie Agile Tour Montréal 2012 L universalité des approches agiles; cycle de vie versus processus et méthodologie Conférencier : Claude Besner, Ph. D., MBA, B. Arch., PMP Ma carte de visite Claude Besner, Ph.

Plus en détail

Principes de management de la qualité

Principes de management de la qualité Principes de management de la qualité Hassen Ammar, consultant formateur en management PLUS CONSEIL: www.plusconseil.net PLUS CONSEIL ISO 9000 Les 8 huit principes de management Principe 1 Orientation

Plus en détail

ISO/IEC 20000-1 versus ITIL

ISO/IEC 20000-1 versus ITIL ISO/IEC 20000- versus ITIL Séminaire du 6 Novembre itsmf OUEST C. LAHURE Axios Systems Ordre du jour ISO / IEC 20000- La Norme et son contexte Le référentiel La démarche d implémentation Le contexte de

Plus en détail

ECOLE SUPERIEURE DE L EDUCATION NATIONALE

ECOLE SUPERIEURE DE L EDUCATION NATIONALE ECOLE SUPERIEURE DE L EDUCATION NATIONALE Formation des Chefs d Etablissement d Affectation Management adaptatif et délégations Support participants SOMMAIRE La formation dans son contexte p.3 Les facteurs

Plus en détail

Rè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 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étail