É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

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

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

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

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

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

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

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

Soyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique

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

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

Processus informatiques de l'administration fédérale Organisation fonctionnelle de l'informatique

Processus informatiques de l'administration fédérale Organisation fonctionnelle de l'informatique Processus informatiques de l'administration fédérale Organisation fonctionnelle de l'informatique Unité de stratégie informatique de la Confédération USIC Friedheimweg 14, 3003 Berne Téléphone 031 32 245

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

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

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

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

AGILITÉ ET PROJETS AVEC SCRUM

AGILITÉ ET PROJETS AVEC SCRUM AGILITÉ ET PROJETS AVEC SCRUM ENSIMAG 2014 Jean-François Jagodzinski @jfjago www.agilessence.fr 1 Jean-François Jagodzinski - Coach Formateur et accompagnateur d équipes agiles Site -> http://www.agilessence.fr

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 DE REFERENCE

HERMES 5.1. Méthode de gestion pour tous les projets MANUEL DE REFERENCE HERMES 5.1 Méthode de gestion pour tous les projets MANUEL DE REFERENCE ÉE PR AP O E CH A E GIL IN R TÉG HERMES EN BREF: Méthode Ce manuel de référence documente la méthode HERMES; il est imprimé et disponible

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

Introduction à l Agile (22/01/2012)

Introduction à l Agile (22/01/2012) Introduction à l Agile (22/01/2012) OCTO 2012 50, avenue des Champs-Elysées 75008 Paris - FRANCE Tél : +33 (0)1 58 56 10 00 Fax : +33 (0)1 58 56 10 01 www.octo.com 1 Plan! Qui suis-je?! Quelques notions

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

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

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

Réinventons la Proximité! L Agilité au service des! Startup innovantes!

Réinventons la Proximité! L Agilité au service des! Startup innovantes! Réinventons la Proximité! L Agilité au service des! Startup innovantes! Thomas Van de Velde http://www.webinage.fr Florent Garin http://www.docdoku.com David Brocard http://davidbrocard.org I - Le contexte

Plus en détail

HERMES pour projets d organisation

HERMES pour projets d organisation Département fédéral des finances DFF Unité de stratégie informatique de la Confédération USIC HERMES pour projets d organisation Un manuel basé sur la méthode HERMES pour la conduite et le déroulement

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

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

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

Les méthodes agiles. Les méthodes agiles sont apparues dans les années 1990 (Extreme Programming, Rapid Application Development, Scrum ) :

Les méthodes agiles. Les méthodes agiles sont apparues dans les années 1990 (Extreme Programming, Rapid Application Development, Scrum ) : SCRUM Les méthodes agiles Les méthodes agiles sont apparues dans les années 1990 (Extreme Programming, Rapid Application Development, Scrum ) : capacité à réagir au changement plutôt que de suivre un plan

Plus en détail

Concevoir des applications Web avec UML

Concevoir des applications Web avec UML Concevoir des applications Web avec UML Jim Conallen Éditions Eyrolles ISBN : 2-212-09172-9 2000 1 Introduction Objectifs du livre Le sujet de ce livre est le développement des applications web. Ce n est

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

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 de Préparation. EXIN Agile Scrum. Foundation

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

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

NORME INTERNATIONALE D AUDIT 700 FONDEMENT DE L OPINION ET RAPPORT D AUDIT SUR DES ETATS FINANCIERS

