É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

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

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

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

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

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. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Modernisation et gestion de portefeuilles d applications bancaires

Modernisation et gestion de portefeuilles d applications bancaires Modernisation et gestion de portefeuilles d applications bancaires Principaux défis et facteurs de réussite Dans le cadre de leurs plans stratégiques à long terme, les banques cherchent à tirer profit

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

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

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

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

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. 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

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

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

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

Les méthodes itératives. Hugues MEUNIER

Les méthodes itératives. Hugues MEUNIER Les méthodes itératives Hugues MEUNIER INTRODUCTION. Toute les méthodes ont le même but : la maîtrise du budget, du planning et de la qualité des projets de développement informatique Plusieurs approches

Plus en dé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

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

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

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

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

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

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

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

La solution IBM Rational pour une ALM Agile

La solution IBM Rational pour une ALM Agile La solution IBM pour une ALM Agile Utilisez votre potentiel agile Points clés Adopter l'agilité à votre rythme Supporter une livraison multiplateforme Intégrer la visibilité Démarrer rapidement Que votre

Plus en détail

Logiciels de Gestion de Projet: Guide de sélection

Logiciels de Gestion de Projet: Guide de sélection Logiciels de Gestion de Projet: Guide de sélection Logiciels de Gestion de Projets: Guide de sélection PPM Software Selection Guide ETAPE 1: Faiblesses Organisationnelles identifier clairement vos besoins

Plus en détail

Appareils technologiques en milieu de travail : 4 e séance. Réunion du Comité consultatif sur le cadre d architecture (CCCA) Le 16 avril 2014

Appareils technologiques en milieu de travail : 4 e séance. Réunion du Comité consultatif sur le cadre d architecture (CCCA) Le 16 avril 2014 Appareils technologiques en milieu de travail : 4 e séance Réunion du Comité consultatif sur le cadre d architecture (CCCA) Le 16 avril 2014 1 Ordre du jour HEURE SUJETS PRÉSENTATEURS 9 h à 9 h 10 Mot

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

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

Analyse structurée de solutions pour BMC Remedy IT Service Management v 7

Analyse structurée de solutions pour BMC Remedy IT Service Management v 7 LIVRE BLANC SUR LES PRATIQUES ITIL Analyse structurée de solutions pour BMC Remedy IT Service Management v 7 Exploiter le potentiel des pratiques ITIL grâce aux ateliers d analyse de solutions organisés

Plus en détail

Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles

Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles Laurent PY CEO, Smartesting Laurent.py@smartesting.com @py_laurent www.smartesting.com Guillaume Coquelle Testeur,

Plus en dé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

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

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

Formation Scrum. 2 jours

Formation Scrum. 2 jours 2 jours +33 6 08 34 63 55 laurent@morisseauconsulting.com SARL unipersonnelle au capital de 3500 - N SIRET : 508 068 590 00019 Code APE 6202A Sommaire 1 Contexte de la formation... 3 2 Le formateur...

Plus en détail

Les méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum

Les méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum Les méthodes Agiles Introduc)on aux méthodes Agiles Exemple : Scrum Défini)on de base Les méthodes Agiles sont des procédures de concep)on de logiciel qui se veulent plus pragma)ques que les méthodes tradi)onnelles

Plus en détail

Guide d Intégration PPM et ERP:

Guide d Intégration PPM et ERP: LIVRE BLANC Guide d Intégration PPM et ERP: Stratégies d intégration de logiciels dans les entreprises organisées par projet De: Neil Stolovitsky E-mail: sales@geniusinside.com Website: www.geniusinside.com

Plus en détail

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de

Plus en détail

Les mécanismes d'assurance et de contrôle de la qualité dans un

Les mécanismes d'assurance et de contrôle de la qualité dans un Les mécanismes d'assurance et de contrôle de la qualité dans un projet Agile SPIN de Montréal - ETS 5 mars 2012 Qui sommes nous? mathieu boisvert Coach Agile Chargé de cours Co auteur d un livre avec Sylvie

Plus en dé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

Estimer et mesurer la performance des projets agiles avec les points de fonction

Estimer et mesurer la performance des projets agiles avec les points de fonction Estimer et mesurer la performance des projets agiles avec les points de fonction Radenko Corovic, MBA radenko.corovic@rsmtechno.ca 1. Introduction Les méthodes agiles de développement des systèmes ont

