Agile en équilibre : Introduction d un processus agile de spécification des besoins. dans une grande entreprise financière. par.

Transcription

1

2 Agile en équilibre : Introduction d un processus agile de spécification des besoins dans une grande entreprise financière par François Papa Essai présenté au CeFTI en vue de l'obtention du grade de maître en technologies de l'information (maîtrise en génie logiciel incluant un cheminement de type cours en technologies de l'information) FACULTÉ DES SCIENCES UNIVERSITÉ DE SHERBROOKE Longueuil, Québec, Canada, avril 2014

3 Sommaire Cet essai porte essentiellement sur l'intégration des méthodes agiles dans un contexte de grande entreprise financière où les processus non-agiles dominent. L'accent a été mis plus particulièrement sur les processus agiles de spécification des besoins et comment en tirer profit dans un tel contexte. La documentation disponible répond à la question : «Existe-t-il des meilleures pratiques pouvant faciliter la gestion du processus de spécification des besoins en agile dans une grande organisation financière utilisant des méthodologies de développement logiciel nonagiles?», en démontrant qu'il existe des méthodes comme DAD et SAFe qui peuvent faciliter l'implantation d'un tel processus dans de grandes entreprises. Selon la première hypothèse de base, il est difficile d'utiliser uniquement des méthodes et pratiques de développement agile dans le contexte d'une grande entreprise financière. Les données portent à croire qu'il est très difficile d'éviter totalement les méthodes de développement traditionnelles. Selon la deuxième hypothèse, il est tout à fait possible de tirer profit de l'agilité pour améliorer la productivité, la qualité et la satisfaction du client (interne et externe). Il existe plusieurs exemples de succès agiles qui permettent de telles améliorations dans de grandes entreprises dans plusieurs domaines, dont le domaine financier. Le candidat a recommandé de profiter de l'existence du bureau de projets chez son employeur afin de faciliter l'implantation de l'agilité dans l'entreprise. Des experts agiles de l'entreprise ont souligné les limites de ce plan d'action dans un contexte de bureaux de projets fédérés. Selon la troisième hypothèse, l'implication du bureau de projets est critique pour réussir à implanter agile dans une entreprise. Les résultats des recherches effectuées pour cet essai ne permettent pas de faire une telle affirmation. Cependant, de par son rôle, le bureau de projets peut faciliter l intégration de l agilité dans une grande organisation. i

4 Remerciements Merci à toute l'équipe du CeFTI : Claude Cardinal, Vincent Échelard, l'équipe des professeurs et les chargés de cours. J'ai bien apprécié la formation que j'ai reçue au campus Longueuil de l'université de Sherbrooke. La relation personnalisée et le support donné aux étudiants me laisseront un bon souvenir de mon passage à l'université de Sherbrooke. C'est maintenant la fin de cette période de travail intense, mais formatrice. Ne vous inquiétez pas pour moi, je saurai quoi faire avec tout ce temps libre. Merci à Scott W. Ambler pour son aide pour la figure 8. Ses commentaires m'ont été très utiles pour obtenir un portrait à haut niveau de Disciplined Agile Delivery. Merci à Emmanuelle Sonntag pour Zotero, Evernote Clearly et autres outils qui m'ont facilité la vie. Merci à Dennie Theodore, Bruno Bouchard et Kristen Ridley pour avoir révisé mon questionnaire et facilité la diffusion de mon sondage. Merci à Daniel Gagnon et Pierre-Martin Tardif pour leur support tout au long du processus d'écriture. Merci à Daniel pour ses révisions et le lien avec l'entreprise. Merci à Pierre-Martin pour le travail d'aiguillage. Messieurs, je ne me suis pas perdu grâce à vous. Merci à Luc Spénard pour les révisions supplémentaires. Son avis et ses conseils m'ont permis d'améliorer mon essai. Je ne serai pas ingrat. ii

5 Table des matières Sommaire... i Remerciements... ii Liste des tableaux... v Liste des figures... vi Glossaire... vii Liste des sigles et acronymes...viii Introduction... 1 Chapitre 1 - Implantation de l agilité dans une organisation Quelques mots sur le choix du sujet Processus agile de spécification des besoins vs méthodes traditionnelles Principaux défis lors de l évolution vers l agilité L'agilité au Groupe Financier Lombard Le contexte Historique (réussites et échecs) Obstacles et résistances Principaux problèmes vécus pour intégrer l agilité et les méthodes non-agiles chez GFL Correspondance entre ce qui a été vécu par GFL et la littérature...10 Chapitre 2 - Problématique Problématique de la recherche Question : Existe-t-il des meilleures pratiques pouvant faciliter la gestion du processus de spécification des besoins en agile dans une grande organisation financière utilisant des méthodologies de développement logiciel non-agiles? Description courtes précisions sur la question Principales hypothèses Approche utilisée Méthodologie Évaluation de la validité du sondage Échantillon utilisé (qui pourquoi - comment)...25 Chapitre 3 - Implantations de la gestion des spécifications en agile Critères de sélection Méthodes et pratiques évaluées La pyramide de la spécification des besoins Comparaison des pratiques de spécification des besoins Comparaison des principes de spécification des besoins Pratiques et processus (Liens entre l'agilité et les processus non-agiles) Rôles et facteurs humains Bureau de projets, structure et hiérarchie Autres points communs entre les méthodes Autres facteurs non considérés Quelques réponses tirées de cette analyse...53 Chapitre 4 - Analyse des résultats Sondage Agile dans le milieu financier...64 iii

6 Chapitre 5 - Recommandations Identification des écarts et plan d action proposé Validation du plan d action Commentaires sur les réponses des experts agiles Ouverture vers d'autres sujets de recherche...70 Conclusion Références Bibliographie Annexe 1 Questionnaire du sondage en français...85 Annexe 2 Questionnaire du sondage en anglais...92 Annexe 3 Résultats du sondage Annexe 4 Introduction à l'agilité iv

7 Liste des tableaux Tableau 1: Processus de spécification des besoins : méthodes traditionnelles vs agile...5 Tableau 2: Rôles impliqués dans la spécification des besoins...44 Tableau 3: Tâches du chargé de projet traditionnel vs équipe agile...46 Tableau 4: Efficacité d'agile (Sondage chez GFL )...56 Tableau 5: Efficacité des équipes agiles (Sondage de Dr. Dobb's )...56 Tableau 6: Pourcentage favorable à l'agilité pour l'élaboration de la spécification des besoins (Sondage chez GFL )...59 Tableau 7: Auto-évaluation de la connaissance d'agile (Sondage chez GFL )...62 v

8 Liste des figures Fig. 1: La triple contrainte : les méthodes traditionnelles vs agiles...4 Fig. 2: Environnement d'un projet pilote XP chez Nokia...12 Fig. 3: La pyramide de la spécification des besoins...32 Fig. 4: Pratiques reliées aux besoins...33 Fig. 5: Le cycle de la spécification des besoins selon SAFe...35 Fig. 6: Exploration de la portée initiale du projet selon DAD...37 Fig. 7: La méthode de l'enveloppe...41 Fig. 8: Relations entre les méthodes...49 Fig. 9: Catégories de répondants au sondage chez GFL Fig. 10: Catégories de répondants au sondage Dr. Dobb's Fig. 11: Répondants élaborant leurs spécifications des besoins en agile (Sondage chez GFL )...58 Fig. 12: Nombre d'années d'expérience en développement agile (Sondage chez GFL )...60 Fig. 13: Nombre d'années d'expérience en agile (VersionOne 2012)...61 Fig. 14: Degré de connaissance de l'existence de passerelles entre les processus agiles et non-agiles (Sondage chez GFL )...62 Fig. 15: Degré de connaissance de l'existence de passerelles entre les processus agiles et non-agiles (Sondage chez GFL )...63 Fig. 16: Proposition de valeur du développement agile vi

9 Glossaire Carnet Carnet de produit Carnet de sprint Complète et à l'avance Épopée LinkedIn Mêlée de mêlées Planification des versions Propriétaire de produit Récit utilisateur Scrum Traduction de l'anglais backlog Trad. de l'anglais product backlog Trad. de l'anglais sprint backlog Trad. de l'anglais big and up front Trad. de l'anglais epic Réseau social professionnel Trad. de l'anglais scrum of scrums Trad. de l'anglais release planning Trad. de l'anglais product owner Trad. de l'anglais user story Méthode de développement agile vii

10 Liste des sigles et acronymes AM AD DAD GFL LeSS PDA PMI SAFe UP WSJF XP Agile Modeling Agile Data Disciplined Agile Delivery Groupe Financier Lombard (nom fictif) Large-Scale Scrum Programme de déploiement de l'agilité (nom fictif) Project Management Institute Scaled Agile Framework Unified Process Weighted Shortest Job First Extreme Programming viii

11 Introduction Depuis le début des années 2000, le mouvement agile secoue les fondements du développement logiciel tel qu'il était pratiqué jusque là. L approche agile sort maintenant des départements TI pour envahir tous les échelons des organisations, avec pour conséquence de changer en profondeur la façon de concevoir les processus de livraison d'une solution logicielle. Le développement logiciel agile est un sujet qui n'est pas souvent abordé par le monde des affaires. Une recherche avec les mots-clés «agile software development» sur le site de la prestigieuse revue Harvard Business Review (hbr.org) retourne seulement 15 résultats 1. Le déploiement d'un processus agile dans une grande organisation est un défi dont il faut identifier les facteurs critiques de succès. L'essai se concentre sur l'importance de bien cerner les besoins du client, facteur essentiel à la livraison d'une solution logicielle répondant aux besoins dudit client. Il sera question des méthodes pouvant faciliter l'implantation d'un processus agile de gestion des spécifications dans les grandes organisations. L'accent sera mis sur les organisations financières, réputées conservatrices en matière de gestion. Parmi les sources les plus importantes de cet essai, notons le livre Disciplined Agile Delivery de Scott W. Ambler et Mark Lines [1] ainsi que le livre Agile Software Requirements de Dean Leffingwell [2], créateur de la méthode SAFe (Scaled Agile Framework). Ces auteurs, très respectés, sont bien connus par ceux qui s'intéressent au monde du développement logiciel agile. L'information provient aussi d'internet, notamment du site de SAFe et de celui de Disciplined Agile Delivery. Les articles proviennent des sites d'universités, d'ieee Xplore et d'autres banques de données disponibles via la bibliothèque de l'université de Sherbrooke. Les premières questions qui ont mené à la rédaction de cet essai tournaient autour de l'existence de bonnes pratiques permettant de faciliter la création d'une spécification des 1 Résultats obtenus le 31 mars

12 besoins en mode agile dans une entreprise qui n'emploie pas les pratiques agiles, ou du moins très peu. Était-il possible d'intégrer une ou des équipes agiles dans un environnement non-agile? De grandes entreprises, en particulier les grandes entreprises financières, pouvaient-elles utiliser agile pour développer du logiciel avec succès? L'utilisation des sources citées précédemment a servi de point de départ, de référence de base, pour vérifier s'il existait de bonnes pratiques pouvant faciliter la gestion du processus de spécification des besoins en agile dans une grande organisation financière utilisant des méthodologies de développement logiciel non-agiles. La publication d'un sondage chez le Groupe Financier Lombard (GFL) 2 a donné plusieurs renseignements sur la situation de l'agilité au sein de l'organisation. La comparaison de ces données avec d'autres études et sondages disponibles dans Internet a mis ces résultats en perspective avec la situation de l'agilité dans d'autres grandes entreprises. Cette comparaison avait pour but de savoir si les résultats du sondage étaient recevables dans le cadre de cet essai, malgré les effets de distorsions dû à la méthode de sondage et aux spécificités locales de l'entreprise. L'essai se termine sur un plan d'action visant à favoriser l'implantation de l'agilité à travers le groupe financier. Il a été validé par des experts agiles de l'organisation. Ces évaluations d'experts furent à leur tout commentées à la lumière de la connaissance de l'organisation gagnée durant la rédaction de l'essai. Le choix de ce sujet n'est pas un hasard et s'inscrit dans un cheminement professionnel où les méthodes agiles feront partie des outils disponibles. Voyons maintenant ce qui a motivé le choix dudit sujet. 2 Nom fictif 2

13 Chapitre 1 Implantation de l agilité dans une organisation 1.1 Quelques mots sur le choix du sujet En œuvrant dans le domaine du développement logiciel depuis plus d'une décennie, il est apparu évident que de nombreuses compagnies souffrent de faiblesses dans le domaine de la collecte des besoins, dans le processus de gestion des demandes de changement, de l'alignement avec les objectifs du client, bref, dans la gestion de la spécification des besoins en général. Le fait d'avoir déjà dû composer avec des besoins définis avec un client sans aucune validation préalable par l'équipe de développement, ou pire, complètement en vase clos, sensibilise à l'importance d'une spécification des besoins claire et d'un bon processus de gestion de ladite spécification. De mauvaises pratiques ou l'absence de pratiques provoquent de mauvaises surprises au cours du cycle de développement (informations manquantes, fonctionnalités irréalisables). On constate des problèmes similaires chez GFL, un grand groupe financier dont le siège social est au Canada. On pouvait y voir les avantages de l'agilité en entreprise, notamment au niveau de la collaboration étroite avec le client. Toutefois, les employés et les cadres de GFL voyaient aussi les limites d'opérer en mode agile dans une organisation qui ne l'est pas. Il sera question de GFL plus amplement dans les sections 1.4 et suivantes. Ces constatations soulèvent des questions quant à la possibilité de trouver des solutions aux problèmes de gestion du processus de spécification des besoins. Cet essai a vu le jour en partie pour savoir s'il existait des meilleures pratiques permettant d'intégrer l'agilité dans une grande entreprise afin de profiter pleinement des avantages d'agile pour améliorer le processus de spécification des besoins, et, par ricochet, le processus de développement logiciel au grand complet. 3

14 1.2 Processus agile de spécification des besoins vs méthodes traditionnelles En comparant la triple contrainte de l'agilité et celle des méthodes dites traditionnelles, on remarque immédiatement que les priorités sont très différentes. La gestion de projet traditionnelle vise, entre autres, le respect du plan de projet. Agile met l'accent sur la livraison de valeur ajoutée. Fig. 1: La triple contrainte : les méthodes traditionnelles vs agiles Traduction libre Source : Leffingwell, D., 2007 ([3], p. 81) En agile, les ressources et les délais sont fixes tandis que la portée du projet est une estimation pouvant être modifiée en cours de route. C'est le contraire en mode traditionnel, où seulement les ressources et les délais peuvent changer. Cette différence est fondamentale dans la création de la spécification des besoins. La documentation exhaustive et quasi-définitive en début de projet est remplacée par une estimation pouvant évoluer, accompagnée d'une documentation légère qui, elle aussi, évolue. Un projet agile ne débute pas par une période consacrée presque uniquement à l'analyse et à la conception avant le début du développement. Les équipes agiles visent une série de 4

15 livraisons rapides à valeur ajoutée pour le client. Durant le processus de spécifications des besoins, les hypothèses de travail sont constamment réévaluées et testées. Les erreurs sont corrigées au besoin. Puisque le cycle est réduit à quelques semaines, la rétroaction avec le client est rapide. Il est possible de s'adapter sans devoir mettre de côté tout le travail d'analyse et de conception ([4], p. 78). Ce tableau ci-dessous donne un aperçu des différences entre agile et le développement traditionnel. Les éléments à gauche du tableau représentent les méthodes de développement traditionnelles axées sur la planification. Les méthodes agiles à droite privilégient le développement évolutif. Spécification des besoins et conception En cascade/méthodes traditionnelles Complète et à l'avance Spécification des besoins marketing à l'avance Spécifications logicielles à l'avance Modèles et plans Conception complète et à l'avance Architecture planifiée Agile Continue/émergente/juste-à-temps Vision et carnet Élaboration juste-à-temps Construction d'incréments Décisions de conception au DMR 3 Architecture émergente Tableau 1: Processus de spécification des besoins : méthodes traditionnelles vs agile Traduction libre Source : Leffingwell, D., 2007 ([5], p. 78) 3 Dernier Moment Responsable 5

16 1.3 Principaux défis lors de l évolution vers l agilité Dans une grande entreprise œuvrant selon un mode de livraison traditionnel, le logiciel livré en production est le produit du travail de plusieurs équipes, chacune ayant son champ d'expertise et de responsabilité. L'un des principaux défis lors de l'implantation de pratiques agiles dans une grande entreprise est la création d'interfaces entre les anciennes et les nouvelles pratiques ([6], p. 30). En effet, un projet agile doit tout de même se conformer aux processus et aux règles déjà en place. Il faut donc trouver une façon d'adapter les processus agiles pour faciliter leur acceptation avant de répandre l'agilité dans l'organisation. Cette adaptation peut éviter l'augmentation de la charge de travail résultant d'éventuelles duplications entre les divers processus impliqués ([7], pp ). Les facteurs de succès d'un projet agile peuvent être regroupés en cinq catégories (Adaptation et traduction libre de [8], p. 48) : Les facteurs organisationnels comme la culture et le support de la direction peuvent ralentir ou aider l'implantation de l'agilité. Les facteurs humains sont, par exemple, les compétences et la capacité à travailler en équipe. Les facteurs liés aux processus touchent à leur gestion proprement dite comme, par exemple, les processus agiles de création de la spécification des besoins, les processus compatibles avec l'agilité, ou la gestion de projet agile. Les facteurs techniques regroupent tout ce qui a trait aux outils. Les facteurs liés aux projets eux-mêmes touchent à la nature et à l'organisation des projets eux-mêmes : taille de l'équipe et dépendances inter-équipes, par exemple. ([9], pp ). Donc, évoluer vers l'agilité demandera des connaissances et des compétences dans de multiples champs d'expertise. 6

17 1.4 L'agilité au Groupe Financier Lombard Le contexte L'essai dresse un historique et la situation actuelle de l'agilité chez GFL. Pour des raisons de confidentialité, tous les noms utilisés sont fictifs Historique (réussites et échecs) En 2007, suite à l'achat d'un progiciel par une filiale, la méthode Scrum fut adoptée par celleci pour s'aligner sur les pratiques du fournisseur. Le progiciel nécessitait une adaptation aux processus d'affaires de l'entreprise. La filiale de GFL se lança dans un programme de déploiement de l'agilité (PDA) dans le service des TI de cette filiale. Ce n'était pas la première expérience de l'entreprise avec agile, deux projets agiles ayant déjà été livrés avec succès avant le PDA. Toutefois, c'est le plus vaste plan de déploiement de l'agilité mis en place chez GFL à ce jour. En effet, il a fallu préparer subitement six équipes différentes pour la livraison de ce projet de grande envergure Obstacles et résistances Après quatre itérations, certains employés se sont demandé pourquoi utiliser l'agilité au lieu des méthodes traditionnelles en cascade. Il est devenu clair que les objectifs initiaux du PDA avaient été perdus de vue. De plus, la formation donnée n'a pas réussi à faire en sorte que les équipes acquièrent une compréhension suffisante de la philosophie de développement agile et des méthodes agiles en général. L'équipe de méthodologie a dû répondre à ces questions pour assurer de l'adhésion de tous. Des employés moins expérimentés que les chargés de projets ont été choisis pour diriger les équipes agiles. Cela s'explique, car l'entreprise a adopté Scrum, qui préconise l'utilisation de facilitateurs appelés «Scrum Masters» qui s'occupent de gérer et faciliter la livraison. Ils ont 7