NORME INTERNATIONALE D AUDIT 700 FONDEMENT DE L OPINION ET RAPPORT D AUDIT SUR DES ETATS FINANCIERS NORME INTERNATIONALE D AUDIT 700 FONDEMENT DE L OPINION ET RAPPORT D AUDIT SUR DES ETATS FINANCIERS Introduction (Applicable aux audits d états financiers pour les périodes ouvertes à compter du 15 décembre

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

Applications du processus unifié

Applications du processus unifié 2TUP : Two Tracks Unified Process Applications du processus unifié Processus proposé par Valtech (consulting) Ref. : UML2 en action Objectif prendre en compte les contraintes de changement continuel imposées

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Memory Arrays avec Memory Gateways Version 5.5.2 Préparé par : Le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien

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

Examen final LOG3000 Hiver 2014

Examen final LOG3000 Hiver 2014 Examen final LOG3000 Hiver 2014 Lundi le 28 avril 2014. Durée : 13h30 à 16h00 (total 2h30). Local : A-532. Total des points : 20. Pondération de l'examen dans la note finale : 40%. Sans documentation.

Plus en détail

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

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

Employée/Employé de commerce CFC «Services et administration»

Employée/Employé de commerce CFC «Services et administration» Employée/Employé de commerce CFC «Services et administration» Le champ d activité des employés 1 de commerce de la branche «Services et administration» va du contact avec la clientèle au back office. La

Plus en détail

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

Code de bonnes pratiques de la statistique européenne

Code de bonnes pratiques de la statistique européenne Code de bonnes pratiques de la statistique européenne POUR LES SERVICES STATISTIQUES NATIONAUX ET COMMUNAUTAIRES Adopté par le Comité du système statistique européen 28 septembre 2011 Préambule La vision

Plus en détail

L'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 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é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

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

Stratégie de la surveillance des assurances en Suisse

Stratégie de la surveillance des assurances en Suisse Stratégie de la surveillance des assurances en Suisse 1. Base juridique...2 2. Tâches principales...2 3. Conditions d accomplissement des tâches principales...2 3.1. Culture de la responsabilité...3 3.2.

Plus en détail

Planification et contrôle de la formation

Planification et contrôle de la formation Planification et contrôle de la formation Aperçu Le présent chapitre contient une introduction aux instruments de planification et de contrôle de la formation. Dans ce domaine, les personnes en formation

Plus en détail

1. Glossaire Attestation fédérale professionnelle (AFP) BDEFA 2 Branche de formation et d examen Branche et entreprise

1. Glossaire Attestation fédérale professionnelle (AFP) BDEFA 2 Branche de formation et d examen Branche et entreprise 1. Glossaire Attestation fédérale professionnelle (AFP) La personne qui a réussi la procédure de qualification au terme de sa formation d assistant de bureau reçoit l attestation fédérale de formation

Plus en détail

Planifier son projet avec SCRUM

Planifier son projet avec SCRUM Avec SCRUM l estimation de la taille du projet est collective. C est l équipe présente qui estime taille et la durée du projet. L estimation se base sur la capacité de l équipe : la vélocité. La vélocité

Plus en détail

ISO/CEI 20000-1 NORME INTERNATIONALE. Technologies de l'information Gestion des services Partie 1: Exigences du système de management des services

ISO/CEI 20000-1 NORME INTERNATIONALE. Technologies de l'information Gestion des services Partie 1: Exigences du système de management des services NORME INTERNATIONALE ISO/CEI 20000-1 Deuxième édition 2011-04-15 Technologies de l'information Gestion des services Partie 1: Exigences du système de management des services Information technology Service

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

Méthodologies SCRUM Présentation et mise en oeuvre

Méthodologies SCRUM Présentation et mise en oeuvre Méthodologies SCRUM Présentation et mise en oeuvre Réalisé par Istace Emmanuel (Manu404) pour la communauté Hackbbs Document sous license GFDL (Licence de documentation libre GNU) http://www.gnu.org/licenses/licenses.fr.html

Plus en détail

I/ PRESENTATION GENERALE DE LA QUALITE : LES CONCEPTS QUALITE EN DIAGNOSTIC

I/ PRESENTATION GENERALE DE LA QUALITE : LES CONCEPTS QUALITE EN DIAGNOSTIC Généralités 3 I/ PRESENTATION GENERALE DE LA QUALITE : LES CONCEPTS QUALITE EN DIAGNOSTIC La multiplicité des acceptations de la notion de Qualité est source de bien de malentendus et de réticences associées

Plus en détail

LES CONTRATS DE RECHERCHE ET DE DÉVELOPPEMENT

LES CONTRATS DE RECHERCHE ET DE DÉVELOPPEMENT 1 I Introduction LES CONTRATS DE RECHERCHE ET DE DÉVELOPPEMENT Par Monsieur le Professeur Dr. Thomas Pfeiffer, Heidelberg Le contrat de vente constitue le modèle du droit des contrats. Cela était déjà

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

GL - 2 2.2 Processus de développement Cycles de vie

GL - 2 2.2 Processus de développement Cycles de vie GL - 2 2.2 Processus de développement Cycles de vie Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, Ph. Lalanda, I. Parissis, Y. Ledru 1 Plan Introduction Modèles en cascade

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

Plan de la Formation. SCRUM en PRATIQUE

Plan de la Formation. SCRUM en PRATIQUE Plan de la Formation SCRUM en PRATIQUE Démarrage clés en mains de votre Projet en SCRUM Intitule de la Formation SCRUM en PRATIQUE Objectifs Les Objectifs de la formation sont de vous fournir une excellente

Plus en détail

Méthodes de développement

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

Gestion de Projet Informatique

Gestion de Projet Informatique Gestion de Projet Informatique Partie 3 : Cycles de vie de projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 1 GPI T. LIU The earliest moment is when you think it is

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

Agile : quel chemin? @thierrycros

Agile : quel chemin? @thierrycros Agile : quel chemin? @thierrycros Cette session Qu'allons-nous apprendre? Agenda Agile? Chemins agiles Scrum Extreme Programming Lean Kanban Processus Unifié agilisé Choisir? http://thierrycros.net 3 Agenda

Plus en détail

Le développement des compétences au service de l organisation apprenante

Le développement des compétences au service de l organisation apprenante Daniel Held et Jean-Marc Riss : Le développement des compétences au service de l organisation apprenante Paru dans : Employeur Suisse, no 13, 1998 Les changements de plus en plus importants et rapides

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

LISTE DES FORMATIONS. Mai 2015

LISTE DES FORMATIONS. Mai 2015 Gestion de projet Analyse d affaires Formation Évaluation de performance +1.514.826.5534 info@lcgsolution.com www.lcgsolution.com LCG Solution se distingue par la qualité du matériel de formation, la qualité

Plus en détail

Les méthodologies traditionnelles : des limites et une résistance au changement

Les méthodologies traditionnelles : des limites et une résistance au changement Julien ALAMI Newsletter, spécial Agile Scrum, 2010 Une enquête réalisée par le Standish Group Study (2002) a montré que 2/3 des fonctions d un système d information sont rarement ou jamais utilisées, et

Plus en détail

Méthodes agiles. www.businessinteractif.com CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS. Jean-Louis Bénard jlb@businessinteractif.

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

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

Sprint Planning. Prépa N Product Backlog. Dev N-1 DEV N. Démarrage d un Item (US, TS, DEFECT) Release Planning (review)

Sprint Planning. Prépa N Product Backlog. Dev N-1 DEV N. Démarrage d un Item (US, TS, DEFECT) Release Planning (review) Sprint N-1 Sprint N Prépa N Product Backlog Sprint Planning Vérification estimations initiales Pour les premiers items : Instanciation d un Tasks Pattern Estimation des tâches en heures Dev N-1 Sprint

Plus en détail

MAcro-clairances pour les Secteurs TERminaux

MAcro-clairances pour les Secteurs TERminaux MAcro-clairances pour les Secteurs TERminaux Frédéric MONJO Table de révision Date Auteur Portée Raison Frédéric MONJO Tout le document Création du document Table des matières Introduction... 1 I - Processus

Plus en détail

RAPPORT DU JURY SUR LA SESSION 2014 DU DSCG

RAPPORT DU JURY SUR LA SESSION 2014 DU DSCG RAPPORT DU JURY SUR LA SESSION 2014 DU DSCG 1. Eléments statistiques 1.1. réussite par UE en 2013 et 2014 Le taux de réussite par UE est repris dans les tableaux ci-après pour 2013 et 2014. En moyenne

Plus en détail

Conduite de projets agiles

Conduite de projets agiles Conduite de projets agiles Management alternatif dans une équipe de développement agile Julien PLÉE Table des matières 1 Chapitre 1 Contexte 1. Introduction.............................................

Plus en détail

MÉTHODE SCRUM. Portrait de l entreprise

MÉTHODE SCRUM. Portrait de l entreprise Portrait de l entreprise Nom : Esterline CMC Électronique Plus de 00 ans d innovation Secteur d activité : aérospatiale, conception et fabrication d équipements Produits et services : CMC Électronique

Plus en détail

Ingénierie, design et communication COM-21573

Ingénierie, design et communication COM-21573 Notes de cours Module 1 La gestion de projets d ingénierie Édition Hiver07 FSG 2007 Ingénierie, design et communication Daniel Dupuis Faculté des sciences et de génie Université Laval Faculté des sciences

Plus en détail

Agilité en BI AGILITÉ EN BI. L'agilité en BI afin d'augmenter votre retour sur investissement. Contactez-nous: 1-888-926-1272 www.agiledss.

Agilité en BI AGILITÉ EN BI. L'agilité en BI afin d'augmenter votre retour sur investissement. Contactez-nous: 1-888-926-1272 www.agiledss. AGILITÉ EN BI L'agilité en BI afin d'augmenter votre retour sur investissement Les auteurs Alexandre Langlois Fort de ses 13 années en technologies de l information, dont 5 ans en intelligence d affaires,

Plus en détail

Cas d étude appliqué à l ingénierie logicielle

Cas d étude appliqué à l ingénierie logicielle ypbl : une méthodologie pédagogique pour la professionnalisation d une formation Cas d étude appliqué à l ingénierie logicielle Ernesto Exposito 1,2, Anne Hernandez 2 1 CNRS ; LAAS ; 7 av. du Colonel Roche,

Plus en détail

INTRODUCTION A L AGILITE ET AU SCRUM. Petits retours sur ce que sont l AGILITE et le SCRUM et les difficultés que cela implique.

INTRODUCTION A L AGILITE ET AU SCRUM. Petits retours sur ce que sont l AGILITE et le SCRUM et les difficultés que cela implique. INTRODUCTION A L AGILITE ET AU SCRUM Petits retours sur ce que sont l AGILITE et le SCRUM et les difficultés que cela implique. Résumé Ayant le vent en poupe, l état d esprit AGILE est aujourd hui de plus

Plus en détail

La reddition de comptes

La reddition de comptes Bureau du vérificateur interne Votre référence en gestion, risque et contrôle La reddition de comptes Novembre 2005 TABLE DES MATIÈRES Page 1. Introduction... 1 2. Une définition de la reddition de comptes...

Plus en détail

Service de Transport des élèves Windsor-Essex student transportation services PLAN STRATÉGIQUE. Septembre 2010. 1 P age

Service de Transport des élèves Windsor-Essex student transportation services PLAN STRATÉGIQUE. Septembre 2010. 1 P age Service de Transport des élèves Windsor-Essex student transportation services PLAN STRATÉGIQUE Septembre 2010 1 P age 1.0 INTRODUCTION Le Plan stratégique du Service de Transport des élèves Windsor Essex

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

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

Directions Métiers : piloter vos projets digitaux en réconciliant Cap & Agilité

Directions Métiers : piloter vos projets digitaux en réconciliant Cap & Agilité Directions Métiers : piloter vos projets digitaux en réconciliant Cap & Agilité «Il n y a pas de vent favorable pour celui qui ne sait où il va» - Sénèque Paris, le 27 Juin 2013 L évolutivité et l incertitude

Plus en détail

1. Étude réalisée par l AFOPE en 2005. 2. Hellriegel D., Slocum J. W., Woodman R. W., Management des organisations, Bruxelles, De Boeck, 1992.

1. Étude réalisée par l AFOPE en 2005. 2. Hellriegel D., Slocum J. W., Woodman R. W., Management des organisations, Bruxelles, De Boeck, 1992. Introduction 1 I n t r o d u c t i o n Créer des usines, des entreprises, des organisations, des méthodes, des produits, des services nouveaux suppose d avoir des équipes motivées, obéissant à un calendrier

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

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

ISO/CEI 19770-1. Technologies de l information Gestion des actifs logiciels. Partie 1: Procédés et évaluation progressive de la conformité

ISO/CEI 19770-1. Technologies de l information Gestion des actifs logiciels. Partie 1: Procédés et évaluation progressive de la conformité NORME INTERNATIONALE ISO/CEI 19770-1 Deuxième édition 2012-06-15 Technologies de l information Gestion des actifs logiciels Partie 1: Procédés et évaluation progressive de la conformité Information technology

Plus en détail

Cisco Unified Computing Migration and Transition Service (Migration et transition)

Cisco Unified Computing Migration and Transition Service (Migration et transition) Cisco Unified Computing Migration and Transition Service (Migration et transition) Le service Cisco Unified Computing Migration and Transition Service (Migration et transition) vous aide à migrer vos applications

Plus en détail

Système Qualité Pharmaceutique (ICH Q10)

Système Qualité Pharmaceutique (ICH Q10) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 Système Qualité Pharmaceutique (ICH Q10) Le document ICH Q10 sur le

Plus en détail

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1 Génie logiciel Concepts fondamentaux Bruno MERMET, Université du Havre 1 Nécessité du Génie Logiciel Bruno MERMET, Université du Havre 2 Développement d un logiciel Caractéristiques souhaitées : Adéquation

Plus en détail

Le Guide Scrum. Le guide définitif de Scrum : les règles du jeu. Juillet 2013. Développé and maintenu par Ken Schwaber et Jeff Sutherland

Le Guide Scrum. Le guide définitif de Scrum : les règles du jeu. Juillet 2013. Développé and maintenu par Ken Schwaber et Jeff Sutherland Le Guide Scrum Le guide définitif de Scrum : les règles du jeu Juillet 2013 Développé and maintenu par Ken Schwaber et Jeff Sutherland Table des matières Raison d être du Guide Scrum... 4 Définition de

Plus en détail

Rapport sur l audit interne de la gouvernance de la gestion de l information et des technologies de l information

Rapport sur l audit interne de la gouvernance de la gestion de l information et des technologies de l information Rapport sur l audit interne de la gouvernance de la gestion de l information et des technologies de l information Bureau du surintendant des institutions financières Novembre 2012 Table des matières 1.

Plus en détail

Programme qualité. de l association suisse des services d aide et de soins à domicile. Projet 02 Octobre 2001

Programme qualité. de l association suisse des services d aide et de soins à domicile. Projet 02 Octobre 2001 Programme qualité de l association suisse des services d aide et de soins à domicile Projet 02 Octobre 2001 A propos de la consultation auprès des associations cantonales 24.10.2001-21.11.2001 1. Situation

Plus en détail

Identification du module

Identification du module Identification du module Numéro de module 475 Titre Développer une analyse pour une application Compétence Développer à partir des exigences fonctionnelles et non fonctionnelles pour une application, les

Plus en détail

[ Hornet ] Charte de méthodologie

[ Hornet ] Charte de méthodologie [ Hornet ] Hornet Cette création est mise à disposition selon le Contrat Paternité - Pas d'utilisation Commerciale - Partage des Conditions Initiales à l'identique disponible en ligne http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

Plus en détail