Plus en détail

Formation agile. Formation agile Created on 24 janv. 2012 Edited on 29 févr. 2012. Page 1 sur 16

Formation agile. Formation agile Created on 24 janv. 2012 Edited on 29 févr. 2012. Page 1 sur 16 Formation agile Page 1 sur 16 1. Qui sommes-nous?... 3 1.1. Pierre-Emmanuel Dautreppe... 3 1.2. Norman Deschauwer... 3 1.3. L association DotNetHub... 3 2. Introduction... 5 3. Agile Manifesto... 6 4.

Plus en détail

Questionnaire. sur l évaluation interne Qualité dans les centres d accueil pour enfants, adolescents et jeunes adultes

Questionnaire. sur l évaluation interne Qualité dans les centres d accueil pour enfants, adolescents et jeunes adultes Questionnaire Université du Luxembourg, Version novembre 2013 Ulla Peters, Julia A. Jäger, Danielle Lellinger sur l évaluation interne Qualité dans les centres d accueil pour enfants, adolescents et jeunes

Plus en détail

Utilisation de ClarityTM pour la gestion du portefeuille d applications

Utilisation de ClarityTM pour la gestion du portefeuille d applications LIVRE BLANC : Gestion du portefeuille d applications Février 2012 Utilisation de CA PPM ClarityTM pour la gestion du portefeuille d applications David Werner CA Service & Portfolio Management agility made

Plus en détail

CHAPITRE 3 : LES METHODES AGILES?

CHAPITRE 3 : LES METHODES AGILES? CHAPITRE 3 : LES METHODES AGILES? UE Gestion de Projet Master 1 STIC 2014/2015 Céline Joiron 2 Introduction Après avoir présenté les cycles de vie «classiques» de la gestion de projet L objectif de ce

Plus en détail

Présentation UBO 12/2008 Présentation des méthodes agiles

Présentation UBO 12/2008 Présentation des méthodes agiles Gestion de projet Vers les méthodes agiles Des approches prédictives aux méthodes agiles appliquées avec SCRUM Présentation UBO 12/2008 Présentation des méthodes agiles Partie 1 : La société Altran Altran

Plus en détail

Feature Team Primer. par Craig Larman et Bas Vodde. Version 1.2

Feature Team Primer. par Craig Larman et Bas Vodde. Version 1.2 ÉQUIPE FEATURE par Craig Larman et Bas Vodde Version 1.2 Les Équipes Feature 1 et les Domaines Fonctionnels 2 sont des éléments essentiels pour dimensionner le développement en mode agile et lean. Ces

Plus en détail

Scrum. ... pour des projets informatiques agiles. Pascal Lando Certified Scrum product owner

Scrum. ... pour des projets informatiques agiles. Pascal Lando Certified Scrum product owner Scrum... pour des projets informatiques agiles Pascal Lando Certified Scrum product owner e-merchant Laboratoire Mis IUP Miage d Amiens pascal.lando@u-picardie.fr 2 octobre 2013 Ceci n est pas un cours

Plus en détail

Jean-Pierre Vickoff www.vickoff.com

Jean-Pierre Vickoff www.vickoff.com Techniques du futur Agile Communication - Architecture - Méthode Vers une approche Agile de 3 ème génération Jean-Pierre Vickoff www.vickoff.com Protocole de séance : Précisions techniques immédiates possibles

Plus en détail

Garantir une meilleure prestation de services et une expérience utilisateur optimale

Garantir une meilleure prestation de services et une expérience utilisateur optimale LIVRE BLANC Garantir une meilleure prestation de services et une expérience utilisateur optimale Mai 2010 Garantir une meilleure prestation de services et une expérience utilisateur optimale CA Service

Plus en détail

SCRUM BUT, LE LIVRE BLANC. De la problématique de mener un projet AGILE dans une organisation classique

SCRUM BUT, LE LIVRE BLANC. De la problématique de mener un projet AGILE dans une organisation classique SCRUM BUT, LE LIVRE BLANC De la problématique de mener un projet AGILE dans une organisation classique Résumé Alors que les demandes de conduite de projet en AGILITE sont de plus en plus fréquentes, les

Plus en détail

Testeur Agile Niveau Fondation 2014 - Bertrand Cornanguer, Vice-chair Agile tester WG