18 été sélectionnés pour leur attitude favorable à l'agilité et leur enthousiasme face à cette nouvelle façon de gérer le développement logiciel. Le projet a rencontré de la résistance de la part des chargés de projets les plus expérimentés car ils se sont sentis mis de côté. Ils ne savaient plus quel était leur rôle, ce qui a fini par créer des tensions, des problèmes de communication et un manque de support des cadres pour les nouvelles équipes agiles. Les changements fréquents dans la composition des équipes empêchaient d atteindre une vitesse de croisière et, par ricochet, d obtenir une vélocité pouvant aider à la planification des itérations. Transformer un groupe d'individu en une équipe multidisciplinaire cohérente et productive se fait, selon Bruce W. Tuckman, en quatre étapes : formation de l équipe, la mise en conflit, l établissement des normes et la performance 4 ([10], p. 396) [11]. Les changements fréquents ont court-circuité ce processus, ce qui a eu pour effet de freiner la création d'équipes performantes. Ces ratés ont miné la crédibilité d'agile dans l'organisation. Une seule équipe résiste encore et toujours à l'envahisseur en continuant d'utiliser l'agilité dans la plupart de ses projets de développement. Le virage agile de l'entreprise a été amorcé discrètement à la mi-2013, laissant les équipes agiles à elles-mêmes, sans support officiel de la haute direction. L'implantation d'agile au niveau entreprise a véritablement commencé au début de l'année 2014, cette fois-ci, avec le support de la direction Principaux problèmes vécus pour intégrer l agilité et les méthodes non-agiles chez GFL La compagnie a décidé d'utiliser Scrum pour les raisons énumérées précédemment. Il faut comprendre l'essence de Scrum afin de mieux expliquer les problèmes d'intégration avec les méthodologies et pratiques déjà en place dans l'entreprise. Brièvement, Scrum est une méthode ayant pour but de faciliter la création de logiciels complexes en divisant le travail en morceaux plus petits. En effet, le développement Scrum est itératif, car les fonctionnalités sont modifiées et améliorées au fil du projet, et incrémental, 4 Traduction libre de «Forming -> Storming -> Norming -> Performing» 8

19 l'équipe ajoutant des fonctionnalités au fur et à mesure. Les livraisons itératives permettent d'aligner les priorités du développement avec celles du client. L'aspect incrémental permet de faire évoluer une fonctionnalité ou une section de l'application en permettant les modifications avant la livraison finale. «Scrum est fondé sur la théorie de contrôle des processus empiriques. Cette théorie affirme que la connaissance s'acquiert par l'expérience et favorise la prise de décision basée sur ce qui est connu. Scrum utilise une approche itérative et incrémentale pour optimiser la prévisibilité et le contrôle des risques.» ([12], p. 4) La structure légère d'une équipe Scrum permet de résoudre les problèmes lorsqu'ils se présentent, de s'améliorer et de communiquer directement et efficacement avec les autres membres de l'équipe [13]. Tout cela se retrouve dans les trois piliers de Scrum : la transparence, l'inspection et l'adaptation ([14], p. 4). Il y a trois rôles dans une équipe Scrum : le propriétaire de produit, l'équipe de développement et le Scrum Master ([15], p. 6). Le chargé de projet et son rôle dans un projet Scrum ne sont mentionnés nulle part dans le Scrum Guide [16]. D'autres méthodologies telles que DAD et SAFe abordent la question des rôles dans un projet agile (voir section 3.7). Dans une organisation telle que GFL, la livraison d'un projet est encore sous la responsabilité de plusieurs chargés de projets. Puisque le Scrum Master est un facilitateur et non un chargé de projet, il ne remplace pas le chargé de projet traditionnel. Le rôle du chargé de projet n'étant pas défini en Scrum, il peut s'en suivre une certaine confusion quant aux rôles et responsabilités des différentes parties. Scrum vise à faciliter le développement, mais il ne donne pas de conseils pour aider l'entreprise à passer à travers les différentes étapes d'approbation et de livraison du cycle traditionnel imposé par le bureau de projets. Dans le cas de GFL, il faut parler de plusieurs bureaux de projets, ce qui complexifie la tâche de tout projet impliquant plusieurs lignes d'affaires. Le sujet de l'arrimage avec les équipes externes, parfois non-agiles, n'est pas abordé par Scrum. Chez GFL, une équipe agile doit souvent interagir avec des équipes qui ne sont pas agiles. À cela s'ajoute le fait que plusieurs méthodes et pratiques non-agiles sont utilisées 9

20 dans tout le groupe. Cette confusion fait en sorte que plusieurs processus et leurs livrables doivent être respectés en même temps. Dans les quatre valeurs de l'agilité, il faut créer «des logiciels opérationnels plus qu une documentation exhaustive» [17]. La méthode Agile Modeling (AM) de Scott Ambler parle de «voyager léger» 5 [18]. Les documents créés durant un projet devront être mis à jour, sans quoi ils perdront de leur valeur et de leur pertinence avec le temps. En créant seulement des documents que l'on veut conserver plus tard, donc en voyageant léger au cours du projet, on n'a pas à faire l'effort de garder à jour une documentation vite devenue inutile ou obsolète. Donc, en agile, il faut documenter ce qui est utile à la bonne marche du projet et à la phase de maintenance en production. Rien de plus. «Les méthodes de documentation existantes ne conviennent pas aux projets agiles, qui favorisent le changement et livrent très rapidement» ([19], p. 1). En suivant le modèle traditionnel, l'organisation a imposé aux équipes agiles une rigidité qui nuit à l'efficacité et qui n'est pas du tout dans l'esprit des valeurs agiles Correspondance entre ce qui a été vécu par GFL et la littérature Il y a plusieurs bureaux de projets à travers GFL. Un bureau de projets d'entreprise existe au niveau du groupe financier. Ce bureau de projets doit coordonner les efforts des différents bureaux de projets des secteurs d'activité et des filiales dans le but d'harmoniser les différentes méthodologies et pratiques de gestion de projet à travers le groupe. Cette tâche est difficile à réaliser étant donné la taille de l'entreprise. Les difficultés d'intégration résultent des nombreuses acquisitions et des différentes méthodologies de développement en place qui entrent souvent en conflit entre elles. Non seulement il y a de la friction entre les équipes utilisant des méthodologies traditionnelles différentes, mais lorsqu'agile s'invite dans la danse, les conflits se multiplient. Sur les cendres du PDA, une méthodologie agile a été développée par le bureau de projets du groupe financier. Cette méthodologie se fonde sur la méthode DAD (Disciplined Agile 5 Traduction libre de travel light 10

21 Delivery) qui est supportée par IBM [20]. Cette version adaptée de DAD est encore en développement (elle est considérée comme étant au stade «alpha» au début de 2014) et commence à peine à être utilisée. Ce processus intègre le processus de gestion du cycle de développement logiciel et le processus de gestion du cycle de vie des projets. Ces processus sont eux-mêmes divisés en sous-processus qu'on ne juge pas utiles de décrire pour les fins de cet essai. Il est difficile d'utiliser des méthodes agiles dans un tel contexte sans perdre à la fois les avantages liés à de telles méthodes, et ceux des pratiques d'un processus traditionnel bien connu de tous ([21], pp ). Les conflits entre les méthodes agiles et non-agiles tirent leur source dans la nature même de chaque méthode. Les méthodes d'estimation ne sont pas du tout les mêmes. Le degré d'incertitude est plus grand en agile pour les éléments qui seront développés plus tard dans le projet, alors que les processus traditionnels tentent de tout prévoir à moyen et à long terme. Les processus évolutifs agiles se heurtent aux méthodes classiques qui se veulent exactes ([22], p. 34). D'après un sondage de Forrester mené pour le compte du PMI en 2011, 33% des bureaux de projet sont favorables à agile, Scrum ou aux méthodes Lean. La majorité est restée fidèle aux méthodes traditionnelles en cascade et au PMBOK MD ([23], p. 23), bien que le PMBOK MD n'interdise pas formellement le développement itératif et incrémental. Il semble que les bureaux de projet chez GFL ne soient pas différents sur ce point. L'équipe de méthodologie de GFL a bien compris l'importance de ne pas forcer tout le monde et chaque projet à utiliser la même méthode en tout temps. Pour qu'agile soit un succès chez GFL, il est clair pour l'équipe de méthodologie qu'il faille utiliser les méthodes appropriées et les adapter selon la nature du projet. Le Franhofer Institute for Experimental Software Engineering, Nokia et Motorola ont tous compris l'importance d'adapter les méthodes agiles au contexte du travail dans une grande organisation ([24], p. 30). Les équipes agiles chez GFL ont de la difficulté à évoluer dans un cadre où l'on retrouve différentes méthodologies non-agiles en place. La collaboration avec les équipes non-agiles n'est pas toujours facile, vu les écarts entre les différentes attentes, livrables et méthodes ([25], p. 31). Chez Nokia, un projet pilote suivant la méthode XP a démontré que le problème n'est pas l'introduction de nouvelles pratiques, mais l'absence d'interfaces bien définies entre 11

22 les pratiques existantes et ces nouvelles pratiques. «Dans une grande organisation, un projet ne peut être totalement indépendant. Il doit interagir et suivre les règles de l'organisation» (Traduction libre) ([26], p. 30). La spécification des besoins des projets non-agiles chez GFL suit un long processus de création et d'approbation. Le même phénomène se produit dans les grandes entreprises produisant du logiciel. Les approches traditionnelles, «comme les spécifications des besoins complètes livrées entièrement d'avance, ont un cycle de rétroaction qui se compte en semaines ou en mois, ce qui les rend plus risquées et plus chères» (Traduction libre) ([27], p. 693). Les approches itératives comme agile se heurtent souvent aux besoins de gouvernance, de gestion du risque et de contrôle des grandes organisations ([28], p.1). La figure suivante donne un exemple de projet agile évoluant dans une grande entreprise. Fig. 2: Environnement d'un projet pilote XP chez Nokia La création d'interfaces entre les nouvelles et les anciennes pratiques pose un défi pour les équipes agiles. Traduction libre Source : Lindvall, M. et al., 2004 ([29], p. 30). 12

23 La documentation en agile se heurte aux méthodes de documentation classiques déjà en place. D'après Asma Hachemi et Mohamed Ahmed-Nacer ([30], p. 2), la documentation classique a de nombreuses lacunes : «Dans la majorité des projets, une méthode de documentation nécessite une équipe dédiée pour pouvoir être mise en place. Ainsi, une grande proportion du coût du procédé de développement est induite par la production de documentation.» «Les documents générés par ces méthodes sont nombreux et volumineux. Les erreurs et les incohérences sont ainsi multiples.» «La mise à jour de la documentation en même temps que la mise à jour du logiciel est souvent négligée dans les méthodes de documentation.» «Une méthode de documentation appliquée lors d un projet suggère la création d un ensemble standard de documents; sans vérifier pour chaque document son utilité par rapport au projet en cours.» «Certains documents sont exigés dans une méthode juste pour le besoin de communication; alors que d autre moyens doivent être privilégiés pour communiquer (les outils de travail collaboratif, les réunions face à face, les conférences vidéo ou téléphoniques).» «Enfin, ces méthodes de documentation ne conviennent pas aux procédés agiles qui favorisent le changement et livrent très rapidement. En effet, ces méthodes livrent la documentation à chaque fin d itération, cette documentation doit être synchronisée avec le logiciel. De plus, ces méthodes traitent de nombreux changements qui doivent se refléter sur la documentation.» On a constaté ces problèmes chez GFL et ailleurs dans l'industrie. Par exemple, chez ABB, une équipe agile employant XP devait utiliser la documentation finale produite avant le début de la conception et de l'implémentation, et ce, sans le concours de l'équipe ([31], p. 31). Ceci est bien entendu contraire aux pratiques et aux principes de XP et de l'agilité en général. 13

24 GFL a toutefois bien saisi qu'en agile, il est important de produire une documentation axée sur le produit et non sur le projet. Agile ne cherche-t-il pas à produire «des logiciels opérationnels plus qu une documentation exhaustive»? [32]. 14

25 Chapitre 2 Problématique 2.1 Problématique de la recherche Question : Existe-t-il des meilleures pratiques pouvant faciliter la gestion du processus de spécification des besoins en agile dans une grande organisation financière utilisant des méthodologies de développement logiciel non-agiles? Les problèmes rencontrés par l'organisation lors de la mise en place d'agile poussent à chercher des solutions pouvant faciliter l'intégration d'agile dans les grandes entreprises financières utilisant des méthodologies de développement non-agiles. L'arrimage entre les méthodes agiles et non-agiles en vigueur dans ce type d'organisation empêche de tirer profit des bénéfices liés à l'agilité Description courtes précisions sur la question Un début de la rédaction de cet essai, l'objectif principal était de savoir s'il existe des meilleures pratiques, ou à tout le moins des pistes de solution, qui pourraient permettre d'adopter une approche agile dans un tel contexte. Ce sujet étant trop vaste pour le cadre de cet essai, il est préférable de se concentrer sur la spécification des besoins en agile, ce qui n'empêchera pas de traiter d'enjeux plus globaux qui influenceront ladite spécification des besoins en agile Principales hypothèses Les principales hypothèses sont, dans le contexte d une grande organisation financière : 1) Il est très difficile, voire quasi impossible d'utiliser uniquement des méthodes et pratiques de développement agile. 15

26 2) Il est possible de tirer profit de l agilité pour améliorer la productivité, la qualité et la satisfaction du client (interne et externe). 3) L'implication du bureau de projets est critique pour une implantation de l'agilité réussie. Il est difficile d'utiliser uniquement des méthodes et pratiques de développement agiles dans une grande organisation financière. La taille de ces entreprises, le volume important de documentation généré par un projet et les structures hiérarchiques et départementales déjà en place peuvent s'avérer des obstacles de taille à une migration totale vers des méthodologies agiles. La complexité de ces organisations et les multiples parties prenantes dans un projet rendent difficile la livraison d'un projet en agile, surtout lorsque de multiples méthodologies sont utilisées pour réaliser un même projet. La nature conservatrice de l'industrie financière est un autre frein à l'adoption d'agile. Elle peut même empêcher la migration d'une organisation vers l'agilité. Malgré cela, il est tout à fait possible de bénéficier des principes agiles pour améliorer la productivité des équipes de développement. Le fait qu'agile soit orienté vers la production de logiciels de qualité répondants aux besoins du client fait en sorte que les entreprises ne peuvent ignorer totalement les bénéfices potentiels de l'agilité. Le bureau de projets est d'une importance capitale dans l'adoption et le déploiement d'agile. Il est le mieux placé pour créer les ponts nécessaires entre les équipes de développement et les parties prenantes travaillant dans diverses filiales ou vice-présidences. Sans l'aide et l'appui du bureau de projets, les initiatives agiles peuvent se buter non seulement aux processus de développement des équipes non-agiles, mais aussi aux processus des autres parties prenantes qui suivent des processus administratifs déjà établis. Le bureau de projets est crucial pour éviter la pseudo-agilité des projets qui perpétuent les livraisons séquentielles qui ne sont pas itératives et incrémentales. Il est important de noter que le bureau de projets devra savoir ce qui se passe sur le terrain, ce qui n'est pas toujours le cas chez GFL. 16

27 2.2 Approche utilisée Une revue de la littérature disponible fut de mise : recherche d'articles et de livres sur l'agilité en général, sur les expériences agiles en grande entreprise et sur la spécification des besoins en agile. Par la suite, afin de mieux connaître la situation de l'agilité, et plus précisément de la spécification des besoins en agile chez GFL, un sondage a circulé parmi les employés en TI de l'entreprise. L'analyse des résultats du sondage se retrouve au chapitre quatre. La documentation rendue disponible par l'entreprise donne un aperçu de ses plans quant au futur de l'agilité. Ces documents donnaient aussi des informations sur l'historique de l'agilité dans la filiale de GFL. Georges Blanchard 6, travaillant pour la direction des systèmes d'information, a passé en revue la documentation existante afin de faire bénéficier cet essai de ses lumières sur les expériences de projets en agile et les plans de déploiement de l'agilité dans l'entreprise. 2.3 Méthodologie La méthodologie du sondage est essentiellement tirée du livre Sondages: Histoire, Pratique et Analyse d'andré Tremblay, Gaëtan Morin Éditeur, 1991, Boucherville, Québec, Canada ([33], pp.65 et suivantes). 1) Motivation Intérêt pour la recherche : Savoir comment améliorer l'intégration de l'agilité en entreprise dans le processus de gestion de la spécification des besoins. Objectifs de la recherche : Mieux connaître l'utilisation de l'agilité, les connaissances et attitudes face à l'agilité chez GLF. Problématique générale : L'utilisation de l'agilité dans les grandes entreprises financières est difficile vu les processus stricts et la hiérarchie rigide de ce type d'organisation. 6 Nom fictif 17

28 2) Définition du thème de la recherche et de la question générale La coexistence dans une grande organisation très hiérarchisée de méthodes de développement de natures différentes est-elle réalisable de façon efficace? Si oui, comment peut-on arriver à tirer profit des avantages de l'agilité dans un tel contexte? En d'autres mots : existe-t-il des meilleures pratiques pouvant faciliter la gestion du processus de spécification des besoins en agile dans une grande organisation financière utilisant des méthodologies de développement logiciel non-agiles? 3) Connaissance de l'objet et construction de la problématique a) Définition de la problématique spécifique (modélisation) : Identification des dimensions conceptuelles : Collecte des besoins en mode agile Mise en œuvre de l'agilité en entreprise Processus de développement agile Processus de développement classiques Processus de développement classiques b) Mise en relation des éléments du problème : La collecte des besoins en mode agile se heurte à l'environnement non-agile des organisations. En effet, la mise en œuvre de l'agilité demande une migration des processus de développement non-agile vers des processus agiles. L'équipe de développement devra tout de même continuer de travailler avec des équipes non-agiles, ce qui peut compliquer la collecte des besoins en mode agile. 18

