É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