Testeur Agile Niveau Fondation 2014 - Bertrand Cornanguer, Vice-chair Agile tester WG Testeur Niveau Fondation 2014 - Bertrand Cornanguer, Vice-chair tester WG Enquêtes 2013 sur l Agilité Seriez-vous interessé par la certification Testeur? Enquête ISTQB (70 pays juin octobre 2013) Ingénieurs

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification BMC Real End User Experience Monitoring and Analytics 2.5 Préparé par le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma

Plus en détail

IKAN ALM et HP ALM/HP Quality Center Enterprise Pour que les Equipes de Développement, de Test et de Production se rejoignent

IKAN ALM et HP ALM/HP Quality Center Enterprise Pour que les Equipes de Développement, de Test et de Production se rejoignent IKAN ALM et HP ALM/HP Quality Center Enterprise Pour que les Equipes de Développement, de Test et de Production se rejoignent Table of contents Sommaire...3 Définition du problème...4 Solution Description...5

Plus en détail

Conditions gagnantes pour démarrer sa transition Agile

Conditions gagnantes pour démarrer sa transition Agile Conditions gagnantes pour démarrer sa transition Agile 1 4 Les De plus en plus d organisations voient l Agilité comme une piste de solution aux problèmes auxquels elles sont confrontées. Par ailleurs,

Plus en détail

D ITIL à D ISO 20000, une démarche complémentaire

D ITIL à D ISO 20000, une démarche complémentaire D ITIL à D ISO 20000, une démarche complémentaire www.teamup-consulting.com Teamup Consulting - 1 Certificat nºinf/2007/29319 1 ère société de conseil française certifiée ISO 20000-1:2011 Sommaire Introduction

Plus en détail

agility made possible

agility made possible DOSSIER SOLUTION Utilitaire ConfigXpress dans CA IdentityMinder Ma solution de gestion des identités peut-elle rapidement s adapter à l évolution des besoins et des processus métier? agility made possible

Plus en détail

Tremplins de la Qualité. Tome 1

Tremplins de la Qualité. Tome 1 Tome 1 CET OUVRAGE EST UN GUIDE D INTERPRETATION DE LA NORME NF EN ISO 9001 VERSION 2000 AVANT-PROPOS Ce guide d aide à la rédaction du Manuel de Management de la Qualité a été rédigé par la Fédération

Plus en détail

Séance 1 Méthodologies du génie logiciel

Séance 1 Méthodologies du génie logiciel Séance 1 Méthodologies du génie logiciel Objectifs : Histoire du développement du logiciel. La crise du logiciel. Explorer les différentes méthodologies de développement. Comprendre l importance d adopter

Plus en détail

Maîtrise d ouvrage agile

Maîtrise d ouvrage agile Maîtrise d ouvrage agile Offre de service Smartpoint 17 rue Neuve Tolbiac 75013 PARIS - www.smartpoint.fr SAS au capital de 37 500 - RCS PARIS B 492 114 434 Smartpoint, en quelques mots Smartpoint est

Plus en détail

Design centré sur l utilisateur et développement Agile : perspectives de réconciliation

Design centré sur l utilisateur et développement Agile : perspectives de réconciliation Design centré sur l utilisateur et développement Agile : perspectives de réconciliation Alexandre Bujold, Sarah Morin-Paquet Université Laval alexandre.bujold.1@ulaval.ca, sarah.morin-paquet.1@ulaval.ca

Plus en détail

Processus d Informatisation

Processus d Informatisation Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue

Plus en détail

S organiser pour le Cloud

S organiser pour le Cloud S organiser pour le Cloud Apporter une valeur supplémentaire à l entreprise en optimisant l organisation des services informatiques pour le Cloud LIVRE BLANC VMWARE Sommaire Synthèse.... 3 Contexte....

Plus en détail

Les méthodes Agile. Implication du client Développement itératif et incrémental

Les méthodes Agile. Implication du client Développement itératif et incrémental Les méthodes Agile Simon ALEXANDRE - CETIC Plan Overview Agile ne signifie pas Agile signifie Objectifs poursuivis Pourquoi les méthodes Agile apparaissent-elles? Principales causes des échecs de projets

Plus en détail

NORME INTERNATIONALE D AUDIT 620 UTILISATION DES TRAVAUX D UN EXPERT DESIGNE PAR L AUDITEUR