29 Ce mode de collecte des besoins demande une plus grande implication des parties prenantes ce qui peut être difficile à accomplir dans les projets de grande envergure. Agile serait, pour certains, inadapté «à des projets gigantesques où la taille et le nombre d intervenants limitent les possibilités de discuter face à face.» [34] c) Cadre théorique Les recherches sur l'agilité ont abouti à la création de méthodologies fondées sur des généralisations empiriques. Elles sont «déduites d'une formalisation théorique fondée sur un schéma propositionnel, reposent sur des relations constantes entre un certain nombre de variables observées dans la réalité empirique et étayées par un réseau d'hypothèses et d'intuitions.» ([35], p. 76) L'agilité est donc qualifiée d'empirique plutôt que de modèle théorique. [36] d) Recherche documentaire (faits, chiffres) Les données proviendront des articles, des sites Internet et des livres traitant de l'agilité et des processus agiles de spécification des besoins en particulier. e) Informateurs clés Des praticiens en agile serviront d'informateurs sur l'agilité en grande entreprise et chez GFL en particulier. 19

30 4) Définition de la population à laquelle les résultats seront généralisés La population visée par ce sondage se compose de professionnels impliqués dans le développement de logiciels destinés à la compagnie elle-même et à ses clients. Cette population est composée des sous-groupes suivants : Analystes Architectes Cadres Chargés de projet Concepteurs d'interface utilisateur Développeurs logiciel Spécialistes en assurance-qualité 5) Démarche méthodologique Des concepts aux indicateurs : ([37], p. 79) a) Représentation imagée du concept D'après le manifeste agile, les signataires dudit manifeste valorisent [38] : «Les individus et leurs interactions plus que les processus et les outils» «Des logiciels opérationnels plus qu une documentation exhaustive» «La collaboration avec les clients plus que la négociation contractuelle» «L adaptation au changement plus que le suivi d un plan» Douze principes sous-jacents donnent plus d'informations sur ces quatre valeurs fondamentales d'agile. Vous pouvez les consulter sur le site du manifeste agile [39]. 20

31 b) Spécification des dimensions ([40], p.80) Problèmes de compréhension des concepts agiles dans l'industrie. Pour plusieurs personnes, développer en agile signifie n'avoir à peu près aucun processus et rédiger une documentation réduite à sa plus simple expression. Pour d'autres, le développement agile consiste à réduire le contrôle et une diminution des efforts d'analyse et de planification. [41] Difficultés d'intégration de l'agilité avec les processus en place dans les grandes entreprises (il faut adapter les méthodologies agiles aux grandes organisations). Problèmes d'arrimage des méthodes agiles avec un environnement non-agile. c) Choix des indicateurs observables Attitude face à l'agilité. Niveau des connaissances des parties prenantes en agilité. Niveau d'expérience des parties prenantes en agilité. Attitude des parties prenantes impliquées dans la création de la spécification des besoins en agile. Niveau d'implication des parties prenantes lors de la création de la spécification des besoins. Implication du propriétaire du produit (PO) dans la création de la spécification des besoins. Degré de concentration ou dispersion géographique des parties prenantes. Outils de développement utilisés. Pratiques et processus de développement. Existence de passerelles entre les équipes agiles et l'environnement non-agile. Existence ou non de plan organisationnel de développement de l'agilité. 21

32 6) Choix d'un design a) Enquête longitudinale Ne voulant pas mesurer l'évolution de la situation dans le temps, un enquête longitudinale sur l'utilisation d'agile ne sera pas nécessaire. b) Enquête synchronique Une enquête synchronique sera lancée pour donner un portrait de la situation de l'agilité dans l'organisation à un moment précis. Préalable : identification et accès à la population cible. 7) Démarche technique a) «Opérationnalité» des questions (intervention) Les questions sont pour la plupart de type fermées, à choix multiples ou dichotomiques (vrai ou faux; oui ou non). Ce type de question facilite la compréhension de la question et fixe le sens de la réponse tout en étant plus faciles à compiler ([42], p. 4). Pour permettre une plus grande liberté d'expression des participants, ils ne seront pas forcés à répondre lorsqu'ils n'auront pas la réponse à une question. Dans certains cas, le choix «autre» sera prévu. «Pour rassurer la personne interrogée et obtenir des réponses fiables, il convient de procéder en entonnoir en partant des questions les moins engageantes aux questions les plus personnelles et du général au particulier» ([43], p. 24). b) Formulation des questions et instructions Le sondage sera disponible en français et en anglais. Une attention toute spéciale devra être portée au sens des questions afin d'éviter des résultats faussés par un sens différent dans une langue ou dans l'autre. 22

33 8) Choix du média d'enquête Le sondage sera de type auto-administré ([44], p. 111). Les participants seront invités à répondre à un sondage sur Internet. Ce choix permettra de rejoindre des participants partout dans l'entreprise qui a des bureaux à plusieurs endroits au Canada et aux États-Unis. Cette technique est appelée auto-rapport. 9) Échantillonnage a) Possibilité d'atteindre la population Il ne sera pas possible d'atteindre tous les employés en TI de la compagnie, les envois de courriels étant contrôlés. Toutefois, il est possible de rejoindre des usagers via le réseau social interne et via certains partenaires dans l'entreprise. Le sondage circulera sur LinkedIn et via une liste de contacts dans l'industrie. Pour élargir le bassin de répondants, il faudra faire appel aux groupes LinkedIn ayant pour intérêt l'agilité ou les TI en général. b) Choix de la technique d'échantillonnage L'échantillonnage sera de nature non-probabiliste. En effet, le recours aux réseaux sociaux et à l'internet en général ne permet «pas d'évaluer la probabilité pour chaque unité de la population d'être échantillonnée, ni d'assurer que toutes les unités de la population ont une chance d'être incluses à l'échantillon.» ([45], p. 162) 10) Démarche d'enquête a) Prétest reformulation prétest reformulation Le sondage sera validé par le directeur académique et le directeur professionnel. Par la suite, il sera testé sur une équipe de développement à l'interne. 23

34 b) Réalisation de l'enquête Pour faciliter sa diffusion, le sondage sera envoyé à certains contacts dans l'entreprise. Il sera aussi publié sur le réseau social interne. De plus, un sondage parallèle sera publié sur les groupes LinkedIn jugés pertinents. Il sera aussi envoyé à des contacts travaillant en développement logiciel dans le secteur financier. c) Sélection d'une équipe, d'une firme On a choisi le site de sondage fluidsurveys.com. Ce service permet les sondages multilingues et offre des services de rapport et d'interprétation des résultats. d) Coûts et contrôle de la qualité Les outils de sondage en ligne sont peu coûteux. Puisque le sondage est auto-administré, aucun contrôle de la qualité du travail des intervieweurs n'est nécessaire. e) Relance des refus Vu la difficulté de contacter directement les employés du secteur des TI de l'entreprise, il ne sera pas possible de savoir combien de personnes ont reçu le lien du sondage sans aller sur le site dudit sondage. 24

35 2.4 Évaluation de la validité du sondage Le questionnaire du sondage est disponible à l'annexe 1 pour la version française et à l'annexe 2 pour la version anglaise. Les résultats sont disponibles à l'annexe 3. Quelques mots de Statistiques Canada sur la taille de l'échantillon : «La taille de la population : Dans une certaine mesure, plus la population est importante, plus on a besoin d'un échantillon de plus grande taille. Cependant, une fois qu'on a atteint un certain niveau, une augmentation de la population n'a plus d'influence sur la taille de l'échantillon. La taille de l'échantillon nécessaire pour atteindre un certain degré de précision, par exemple, sera à peu près la même pour une population d'un million que pour une population deux fois plus importante.» [46] 77 réponses complètes ont été obtenues dans un bassin potentiel d'environ 1000 employés en TI impliqués dans le développement logiciel chez GFL, soit environ 8% de la population étudiée. Cette proportion est largement suffisante pour obtenir un degré de précision acceptable d'après cette explication de Statistique Canada Échantillon utilisé (qui pourquoi - comment) Qui? La population visée par ce sondage se compose de professionnels impliqués dans le développement de logiciels pour usage interne et comme outils de service à la clientèle. Cette population était composée des sous-groupes (dérivés de la liste du point 2.3, point 4) : Analyste d'affaire Analyste de système (une catégorie d'analyste d'affaire chez GFL) Architecte Administrateur de bases de données Cadre intermédiaire 25

36 Cadre supérieur Chargé de projet Chef d'équipe Concepteur d'interface utilisateur Développeur logiciel Spécialiste en assurance-qualité Pourquoi? Le but recherché était d'avoir l'heure juste quant à l'utilisation de l'agilité et de la spécification des besoins en agile à travers le groupe. Diverses catégories d'employés impliqués dans le processus de développement logiciel ont été choisies afin d'avoir un portrait plus global et plus juste de la situation. Ces catégories englobent les groupes d'employés participant aux projets de développement les plus nombreux. Comment? Le sondage ne faisait pas partie d'une enquête longitudinale puisque l'objectif n'était pas de connaître l'évolution des pratiques et opinions dans le temps. On a donc opté pour une enquête de type synchronique dans le but d'avoir un portrait de la situation à un moment donné. Le sondage a été envoyé à plusieurs équipes de TI dans l'entreprise et fut publié sur le réseau social interne de l'entreprise. Un sondage ouvert à tous les usagers du réseau social LinkedIn qui sont membres de groupes de TI a aussi circulé. Malheureusement, il n'y avait pas assez de répondants sur LinkedIn pour permettre de faire des comparaisons avec le sondage interne. Ces données ne peuvent donc pas être utilisées pour enrichir la compréhension du phénomène. Ce sondage Internet est de type non-probabiliste et volontaire. Étant donné la répartition géographique et la variété des participants, et les règles de communication de l'entreprise, on 26

37 n'avait guère le choix de fonctionner sur une base volontaire. Il faut être conscient des limites de la méthode de sondage. «Le fait d'échantillonner des participants volontaires plutôt que la population en général peut introduire des biais marqués. Souvent, à l'occasion des sondages d'opinion, seuls les gens qui se soucient assez fortement d'une façon ou d'une autre de la question étudiée ont tendance à y répondre. La majorité silencieuse n'y répond généralement pas, ce qui entraîne un important biais sur le plan de la sélection.» [47] Pour pallier à tous ces problèmes et aux limites de le méthode, il faut donc comparer les résultats avec ceux des études et sondages menés par des chercheurs et des organismes se tenant bien au fait des tendances de l'industrie. 27

38 Chapitre 3 Implantations de la gestion des spécifications en agile 3.1 Critères de sélection Pour implanter les principes agiles, de multiples méthodes agiles et des méthodes puisant dans plusieurs décennies de recherche sur la gestion de projet et les processus (diagrammes d'ishikawa, principes Lean) sont disponibles. Les méthodes les plus répandues dans l'industrie et celles qui sont présentement étudiées chez GFL par l'équipe de méthodologie agile et les praticiens agiles ont été sélectionnées. Dans un avenir rapproché, l'organisation planifie une utilisation d'agile à grande échelle. 3.2 Méthodes et pratiques évaluées Les pratiques liées à la spécification des besoins en agile et à l'intégration d'agile avec un cycle de développement en cascade seront évalués dans les pages qui suivent. On a voulu savoir si les différentes méthodologies peuvent aider au développement d'une spécification des besoins en agile dans une grande entreprise utilisant des méthodes traditionnelles. La littérature fournit divers points de vue sur certains aspects du sujet. Les méthodes sur lesquelles cet essai met l'accent sont : Scrum XP (Extreme Programming) DAD (Disciplined Agile Delivery) SAFe (Scaled Agile Framework) AM (Agile Modeling) 28

39 Scrum et XP Scrum et XP sont les méthodes agiles les plus répandues dans l'industrie [48]. De plus, elles sont utilisées seules ou conjointement par certaines équipes chez GFL. Étant bien connues dans le monde agile, il n'est pas nécessaire d''expliquer ces méthodes plus en détail. AM, SAFe et DAD L'adoption de AM, SAFe et DAD progresse considérablement dans l'industrie tout comme chez GFL, d'où leur inclusion dans l'essai. AM se penche sur la modélisation en agile. SAFe et DAD tentent de résoudre les problèmes d'intégration de l'agilité dans les grandes organisations. Quelques mots sur AM, SAFe et DAD. AM La FAQ du site web d'am de Scott Ambler donne la définition suivante : «Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and lightweight manner. You may take an agile modeling approach to requirements, analysis, architecture, and design.» 7 [49] AM se concentre sur la modélisation et la documentation. Ce n'est pas un processus de développement logiciel complet. AM fournit des pratiques pouvant aider à la spécification des besoins. 7 La modélisation agile (AM pour Agile Modeling) est une méthodologie basée sur des pratiques ayant pour but de modéliser et documenter efficacement des systèmes logiciels. En bref, AM est une collection de valeurs, principes, et pratiques de modélisation logicielle qui peut être utilisée dans des projets de développement efficacement, et sans lourdeur. Vous pouvez utiliser l'approche AM pour la spécification des besoins, l'analyse, l'architecture et le design. (traduction libre) 29

40 SAFe Sur le site officiel de Scaled Agile Framework, Dean Leffingwell décrit SAFe comme ceci : «The Scaled Agile Framework (pronounced SAFe ) is an interactive knowledge base for implementing agile practices at enterprise scale.» 8 [50] SAFe se base sur le site scalingsoftwareagilityblog.com et sur deux livres de Dean Leffingwell : Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) [51] Scaling Software Agility: Best Practices for Large Enterprises (2007) [52] SAFe intègre les pratiques de développement itératif et incrémental (Scrum, XP), de Lean, du développement agile, des principes de flux de développement de produit et tire partie des expériences agiles menées en grande entreprise. Les activités sont divisées en trois niveaux [53]: le niveau du portefeuille le niveau du programme le niveau de l'équipe Une revue des activités de spécification des besoins de SAFe sera faite à tous les niveaux. 8 Scaled Agile Framework (prononcé comme le mot anglais safe) est une base de connaissances interactive servant à implanter agile au niveau entreprise. (traduction libre) 30

41 DAD Dans leur livre Disciplined Agile Delivery [54], Scott Ambler et Mark Lines définissent DAD comme suit : «The Disciplined Agile Delivery (DAD) process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a riskvalue lifecycle, is goal-driven, is scalable, and is enterprise aware.» 9 ([55], p. 6) DAD est une approche supportée par IBM qui a été adoptée et adaptée par GFL. DAD aborde tous les aspects de l'agilité durant tout le cycle de développement logiciel en tenant compte du contexte global de l'entreprise. Le processus «DAD a adopté des stratégies empruntées aux méthodes suivantes» ([56], pp. 9-10) : Scrum XP AM UP (Unified Process) AD (Agile Data) Kanban Il est à noter que l'un des coauteurs du livre Disciplined Agile Delivery, Scott Ambler, est le créateur d'am et AD, entre autres. D'autres méthodes ont influencé la création de DAD comme Crystal ou DSDM, mais leur influence est moins importante. 9 Le processus de livraison agile DAD (Disciplined Agile Delivery) est une approche agile hybride de livraison de solutions TI centrée sur les gens. Elle met l'accent sur l'apprentissage. Son cycle de vie vise la livraison de valeur et la diminution du risque. DAD est axé sur l'atteinte des objectifs, est évolutif et tient compte de l'environnement corporatif. (traduction libre) 31

42 3.3 La pyramide de la spécification des besoins Fig. 3: La pyramide de la spécification des besoins Traduction libre Source : Leffingwell, D., 2007 ([57], p. 214) Images : Master isolated images, 2011, FreeDigitalPhotos.net, # Erik Pitti, San Diego, CA, USA (IBM System/360 Mainframe, téléversé par Mewtu) 10, via Wikimedia Commons La littérature a produit un nombre substantiel d'écrits sur le sujet de la spécification des besoins. Cette pyramide de Leffingwell et Widrig donne une vue d'ensemble de la question. Au sommet de la pyramide, on retrouve les besoins des usagers et le domaine dans lequel ils évoluent. Une fois les besoins et le domaine bien compris, les équipes de développement conçoivent les fonctionnalités et les spécifications logicielles servant à mettre en place la solution. Les défis de la mise en place d'une solution répondant aux besoins d'une grande organisations aux multiples parties prenantes est à l'origine des méthodes agiles et plus spécifiquement des méthodes agiles d'entreprise comme SAFe et DAD. Cet essai décrit comment Scrum, XP, AM, DAD et SAFe peuvent faciliter le développement de solutions 10 CC-BY-2.0 ( 32

43 logicielles à valeur ajoutée pour une grande entreprise. 3.4 Comparaison des pratiques de spécification des besoins Pratiques Les différentes méthodes énumérées précédemment proposent divers outils pour faciliter la création de la spécification des besoins. Pour chaque méthode, seules les pratiques qui touchent à la création de la spécification des besoins ont été retenues. La figure suivante dresse un portrait global des différentes pratiques liées au processus de spécification des besoins pour Scrum, XP, AM, SAFe et DAD. Fig. 4: Pratiques reliées aux besoins Sources : Ambler, S. W. et Lines, M., 2012 ([58], p. 44) Wells, D., 1999 [59] Ambler, S. W., 2012 [60] Leffingwell, D., 2011 ([61], p. 28, pp , pp ) 33

44 Cette vue à haut niveau donne un aperçu des pratiques liées à la spécification des besoins, telles que prescrites par ces méthodes. Il est à noter que les pratiques de Scrum, XP et AM peuvent fonctionner ensemble. Il en sera question plus tard, au point 3.9. Toutes, sauf XP, ont comme pratique l'utilisation des listes d'éléments de travail. La gestion des priorités est un élément central de ces méthodes, et particulièrement les méthodes d'entreprise comme SAFe. Ces pratiques et outils reflètent les préoccupations de chaque méthode agile étudiée ici. Scrum, XP et AM se concentrent sur l'exécution et les activités de construction du logiciel ([62], p. 3) et donc, n'ont pas vraiment de vision plus large. Ces méthodes ne se préoccupent pas de l'intégration de l'agilité au niveau entreprise. Ils aident les équipes à recueillir les besoins des clients, mais ils ne s'inscrivent pas dans une perspective de gestion des besoins de l'entreprise au niveau stratégique. 34

45 SAFe SAFe prescrit une méthode de gestion des besoins à trois niveaux. Le niveau du portefeuille, du programme et des équipes. Fig. 5: Le cycle de la spécification des besoins selon SAFe Traduction libre Sources : Leffingwell, D., 2011 ([63], p. 87) Leffingwell, D., 2013 [64] Tout démarre lors du processus budgétaire où l'on détermine l'attribution des ressources regroupées par thèmes d'investissements. Par exemple, un département décide d'allouer quinze pour cent du budget d'investissement en TI à l'intranet et vingt-cinq pour cent au site transactionnel. Ces thèmes d'investissements vont se transformer dans le portefeuille en descriptions de projet à haut niveau appelées épopées 11 ([65], p. 450). En effet, au niveau du portefeuille, les gestionnaires de portefeuille créent des épopées pour obtenir une liste de besoins d'affaires (le quoi) et architecturaux (le comment) à partir d'une liste de thèmes d'investissements ([66], p. 44). Ces épopées se résument à une description de quelques lignes tout au plus. Ces épopées à haut niveau sont recueillies dans des carnets de portefeuille hiérarchisés [67]. 11 Traduction libre du terme epic 35

46 Par la suite, les épopées sont divisées en fonctionnalités qui sont hiérarchisées dans le carnet de programme. Ces fonctionnalités sont alignées sur la vision et leur livraison est alignée sur la feuille de route du programme. Finalement, ces fonctionnalités sont elles-mêmes divisées en récits utilisateurs (aussi appelés scénarios utilisateurs) et hiérarchisées dans les carnets des équipes afin qu'elles puissent démarrer les activités de construction. En plus d'intégrer les techniques de spécification des besoins de Scrum et XP, SAFe propose des boîtes à outils pour les équipes et les programmes ([68], pp et pp ). Ces techniques seront utiles pour mieux définir les fonctionnalités et les récits utilisateurs à partir des épopées écrites par les gestionnaires de portefeuilles. Ces trois paliers constituent un tout cohérent où l'alignement des équipes, du programme et du portefeuille constituent un processus de livraison logicielle répondant à la fois aux objectifs des équipes et aux objectifs stratégiques de l'entreprise ([69], pp ). DAD À la figure 8, on voit que SAFe est l'une des nombreuses méthodes englobées dans DAD. DAD étant un outil de décision non-prescriptif, toute méthode de cueillette de l'information proposée par SAFe, XP, AM et consort peut être utilisée dans le cadre de DAD. Il peut être difficile de choisir la bonne approche ou le bon outil parmi ceux qui sont mentionnés à la figure 4. La figure suivante propose une liste de paramètres à considérer, et quelques suggestions en caractères gras, pour les équipes qui ne disposent pas du temps et des ressources nécessaires pour adapter ces processus à leur situation particulière. Plus une pratique se rapproche de la pointe d'une flèche, plus elle est adéquate pour un projet agile. Le niveau de détail peut être constitué d'un simple carnet de récits utilisateurs dans une petite équipe de développement. Pour une équipe travaillant sur un projet lancé en réponse à une exigence réglementaire spécifique (santé, militaire, sécurité) où tout peut être fixé à l'avance avec un grand niveau de certitude, avec une envergure précise et non-négociable, une spécification des besoins très détaillée est envisageable. Le niveau de détail 36