NORME INTERNATIONALE D AUDIT 620 UTILISATION DES TRAVAUX D UN EXPERT DESIGNE PAR L AUDITEUR NORME INTERNATIONALE D AUDIT 620 UTILISATION DES TRAVAUX D UN EXPERT DESIGNE PAR L AUDITEUR Introduction (Applicable aux audits d états financiers pour les périodes ouvertes à compter du 15 décembre 2009)

Plus en détail

Scrum et l'agilité des équipes de développement

Scrum et l'agilité des équipes de développement NormandyJUG Scrum et l'agilité des équipes de développement Par Dimitri Baeli & Nicolas Giard 23 Février 2010 Présentation des intervenants Dimitri Baeli http://twitter.com/dbaeli VP Quality Enterprise

Plus en détail

Concevoir et déployer un data warehouse

Concevoir et déployer un data warehouse Concevoir et déployer un data warehouse Ralph Kimball Éditions Eyrolles ISBN : 2-212-09165-6 2000 2 Le cycle de vie dimensionnel Avant d étudier de plus près les spécificités de la conception, du développement

Plus en détail

TDD Agilité et Kanban Planning Poker

TDD Agilité et Kanban Planning Poker TDD Agilité et Kanban Planning Poker Philippe Collet Licence 3 Informatique S6 2013-2014 http://deptinfo.unice.fr/twiki/bin/view/linfo/projetdelicence201314 Plan r TDD r XP r Scrum r Kanban r Planning

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

Retour d expérience implémentation Scrum / XP

Retour d expérience implémentation Scrum / XP Retour d expérience implémentation Scrum / XP Bruno Orsier Octobre 2008 p.1 Bruno Orsier, Agile Tour 2008 Grenoble Plan Qui sommes nous? Pourquoi Scrum/XP? Historique de la mise en œuvre Bilan Sondage

Plus en dé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

Conseil d administration Genève, mars 2007 PFA/ICTS POUR DÉCISION. Stratégie en matière de technologies de l information (2007-2009) Liens

Conseil d administration Genève, mars 2007 PFA/ICTS POUR DÉCISION. Stratégie en matière de technologies de l information (2007-2009) Liens BUREAU INTERNATIONAL DU TRAVAIL GB.298/PFA/ICTS/1 298 e session Conseil d administration Genève, mars 2007 Sous-comité des technologies de l'information et de la communication PFA/ICTS POUR DÉCISION PREMIÈRE

Plus en détail

Retour d expérience. Le rôle du Business Analyst chez Orange. Nadia Magarino & Christophe Dufour 29 avril 2015

Retour d expérience. Le rôle du Business Analyst chez Orange. Nadia Magarino & Christophe Dufour 29 avril 2015 Retour d expérience Le rôle du Business Analyst chez Orange Nadia Magarino & Christophe Dufour 29 avril 2015 Plus de 161 000 salariés à votre service mobile entreprises internet et fixe Plus de 161 000

Plus en détail

Norme internationale d information financière 1 Première application des Normes internationales d information financière

Norme internationale d information financière 1 Première application des Normes internationales d information financière IFRS 1 Norme internationale d information financière 1 Première application des Normes internationales d information financière Objectif 1 L objectif de la présente Norme est d assurer que les premiers

Plus en détail

Bureau du surintendant des institutions financières. Audit interne des Services intégrés : Services de la sécurité et de l administration

Bureau du surintendant des institutions financières. Audit interne des Services intégrés : Services de la sécurité et de l administration Bureau du surintendant des institutions financières Audit interne des Services intégrés : Services de la sécurité et de l administration Avril 2014 Table des matières 1. Contexte... 3 2. Objectif, délimitation

Plus en détail

Plan. 1 Cycles de développement. 2 Méthodes agiles, principes généraux. 3 Comment se passe un Sprint?

Plan. 1 Cycles de développement. 2 Méthodes agiles, principes généraux. 3 Comment se passe un Sprint? Plan nitiation au Génie Logiciel Cours 5 ntroduction au π développement agile T. Genet (genet@irisa.fr) (STC/RSA) GEN-5 1/ 28 T. Genet (genet@irisa.fr) (STC/RSA) GEN-5 2/ 28 Bibliographie Plan L informatique

Plus en détail