47 correspondra donc à la nature du projet et au contexte dans lequel il évolue [70]. Le type de vue choisi servira à augmenter la compréhension des récits utilisateurs ou de la documentation plus classique en lui donnant une dimension plus visuelle (maquette d'interface, diagramme de classe, etc.). Fig. 6: Exploration de la portée initiale du projet selon DAD Traduction libre Source : Ambler, S. W., 2013 [71] La stratégie de modélisation variera selon le contexte. Il est possible d'utiliser une ou plusieurs techniques selon le degré d'implication et le disponibilité des parties prenantes dans le projet. La stratégie de gestion des listes de travail sert à gérer les changements apportés au projet par le client ou d'autres parties prenantes. Vous pouvez opter pour la gestion de carnet de Scrum axée sur le valeur ajoutée ou la liste de travail de DAD axée sur la gestion des risques, ou la méthode WSJF de SAFe. Une approche plus formelle peut être à considérer 37

48 dans un environnement plus contrôlé. Les besoins non-fonctionnels peuvent être énoncés en simples récits techniques ou sous forme de liste plus exhaustive si le degré de difficulté technique ou la complexité du domaine d'affaire est élevé. En résumé, il faut utiliser les outils les mieux adaptés au projet afin de mieux comprendre les besoins du client et des parties prenantes. Ces diverses pratiques couplées à des méthodes entreprise comme SAFe et DAD facilitent la création et l'évolution de la spécification des besoins au cours d'un projet agile, même dans une entreprise plus ou moins grande qui n'est pas totalement agile. 3.5 Comparaison des principes de spécification des besoins Essentiellement, Scrum, XP, AM, SAFe et DAD s'appuient sur les mêmes quatre valeurs et douze principes du manifeste agile. DAD et SAFe apportent quelques modifications aux principes agiles et enrichissent leur boîte à outil avec des principes importés du monde Lean. DAD modifie légèrement deux des valeurs-clés de l'agilité ([72], pp ) : «Des solutions (NDLR : au lieu de «logiciels») opérationnelles plus qu une documentation exhaustive.» «La collaboration avec les parties prenantes (NDLR : au lieu de «clients») plus que la négociation contractuelle.» Ces altérations semblent triviales, mais elles marquent une évolution dans la façon de concevoir la place de l'agilité dans une organisation. L'objectif n'est plus de simplement livrer un logiciel, mais bien une solution globale qui inclut le matériel, les processus qu'il supporte, et la documentation. La collaboration n'est pas limitée aux clients, car l'apport des représentants des diverses parties prenantes est essentiel pour bien comprendre les besoins auxquels la solution va répondre. 38

49 DAD apporte d'autres modifications aux douze principes agiles pour refléter les valeurs agiles à la sauce DAD. Notons l'ajout de trois nouveaux principes aux douze du manifeste ([73], p. 32) : «Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.» 12 «Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.» 13 «The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams.» 14 DAD prend en compte le fait qu'une équipe agile évolue dans un environnement où l'on retrouve des systèmes déjà existants et des services, des processus déjà en place. Ce sont à la fois des contraintes et des actifs dont il faudra tenir compte pour livrer une solution avec succès. La visualisation des flux et la minimisation des travaux en cours sont des emprunts que DAD a fait au mouvement Lean, qui lui même tire ses sources dans le système de production Toyota. La gestion des flux et l'élimination du gaspillage sont des concepts-clés de Lean. Les stocks, représentés ici par les travaux en cours, font partie d'un des sept gaspillages (muda en japonais) [74]. DAD a importé de Lean un outil très connu, le tableau Kanban, qui sert essentiellement à gérer les flux et les travaux en cours. Le développement logiciel Lean applique ce principe de gestion des flux à la fois aux fournisseurs et aux clients de toute la chaîne de valeur de l'organisation. Tout comme agile, Lean a pour but de livrer de la valeur rapidement de façon soutenable. Il est lui aussi basé sur le respect et l'amélioration continue. ([75], p ) Un projet agile dans une moyenne ou grande entreprise évolue rarement, pour ne pas dire 12 Tirer profit et faire évoluer les actifs de l'écosystème organisationnel et collaborer avec les personnes responsables pour atteindre ces objectifs. (traduction libre) 13 Visualisez le flux afin d'améliorer la fluidité de la livraison tout en gardant les travaux en cours au minimum. (traduction libre) 14 L'écosystème organisationnel doit évoluer pour refléter et améliorer le travail des équipes agiles, tout en étant suffisamment souple pour continuer de supporter les équipes non-agiles ou hybrides. (traduction libre) 39

50 jamais, dans un univers où tout est agile. De multiples approches de livraison sont utilisées dans les entreprises. La stratégie TI et la stratégie de gouvernance devront tenir compte de ce fait pour que les équipes puissent travailler efficacement. Les entreprises qui appliquent à tous les projets TI la même solution de livraison finissent par avoir des difficultés ([76], p. 32). Une organisation devra non seulement adopter ses pratiques, mais aussi la culture de l'agilité pour pleinement en tirer profit. Un tel bouleversement peut entraîner des conflits si l'adoption d'agile ne s'opère pas autour d'équipes converties à l'agilité. Il ne faut pas sous-estimer un éventuel choc de valeurs car il peut aboutir à des conflits à l'intérieur de l'organisation [77]. 3.6 Pratiques et processus (Liens entre l'agilité et les processus non-agiles) Il n'est pas facile d'intégrer agile dans les entreprises dont les pratiques et la culture d'entreprise sont plutôt de type traditionnel. Les processus d'affaire et les processus TI en place sont bien souvent le reflet de l'état d'esprit et de la culture organisationnelle ([ 78], p. 252). En ce qui concerne la spécification des besoins, pour les traditionalistes, il est courant de croire qu'il est possible de concevoir une solution de A à Z et régler tous les problèmes potentiels avant même d'avoir commencé le travail proprement dit ([79], p. 254). Cette façon de penser est à l'opposé des pratiques agiles visant la minimisation du travail préparatoire. Le quinzième principe de DAD stipule que : «The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams.» 15 ([80], p. 32) Les organisations utilisent plusieurs approches en matière de livraison TI. Cela a aussi été constaté chez GFL. Il faut tenir compte de cette réalité et ne pas imposer une seule et même méthode à tous les projets ([81], p. 32). Lorsqu'une équipe agile doit interagir avec des départements ou des équipes non-agiles, il 15 L'écosystème organisationnel doit évoluer pour refléter et améliorer le travail des équipes agiles, tout en étant suffisamment souple pour continuer de supporter les équipes non-agiles ou hybrides. (traduction libre) 40

51 est important de bien leur faire comprendre quelle est sa méthode travail et quelles sont les attentes vis-à-vis les partenaires. Joseph Flahiff propose la méthode de l'enveloppe pour faciliter la cohabitation entre les méthodes agiles, les méthodes en cascade et l'environnement corporatif [82]. Fig. 7: La méthode de l'enveloppe Traduction libre Source : Flahiff, J., 2011 [83] Tout d'abord, le travail de développement de l'équipe agile et les tests sont effectués dans la première enveloppe. C'est au chef d'équipe agile de résoudre les problèmes de première ligne. S'il ne peut résoudre un problème, il devra faire appel au chargé de projet. Dans la deuxième enveloppe se retrouvent les activités liées au projet qui ne sont pas gérées en agile, comme l'achat d'équipement et les tests d'acceptations. Ce sera la responsabilité du gestionnaire de projet de s'assurer que ces activités ne ralentissent pas la bonne marche des opérations. 41

52 Finalement, c'est au niveau de la troisième enveloppe que le projet va interagir avec l'environnement corporatif (comité de pilotage, commanditaires, cadres). Le chargé de projet devra s'occuper des questions liées à la gestion de programme et à la gestion de portefeuille. Le chargé de projet et le chef d'équipe agile devront travailler ensemble pour préparer la mise en production de la solution. À propos de l'hypothèse 1 La première hypothèse stipulait qu'il est très difficile, voire quasi impossible d'utiliser uniquement des méthodes et pratiques de développement agile dans une grande organisation financière. Ces sources permettent de croire qu'il n'est pas facile de déployer un tel processus de niveau entreprise. Toutefois, rien ne permet d'affirmer qu'il soit totalement impossible de mettre en place un processus de développement logiciel complètement ou fortement agile dans une grande entreprise. 3.7 Rôles et facteurs humains Les équipes agiles multidisciplinaires permettent de transcender les barrières entre les différents départements qui fonctionnent en silo ([84], p. 51). Ce principe d'équipe multidisciplinaire fait partie de toutes les méthodes agiles les plus utilisées. Les méthodes agiles étudiées ici définissent une série de rôles. Les différences entre les attributions des rôles ne sont que le reflet des caractéristiques de chaque approche. Rappelons que Scrum, XP et AM se concentrent avant tout sur l'exécution et les activités de construction d'un logiciel. DAD et SAFe tiennent compte de l'environnement corporatif dans son ensemble. Le tableau suivant ne tient compte que des rôles impliqués dans le processus de spécification des besoins. 42

53 Méthode Rôles Scrum Propriétaire de produit Équipe de développement Scrum Master XP Client Développeur Coach DAD Rôles primaires Partie prenante Rôles de l'équipe : Propriétaire de produit Membre de l'équipe Chef d'équipe Propriétaire de l'architecture SAFe Rôles secondaires Spécialiste Testeur indépendant Expert du domaine d'affaires Expert technique Intégrateur Niveau du portefeuille Gestionnaires de portefeuilles de programmes Propriétaire d'épopée Architecte d'entreprise Niveau du programme Gestionnaires de produit Architecte Spécialiste en expérience utilisateur Propriétaire fonctionnel Niveau de l'équipe Propriétaire de produit Scrum/Agile master Développeurs et testeurs AM Architecte (incl. propriétaire de l'architecture) Administrateur agile de base de données Développeur Administrateur d'entreprise Architecte d'entreprise 43

54 Méthode Rôles Concepteur Analyste Parties prenantes (incl. propriétaire de produit) Tableau 2: Rôles impliqués dans la spécification des besoins Traduction libre Sources : Schwaber, K. et Sutherland, J., 2011 ([85], p.6) O'Reilly media, 2003 ([86], pp. 59 à 64) Ambler, S. W. et Lines, M., 2012 ([87], pp ) Leffingwell, D., 2013 [88] Ambler, S. W., 2012 [89] Ambler, S. W., 2012 [90] Ambler, S. W., 2012 [91] Toutes ces méthodes tiennent compte de l'importance d'avoir un propriétaire de produit impliqué dans une équipe multidisciplinaire, cette personne étant la voix du client (interne ou externe) dans l'équipe. SAFe ajoute un gestionnaire de programme et un gestionnaire de portefeuille pour séparer les responsabilités de représentant du client de la gestion de programme et de la gestion de portefeuille. SAFe prescrit une série de rôles pour mettre en place une méthode de gestion du cycle de développement logiciel. DAD est plus vague, définissant des rôles qui correspondent plus à des catégories de rôles regroupant plusieurs spécialités. DAD et SAFe font une place au rôle d'architecte, mais pas au même niveau. DAD a emprunté à AM le rôle de propriétaire de l'architecture. Pour DAD, il fait partie intégrante de l'équipe. Scrum et XP ne considèrent pas qu'un architecte puisse faire partie de l'équipe. SAFe place le rôle de l'architecte au niveau du programme et du portefeuille. La collaboration entre l'équipe d'architecture et l'équipe permet de mitiger les risques souvent importants liés à l'architecture ([92], p. 76). DAD, en tant que méthode agile de niveau entreprise, prend en compte la nécessité d'assister l'équipe de développement par des personnes occupant des postes de support, 44

55 appelés rôles secondaires. Ce sont des spécialistes du domaine d'affaire, des experts techniques et des intégrateurs ([93], p. 16). De plus, DAD prend en compte le fait qu'une équipe de projet a des interactions avec de multiples parties prenantes : utilisateurs, partenaires, commanditaires et membres de la haute direction. DAD a pris certains rôles d'am, les a regroupés en rôles primaires et secondaires et a ajouté les rôles secondaires énumérés dans le tableau précédent. DAD vise à augmenter le niveau de maturité pour permettre de passer de la simple livraison de logiciels à la mise en place de solutions à valeur ajoutée pour le client. Le logiciel n'est plus une fin en soi, mais bien un moyen d'aider l'entreprise à atteindre ses objectifs d'affaires ([94], p. 10). La synergie entre les spécialités facilitera la compréhension des besoins et la création d'une solution logicielle répondant aux besoins de l'entreprise. Ces équipes multidisciplinaires feront collaborer le monde des TI avec le reste de l'entreprise, ce qui est parfaitement en phase avec les principes de communication et de collaboration du manifeste agile. Le rôle de chargé de projet, au sens traditionnel du terme, n'est pas reconnu en Scrum, XP ou même AM. Selon Scott Ambler, en DAD, les tâches du chargé de projet traditionnel se répartissent entre le propriétaire de produit, le chef d'équipe et les membres de l'équipe ([95], p. 62). En résumé, le chef d'équipe joue un rôle de facilitateur qui met en place et maintient les conditions propices au succès de l'équipe ([96], p. 73). Il aide l'équipe à remplir ses tâches de gestion de projet, façon agile, bien sûr. Cela est similaire au coach XP ou au Scrum Master de Scrum. DAD a adopté le terme chef d'équipe (angl. team lead) pour ne pas privilégier l'une ou l'autre des méthodes disponibles les plus utilisées. Pour Dean Leffingwell, créateur de SAFe, les fonctions traditionnelles de contrôle disparaissent avec agile. Toutefois, les tâches qui étaient autrefois la seule responsabilité du chargé de projet sont dorénavant la responsabilité de l'équipe qui ne sait pas toujours comment exécuter ces tâches de gestion de projet agile ([97], p. 442). 45

56 Tâches du chargé de projet traditionnel Structure de découpage du projet (SDP) Planification à l'aide d'un diagramme de Gantt Analyse du chemin critique Rapports Tâches de l'équipe agile Estimations basées sur la vélocité Planification des itérations Planification des versions Feuille de route Versions/Itérations Revues/Rétrospectives Tableau 3: Tâches du chargé de projet traditionnel vs équipe agile Traduction libre Source : Leffingwell, D., 2011 ([98], p. 443) Dean Leffingwell préfère convertir les chargés de projet en chargés de projets agile. Ils aideront les membres de l'équipe à compléter les versions agiles de ces tâches de gestion de projet. Le chargé de projet ([99], p. 443) 16 : S'occupe des évènements Scrum (sprint, réunion de planification de sprint, mêlée quotidienne, revue de sprint, rétrospective de sprint) ([100], pp. 9 à 14) Assiste aux mêlées de mêlées. Effectue le travail de coordination avec les fournisseurs externes et les équipes de déploiement ou de distribution. Gère la comptabilité de projet. Facilite les démonstrations. Aide l'équipe à estimer les items du carnet de produit. Aide l'équipe à travailler avec les gestionnaires de portefeuille à estimer et planifier le travail à faire. 16 Traduction libre 46

57 3.8 Bureau de projets, structure et hiérarchie Pour mettre en place une méthode de livraison, il est important de faire appel à un champion de la haute direction afin d'obtenir le support et les fonds nécessaires. Il faut aussi impliquer les TI et d'autres parties prenantes désirant opérer une migration vers l'agilité. Ce support sera critique afin d'obtenir les ressources et les appuis nécessaires aux responsables de ce changement à la fois culturel et méthodologique ([101], p. 12). Le bureau de projets occupera un rôle central dans cette migration. Dans DAD, le bureau de projets a encore sa place, même avec l'introduction de l'agilité. Selon eux, les grandes entreprises continueront d'avoir besoin de piloter l'exécution et d'assurer le suivi des projets avec rigueur, projets agiles ou pas. Un bureau de projets moderne encouragera l'utilisation de techniques non-conformistes. Il tentera de tirer profit de ces méthodes si elles permettent d'économiser de l'argent, tout en facilitant la livraison de solutions conformes aux attentes du client et ce, dans les délais et sans augmenter les risques du projet ([102], p. 107). Le cabinet de consultation en gestion de projet ESI International a effectué en 2013 un sondage auprès de 2300 répondants à travers le monde. 72% ont déclaré avoir un bureau de projets actif dans leur organisation ([103], p. 6). 33% des bureaux de projet supportent agile, Scrum ou les méthodes Lean. À l'échelle mondiale, seulement 21% des répondants sous la gouverne d'un bureau de projets recevaient de la formation et du support en agilité. Ce pourcentage tombe à 17% pour ceux qui ne sont pas supervisés par un bureau de projets ([104], p. 23). Tout cela n'est guère surprenant, vu les réticences des bureaux de projet face à l'agilité. Selon SAFe, pour faire changer d'avis un bureau de projets peu favorable à l'agilité, une équipe agile doit mettre de l'avant ses réussites, plus susceptibles de convaincre que des promesses ([105], p. 431). L'introduction de l'agilité en entreprise entraîne une série de changements organisationnels et culturels. Il faudra modifier des comportements hérités de décennies de développement et de gestion en mode traditionnel ([106], p. 433). Pour Scott Ambler et Mark Lines : «It is easier to avoid your traditional governance and tell management that 47

58 agile is different than it is to work with your governors to adapt your governance to properly guide the delivery of your agile teams.» 17 ([107], p. 493) Le besoin de gouvernance ne disparaît donc pas avec agile. Pour passer de la livraison agile à une gouvernance agile, il faudra passer à travers une série d'étapes de gestion du changement dont le bureau de projets est un acteur-clé. En se basant sur le PMBOK MD, le bureau de projets d'entreprise aura, entre autre, pour rôle de ([108], p. 11) : Développer la nouvelle méthodologie, les meilleures pratiques et les standards de l'entreprise. Former, assister et superviser les gens lors du passage à l'agilité. Surveiller la conformité des politiques, procédures et modèles de documents avec les standards de gestion de projet de l'entreprise via des audits. Mettre en place les nouveaux standards de documentation agile, les modèles de document et les nouvelles procédures de gestion de projet. À propos de l'hypothèse 3 Il est raisonnable de conclure que la troisième hypothèse (L implication du bureau de projets est critique pour une implantation d agile réussie) semble tenir la route. De par son rôle, le bureau de projets peut donc faciliter l intégration de l agilité dans une grande organisation 17 Il est plus facile d'éviter la gouvernance traditionnelle et de dire à la direction qu'«agile est différent», plutôt que de travailler avec vos dirigeants pour adapter votre gouvernance afin d'assister correctement vos équipes agiles dans le processus de livraison. (traduction libre) 48

59 3.9 Autres points communs entre les méthodes Les tableaux précédents révèlent que les différentes pratiques étudiées dans cet essai ont plusieurs points en commun. La figure 8 présente une vision plus synthétique des relations et des emprunts entre ces méthodes. Maintenant, quelques mots sur ces relations. Il sera principalement question des points qui portent sur la spécification des besoins. Fig. 8: Relations entre les méthodes NDLR : Les méthodes sur lesquelles cet essai met l'accent sont en noir (DAD, AM, Scrum, XP et SAFe). Sources : Lines, M., 2013 [109] ([110], p. 6) Lines, M. et Ambler, S. W., 2012 ([111], pp et p. 58) 49

60 DAD a emprunté à plusieurs méthodes pour constituer sa méthode agile de livraison logicielle évolutive pour les grandes entreprises. DAD a été fortement influencé au départ par UP, XP, Scrum et AM [112] de Scott Ambler, co-auteur du livre Disciplined Agile Delivery [113]. Les différentes pratiques de spécifications des besoins des méthodes étudiées ici se retrouvent dans DAD, bien que DAD ne recommande pas de les utiliser toutes en même temps. D'autres méthodes comme AD, DSDM et SAFe font elles aussi partie de DAD ([114], p. 58). Tout comme DAD, SAFe a emprunté des techniques de développement et de gestion de projet à Scrum (itérations à durée fixes, démo, rétro). SAFe a aussi emprunté des pratiques de XP (intégration continue, récits utilisateurs). SAFe parle même de ScrumXP [115]. Les tableaux Kanban ont d'abord été utilisés pour la gestion des priorités et des encours au niveau du portefeuille [116]. Dean Leffingwell et ses collaborateurs sont en train d'intégrer Kanban ou certains de ses principes au niveau des équipes SAFe [117] [118] [119] : le ScrumXPban! Scrum et XP sont souvent utilisées ensemble. Dans l'industrie, environ une équipe sur cinq utilise une méthodologie hybride sur mesure ou hybride Scrum/XP [120] ([121], p.9). En ce qui a trait à la spécification des besoins, les carnets de produits et les carnets de sprint de Scrum sont souvent construits à l'aide de récits utilisateurs de XP. Le développement est géré à l'aide de sprints et des cérémonies Scrum. La qualité du code est assurée par les pratiques d'ingénierie de XP (propriété collective du code, intégration continue, programmation en binôme). XP n'utilise pas seulement les récits utilisateurs pour mieux comprendre les besoins du client. Les schémas, graphiques et autres diagrammes sont des outils de modélisation pouvant parfaitement être utilisés par XP. La valeur ajoutée d'am est donc évidente, même dans un projet purement XP [122]. 50

61 3.10 Autres facteurs non considérés Les autres méthodes faisant partie de l'arsenal de DAD n'ont pas été décrites. L'objectif étant de se concentrer sur les questions liées à la spécification des besoins, l'accent a été mis sur les méthodes les plus utilisées et les plus utiles dans un contexte de grande entreprise. LeSS La version de Scrum pour les grands projets s'appelle LeSS (Large-Scale Scrum). Il s'agit essentiellement d'une façon de faciliter la gestion de multiples équipes Scrum (plus de dix) en créant des rôles d'adjoints au propriétaire de produit [123]. Étudier plus en profondeur ce raffinement de la méthode Scrum n'aurait pas apporté un nouvel angle enrichissant grandement la réflexion. PMI Le PMI (Project Management Institute) mentionne agile et les techniques de collecte d'information à quelques reprises dans sa 5 e édition du PMBOK MD [124], notamment dans les sections suivantes : Adaptive Life Cycles (p. 45) Collect requirements : Tools and techniques (pp. 114 à 116) 6.7 Control schedule (p. 187) Signalons tout de même que le PMI a publié en 2013 une extension au PMBOK, le Software Extension to the PMBOK Guide Fifth Edition, qui a pour but de faire le pont entre le PMBOK MD traditionnel et les méthodes de développement agile [125]. Notons que le PMI propose une certification agile : le PMI-ACP (PMI Agile Certified Practitioner), centré essentiellement sur la gestion de projet, version agile [126]. 51

62 SWEBOK Le SWEBOK (Software Engineering Body of Knowledge) V3.0 [127] de l'ieee Computer Society parle de la spécification des besoins au chapitre 1 ([128], pp. 1-1 à 1-18). Agile est évoqué par le SWEBOK, mais le sujet n'y est pas abordé en profondeur. Le point 4.4 ([129], p. 9-9) consacre une page aux méthodes agiles. Le point 2.6 ([130], p. 12-8) sur le cycle de vie d'un projet parle brièvement du cycle de développement agile qui est itératif et incrémental. Au point 5.1, il est mentionné qu'agile adhère au principe «suffisant» 18 ([131], pp , 12-15). Finalement, le SWEBOK mentionne un standard de développement de documentation utilisateur dans un environnement agile à l'annexe B, le standard ISO/IEC/IEEE 26515:2012 ([132], p. B-7). CMMI Le CMMI Institute, responsable du développement du CMMI (Capability Maturity Model Integration), mentionne brièvement agile dans son modèle pour le développement, le CMMI- DEV. Dans la version 1.3 du CMMI-DEV [133], il est question de l'utilisation de CMMI dans un contexte de développement agile, CMMI ayant été conçu pour être utilisée dans plusieurs contextes différents. «Comme le CMMI ne soutient aucune approche de développement particulière, il fournit peu d informations spécifiques à une démarche donnée» ([134], p. 97). «Pour aider ceux qui utilisent des méthodes agiles à interpréter les pratiques du CMMI dans leur environnement, nous avons ajouté des remarques à des domaines de processus sélectionnés. Elles se trouvent généralement dans les notes explicatives des domaines de processus suivants de CMMIDEV : CM, PI, PMC, PP, PPQA, RD, REQM, RSKM, TS et VER. Toutes ces remarques commencent par les mots «dans les environnements agiles» ([135], p. 98). Sur le site du CMMI Institute, une section est consacrée à CMMI et Agile [136]. Vous pouvez y retrouver des articles expliquant comment utiliser CMMI dans un contexte de développement agile. 18 Good enough (traduction libre) 52

63 BABOK L'IIBA (International Institute of Business Analysis) a publié une extension agile au BABOK (Business Analysis Body of Knowledge) [137], le guide de référence des processus d'analyse d'affaire. Bien que très pertinent, le BABOK et son extension sont centrés exclusivement sur l'analyse d'affaire. Tout ce qui touche à la spécification des besoins occupe bien sûr une place très importante dans cette extension du BABOK. L'objectif n'étant pas d'approfondir un rôle ou un sous-processus en particulier, ce sujet n'a pas été abordé Quelques réponses tirées de cette analyse Suite à cette analyse de méthodes existantes, on peut tenter quelques réponses à la question : «Existe-t-il des meilleures pratiques pouvant faciliter la gestion du processus de spécification des besoins en agile dans une grande organisation financière utilisant des méthodologies de développement logiciel non-agiles?» On constate qu'il existe bel et bien des méthodes pour faciliter la gestion du processus de spécification des besoins en agile dans une grande entreprise. De plus, on voit qu'il existe des méthodes pour faciliter l'intégration d'agile dans une grande entreprise. Veuillez noter que ce ne sont pas les seules méthodes qui existent, mais elles confirment l'existence de méthodes de gestion du processus de spécification des besoins dans les grandes entreprises. Le chapitre qui suit se penche sur la situation de l'agilité chez GFL, dans les grandes entreprises et dans l'industrie financière en particulier. 53

64 Chapitre 4 Analyse des résultats 4.1 Sondage Les résultats bruts du sondage permettent d'obtenir des informations sur le niveau de connaissance, la perception et sur l'utilisation des méthodologies agiles dans l'entreprise. Les résultats du sondage sont disponibles à l'annexe 3. Rappelons que ces données ont été obtenues dans le cadre d'un sondage Internet complété sur une base volontaire. Bien que l'échantillon soit satisfaisant (77 sur un bassin de répondants potentiels de 1000 employés concernés par le développement logiciel), il est tout de même important de valider ces résultats avec quelques données provenant d'études et de sondages sur le sujet. Profil des répondants Question 1 - Sondage chez GFL Catégories d'emploi Autre 6% Spécialiste en assurance-qualité 13% Développeur logiciel 22% Chef d'équipe 5% Chargé de projet 13% Cadre 17% Architecte 10% Analyste 14% 0% 5% 10% 15% 20% 25% Fig. 9: Catégories de répondants au sondage chez GFL En regardant les résultats de la question 1, on constate que les diverses catégories d'employés énumérées en sont pour la plupart bien représentées dans l'échantillon. Les analystes et les cadres ont été regroupés. 54

65 Sondage Dr. Dobb's 2008 Catégories d'emploi Parties prenantes - affaire Opérations/support Professionnel des données 1% 3% 2% Cadre en TI 17% Analyste 2% Autre 6% Spécialiste en assurance-qualité 2% Développeur logiciel 55% Chargé de projet 12% 0% 10% 20% 30% 40% 50% 60% Fig. 10: Catégories de répondants au sondage Dr. Dobb's Traduction libre Source : Ambler, S.W., 2008 [138] En 2008, le magazine Dr. Dobb's, spécialisé dans le développement logiciel, a envoyé à ses lecteurs un sondage de Scott W. Ambler sur l'agilité [139]. 642 personnes ont répondu au sondage en février ,8% ont répondu travailler comme développeurs, ce qui donne une représentation un peu différente des résultats à la question 1 du sondage. Méthodologies agiles compréhension et perceptions Afin de mesurer le degré de compréhension d'agile, il a été demandé de définir agile à l'aide d'une question à choix multiple. Soixante-cinq pour cent des répondants ont répondu que les méthodes de développement logicielles agiles «visent la livraison régulière de fonctionnalités ayant une forte valeur ajoutés». C'était la meilleure réponse. Vingt-trois pour cent ont répondu qu'elles sont «moins chères, itératives et incrémentales». Bien sûr, les méthodes agiles sont itératives et incrémentales, mais rien ne permet d'affirmer pour l'instant qu'elles soient automatiquement moins chères. Il s'agissait d'une question-piège dont le but était de 55

66 mesurer leur degré de compréhension de l'agilité. Personne n'a répondu qu'agile élimine la documentation écrite. Les répondants ont fait le bon choix car, tel qu'expliqué précédemment, agile n'élimine pas toute documentation écrite. Huit pour cent ont jugé les méthodes agiles comme étant «déstructurées, sans processus formel, car elles reposent sur la collaboration». Quatre pour cent ne savaient pas quoi répondre. 1 = Inefficaces 5 = Très efficaces Question 5 Perception du niveau d'efficacité d'agile Je ne sais pas 8% 1 4% 2 5% 3 25% 4 39% 5 19% Tableau 4: Efficacité d'agile (Sondage chez GFL ) À la question 5, il a été demandé à la population-cible ce qu'elle pensait du niveau d'efficacité des méthodes agiles. Pour la majorité des répondants, le niveau d'efficacité des méthodes agiles va de moyen à très élevé. Pour le sondage du magazine Dr. Dobb's, les répondants ont évalué l'efficacité des équipes agiles selon les facteurs suivants : Traduction libre Facteur S'est amélioré Aucun changement S'est dégradé Productivité 82% 13% 5% Qualité 77% 14% 9% Satisfaction des parties prenantes 78% 15% 7% Coût 37% 40% 23% Tableau 5: Efficacité des équipes agiles (Sondage de Dr. Dobb's ) Source : Ambler, S.W., 2008 [140] 56

67 Ce sondage porte à croire qu'il est vrai qu'agile améliore la productivité, la qualité et la satisfaction des parties prenantes. Ces résultats sont comparables aux réponses obtenues à la question 5. Les répondants ont une opinion favorable d'agile quant à son efficacité. Une étude de 2011 du CIO Executive Board (CEB) menée auprès de 200 organisations allant de CapitalOne à Honda démontre qu'en moyenne, agile procure un retour sur l'investissement qui est 25% plus élevé qu'avec les méthodes de gestion de projet traditionnelles. Chez Raytheon, la satisfaction de la clientèle est passée de 3 à 4 sur une échelle de 5. Chez Intergraph, 89% des commanditaires de projet jugent que les solutions développées avec Scrum sont de qualité égale ou supérieure. Chez British Airways et Emergn, l'entreprise met 50% moins de temps avant de voir les premiers bénéfices d'un projet ([141], p. 15). Agile a fait son chemin dans les grandes entreprises au grand bénéfice de celles-ci. À propos de l'hypothèse 2 Selon la deuxième hypothèse, il est possible de tirer profit de l agilité pour améliorer la productivité, la qualité et la satisfaction du client (interne et externe). Ce sondage et les données du CEB semblent valider cette hypothèse. 57

68 Spécification des besoins en agile Question 13 - Sondage chez GFL Nous élaborons notre spécification des besoins en agile Oui 9% Non 38% Partiellement 36% Je ne sais pas 17% 0 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4 Fig. 11: Répondants élaborant leurs spécifications des besoins en agile (Sondage chez GFL ) En ce qui a trait à la création de spécification des besoins en agile (question 13), seulement neuf pour cent disent utiliser uniquement agile, trente-six pour cent partiellement et trente-huit pour cent pas du tout. Dix-sept pour cent ne savaient pas quoi répondre. Donc, bien que la majorité y soit favorable, moins de la moitié des répondants ont déclaré utiliser agile pour la spécification des besoins. À la question 6 du sondage chez GFL, quarante-quatre pour cent des répondants déclaraient n'utiliser aucune méthode agile. Ce résultat est cohérent avec les résultats de la question 13. Agile est utilisé par environ la moitié des répondants. Ces résultats peuvent être comparés avec ceux d'un sondage réalisé en 2012 auprès de 4048 répondants par la compagnie VersionOne [142]. Quatre-vingt-quatre pour cent des répondants au sondage de VersionOne déclaraient faire du développement agile. 58

69 Il faut mettre ce résultat en perspective, car la moitié des répondants au sondage VersionOne déclaraient utiliser agile sur cinquante pour cent de leurs projets et moins ([143], p. 3). De plus, selon une autre étude, seulement cinquante-trois pour cent des gens se déclarant dans une équipe agile faisaient vraiment partie d'une telle équipe ([144], p. 692). D'autres données renvoient un portrait conservateur de la situation d'agile dans les entreprises. Selon un rapport de 2011 du CIO Executive Board (CEB), soixante et onze pour cent des bureaux de projets sondés déclaraient utiliser agile ou une méthode itérative dans moins de vingt pour cent de leurs projets ([145], p. 9). GFL semble donc se situer parmi les entreprises plutôt conservatrices en terme d'adoption de l'agilité. Il faut être conscient qu'il faudrait obtenir des données ciblées sur l'adoption d'agile dans l'industrie financière pour avoir une meilleure idée de la position de la compagnie face à ses concurrents. Chose certaine, agile n'est pas la norme pour tous en matière de développement logiciel chez GFL, bien que ces méthodes de développement se soient répandues dans l'entreprise. 1 = Défavorable 5 = Favorable 1 5% 2 9% 3 21% 4 40% 5 25% Question 14 À quel point les répondants étaient-ils favorables à l'utilisation des méthodes agiles pour l'élaboration de la spécification des besoins? Tableau 6: Pourcentage favorable à l'agilité pour l'élaboration de la spécification des besoins (Sondage chez GFL ) À la question 14, quarante pour cent des répondants ont répondu 4 et vingt-cinq pour cent un 5 sur une échelle de 1 à 5 (5 étant le niveau le plus favorable). Vingt et un pour cent ont répondu 3, soit moyennement favorable. Ces résultats portent qu'à croire qu'en général, les employés sont favorables à l'utilisation de méthodes agiles dans la spécification des besoins. 59

70 Bien que l'entreprise soit conservatrice en terme d'adoption de l'agilité, les employés semblent plus réceptifs à de nouvelles façons de faire. Expérience et connaissance d'agile Question 10 - Nombre d'années d'expérience en développement agile 8% 12% 38% 17% 6 à 10 ans 3 à 5 ans 1-2 ans Moins d'un an Aucune expérience 25% Fig. 12: Nombre d'années d'expérience en développement agile (Sondage chez GFL ) À la question 10, on constate que seulement 8% des répondants déclarent avoir de 6 à 10 ans d'expérience en développement agile. 38% ont de 3 à 5 ans d'expérience. Vingt-cinq pour cent ont d'un à deux ans d'expérience. Cela laisse croire qu'il y a une masse critique de gens ayant une certaine expérience en agile, mais qu'il y a peu de gens très expérimentés dans l'organisation. Il faudra en tenir compte advenant un déploiement de l'agilité à grande échelle. 60

71 Années d'expérience avec les pratiques de développement agiles 25% 19% +5 ans 3 à 4 ans 1-2 ans Moins d'un an 26% 30% Fig. 13: Nombre d'années d'expérience en agile (VersionOne 2012) Traduction libre Source : VersionOne, 2012 ([146], p. 2) Vingt-cinq pour cent des répondants au sondage VersionOne ont déclaré avoir plus de 5 ans d'expérience avec les pratiques de développement agile. Dix-neuf pour cent ont moins d'un an d'expérience, vingt-six pour cent de 1 à 2 ans et trente pour cent ont de 3 à 4 ans d'expérience. Ces résultats sont comparables à ceux obtenus à la question

72 1 = Faible 5 = Élevée Question 11 Auto-évaluation de la connaissance d'agile 1 21% 2 16% 3 26% 4 29% 5 9% Tableau 7: Auto-évaluation de la connaissance d'agile (Sondage chez GFL ) À la question 11, on a demandé aux sondés de GFL quel est leur niveau de connaissance des méthodologies, méthodes et pratiques agiles. Un peu plus de la moitié déclarent avoir une connaissance d'agile de moyenne à excellente, mais peu d'entre eux peuvent prétendre à une excellente connaissance d'agile. Connaissance des plans de l'entreprise Question 15 - Pourcentage des répondants au courant de l'existence de passerelles agiles et non-agiles Non 53% Oui 47% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Fig. 14: Degré de connaissance de l'existence de passerelles entre les processus agiles et non-agiles (Sondage chez GFL ) On ne peut affirmer que la majorité des employés soient au courant de l'existence de passerelles entre les processus agiles et non-agiles. À la question 15, quarante-sept pour cent des participants affirmaient connaître l'existence de telles passerelles tandis que cinquante-trois pour cent déclaraient le contraire. 62

73 Question 16 - Pourcentage des répondants au courant de l'existence d'un plan de déploiement de l'agilité Non 82% Oui 18% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Fig. 15: Degré de connaissance de l'existence de passerelles entre les processus agiles et non-agiles (Sondage chez GFL ) Il semble que la grande majorité des employés ne sont pas au courant d'un quelconque plan de déploiement de l'agilité. À la question 16, quatre-vingt-deux pour cent des participants déclarent ne pas être au courant d'un tel plan! En résumé, le sondage fournit les informations suivantes : La population échantillonnée chez GFL serait globalement favorable à accueillir un processus agile, et plus particulièrement un processus agile de spécification des besoins. Actuellement, moins de la moitié des répondants utilisent en ce moment un processus agile de spécification des besoins. Environ la moitié des répondants disent utiliser une méthode de développement agile en ce moment. Un peu moins de la moité des répondants sont au courant de passerelles entre les processus agiles et non-agiles. La grande majorité des répondants ne sont pas au courant d'un plan de déploiement de l'agilité dans l'entreprise. 63

74 4.2 Agile dans le milieu financier Terminons ce chapitre par quelques mots sur la situation d'agile dans l'industrie financière. Voici quelques témoignages de hauts dirigeants en TI dans le domaine financier. La banque d'investissement de la Société générale en France a amorcé avec succès un virage vers le développement agile. Selon Carlos Goncalves, DSI (directeur des systèmes d'information) de la banque d'investissement de la Société générale : «L agilité fonctionne par viralité. Les équipes qui n y sont pas veulent en être. L effet des méthodes agiles sur la motivation des équipes est très intéressant, la reconnaissance du travail accompli est immédiate». [147] «L'adoption des méthodes agiles a eu aussi pour conséquence de faciliter le projet de rationalisation de l'ensemble du parc applicatif de la direction des systèmes d'information engagé en 2010 et qui est toujours en cours. Nous avions à cette époque 1882 applications. Fin 2012, nous n'en avions plus que 960, ce qui nous permet de générer 40 millions d'euros d'économies par an». [148] Clive Whincup, directeur des systèmes d'information (anglais : CIO) de la australienne Westpac Group commente : banque «It s a very good way of getting maximum delivery throughput for the core business outcomes we re driving towards, Whincup adds. Agile is a methodology we will be using more extensively on larger programs going forward.» 19 [149] D'autres implantations ont eu lieu avec succès chez de grands groupes financiers comme Barclay's [150] et la banque ING [151]. Ces succès démontrent qu'il est tout à fait possible d'adopter le développement agile dans une grande organisation financière. 19 C'est un très bon moyen d'obtenir un débit de livraison maximal au bénéfice des objectifs visés par l'activité principale de la compagnie, ajoute Whincups. Agile est une méthodologie que nous utiliserons de plus en plus sur des programmes plus importants. (traduction libre) 64

75 Chapitre 5 Recommandations 5.1 Identification des écarts et plan d action proposé On a cherché des réponses dans la littérature et dans les données disponibles sur le développement logiciel dans les grandes entreprises. On y trouve des cas où le développement agile peut s'appliquer à l'industrie financière. Suite au sondage et à une consultation de documents internes, on constate que chez le Groupe Financier Lombard : Certains échecs ont miné la crédibilité d'agile dans au moins une filiale du groupe. Agile a servi de bouc émissaire pour les problèmes rencontrés durant le projet, qu'ils aient été liés au processus d'implantation d'agile ou non. L'agilité n'est pas répandue dans toute l'entreprise. Moins de la moitié des répondants déclarent utiliser, purement ou partiellement, un processus agile de spécification des besoins. De multiples méthodes de développements agiles et non-agiles coexistent dans l'entreprise. Les passerelles entre les projets agiles et non-agiles en sont encore au stade embryonnaire. Elles sont peu connues des répondants. Il y a un de multiples bureaux de projets chapeautés par un bureau de projets d'entreprise pour tout le groupe financier. L'entreprise travaille sur un plan d'implantation de l'agilité basé sur DAD. Pour l'instant, il est au stade «alpha» et n'a jamais été utilisé durant un projet complet. Il va passer ses premiers tests à l'aide d'un projet pilote durant l'année Pour régler les problèmes énumérés cihaut, le groupe financier peut mettre en place le plan d'action suivant : 65

76 S'assurer du support de la haute direction de l'entreprise, tant du côté affaire que du côté technologie. Tirer profit de l'existence du bureau de projets d'entreprise de GFL pour faciliter la transition de l'entreprise vers l'agilité. Établir un plan de communication pour faire connaître l'existence de la méthodologie agile d'entreprise et le fait qu elle soit supportée par les hautes instances de GFL. Établir un plan de formation pour les équipes (incluant le support) de projet et les parties prenantes. Le bureau de projets d entreprise devrait former et supporter les bureaux de projets de chaque secteur d'activité. Les bureaux de projets de chaque secteur d'activité devront supporter les équipes de projet qui débutent avec les standards agiles de l'entreprise. Donner des instructions claires pour que les employés sachent comment arrimer les projets agiles avec la méthodologie standard non-agile déjà en place. Le bureau de projets d entreprise devra agir comme représentant de la gouvernance d'entreprise. Il doit s'assurer que la méthodologie est utilisée correctement par les bureaux de projets de chaque secteur d'activité. Créer des modèles de documents destinée aux projets agiles. Prendre le pouls des projets agiles pour assurer le suivi des déploiements d agile dans l entreprise. Insérer agile dans un contexte non-agile est un premier pas vers l'agilité. L'étape suivante sera de faire évoluer les processus en place afin de tirer le maximum de l'agilité. Un processus agile de spécification des besoins complet demande l'implantation d'agile à plusieurs niveaux et ce, dans plusieurs départements de l'organisation. Tel que constaté précédemment, plusieurs méthodes existent pour implanter l'agilité dans une grande entreprise et pour faciliter le gestion du processus de spécification des besoins dans un tel contexte. Pour choisir une méthode, il faut passer à travers un processus de sélection qui 66

77 constitue un sujet dépassant le cadre de cet essai. Tel qu'expliqué précédemment, un virage vers l'agilité est un changement culturel qui peut prendre du temps à s'installer dans les us et coutumes d'une organisation. 5.2 Validation du plan d action Des experts agiles travaillant pour l'entreprise ont validé la cohérence et la pertinence du plan d'action. Ils ont répondu à cinq questions. Voici leurs réponses : Question 1 : Ce plan est-il applicable chez le Groupe Financier Lombard? Un expert confirme que ce plan est réalisable car un tel plan est en cours. Un autre expert agile a répondu que ce plan pourrait être très bien exécuté chez GFL. Cependant, il ne croit pas qu'il soit nécessaire de fournir des modèles de documents, «mais bien de fournir une base méthodologique documentée (standard commun) où les utilisateurs pourront trouver les processus, rôles, responsabilités, outils, modèles et alignements». Pour le plan de communication, il parle de socialisation, soit d'éveiller les parties prenantes «aux changements et à ses bénéfices». La stratégie d'adoption centrée sur le bureau de projets de l'entreprise ne s'appliquera pas chez GFL où chaque bureau de projets devra s'occuper lui-même de la formation et du coaching. «Il en revient aux différents PMO des lignes d affaires de s approprier la méthodologie d entreprise et de financer/planifier individuellement leur modèle de formation/coaching. L entreprise développe le standard commun et fait une formation de très haut niveau. La raison? Un problème de capacité et de budget à desservir dans un modèle fédéré.» Question 2 : Faciliterait-il l'implantation d'agile dans l'entreprise? Selon le premier expert, il faciliterait l'implantation d'agile dans l'entreprise car il serait impossible d implanter l'agilité sans un plan. Pour le second expert, ce plan faciliterait l'implantation d'agile car «il s agit d une approche très structurée qui s applique assez bien dans un modèle fédéré», tel qu'expliqué dans le paragraphe précédent. 67

78 Question 3 : Quels seraient les objectifs les plus difficiles à réaliser? Selon le premier expert agile, l'objectif le plus difficile à atteindre serait d'en arriver au point où toutes les équipes soient considérées comme agiles «de la conception du produit jusqu'au déploiement.» Le second expert agile confirme ce point de vue. Selon lui, «dans un modèle fédéré où la responsabilité réside dans divers groupes d entreprise, il est difficile d aligner toutes les parties prenantes comme l'infrastructure et l architecture rapidement.» Le support du côté affaire et technologique sont difficiles à obtenir en même temps. Les priorités ne sont pas les mêmes pour chacun, ce qui complique l'alignement de ces départements. Question 4 : L implantation d un processus agile de spécifications des besoins est-il envisageable dans un avenir prévisible avec un tel plan? Selon le premier expert agile, l implantation d un processus agile de spécifications des besoins est envisageable dans un avenir prévisible. En effet, un processus de gestion des spécifications est en gestation. L'objectif visé est de le fusionner avec la méthodologie agile d'entreprise. Le second expert est d'accord, mais il met en relief le fait que la tâche sera compliquée par le modèle fédéré de l'entreprise et des bureaux de projet. Question 5 : Ce plan pourrait-il être adopté par le bureau de projets de l'entreprise? Le premier expert souligne que le bureau central de projet a déjà adopté une stratégie agile à l'aide de plusieurs groupes comme la direction des TI (OCIO Office of the CIO), le nouveau centre d'excellence agile et le groupe de travail agile qui représente l'ensemble des intervenants pour assurer un lien entre le volet technologique et le volet affaire. Le second expert souligne que le modèle fédéré adopté par l'entreprise fera en sorte que la stratégie d'adoption globale différera quelque peu du plan proposé. 68

79 5.3 Commentaires sur les réponses des experts agiles Le fait de laisser chaque bureau de projets procéder à l'implantation de la méthode d'entreprise sans supervision et sans contrôle peut mener à l'émergence chez GFL de multiples méthodes agiles basées sur la même méthode d'entreprise. On a constaté que les employés impliqués dans le projet pilote d'implantation de la méthode d'entreprise avaient besoin de modèles de documentation agile. On peut supposer que ce besoin se manifestera à travers l'entreprise. Il serait bon d'y répondre avant de voir apparaître de nombreux standards de documentation agile. Ayant déjà vécu dans le projet pilote des problèmes d'arrimage entre la méthode agile d'entreprise et les processus non-agiles déjà en place, il serait judicieux de s'attaquer à la question des passerelles entre les méthodes et processus agiles et non-agiles. Ainsi, on pourrait diminuer, voire éviter des frictions inutiles entre les différents groupes et départements de l'entreprise. 69

80 5.4 Ouverture vers d'autres sujets de recherche L'agilité tire profit de la collaboration étroite entre les membres d'une équipe. Sans s'embarquer dans une analyse d'agile à la lumière de la théorie de la complexité tel que représentée par le modèle Cynefin ([152], p. 33), il est tout de même possible de tirer profit des recherches sur le comportement humain pour avoir un aperçu des fondements cognitifs des décisions humaines et des réticences à changer de cap lorsque nécessaire. «This tendency to cling to our initial assumptions and plotted course is down to the way our minds deal with new situations. The process of first-fit pattern matching evolved to make us capable of fast decisions in danger, based on previous experience. Once that fit has been made it s hard for us to let go and consider alternatives within a complex problem. It also makes humans bad at cutting their losses and changing tack mid-project.» 20 ([153], p. 31) On a pu le constater chez GFL, où des modifications de spécifications logicielles, d'affaires ou architecturales ont parfois entraîné des luttes politiques intestines. Une meilleure compréhension des aspects psychologiques et culturels d'une migration vers l'agilité pourrait augmenter le taux de réussite des implantations d'agile et de permettre de tirer le maximum de l'agilité. 20 Cette tendance de s'accrocher à nos hypothèses initiales et au chemin que nous avons déjà tracé s'inscrit dans la façon dont esprit compose avec de nouvelles situations. Le processus du premier modèle convenable a évolué pour nous rendre capable de décisions rapides en cas de danger, en nous basant sur nos expériences passées. Une fois ce modèle établi, il est difficile d'y renoncer et de considérer d'autres alternatives face à un problème complexe. Cela rend les humains moins aptes à essuyer leurs pertes et virer de bord en milieu de projet. (traduction libre) 70

81 Conclusion La recherche effectuée au cours de la rédaction de cet essai avait pour but premier de savoir s'il existe des meilleures pratiques pouvant faciliter la gestion du processus de spécification des besoins en agile dans une grande organisation financière utilisant des méthodologies de développement logiciel non-agiles. Une revue de la littérature sur le sujet, centrée sur les méthodes DAD et SAFe, a démontré qu'il existe des meilleures pratiques en matière d'agilité de niveau entreprise. Le sondage chez GFL et les données de divers sondages (VersionOne et Dr. Dobb's) portent à croire que les entreprises sont prêtes à accueillir l'agilité au niveau entreprise. Selon Gartner, l'agilité au niveau entreprise est appelée à devenir la norme d'ici 5 à 10 ans, malgré certaines résistances à l'intérieur des entreprises. ([154], p. 5, pp. 21 à 23) Le bureau de projets peut jouer un rôle favorisant l'implantation de l'agilité dans une entreprise dotée d'un tel bureau de projets. Un plan d'action tirant profit du rôle du bureau de projets chez GFL a été mis sur pied. Il a été présenté à des experts agiles de l'entreprise qui ont commenté le plan. Le bureau de projets jouera en effet un rôle dans l'implantation d'agile chez GFL, mais il n'aura pas un rôle directif principalement à cause du modèle de bureaux de projets fédérés de l'entreprise. Les bénéfices de ces méthodes agiles d'entreprise et de l'agilité en général peuvent apporter de nombreux bénéfices aux entreprises ([155], p. 23). Afin de continuer la discussion sur le sujet, il serait intéressant de poursuivre non seulement sur les fondements cognitifs du processus décisionnel, mais de comprendre l'influence de la planification stratégique sur la culture des grandes entreprises. 71

82 À propos de planification stratégique, d'après Henry Mintzberg, l'une des hypothèses qui sous-tend les méthodes de planification stratégique, l'hypothèse de prédétermination, suppose que : «le contexte du processus stratégique est stable, ou à tout le le moins prévisible, le processus lui-même, et ses conséquences les stratégies peuvent être prédéterminés.» ([156], p.235) Il serait intéressant de voir si agile pourrait jouer un rôle pour remédier aux conséquences de la planification stratégique dans les grandes entreprises qui évoluent dans un environnement qui est tout, sauf stable. 72

83 Références [1] Mark Lines et Scott W. Ambler, Disciplined Agile Delivery: A Practitioner s Guide to Agile Software Delivery in the Enterprise, IBM Press, 2012, 513 p. [2] Dean Leffingwell, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley Professional, 2011, 518 p. [3] Dean Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, Addison- Wesley Professional, 2007, 349 p. [4] Ibidem. [5] Ibidem. [6] M. Lindvall, D. Muthig, A. Dagnino[et al.], «Agile software development in large organizations», Computer, vol. 37 / 12, décembre 2004, p [7] Ibidem. [8] Dac-Buu Cao, An empirical investigation of critical success factors in agile software development projects, Ph.D., Capella University, 2006, 179 p. [9] Ibidem. [10]Bruce W. Tuckman, «Developmental sequence in small groups», Psychological Bulletin, vol. 63 / 6, juin 1965, p [11]Eventus France, «Team building ou cohésion d équipe pour un management performant», En ligne : [Accès le ]. [12]Ken Schwaber et Jeff Sutherland, Scrum GuideTM en français, Scrum.org, [13]Scrum.org, «What is Scrum?», En ligne : Scrum. [Accès le ]. [14]Ken Schwaber et Jeff Sutherland, op. cit. [15]Ibidem. [16]Ibidem. [17]Mike Beedle, Arie van Bennekum, Alistair Cockburn[et al.], «Manifeste pour le développement Agile de logiciels», En ligne : [Accès le ]. [18]Scott W. Ambler, «The Principles of Agile Modeling (AM)», En ligne : [Accès le ]. [19]Asma Hachemi et Mohamed Ahmed-Nacer, «Documentation Agile: pratiques actuelles et défis», [20]Chris L Sibbald, «What s new in IBM Rational Method Composer Version 7.5.1», En ligne : [Accès le ], p. 1. [21]Barry Boehm et Richard Turner, «Management challenges to implementing agile processes in traditional development organizations», IEEE Software, vol. 22 / 5, octobre 2005, p [22]Ibidem. [23]ESI International, «Full Survey Report - The Global State of the PMO: An Analysis for 2013», En ligne : [Accès le ]. [24]M. Lindvall[et al.], op. cit. 73

84 [25]Barry Boehm et Richard Turner, op. cit., p. 31. [26]M. Lindvall[et al.], op. cit. [27]Denis Duka, «Agile experiences in software development», 2012 Proceedings of the 35th International Convention MIPRO, 2012, p [28]D. Tudor et G.A. Walter, «Using an agile approach in a large, traditional organization», Agile Conference, 2006, Minneapolis, MN, 2006, p. 7 pp [29]M. Lindvall[et al.], op. cit. [30]Asma Hachemi et Mohamed Ahmed-Nacer, op. cit. [31]M. Lindvall[et al.], op. cit. [32]Mike Beedle[et al.], op. cit. [33]André Tremblay, Sondages: Histoire, Pratique et Analyse, Boucherville, Québec, Canada, Gaëtan Morin Éditeur, 1991, 492 p. [34]Christian Fauré, «Critique des démarches agiles», En ligne : [Accès le ]. [35]André Tremblay, op. cit. [36]Ken Schwaber, «Empiricism, the act of making decisions based on what is», En ligne : [Accès le ]. [37]André Tremblay, op. cit. [38]Mike Beedle[et al.], op. cit. [39]Mike Beedle, Arie van Bennekum, Alistair Cockburn[et al.], «Principes sous-jacents au manifeste», En ligne : [Accès le ]. [40]André Tremblay, op. cit. [41]Curtis Reed, «Agile Misconceptions: What Agile is Not», En ligne : [Accès le ]. [42]Benoît Le Maux, «La conception d un questionnaire», En ligne : [Accès le ]. [43]Ibidem. [44]André Tremblay, op. cit. [45]Ibidem. [46]Statistique Canada, «Les statistiques : le pouvoir des données! Sélection d un échantillon», En ligne : [Accès le ]. [47]Statistique Canada, «Les statistiques : le pouvoir des données! Échantillonnage non probabiliste», En ligne : [Accès le ]. [48]John P. Desmond, «Agile Development Techniques Produce Record Results at BMC Software», En ligne : [Accès le ]. [49]Scott W. Ambler, «Agile Modeling -- Frequently Asked Questions (FAQ)», En ligne : [Accès le ]. [50]Dean Leffingwell, «The Scaled Agile Framework - What is this?», En ligne : [Accès le ]. 74

85 [51]Dean Leffingwell, op. cit. [52]Dean Leffingwell, op. cit. [53]Dean Leffingwell, «Scaled Agile Framework Big Picture», En ligne : [Accès le ]. [54]Mark Lines et Scott W. Ambler, op. cit. [55]Ibidem. [56]Ibidem. [57]Dean Leffingwell, op. cit. [58]Mark Lines et Scott W. Ambler, op. cit. [59]Don Wells, «User Stories», En ligne : [Accès le ]. [60]Scott W. Ambler, «Agile Requirements Modeling», En ligne : [Accès le ]. [61]Dean Leffingwell, op. cit. [62]Mark Lines et Scott W. Ambler, op. cit. [63]Dean Leffingwell, op. cit. [64]Dean Leffingwell, op. cit. [65]Dean Leffingwell, op. cit. [66]Ibidem. [67]Dean Leffingwell, op. cit. [68]Dean Leffingwell, op. cit. [69]Ibidem. [70]Scott W. Ambler, «Exploring Initial Scope on Disciplined Agile Teams», En ligne : [Accès le ]. [71]Ibidem. [72]Mark Lines et Scott W. Ambler, op. cit. [73]Ibidem. [74]Wikipédia, «Lean», En ligne : [Accès le ]. [75]Dean Leffingwell, op. cit. [76]Mark Lines et Scott W. Ambler, op. cit. [77]François Beauregard, «Adopter l agilite amène un changement de culture», En ligne : [Accès le ]. [78]Joseph C. Thomas et Steven W. Baker, «Establishing an Agile Portfolio to Align IT Investments with Business Needs», IEEE, 2008, p [79]Ibidem. [80]Mark Lines et Scott W. Ambler, op. cit. [81]Ibidem. [82]Joseph Flahiff, «Integrating Agile into a Waterfall World», En ligne : [Accès le ]. [83]Ibidem. [84]Dean Leffingwell, op. cit. [85]Ken Schwaber et Jeff Sutherland, op. cit. [86]O Reilly Media, Extreme Programming Pocket Guide, O Reilly Media, 2003, 108 p. [87]Mark Lines et Scott W. Ambler, op. cit. 75

86 [88]Dean Leffingwell, op. cit. [89]Scott W. Ambler, «Agile Modeling: Where Do I Start?», En ligne : [Accès le ]. [90]Scott W. Ambler, «The Product Owner Role: A Stakeholder Proxy for Agile Teams», En ligne : [Accès le ]. [91]Scott W. Ambler, «The Architecture Owner Role: How Architects Fit in on Agile Teams», En ligne : [Accès le ]. [92]Mark Lines et Scott W. Ambler, op. cit. [93]Paul Gorans et Philippe Kruchten, «A Guide to Critical Success Factors in Agile Delivery», En ligne : [Accès le ]. [94]Mark Lines et Scott W. Ambler, op. cit. [95]Ibidem. [96]Ibidem. [97]Dean Leffingwell, op. cit. [98]Ibidem. [99]Ibidem. [100]Ken Schwaber et Jeff Sutherland, op. cit. [101]Paul Gorans et Philippe Kruchten, op. cit. [102]Mark Lines et Scott W. Ambler, op. cit. [103]ESI International, op. cit. [104]Ibidem. [105]Dean Leffingwell, op. cit. [106]Ibidem. [107]Mark Lines et Scott W. Ambler, op. cit. [108]Project Management Institute, A Guide To The Project Management Body Of Knowledge: (Pmbok Guide), 5th edition, Project Management Institute, 2013, 589 p. [109]Mark Lines, «Comparing DAD to the Rational Unified Process (RUP) Part 1», En ligne : [Accès le ]. [110]Mark Lines, «Disciplined Agile Delivery - A Tutorial», En ligne : [Accès le ]. [111]Mark Lines et Scott W. Ambler, op. cit. [112]Mark Lines, op. cit. [113]Mark Lines et Scott W. Ambler, op. cit. [114]Ibidem. [115]Dean Leffingwell, «SAFe ScrumXP Graphic», En ligne : [Accès le ]. [116]Dean Leffingwell, op. cit. [117]Dean Leffingwell, «Kanban at the Team Level in SAFe», En ligne : [Accès le ]. [118]Al Shalloway, «SAFe Kanban», En ligne : [Accès le ]. 76

87 [119] Dean Leffingwell, «SAFe Sprint Execution with SAFe ScrumXPban», En ligne : [Accès le ]. [120]John P. Desmond, op. cit. [121]VersionOne, «7th Annual State of Agile Development Survey Results», En ligne : [Accès le ]. [122]Scott W. Ambler, «Agile Modeling and extreme Programming (XP)», En ligne : [Accès le ]. [123]Craig Larman et Bas Vodde, «Large-Scale Scrum», En ligne : [Accès le ]. [124]Project Management Institute, op. cit. [125]Project Management Institute, Software Extension to the PMBOK Guide Fifth Edition, 2013, 247 p. [126]Project Management Institute, «PMI Agile Certified Practitioner (PMI-ACP)», En ligne : WT.mc_id=agilehomepage1213. [Accès le ]. [127]IEEE Computer Society, Pierre Bourque et Richard E. Fairley, SWEBOK Guide, V3.0, IEEE, 2014, 346 p. [128]Ibidem. [129]Ibidem. [130]Ibidem. [131]Ibidem. [132]Ibidem. [133]CMMI Institute, CMMI pour le développement, V1.3, CMMI Institute, [134]Ibidem. [135]Ibidem. [136]CMMI Institute, «CMMI and Agile», En ligne : [Accès le ]. [137]IIBA, «Agile Extension to the BABOK Guide», En ligne : Guide/Agile-Extension-to-the-BABOK-Guide-IIBA.aspx. [Accès le ]. [138]Scott W. Ambler, «Agile Adoption Rate Survey Results: February 2008», En ligne : [Accès le ]. [139]Scott W. Ambler, «Has Agile Peaked?», En ligne : [Accès le ]. [140]Ibidem. [141]CIO Executive Board, «Federal IT Management Series - Agile at Scale», CIO Executive Board, 2011, p [142]VersionOne, op. cit. [143]Ibidem. [144]Denis Duka, op. cit. [145]CIO Executive Board, op. cit. [146]VersionOne, op. cit. [147]Marie Jung, «La banque d investissement de la Société générale passe ses équipes à l agilité», En ligne : 77

88 la-societe-generale-passe-ses-equipes-a-l-agilite/. [Accès le ]. [148]Yves Rivoal, «Société Générale CIB mise sur les «méthodes agiles»», En ligne : html. [Accès le ]. [149]Nadia Cameron, «Banking IT s success on customer behaviour - Westpac, Clive Whincup, bank - CIO», En ligne : [Accès le ]. [150]Lubaina Manji et Dragan Jojic, «Agile Transformation at Barclays Retail and Business Banking (RBB)», En ligne : [Accès le ]. [151]Gunther Verheyen, «ING: Capturing agility via Scrum at a large Dutch bank», En ligne : Capturing-agility-via-Scrum-at-a-large-Dutch-bank. [Accès le ]. [152]Joseph Pelrine, «On Understanding Software Agility: A Social Complexity Point Of View», Emergence: Complexity & Organization, vol. 13 / 1/2, mars 2011, p [153]Ibidem. [154]Nathan Wilson, Gordon Van Huizen et Brian Prentice, «Hype Cycle for Application Development, 2013», En ligne : [Accès le ]. [155]Ibidem. [156]Henry Mintzberg, Grandeur et décadence de la planification stratégique, Paris, Dunod, 1994, 455 p. 78

89 Bibliographie AMBLER, Scott W., «Agile Adoption Rate Survey Results: February 2008»,En ligne : [Accès le ]. AMBLER, Scott W., «Agile Modeling and extreme Programming (XP)»,En ligne : [Accès le ]. AMBLER, Scott W., «Agile Modeling -- Frequently Asked Questions (FAQ)»,En ligne : [Accès le ]. AMBLER, Scott W., «Agile Modeling: Where Do I Start?»,En ligne : [Accès le ]. AMBLER, Scott W., «Agile Requirements Modeling»,En ligne : [Accès le ]. AMBLER, Scott W., «Exploring Initial Scope on Disciplined Agile Teams»,En ligne : [Accès le ]. AMBLER, Scott W., «Has Agile Peaked?»,En ligne : [Accès le ]. AMBLER, Scott W., «The Architecture Owner Role: How Architects Fit in on Agile Teams»,En ligne : [Accès le ]. AMBLER, Scott W., «The Principles of Agile Modeling (AM)»,En ligne : [Accès le ]. AMBLER, Scott W., «The Product Owner Role: A Stakeholder Proxy for Agile Teams»,En ligne : [Accès le ]. BEAUREGARD, François, «Adopter l agilite amène un changement de culture»,en ligne : [Accès le ]. BEEDLE, Mike, BENNEKUM, Arie VAN, COCKBURN, Alistair[et al.], «Manifeste pour le développement Agile de logiciels»,en ligne : [Accès le ]. BEEDLE, Mike, BENNEKUM, Arie VAN, COCKBURN, Alistair[et al.], «Principes sous-jacents au manifeste»,en ligne : [Accès le ]. 79

90 BOEHM, Barry et TURNER, Richard, «Management challenges to implementing agile processes in traditional development organizations», IEEE Software, vol. 22 / 5, octobre 2005, p CAMERON, Nadia, «Banking IT s success on customer behaviour - Westpac, Clive Whincup, bank - CIO»,En ligne : [Accès le ]. CAO, Dac-Buu, An empirical investigation of critical success factors in agile software development projects, Ph.D., Capella University, 2006, 179 p., En ligne : CIO EXECUTIVE BOARD, «Federal IT Management Series - Agile at Scale», CIO Executive Board, 2011, p CMMI INSTITUTE, «CMMI and Agile»,En ligne : [Accès le ]. CMMI INSTITUTE, CMMI pour le développement, V1.3, CMMI Institute, 2010, En ligne : DESMOND, John P., «Agile Development Techniques Produce Record Results at BMC Software»,En ligne : [Accès le ]. DUKA, Denis, «Agile experiences in software development», 2012 Proceedings of the 35th International Convention MIPRO, 2012, p ESI INTERNATIONAL, «Full Survey Report - The Global State of the PMO: An Analysis for 2013»,En ligne : [Accès le ]. EVENTUS FRANCE, «Team building ou cohésion d équipe pour un management performant»,en ligne : [Accès le ]. FAURÉ, Christian, «Critique des démarches agiles»,en ligne : [Accès le ]. FLAHIFF, Joseph, «Integrating Agile into a Waterfall World»,En ligne : [Accès le ]. 80

91 GORANS, Paul et KRUCHTEN, Philippe, «A Guide to Critical Success Factors in Agile Delivery»,En ligne : [Accès le ]. HACHEMI, Asma et AHMED-NACER, Mohamed, «Documentation Agile: pratiques actuelles et défis», 2011, En ligne : IEEE COMPUTER SOCIETY, BOURQUE, Pierre et FAIRLEY, Richard E., SWEBOK Guide, V3.0, IEEE, 2014, 346 p., En ligne : IIBA, «Agile Extension to the BABOK Guide»,En ligne : Guide/Agile-Extension-to-the-BABOK-Guide-IIBA.aspx. [Accès le ]. JUNG, Marie, «La banque d investissement de la Société générale passe ses équipes à l agilité»,en ligne : [Accès le ]. LARMAN, Craig et VODDE, Bas, «Large-Scale Scrum»,En ligne : [Accès le ]. LEFFINGWELL, Dean, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley Professional, 2011, 518 p. LEFFINGWELL, Dean, «Kanban at the Team Level in SAFe»,En ligne : [Accès le ]. LEFFINGWELL, Dean, «SAFe ScrumXP Graphic»,En ligne : [Accès le ]. LEFFINGWELL, Dean, «SAFe Sprint Execution with SAFe ScrumXPban»,En ligne : [Accès le ]. LEFFINGWELL, Dean, «Scaled Agile Framework Big Picture»,En ligne : [Accès le ]. LEFFINGWELL, Dean, Scaling Software Agility: Best Practices for Large Enterprises, Addison-Wesley Professional, 2007, 349 p. LEFFINGWELL, Dean, «The Scaled Agile Framework - What is this?»,en ligne : [Accès le ]. LE MAUX, Benoît, «La conception d un questionnaire»,en ligne : [Accès le ]. LINDVALL, M., MUTHIG, D., DAGNINO, A.[et al.], «Agile software development in large organizations», Computer, vol. 37 / 12, décembre 2004, p

92 LINES, Mark, «Comparing DAD to the Rational Unified Process (RUP) Part 1»,En ligne : [Accès le ]. LINES, Mark, «Disciplined Agile Delivery - A Tutorial»,En ligne : [Accès le ]. LINES, Mark et AMBLER, Scott W., Disciplined Agile Delivery: A Practitioner s Guide to Agile Software Delivery in the Enterprise, IBM Press, 2012, 513 p., En ligne : MANJI, Lubaina et JOJIC, Dragan, «Agile Transformation at Barclays Retail and Business Banking (RBB)»,En ligne : Transformation-at-Barclays-Bank.pdf. [Accès le ]. MINTZBERG, Henry, Grandeur et décadence de la planification stratégique, Paris, Dunod, 1994, 455 p. O REILLY MEDIA, Extreme Programming Pocket Guide, O Reilly Media, 2003, 108 p., En ligne : PELRINE, Joseph, «On Understanding Software Agility: A Social Complexity Point Of View», Emergence: Complexity & Organization, vol. 13 / 1/2, mars 2011, p PROJECT MANAGEMENT INSTITUTE, A Guide To The Project Management Body Of Knowledge: (Pmbok Guide), 5th edition, Project Management Institute, 2013, 589 p. PROJECT MANAGEMENT INSTITUTE, «PMI Agile Certified Practitioner (PMI-ACP)»,En ligne : WT.mc_id=agilehomepage1213. [Accès le ]. PROJECT MANAGEMENT INSTITUTE, Software Extension to the PMBOK Guide Fifth Edition, 2013, 247 p., En ligne : GMProduct= REED, Curtis, «Agile Misconceptions: What Agile is Not»,En ligne : [Accès le ]. RIVOAL, Yves, «Société Générale CIB mise sur les «méthodes agiles»»,en ligne : [Accès le ]. 82

93 SCHWABER, Ken, «Empiricism, the act of making decisions based on what is»,en ligne : [Accès le ]. SCHWABER, Ken et SUTHERLAND, Jeff, Scrum Guide TM en français, Scrum.org, 2011, En ligne : SCRUM.ORG, «What is Scrum?»,En ligne : Scrum. [Accès le ]. SHALLOWAY, Al, «SAFe Kanban»,En ligne : [Accès le ]. SIBBALD, Chris L, «What s new in IBM Rational Method Composer Version 7.5.1»,En ligne : [Accès le ]. STATISTIQUE CANADA, «Les statistiques : le pouvoir des données! Échantillonnage non probabiliste»,en ligne : fra.htm#a4. [Accès le ]. STATISTIQUE CANADA, «Les statistiques : le pouvoir des données! Sélection d un échantillon»,en ligne : [Accès le ]. THOMAS, Joseph C. et BAKER, Steven W., «Establishing an Agile Portfolio to Align IT Investments with Business Needs», IEEE, 2008, p , En ligne : TREMBLAY, André, Sondages: Histoire, Pratique et Analyse, Boucherville, Québec, Canada, Gaëtan Morin Éditeur, 1991, 492 p. TUCKMAN, Bruce W., «Developmental sequence in small groups», Psychological Bulletin, vol. 63 / 6, juin 1965, p TUDOR, D. et WALTER, G.A., «Using an agile approach in a large, traditional organization», Agile Conference, 2006, Minneapolis, MN, 2006, p. 7 pp VERHEYEN, Gunther, «ING: Capturing agility via Scrum at a large Dutch bank»,en ligne : [Accès le ]. VERSIONONE, «7th Annual State of Agile Development Survey Results»,En ligne : [Accès le ]. WELLS, Don, «User Stories»,En ligne : [Accès le ]. 83

94 WIKIPÉDIA, «Lean»,En ligne : [Accès le ]. WILSON, Nathan, HUIZEN, Gordon VAN et PRENTICE, Brian, «Hype Cycle for Application Development, 2013»,En ligne : [Accès le ]. 84

95 Annexe 1 Questionnaire du sondage en français Sondage sur l'agilité Ce questionnaire vise à mesurer les connaissances en agilité et l'utilisation des méthodes de développement agile dans les équipes TI des entreprises financières. Les données recueillies seront utilisées dans le cadre de mon essai de maîtrise. Il n'y a pas de mauvaises réponses. Toutes vos réponses demeureront confidentielles. Ce questionnaire comporte 16 questions à choix de réponses. 1) Quel est votre rôle dans l'organisation? Analyste d'affaire Analyste de système Architecte Administrateur de bases de données Cadre intermédiaire Cadre supérieur Chargé de projet Chef d'équipe Concepteur d'interface utilisateur Développeur logiciel Spécialiste en assurance-qualité Autre 85

96 2) Sur combien de sites géographiques votre équipe de développement est-elle distribuée? Idéalement, une équipe colocalisée partage un espace contigu sur un même étage à 4 5 à 7 8 à et plus Je ne sais pas 3) Votre plus grosse équipe, située dans les même locaux, représente quel pourcentage de toute l'équipe de développement, tous lieux confondus? Idéalement, une équipe colocalisée partage un espace contigu sur un même étage. 20% ou moins 21% - 40% 41% - 60% 61% - 80% 81% - 100% Je ne sais pas 86

97 4) Selon vous, les méthodes de développement logicielles agiles sont, grosso modo : moins chères, itératives et incrémentales visent la livraison régulière de fonctionnalités ayant une forte valeur ajoutée des méthodes de développement qui éliminent toute documentation écrite déstructurées, sans processus formel car elles reposent sur la collaboration Je ne sais pas 5) En général, je considère le niveau d'efficacité des méthodes agiles comme... 1 = Inefficaces; 5 = Très efficaces Je ne sais pas 6) Quelle(s) méthode(s) de développement agile utilisez-vous en ce moment? Vous pouvez choisir plus d'une réponse. Scrum Extreme programming (XP) RAD DSDM Autre Je n'utilise aucune méthode agile Je ne sais pas 87

98 7) Selon vous, quel est le niveau d'implication du propriétaire du produit dans la création des requis en ce moment? Le propriétaire du produit est le représentant des clients et des utilisateurs.1 = Pas impliqué du tout; 5 = Très impliqué Je ne sais pas 8) À votre avis, quel est le niveau d'implication des parties prenantes dans la création des requis en ce moment?ne tenez pas compte de l'implication du propriétaire du produit. Une partie prenante est un acteur, individuel ou collectif (groupe ou organisation), activement ou passivement concerné par une décision ou un projet Je ne sais pas 88

99 9) En général, diriez-vous que les parties prenantes sont favorables à l'agilité? 1 - Défavorables; 5 = Favorables Je ne sais pas 10) Au total, combien d'années d'expérience avez-vous en développement agile? 0 Moins d'un an 1 à 2 ans 3 à 5 ans 6 à 10 ans 11 ans et plus 11) Je considère ma connaissance des méthodologies, méthodes et pratiques agiles comme... 1 = Faible; 5 = Élevée

100 12) Quels outils de développement votre équipe utilise-t-elle? Vous pouvez choisir plus d'une réponse. Outils de gestion du code source (CVS, Subversion, MKS, GIT, etc.) Outils d'intégration continue (Hudson/Jenkins, etc.) Tests unitaires (JUnit, etc.) Tests intégrés Environnements de développement intégrés (Eclipse, RAD, MS Visual Studio, etc.) Outils d'audit de code (Sonar, Fortify, etc.) Autre Je ne sais pas 13) Nous élaborons nos requis en mode agile. Oui Non Partiellement Je ne sais pas 14) À quel point seriez-vous favorable à l'utilisation de méthodes agiles pour l'élaboration de requis? 1 = Défavorable; 5 = Favorable

101 15) Je suis au courant de l'existence de passerelles entre l'agilité et les processus non-agiles de l'entreprise. Oui Non 16) L'entreprise m'a fait part d'un plan de développement de l'agilité. Oui Non 91

102 Annexe 2 Questionnaire du sondage en anglais Survey on Agile With this questionnaire, I want to assess the level of knowledge in agility and the usage of agile software development methods in IT teams working in the financial sector. The data gathered will be used in the context of my master's degree essay. There are no wrong answers. All your answers will remain strictly confidential. This questionnaire is composed of 16 multiple choices questions. 1) What is your role in the organization? Business analyst Systems analyst Architect Database administrator Middle management Upper management Project manager Team leader User interface designer Software developer Quality assurance specialist Other 92

103 2) On how many geographical sites is your development team distributed? Ideally, a co-located team shares contiguous space on a single floor to 4 5 to 7 8 to and more I don't know 3) Your biggest development team, located in the same office, represents what percentage of the whole development team, including every geographical site? Ideally, a co-located team shares contiguous space on a single floor. 20% or less 21% - 40% 41% - 60% 61% - 80% 81% - 100% I don't know 93

104 4) In your opinion, agile software development methods are, more or less : less expensive, iterative and incremental. geared towards regular deliveries of functionalities with a lot of added value. development methods that eliminate all forms of written documentation. unstructured, with no formal process because they rely on collaboration. I don't know. 5) In general, I consider the level of efficiency of agile methods to be... 1 = Inefficient; 5 = Very efficient I don't know 94

105 6) Which agile development method(s) are you using right now? You can choose more than one answer. Scrum Extreme programming (XP) RAD DSDM Other I don't use any agile methods. I don't know. 7) In your opinion, what is the level of involvement of the product owner in the creation of requirements right now? The Product Owner represents the stakeholders and is the voice of the customer.1 = Not involved at all; 5 = Very involved I don't know 95

106 8) In your opinion, what is the level of involvement of all stakeholders in the creation of agile requirements right now? Do not take the involvement of the product owner into account. A stakeholder is an entity, individual or collective (group or organization), actively or passively implicated in a decision or project.1 = Not involved at all; 5 = Very involved I don't know 9) In general, what is the attitude of stakeholders towards agility? 1 = Unfavourable; 5 = Favourable I don't know 96

107 10) How many years of experience do you have in agile development? 0 Less than a year 1 to 2 years 3 to 5 years 6 to 10 years 11 years and more 11) I consider my knowledge of agile methodologies, methods and practices to be... 1 = Low; 5 = High

108 12) Which development tools is your team using? You can choose more than one answer. Source control tools (CVS, Subversion, MKS, GIT, etc.) Continuous integration tools (Hudson/Jenkins, etc.) Unit tests (JUnit, etc.) Integrated tests Integrated development environment (Eclipse, RAD, MS Visual Studio, etc.) Code audit tools (Sonar, Fortify, etc.) Other I don't know 13) We are creating our requirements using agile methods. Yes No Partially I don't know. 98

109 14) To which point would you be favourable to the creation of requirements using agile methods? 1 = Unfavourable; 5 = Favourable ) I am aware of the existence of bridges between agility and non-agile processes in the enterprise. Yes No 16) The company told me about an agile development plan. Yes No 99

110 Annexe 3 Résultats du sondage Sondage Internet chez le Groupe Financier GFL Du 15 au 30 juillet 2013 Nombre de répondants : 77 Taux d'achèvement : 74% Langue des répondants : Français (29), Anglais (48) Pays : Canada (75), États-Unis (2) 1) Quel est votre rôle dans l'organisation? Réponse Pourcentage Décompte Analyste d'affaire 6% 5 Analyste de système 6% 5 Architecte 10% 8 Cadre intermédiaire 14% 11 Cadre supérieur 3% 2 Chargé de projet 13% 10 Chef d'équipe 5% 4 Développeur logiciel 22% 17 Spécialiste en assurance-qualité 13% 10 Autre 6% 5 Total des réponses 77 1) Quel est votre rôle dans l'organisation? (Autre) # Réponse 1 information specialist 2 IT Specialist 3 Gating Specialist 4 PCO 5 Scrum Master 100

111 2) Sur combien de sites géographiques votre équipe de développement est-elle distribuée? Réponse Pourcentage Décompte 1 23% % 23 3 à 4 35% 27 5 à 7 5% 4 8 à 10 0% 0 11 et plus 0% 0 Je ne sais pas 6% 5 Total des réponses 77 3) Votre plus grosse équipe, située dans les même locaux, représente quel pourcentage de toute l'équipe de développement, tous lieux confondus? Réponse Pourcentage Décompte 20% ou moins 16% 12 21% - 40% 8% 6 41% - 60% 25% 19 61% - 80% 17% 13 81% - 100% 19% 15 Je ne sais pas 16% 12 Total des réponses

112 4) Selon vous, les méthodes de développement logicielles agiles sont, grosso modo : Réponse Pourcentage Décompte moins chères, itératives et incrémentales. 23% 18 visent la livraison régulière de fonctionnalités ayant une forte valeur ajoutée. des méthodes de développement qui éliminent toute documentation écrite. déstructurées, sans processus formel car elles reposent sur la collaboration. 65% 50 0% 0 8% 6 Je ne sais pas. 4% 3 Total des réponses 77 5) En général, je considère le niveau d'efficacité des méthodes agiles comme... Réponse Pourcentage Décompte 1 4% 3 2 5% % % % 15 Je ne sais pas 8% 6 Total des réponses

113 6) Quelle(s) méthode(s) de développement agile utilisez-vous en ce moment? Réponse Pourcentage Décompte Scrum 40% 31 Extreme programming (XP) 9% 7 RAD 8% 6 DSDM 1% 1 Autre 9% 7 Je n'utilise aucune méthode agile. 44% 34 Je ne sais pas. 8% 6 Total des réponses 77 6) Quelle(s) méthode(s) de développement agile utilisez-vous en ce moment? (Autre) # Réponse 1 kanban 2 Kanban 3 Kanban 4 Kanban 5 Kanban Adaptation de principes 6 agiles / incrémentals Officially the some dev teams are using Scrum, but in reallity they are using a Waterfall 7 disguised as Scrum. 103

114 7) Selon vous, quel est le niveau d'implication du propriétaire du produit dans la création des requis en ce moment? Réponse Pourcentage Décompte 1 3% % % % % 14 Je ne sais pas 10% 8 Total des réponses 77 8) À votre avis, quel est le niveau d'implication des parties prenantes dans la création des requis en ce moment? Ne tenez pas compte de l'implication du propriétaire du produit. Réponse Pourcentage Décompte 1 3% % % % % 3 Je ne sais pas 22% 17 Total des réponses

115 9) En général, diriez-vous que les parties prenantes sont favorables à l'agilité? Réponse Pourcentage Décompte 1 1% % % % % 4 Je ne sais pas 23% 18 Total des réponses 77 10) Au total, combien d'années d'expérience avez-vous en développement agile? Réponse Pourcentage Décompte 0 13% 10 Moins d'un an 17% 13 1 à 2 ans 25% 19 3 à 5 ans 38% 29 6 à 10 ans 8% 6 11 ans et plus 0% 0 Total des réponses 77 11) Je considère ma connaissance des méthodologies, méthodes et pratiques agiles comme... Réponse Pourcentage Décompte 1 21% % % % % 7 Total des réponses

116 12) Quels outils de développement votre équipe utilise-t-elle? Réponse Pourcentage Décompte Outils de gestion du code source (CVS, Subversion, MKS, GIT, etc.) 68% 52 Outils d'intégration continue (Hudson/Jenkins, etc.) Tests unitaires (JUnit, etc.) 40% 31 51% 39 Tests intégrés 32% 25 Environnements de développement intégrés (Eclipse, RAD, MS Visual Studio, etc.) Outils d'audit de code (Sonar, Fortify, etc.) 64% 49 36% 28 Autre 4% 3 Je ne sais pas 25% 19 Total des réponses 77 12) Quels outils de développement votre équipe utilise-t-elle? (Autre) # Réponse Ouitl de gestion des requis/incidents/tests 1 VersionOne 2 n/a version One / tests 3 systemes 106

117 13) Nous élaborons nos requis en mode agile. Réponse Pourcentage Décompte Oui 9% 7 Non 38% 29 Partiellement 36% 28 Je ne sais pas. 17% 13 Total des réponses 77 14) À quel point seriez-vous favorable à l'utilisation de méthodes agiles pour l'élaboration de requis? Réponse Pourcentage Décompte 1 5% 4 2 9% % % % 19 Total des réponses 77 15) Je suis au courant de l'existence de passerelles entre l'agilité et les processus non-agiles de l'entreprise. Réponse Pourcentage Décompte Oui 47% 36 Non 53% 41 Total des réponses 77 16) L'entreprise m'a fait part d'un plan de développement de l'agilité. Réponse Pourcentage Décompte Oui 18% 14 Non 82% 63 Total des réponses

118 Annexe 4 Introduction à l'agilité Bref historique du mouvement agile La naissance du mouvement agile prend sa source dans l'apparition de nouvelles méthodologies plus légères comme XP 21 et SCRUM 22 durant les années '90. En , 17 personnes représentant divers courants comme «Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development et Pragmatic Programming» 24 se sont réunies en Utah pour discuter des alternatives aux méthodologies de développement classiques. Les participants trouvaient ces méthodes, souvent appelées «waterfall» ou «en cascade» en français, trop lourdes et trop axées sur la documentation. Le résultat de cette rencontre fut le manifeste agile 25 qui comporte quatre valeurs de base qui forment le cœur de l'agilité : «Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser : Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L adaptation au changement plus que le suivi d un plan Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.» Don Wells, «Extreme Programming: A Gentle Introduction.», En ligne : [Accès le ]. 22 Ken Schwaber, «Scrum Development Process (Position paper)», En ligne : [Accès le ]. 23 Jim Highsmith, «History: The Agile Manifesto», En ligne : [Accès le ]. 24 Ibidem. 25 Mike Beedle, Arie van Bennekum, Alistair Cockburn[et al.], «Manifeste pour le développement Agile de logiciels», En ligne : [Accès le ]. 26 Ibidem. 108

119 Sans renier totalement les méthodes de développement créées auparavant, les signataires du manifeste agile proposent une philosophie de développement collaborative et souple qui réduit la documentation comme moyen de transmission primaire de l'information, qui s'adapte aux besoins changeants du client et qui livre un produit qui correspond à ses attentes et à ses besoins. Différences entre les approches traditionnelles et agiles Les méthodes traditionnelles s'appuient principalement sur la méthodologie dite «en cascade». Ce type de développement amène un développement linéaire, les étapes se suivant sans jamais se chevaucher( 27, p. 5), du moins en théorie. Il n'est pas nécessaire de parler des méthodes en spirale ou itératives car elles ne sont que des variantes de la méthode de développement en cascade. Les méthodologies agiles se basent sur les quatre valeurs énoncées précédemment qui elles-mêmes sont supportées par douze principes 28. Tel que mentionné plus haut, la documentation ne disparaît pas en agile. Il faut produire la documentation jugée nécessaire pour pouvoir assurer la pérennité des informations essentielles à la maintenance du produit. «Des logiciels opérationnels plus qu une documentation exhaustive» ne veut pas dire sans documentation tout court. Contrairement au mode de développement en cascade, la documentation n'est plus le principal vecteur de communication. La communication directe, face-à-face, n'est pas toujours possible dans un contexte où les équipes sont géodistribuées. Il ne faut pas croire que les modes de communication informatiques remplacent parfaitement la communication face-à-face. En effet, selon Jacques Fisher-Lokou, Nicolas Guégen et Nathalie Lépy : «... le mode de communication, comme support à la négociation ou à une activité de médiation, peut jouer un rôle déterminant sur son résultat, selon que le mode utilisé correspond au CMO (communication médiée par ordinateur) ou au FàF (face-à-face). Lorsque la négociation se déroule en 27 Ken Schwaber, «SCRUM Development Process», En ligne : [Accès le ]. 28 Mike Beedle, Arie van Bennekum, Alistair Cockburn[et al.], «Principes sous-jacents au manifeste», En ligne : [Accès le ]. 109

120 face-à-face, les sujets parviennent plus facilement à un accord que lorsqu'elle se déroule par ordinateur.» ( 29, p. 532) L'équipe de développement travaille avec les utilisateurs ou le client pour concevoir et ultimement livrer le logiciel. Elle ne fait pas que recevoir et implanter les spécifications déjà prêtes, développées sans leur participation ou avis. Les méthodes agiles sont favorables aux livraisons fréquentes, ou du moins sur des livrables pouvant potentiellement être mis en production dès qu'ils sont terminés. En bref, les méthodes agiles ne suivent pas un processus linéaire composé d'étapes séparées, mais d'une suite d'itérations impliquant toutes les parties concernées. Ces itérations produisent des livrables qui peuvent potentiellement être mis en production par le client. Bénéfices de l agilité Les bénéfices de l'agilité peuvent être classés en quatre catégories : la visibilité, l'adaptabilité, la valeur commerciale accrue et la gestion du risque (voir figure 16). Un projet agile vise la livraison rapide et fréquente de valeur ajoutée 30. Si le projet devait être interrompu, la somme des livrables constituerait un actif utile pour l'entreprise. Dans un projet en cascade annulé, il ne resterait qu'un inventaire de code et de documents non-testés, n'ayant aucune valeur ajoutée dans l'immédiat. De plus, les besoins étant en constante évolution, ces actifs risquent de se dévaluer, de voir leur contenu perdre de sa pertinence avec le temps. Ces livraisons fréquentes permettent d'accroître la visibilité du projet en démontrant que le logiciel est de plus en plus fonctionnel au fil des itérations. Le client peut s'assurer que le projet apporte de la valeur ajoutée à l'organisation avant la livraison finale. La transparence avec le client est ainsi accrue. 29 Jacques Fischer-Lokou, Nicolas Guéguen et Nathalie Lépy, «Effets de la communication par réseaux informatiques versus en face-à-face sur la représentation réciproque des négociateurs et leur prise de décision.», Bulletin de Psychologie, vol. 57 / 473, 2004, p VersionOne, «Benefits of Agile Software Development», En ligne : [Accès le ]. 110

121 Fig. 16: Proposition de valeur du développement agile Traduction libre Source : VersionOne, Les livraisons fréquentes de valeur ajoutée réduisent le risque en faisant ressortir les problèmes plus tôt. L'agilité préconise de s'attaquer d'abord aux risques les plus élevés. Ce concept est appelé «fail fast» Cela permet d'avoir l'heure juste au début du projet et de prendre les mesures appropriées, incluant l'arrêt ou le report des travaux, tôt plutôt que 31 Ibidem. 32 Échouer rapidement. (traduction libre) 33 Devesh Maheshwari, «Test early, fail fast!!», Agile Tester,

122 tard 34. On peut ainsi mettre un terme à un projet voué à l'échec avant qu'il n'engloutisse trop de ressources. Au niveau de la gestion du portefeuille de projet, on réduit le risque global dudit portefeuille et on limite les pertes financières au strict minimum. Ce processus itératif et incrémental caractérisé par de multiples interactions avec le client permet à l'équipe de développement de s'adapter à de nouvelles demandes du client au cours du développement. De plus, développer de cette manière permet de rajuster le tir lorsque l'on découvre des problèmes de nature technologique ou de rajuster le tir advenant un bouleversement dans le marché. Au lieu d'effectuer les tests à la fin du cycle de développement, en agile, les tests se font tout le long du processus de développement du logiciel. Ces tests réguliers permettent de débusquer les problèmes de conception et de programmation plus tôt. Les corrections se feront au cours du cycle de développement plutôt qu'à la fin. Cette méthode valorise de façon innovatrice le rôle des testeurs, qui se sentiront interpellés et utilisés à bon escient tout au long du projet. La qualité étant intégrée à tous les niveaux, les testeurs participerons à la livraison tout au long du projet, pas seulement à la fin lors des tests et des corrections de bogues. Régler un problème lors de la phase de test ou après la mise en production peut coûter jusqu'à 100 fois plus cher que de le régler lors de l'étape de la collecte des besoins Scott W. Ambler, «Agile Requirements Best Practices», En ligne : [Accès le ]. 35 Devesh Maheshwari, op. cit. 112