HEC Montréal. L impact des caractéristiques de l équipe sur. l agilité des équipes de développement de. systèmes TI.

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

Download "HEC Montréal. L impact des caractéristiques de l équipe sur. l agilité des équipes de développement de. systèmes TI."

Transcription

1 HEC Montréal L impact des caractéristiques de l équipe sur l agilité des équipes de développement de systèmes TI. Par Wafaa Toumi Sciences de la gestion (Technologie de l information) Mémoire présenté en vue de l obtention du grade de maîtrise ès gestion (M. Sc.) Octobre 2014 Wafaa Toumi, 2014

2 Sommaire De nos jours, il y a une croissance significative du déploiement des innovations technologiques dans divers contextes de plus en plus variés. Pour cette raison, le risque de livraison des projets TI avec un scope et des besoins qui changent durant le cycle de vie d un projet devient élevé. Pour pallier à ce risque, les approches de développement agile comme la méthode SCRUM, XP (extreme Programming), DSDM (Dynamic System Development Method) ont été proposées pour aider à adresser le facteur de risque relativement aux changements des requis (Beck et Andres, 2005). Ce travail de recherche va essayer de faire le lien entre l agilité et les caractéristiques des membres d équipe pour livrer un projet TI avec des requis qui changent. Le principal objectif de ce travail de recherche est de déterminer l influence de trois caractéristiques de l équipe (l autonomie, la diversité et la flexibilité) sur les dimensions de l agilité, d où la question de recherche suivante : L autonomie, la diversité et la flexibilité influencent-t-elles l agilité dans les projets TI? Dans le but de vérifier l influence de ces caractéristiques sur l agilité, le modèle de recherche s est basé principalement sur le modèle de Lee et Xia (2010) qui a étudié l influence de l autonomie et la diversité de l équipe sur les deux dimensions des approches agiles, soit l ampleur (response extensiveness) et l efficacité (response efficiency) de la réponse de l équipe auxquelles il a été ajouté la caractéristique de la flexibilité. Dans le but de vérifier les hypothèses du modèle de recherche une validation a été effectuée à l aide d une enquête par questionnaire auprès des gestionnaires de projets ayant complété des projets TI avec une approche agile. La collecte des données s est effectuée auprès des membres du comité agile du Québec. Par la suite, les données recueillies ont été analysées avec l outil SPSS par le biais d analyses descriptives, de fiabilité, de corrélation et finalement de régression afin de tester la validité, la fiabilité des mesures et les hypothèses de recherche. i

3 Les résultats de l enquête ont permis de constater que l influence conjointe des trois caractéristiques sur l ampleur de la réponse de l équipe, le pourcentage de variance expliquée obtenu dans ce travail de recherche (47%) est supérieur à celui obtenu dans l étude de Lee et Xia (2010) (14%). Ce résultat est explicable avec l ajout d une nouvelle caractéristique de l équipe au modèle qui est la flexibilité. Ce résultat permet de constater que la flexibilité a une influence additionnelle sur l ampleur de la réponse d une équipe qui travaille en mode agile. Quant au résultat de l influence conjointe des trois caractéristiques sur l efficacité de la réponse de l équipe, il est aussi supérieur (38%) par rapport au résultat de l étude de Lee et Xia (2010) (26%). Ce résultat indique que l ajout de la caractéristique flexibilité au modèle est pertinent puisque la valeur de l influence conjointe des caractéristiques a augmenté. Le résultat de l influence des deux caractéristiques combinées (autonomie et diversité) sur la flexibilité est significatif et le pourcentage de la variance expliquée (R 2 ) est de 24% de la variance de la flexibilité. Ce résultat permet d observer qu il existe bel est bien une relation entre ces caractéristiques. En fait, ce résultat montre un lien entre les caractéristiques de l équipe flexibilité et autonomie, diversité, qu il faut analyser en profondeur pour clarifier le type de la relation. Les résultats obtenus indiquent l influence des caractéristiques de l équipe (autonomie, diversité et flexibilité) sur les dimensions de l agilité (l ampleur et l efficacité de la réponse de l équipe aux changements) ainsi que ceux de l autonomie et de la diversité sur la flexibilité. Cependant, les résultats statistiques ne permettaient pas de généraliser cette relation. Ainsi, les résultats obtenus pourraient s avérer utiles pour guider les gestionnaires dans leurs choix des membres de l équipe, mais également ils permettaient d identifier de nouvelles pistes de recherches futures qui pourront approfondir la relation entre les caractéristiques de l équipe et l agilité et principalement «la flexibilité». Les mots clés : Approche agile, autonomie, diversité, flexibilité, ampleur, efficacité, caractéristique de l équipe. ii

4 Table des matières Remerciements... viii Chapitre1 : Problématique de recherche Contexte de la recherche Objectif de la recherche Contribution potentielle... 5 Chapitre 2 : Revue de la littérature et modèle de recherche Les approches agiles Définition des concepts L agilité L autonomie La Diversité La flexibilité Les principes des pratiques agiles Modèle de Lee et Xia (2010) Modèle de recherche Justificatif de l ajout de la flexibilité Modèle de recherche proposé Chapitre 3 : Méthodologie de recherche Justification de la démarche Les mesures des construits Design de l étude Méthode de collecte de données Échantillon Pré-test du questionnaire iii

5 Chapitre 4 : Analyse Taux de réponse Profil des répondants Profil des projets Résultats descriptifs Analyse de fiabilité Corrélations Analyse de régression Chapitre 5 : Discussion et Conclusion Discussion des résultats Limites de l étude Contributions théoriques et pratiques Piste de recherches futures Conclusion Annexe A : Questionnaire de collecte des données Annexe B: Tableau des corrélations entre tous les items iv

6 Liste des Tableaux Tableau 1 Les aspects influencés par les approches agiles Tableau 2 - Les apports et les inconvénients des méthodologies agiles... 9 Tableau 3 - L'agilité dans la littérature Tableau 4 - L'autonomie de l'équipe dans la littérature Tableau 5 - La diversité de l'équipe dans la littérature Tableau 6 - La flexibilité de l'équipe dans la littérature Tableau 7 - Les principes clés des approches agiles Tableau 8 - Métrique de la flexibilité Tableau 9-Chef d'équipe projet Vs. Membre d équipe Tableau 10-Distribution du sexe des participants Tableau 11-L'éducation des participants Tableau 12-Secteur économique du système Tableau 13-Domaine d'application du système Tableau 14-Les aspects des projets Tableau 15-Coûts estimés, le projet complété Tableau 16 - L'échéancier, le projet complété Tableau 17 - L'envergure du projet complété Tableau 18-Le succès des projets Tableau 19-Approche agile adoptée Tableau 20-Demandes de changement en cours de réalisation Tableau 21-La taille de l'équipe projet Tableau 22 - Statistiques descriptifs des construits indépendants Tableau 23-Statistiques descriptifs des construits dépendants v

7 Tableau 24 - Résultats Alpha de Cronbach Tableau 25 - Les scores des construits Tableau 26- Corrélation des construits Tableau 27 - Régression multiple Tableau 28 - Résultats de la régression: Efficacité = Autonomie, Diversité, Flexibilité Tableau 29 - Résultats de la régression: Efficacité = Autonomie, Diversité, Flexibilité Tableau 30 - Résultats de la régression: Flexibilité = Autonomie, Diversité Tableau 31- Sommaire comparatif des résultats Tableau 32 - L influence des caractéristiques de l'équipe sur les dimensions de l'agilité Tableau 33- Les éléments de différence entre les études vi

8 Liste des Figures Figure 1 : Cycle de vie d'un projet TI... 3 Figure 2 : Le modèle de recherche de Lee et Xia (2010) Figure 3 : Les résultats de Lee et Xia (2010) Figure 4 : Le modèle de recherche du mémoire Figure 5: Le modèle de recherche et ses mesures Figure 6 : Méthodologie de recherche Figure 7 - Paramètres de gestion des projets Figure 8: Les résultats des trois régressions vii

9 Remerciements J'adresse mes sincères remerciements et ma reconnaissance aux personnes qui m'ont aidé dans la réalisation de ce mémoire. En premier lieu, je remercie, M. Barki, professeur à l École des Hautes Études commercial (HEC). En tant que Directeur de mémoire, il m'a guidé dans mon travail, encadré, orienté, aidé à trouver des solutions pour avancer, conseillé et surtout il m a soutenu et encouragé pour que j arrive à compléter mon travail de recherche. J adresse mes remerciements également à tous les professeurs, intervenants et toutes les personnes qui par leurs paroles, leurs écrits, leurs conseils et leurs critiques ont guidé mes réflexions et ont accepté de me rencontrer et répondre à mes questions durant mes recherches. Je remercie très chaleureusement mon conjoint «Elyes El Air», qui grâce à son encouragement continu, à ses précieux conseils et sa patience j ai pu réussir à finaliser ce travail de recherche. A mes parents pour m avoir encouragé et supporté à entreprendre cette maîtrise. Sans eux, je n en serais pas là. Enfin, je remercie tous ceux qui, de près ou de loin, ont contribué à la réalisation de ce travail. viii

10 Chapitre1 : Problématique de recherche 1.1. Contexte de la recherche Dans l ère de la mondialisation, les entreprises évoluent dans un environnement de plus en plus complexe et changeant : des marchés saturés, une compétitivité croissante, une plus grande accessibilité au savoir, ainsi que des clients plus exigeants et moins fidèles (Rivard, 2003). Dans ce contexte d environnement changeant, les entreprises font face à des besoins d affaires davantage volatiles. Paré et al. (2008) notent que ces changements des besoins représentent un des facteurs de risque des projets TI. Ces facteurs peuvent causer des résultats indésirables tels que le dépassement de budget, d échéancier et/ou une mauvaise qualité du système. En effet, d après le «Standish group» 1 en 2008, seuls 32% des projets TI sont considérés comme un succès, alors que 24% sont des échecs et 44% sont entre les deux, et ce, en se basant sur les trois critères d évaluation des projets TI (échéancier, budget et fonctionnalité). Pour cette raison, les approches de développement agile comme la méthode SCRUM, XP (extreme Programming), DSDM (Dynamic System Development Method) ont été proposées pour aider à adresser le facteur de risque en liaison aux changements des requis (Beck et Andres, 2005). En fait, l approche de développement agile diffère des approches de planification structurées traditionnelles (telles que cascade, spirale, ou prototypage) puisqu elle met plus l emphase sur la souplesse des processus et l adaptation dynamique que sur la planification «front-end» et une lourde documentation (Nerur et Balijepally, 2007). L idée principale des méthodologies agiles est la notion de l agilité, qui est définie dans ce mémoire comme étant la capacité de l équipe du projet TI à répondre aux changements des besoins du client d une façon efficace et efficiente (Lee et Xia, 2010). Selon l étude de Scott Ambler (2008), cette méthodologie est assez répandue dans le monde des TI puisque son taux d adoption est de l ordre de 69%. En adoptant une telle approche, les entreprises visent à améliorer plusieurs aspects comme le montre le Tableau 1 : 1 Le rapport «Chaos Summary 2009: The 10 Laws of CHAOS». 1

11 Tableau 1 Les aspects influencés par les approches agiles. Facteurs Amélioration Aucun changement Aggravé Productivité 82% 13% 5% Qualité 77% 14% 9% Satisfaction des parties prenantes 78% 15% 7% Coût 37% 40% 23% De plus, les résultats obtenus de cette étude montrent qu il y a une adoption de plus en plus croissante des méthodes agiles. Toutefois, malgré la croissance de la popularité de ce type d approches, en pratique l agilité reste difficile à atteindre (Cockburn, 2001). Plusieurs organisations adoptent ces méthodologies sans comprendre clairement les facteurs à contrôler pour influencer cette notion (Lee et Xia, 2010). De ce fait, plusieurs chercheurs ont étudié en profondeur l agilité dont Lee et Xia (2010) qui l ont représentée par deux dimensions à savoir : l efficacité de la réponse de l équipe (Team Response Efficiency) et l ampleur de la réponse de l équipe (Team Response Extensiveness). L efficacité de la réponse de l équipe (Team Response Efficiency) a été définie par le temps, le coût, le personnel et les ressources requises par l équipe pour répondre aux changements demandés par le client et les intégrer dans le système. Ainsi, plus l équipe répondra de façon efficace, plus le niveau de l agilité sera élevé. En ce qui concerne l ampleur de la réponse de l équipe (Team Response Extensiveness), elle a été représentée par la proportion des différents types de changement des besoins de client auxquels l équipe du projet a répondu et intégrée au système. Du coup, plus l équipe répondra à une grande proportion des changements, plus son niveau d agilité sera élevé. Toutefois, il est à noter que la plupart des recherches portant sur les approches agiles, ne considèrent que la partie développement du système du projet TI. Dans ce présent travail, la méthodologie sera appliquée aux différentes étapes du cycle de vie du projet TI : gestion du projet, développement du système et implantation du système (Figure 1). 2

12 Développement du système Implantation du système Gestion du projet Figure 1 : Cycle de vie d'un projet TI Étant donné le cycle de vie des projets TI considérés, les équipes de projet multidisciplinaires se composeront principalement des analystes d affaires, analystes fonctionnels, développeurs, testeurs, gestionnaires de projet, gestionnaires du changement, champions, et les sponsors du projet. D un autre côté, Lee et Xia (2010) se sont également intéressés aux facteurs influençant l agilité dont principalement les caractéristiques de l équipe du projet. Il est à noter que ces chercheurs sont les premiers ayant examiné l influence de l autonomie et la diversité sur l agilité du développement logiciel. Ainsi, dans leur étude, l autonomie fait référence à l habilité de l équipe du projet à avoir l autorité et le contrôle à prendre des décisions pour bien mener le projet. En ce qui concerne la diversité, elle fait référence à la différence des membres de l équipe en termes de leurs profils, compétences, expertises et expériences. Les résultats obtenus viennent appuyer d autres recherches ayant conclu que les approches agiles considèrent l autonomie et la diversité de l équipe du projet comme étant des principes fondamentaux pour assurer l agilité (Larman, 2004). En effet, la méthodologie agile recommande que l équipe de projet soit dotée d auto-organisation, d auto-direction et d autodiscipline (Highsmith, 2004; Larman, 2004). De plus, Beck et Andres (2005) mentionnent que dans une approche agile, l équipe du projet doit posséder une variété de compétences et de perspectives nécessaires pour détecter les problèmes et les pièges, et ce, dans le but de résoudre des problèmes et la mise en œuvre des solutions. 3

13 De plus, d autres recherches ont étudié des caractéristiques de l équipe autres que l autonomie et la diversité dans le cadre de projet TI dont notamment la flexibilité de l équipe. Ainsi, Maruping et al. (2009) mentionnent que la flexibilité est requise dans la situation où les requis changent et l environnement est incertain. De plus, Lee et Xia (2005) et MacCormack et al. (2001) ont mis l emphase sur l importance de la flexibilité pour permettre à l équipe de développement logiciel de faire face aux changements des requis. Dans ce contexte, Harris et al. (2009) définissent la flexibilité de l équipe du projet comme étant sa capacité à improviser en réaction aux changements dans les requis, le budget, l échéancier et le risque. Dans ce contexte, Pavlou et El Sawy (2010) définissent les capacités d'improvisation comme étant la possibilité de reconfigurer spontanément les ressources existantes pour construire de nouvelles capacités opérationnelles afin de répondre aux urgences, aux imprévisibles et aux nouvelles situations de l'environnement. De plus, Lee et Xia (2005) ont reporté une relation positive entre la flexibilité et la satisfaction des utilisateurs finaux du système. Ainsi, plus l équipe du projet est flexible, plus elle pourra répondre aux changements demandés par le client. La flexibilité n a pas été étudiée comme un critère antécédent de l agilité, mais les recherches antérieures suggèrent qu elle serait un critère important. De ce fait, dans le cadre de ce mémoire, une amélioration sera apportée au modèle de Lee et Xia (2010) et ce, en ajoutant la flexibilité comme variable influençant l agilité. Par conséquent, ce travail mettra l emphase sur l influence de trois caractéristiques de l équipe sur l agilité soit l autonomie, la diversité et la flexibilité. Par ailleurs, il est également possible que l autonomie et la diversité aient une influence sur la flexibilité. Pour cette raison, la relation entre la flexibilité et les autres caractéristiques de l équipe sera également examinée Objectif de la recherche Les valeurs fondamentales, les principes et les pratiques de développement agile ont été tirés principalement des expériences passées. Son efficacité a été largement soutenue par des anecdotes et des arguments rhétoriques, ce qui a causé un manque de compréhension de la notion agile (Lee et Xia, 2010). Dans ce contexte, ce mémoire a pour but d approfondir la compréhension de la notion d agilité dans les projets TI en examinant les facteurs qui peuvent l influencer. 4

14 Ainsi, ce mémoire examinera les caractéristiques de l équipe du projet qui peuvent influencer l agilité. Pour ce faire, trois caractéristiques ont été sélectionnées : l autonomie, la diversité et la flexibilité. Dans le but de vérifier leur influence sur l agilité, deux dimensions d agilité seront prises en considération : l efficacité et l ampleur de la réponse de l équipe. De ce fait, le principal objectif de ce travail est d évaluer l influence de chaque caractéristique de l équipe sur les dimensions d agilité, d où la question de recherche suivante : L autonomie, la diversité et la flexibilité influencent-t-elles l agilité dans les projets TI? Ou L autonomie, la diversité et la flexibilité influencent-t-elles l efficacité et l ampleur de la réponse de l équipe dans le cadre des projets TI utilisant l approche agile? Telles que mentionnées précédemment, les relations entre les caractéristiques de l équipe (autonomie, diversité et flexibilité) seront aussi examinées. Par contre, la relation entre les dimensions de l agilité (ampleur et efficacité de la réponse) ne sera pas abordée, et ce, pour mettre davantage l emphase sur les caractéristiques de l équipe Contribution potentielle Plusieurs extrants seront générés par ce travail de recherche. Prime à bord, les travaux de recherche qui ont examiné les facteurs influençant l agilité sont limités, alors à travers ce mémoire, il est possible d enrichir la littérature sur la notion d agilité et les caractéristiques de l équipe. En fait, Lee et Xia (2010) sont les seuls qui ont étudié la relation entre les caractéristiques (autonomie et diversité) et l agilité. De ce fait, ce présent travail permettra de valider leur modèle et d ajouter une caractéristique supplémentaire de l équipe (la flexibilité). Au niveau pratique, ce mémoire aidera les gestionnaires à approfondir leur compréhension en ce qui concerne la notion d agilité en leur permettant de mieux choisir les membres de l équipe ayant plus d habilité à travailler en approche agile. Il sera même possible d adapter la méthode d embauche du personnel de travail dans le domaine des TI selon les caractéristiques étudiées. 5

15 Chapitre 2 : Revue de la littérature et modèle de recherche L objectif de cette revue de littérature est de présenter l ensemble des articles pertinents traitant le sujet d intérêt afin de bâtir les fondements théoriques sur lesquels baser notre étude. Les principales revues scientifiques dans le domaine des systèmes d information ont été consultées à partir de bases de données telles que ABI/Inform (Proquest), Business sources, et IEEE explorer. Les termes «agil*», «team», «autonomy», «diversity», «flexibility», ont servi de mots clés pour la sélection des articles. Également, des comptes rendus de conférences réputées dans le domaine scientifique en systèmes d information ont été consultés dont European Conference Information Systems, Hawaii Conference on System Sciences, International Conference on Information Systems et International Conference on Software Engineering. Finalement, les études auxquelles référaient les citations pertinentes des articles identifiés précédemment ont été explorées dans le but de définir l agilité, l autonomie, la diversité et la flexibilité. Ainsi, cette présente revue de littérature est structurée comme suit : dans un premier temps, les approches agiles seront présentées et développées. Ensuite, un modèle existant qui traite de l effet des caractéristiques de l équipe (diversité et autonomie) sera décrit. Pour terminer, le modèle à l étude dans ce présent travail sera présenté Les approches agiles Les approches agiles ont vu le jour dans le milieu des années En fait, ces méthodologies ont été développées dans le but de palier aux lacunes et lourdeurs des méthodes traditionnelles telles que les problèmes de dépassement de budget, échéancier et le manque de la réceptivité (Responsiveness) aux changements des requis (Beck et Andres, 2005; Cockburn, 2001; Highsmith, 2004; Larman, 2004). Le processus de gestion des projets TI en méthodologie agile est considéré dynamique, évolutif et intégré plutôt que statique, prédéfini et mécanique (Beck et Andres, 2005; Highsmith, 2000). Les méthodes agiles les plus communes sont XP (extreme Programming), Scrum, DSDM (Dynamic Systems Development Method), et FDD (Feature-Drive Development). En 2001, Agile Manifesto a publié les quatre valeurs fondamentales et les douze principes de développement agile. En effet, les quatre valeurs des approches agiles présentées sont (Agile Alliance, 2001) : 6

16 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. En plus de ces quatre valeurs, Beck (2000) et Cockburn (2002) ajoutent que les approches agiles préconisent l adaptation plutôt que l optimisation ainsi que l utilisation des itérations courtes de planification, d organisation et de codage tout au long du cycle de vie du projet. Les méthodologies agiles essayent de gérer efficacement les besoins changeants des utilisateurs à travers une variété de techniques (Beck et Andres, 2005). Elles favorisent la livraison fréquente et continue du travail de développement du système, l évolution des changements des requis, une étroite collaboration entre les développeurs et les clients, l auto-organisation et les habilités des équipes, la communication face à face, l excellence des techniques, la simplicité et l adaptation continue (Agile Alliance, 2001). En effet, accepter et répondre aux changements des requis du client sont au cœur du développement agile d un système (Lee et Xia, 2010). Ben Jemia (2009) a établi les apports et les inconvénients des méthodes agiles (voir Tableau 2) en se basant sur Schwaber (1995) et Lindstorm et Jeffries (2004). Bien que plusieurs avantages du développement agile ont été spéculés et revendiqués et que de plus en plus d organisations adoptent les approches agile, il y a eu peu d études empiriques qui ont rigoureusement examiné l efficacité du développement agile (Fruhling et De Vreede, 2006; Moe et al., 2008). En conséquence, les méthodologies agiles manquent de fondement théorique et des preuves scientifiques qui appuient leurs bénéfices revendiqués et leurs principes clés (Erickson et al., 2005). Dans le but d aider à réduire ce manque théorique, ce travail essaye de contribuer à mieux comprendre les principes et les fondements des approches agiles Définition des concepts Cette section sera consacrée à la définition des construits clés de ce travail, soit : l agilité, l autonomie de l équipe, la diversité de l équipe et la flexibilité de l équipe. 7

17 L agilité La littérature présente plusieurs définitions et descriptions de la notion d agilité dans le développement des SI. Par contre, elle reste vague quant à ses dimensions et mesures. Toutefois, il y a un point commun entre les différentes définitions et descriptions d agilité puisqu ils le définissent comme le fait d accepter et de répondre aux changements (Conboy et Fitzgerald, 2004; Erickson et al., 2005; Henderson-Sellers et Serour, 2005; Highsmith, 2004; Larman, 2004; Qumer et Henderson-Sellers, 2008). Dans ce travail, le construit agilité sera défini comme étant la capacité de répondre de façon efficace et efficiente aux changements des requis des utilisateurs durant le cycle de vie du projet (Lee et Xia, 2010). De ce fait, il est important de préciser que cette définition de l agilité a été choisie parce qu elle concerne le processus de développement et de gestion d un projet de technologie de l information. 8

18 Tableau 2 - Les apports et les inconvénients des méthodologies agiles (tiré de Ben Jemia, 2009) Auteurs Apports Inconvénients Schwaber (1995) Lindstorm et Jeffries (2004) Fait face à l imprévisible de l environnement que ce soit au début ou durant le projet. Flexible. Possède des mécanismes de contrôle qui permettent de gérer les variables du projet durant son déroulement (clients, échéancier, compétiteurs, qualité, visions, ressources). Partage des connaissances. Conduit à peu d erreurs. Les fonctionnalités qui ont le plus de valeurs sont développées avant les autres. Permet un accès continu aux informations concernant le statut des fonctionnalités ainsi qu à la qualité totale du système. Une équipe de développement qui travaille dans un espace énergétique qui communique constamment. Un développement qui n est pas dépendant d un seul programmeur. Une flexibilité par rapport au changement des besoins. Le développeur estime lui-même la durée des tâches. Le développeur a constamment accès au client pour clarifier tout détail qui concerne des fonctionnalités qu il est en train d implanter. Le développeur peut (et doit) nettoyer le code. Le projet est complété en quelques semaines. Tout développeur peut travailler sur n importe quelle partie du système. Le développeur peut choisir n importe quelle personne pour l aider, et ce, à tout moment. Le développeur n a pas à travailler durant de longues heures. L information non documentée détenue par les membres de l équipe occupe une place importante. Nécessite des équipes de petite taille. Contient peu de documentation. Nécessite un bon sens du relationnel (importance des interactions). Impose une contrainte supplémentaire puisqu elle nécessite que le client soit prêt à s impliquer. 9

19 De plus, il semble à priori que la littérature ait tendance à décomposer l agilité en deux dimensions principales : l ampleur de la réponse de l équipe (response extensiveness) et l efficacité de la réponse de l équipe (response efficiency) (Lee et Xia, 2010). En fait, l ampleur de la réponse est reliée à l étendue, la portée, l envergure et la variété de la réponse de l équipe de projet (Lee et Xia, 2010). En revanche, l efficacité de la réponse fait référence aux temps, coût, ressources ou effort associé à la réponse de l équipe de travail (Lee et Xia, 2010). Le développement agile favorise à la fois l ampleur de la réponse à accepter (embracing) les divers changements (Henderson-Sellers et Serour, 2005; Qumer et Henderson- Sellers, 2008) et l efficacité de la réponse en termes de répondre de façon rapide et à faible coût (Conboy et Fitzgerald, 2004; Erickson et al., 2005; Larman, 2004; Qumer et Henderson- Sellers, 2008). Dans ce contexte, le Tableau 3 résume les différentes définitions du construit d agilité. 10

20 Tableau 3 - L'agilité dans la littérature (Lee & Xia, 2010) (traduction libre) Référence Cockburn (2007) Conboy et Fitzgerald (2004) Erickson et al. (2005) Henderson-Seller et Serour (2005) Highsmith (2004) Larman (2004) Lyytinen et Rose (2006) Qumer et Henderson- Sellers (2008) Définition / Concepts L agilité peut être comparée à une lumière qui est à peine suffisante, et maniable. L'agilité est définie comme étant la prédisposition (readiness) permanente d'une entité à accepter le changement rapidement ou intrinsèquement, de manière proactive ou réactive, à travers la haute qualité, la simplicité, des composants économiques et les relations avec son environnement. L agilité est associée à des concepts connexes comme la légèreté, la souplesse, la rapidité, la dextérité, la vivacité, ou la vigilance, il signifie la diminution de la lourdeur des méthodes traditionnelles de développement de logiciels afin de promouvoir une réponse rapide aux changements des environnements et aux changements dans les besoins des utilisateurs. L agilité réfère à la prédisposition (readiness) d'agir ou de changer. Il a deux dimensions: (1) la capacité de s'adapter aux divers changements et (2) la capacité d'affiner et restructurer le processus du développement de logiciels en cas de besoin. L'agilité est la capacité à la fois de créer et de répondre aux changements afin de tirer profit dans un environnement économique turbulent. C'est la capacité d'équilibrer la flexibilité et la stabilité. L'agilité est une réponse rapide et flexible aux changements. L'agilité est définie comme la capacité de sentir et de répondre rapidement aux changements techniques et aux nouvelles opportunités d affaires, il est édicté par l'apprentissage basé sur l'exploration et l'exploitation. L'agilité est un comportement persistant de la capacité d'une entité qui présente de la flexibilité de tenir compte des changements prévus ou imprévus rapidement, suivant la plus courte durée de temps et utilisant des instruments économiques, simples et de qualité dans un environnement dynamique; l agilité peut être évaluée par la flexibilité, la vitesse, la maigreur (leanness), l'apprentissage et la réceptivité (responsiveness) 11

21 L autonomie Le développement agile des systèmes d information est fondamentalement centré sur les gens et reconnaît la valeur des compétences des membres de l'équipe pour rendre le processus de développement plus agile (Nerur et Balijepally, 2007). En fait, avoir des personnes ayant les compétences appropriées et les autoriser à prendre des décisions est essentielle pour la réussite du développement agile (Chow et Cao, 2008; Cockburn, 2007; Highsmith, 2004). L autonomie de l équipe reflète le degré de discrétion et d indépendance accordé à l équipe dans la planification des travaux, l établissement des procédures et des méthodes à utiliser, la sélection et le déploiement des ressources, l embauche et le renvoi des membres de l équipe, l assignation des tâches aux membres de l équipe et la réalisation des tâches assignées (Breaugh, 1985). Cette caractéristique permet la décentralisation du pouvoir décisionnel à ceux qui vont effectivement réaliser les tâches (Tatikonda et Rosenthal, 2000). Le développement agile met l accent sur l importance de l autonomie, l'auto-organisation, l auto-direction, et l'autodiscipline de l équipe du projet afin d atteindre l'agilité dans le développement du système (Highsmith, 2004; Nerur et Balijepally, 2007; Sharp et Robinson, 2004). En effet, les équipes autonomes ont une marge considérable dans la façon de produire les résultats (Highsmith, 2004). Étant donné que l autonomie donne le pouvoir décisionnel aux personnes qui font face aux problèmes et les gèrent dans le quotidien, elle augmente la vitesse et l efficacité de la résolution des problèmes (Larman, 2004; Tata et Prasad, 2004). Bien que l autonomie des équipes soit l un des principes clés du développement agile, il existe peu de recherches empiriques ayant testé son effet sur l agilité du développement des systèmes (Lee et Xia, 2010). Le Tableau 4 résume la revue de littérature liée à l autonomie de l équipe. 12

22 Tableau 4 - L'autonomie de l'équipe dans la littérature (Lee & Xia, 2010) (traduction libre) Référence Beck et Andres (2005) Chow et Cao (2008) Cockburn & Highsmith (2001) Highsmith (2002) Highsmith (2004) Kelley (2008) Larman (2004) Nerur et Balijepally (2007) Sharp et Robinson (2004) Définition / Concepts Un des principes de XP est la responsabilité et l'autorité de l'équipe. L auto-organisation de l équipe permet l augmentation de la qualité du système. Les équipes agiles sont caractérisées par l'auto-organisation. L équipe du projet devrait permettre à l'équipe la prise de décision Le développement agile soutient l'auto-organisation, l'autodiscipline, et l'autogestion. La délégation des responsabilités est un élément clé pour le développement agile. En Scrum, l'équipe est dotée de l'autorité et des ressources pour trouver leur propre voie et de résoudre leurs propres problèmes. L auto-organisation de l équipe est la clé de la réceptivité (Responsiveness) et de la flexibilité. L autogestion et l auto-organisation sont essentielles pour la culture de l équipe du développement agile, en particulier pour XP La Diversité La diversité reflète l'hétérogénéité au sein de l'équipe en termes d'attributs individuels, tels que l'âge, le sexe, l'origine ethnique, l'éducation, les antécédents fonctionnels, l'ancienneté, et les capacités techniques (Williams et O Reilly, 1998). En fait, le développement agile se base sur l idée que les équipes diversifiées sont plus efficaces que les équipes homogènes pour détecter et répondre aux diverses modifications de l environnement (Cockburn, 2007; MacCormack et al., 2001). En s appuyant sur la loi de la variété requise (Ashby, 1956), la littérature suggère que la variété interne d une équipe de développement du système doit correspondre à la variété et à la complexité de son environnement et que la diversité des compétences amplifie la variété interne qui permet à l'équipe de bien répondre aux changements de l'environnement (Highsmith, 2004; Nerur et Balijepally, 2007). Malgré le fait que la diversité de l équipe soit souvent accompagnée par des conflits, il est suggéré pour le développement agile que les équipes ont besoin de réunir une variété de compétences et de perspectives afin de pouvoir détecter les problèmes et réfléchir aux différentes façons de les résoudre et d implanter des 13

23 solutions (Coad et al., 1999). Néanmoins, peu de recherches empiriques ont étudié comment la diversité des équipes affecte l'agilité de développement (Lee et Xia, 2010). Le Tableau 5 présente la revue de littérature liée à la diversité de l équipe. Tableau 5 - La diversité de l'équipe dans la littérature (Lee & Xia, 2010) (traduction libre) Référence Beck et Andres (2005) Cockburn (2007) Highsmith (2004) MacCormack et al. (2001) Nerur et Balijepally (2007) Définition / Concepts Un principe de XP est la diversité des équipes, représenté par la notion de «toute l'équipe». La diversité de l'équipe est souhaitable; les équipes hétérogènes performent mieux que les équipes homogènes. Il est essentiel d avoir les bonnes personnes ayant les compétences appropriées. Le nombre de participants expérimentés d une équipe est positivement lié à sa performance. La diversité de l'équipe est la clé du développement agile La flexibilité La flexibilité est nécessaire dans la gestion du développement des innovations et des applications TI étant donné que les projets TI varient considérablement en taille et en complexité. Les approches souples et itératives du type «Agile» ont fourni un cadre adéquat pour développer et mettre en œuvre ce type de projets (Chang, 2010). En effet, la flexibilité a été identifiée comme un facteur clé qui permet aux équipes de projet logiciel de rester adaptables aux éventuels risques environnementaux au cours du processus de développement logiciel (Maruping, 2006). D un autre côté, Golden et Powell (2000) définissent la flexibilité comme étant la capacité de s adapter. L'adaptabilité de l'équipe représente la mesure dans laquelle elle est capable de modifier sa configuration des rôles et des tâches pour trouver des solutions alternatives dans le but de réaliser la correspondance entre son comportement et une série de nouvelles exigences auxquelles elle est confrontée (LePine, 2005). De plus, Harris et al. (2009) ajoutent un élément supplémentaire à la définition de la flexibilité qui est la capacité d improviser afin de répondre aux changements dans les requis, le budget, l échéancier, et le risque. Il est important de signaler que Crossan et al. (2005) avaient noté que la capacité des développeurs à improviser peut permettre aux individus de faire des ajustements 14

24 en continu grâce à un processus créatif qui permet le développement de solutions nouvelles et utiles dans un court laps de temps. Dans ce contexte, Pavlou et El Sawy (2010) définissent les capacités d'improvisation comme étant la possibilité de reconfigurer spontanément les ressources existantes pour construire de nouvelles capacités opérationnelles dans le but de répondre aux urgences, aux imprévisibles ainsi qu aux nouvelles situations de l'environnement. En fait, selon ces définitions il est possible de déduire que les membres d une équipe agile doivent être flexibles en ayant des capacités d improvisation pour qu ils puissent répondre aux changements des requis. Il est important de signaler que la flexibilité et l'ouverture créent la confiance entre les membres du groupe lors du partage de l'information (Brzovic et Matz, 2009) et représentent des éléments fondamentaux qui permettent aux équipes de travailler en méthodologie agile. Le Tableau 6 résume la revue de littérature liée à la flexibilité de l équipe. Tableau 6 - La flexibilité de l'équipe dans la littérature Référence Golden et Powell (2000) Harris et al. (2009) Lee et Xia (2005) Maruping et al. (2009) Maruping (2006) Smith (2008) Définition / Concepts La flexibilité est la capacité de s adapter. La flexibilité de l équipe du projet est sa capacité à improviser en réaction aux changements dans les requis, le budget, l échéancier, et le risque. La capacité de l'équipe à répondre de façon efficace et efficiente aux changements d'activité et de la technologie. La flexibilité est requise quand les requis changent et l environnement est incertain. La flexibilité a été identifiée comme un facteur clé qui permet aux équipes de projet logiciel de rester adaptables aux éventuels risques environnementaux au cours du processus de développement logiciel. La capacité d'apporter des changements dans le logiciel en cours de développement ou dans le processus par lequel il se développe, même relativement tard dans le développement, sans avoir beaucoup de perturbation Les principes des pratiques agiles Ayant défini les concepts fondamentaux de ce mémoire, il est important de résumer (voir Tableau 7) les principes clés et les pratiques implicites dans le Agile Manifesto et les quatre méthodes agiles couramment utilisées qui mettent l'accent sur l agilité de développement de logiciels, ainsi que sur l'autonomie, la diversité, et la flexibilité des équipes (Lee et Xia, 2010). 15

25 Tableau 7 - Les principes clés des approches agiles Les approches agiles Agile Alliance Manifesto (Agile Alliance, 2001) DSDM (Stapleton, 1997) FDD (Coad et al., 1999) Scrum (Schwaber et Beedle, 2002) Les principes et les pratiques pour développer avec agilité Bienvenue aux changements des besoins, même si ils arrivent tard dans le processus du développement, Le processus agile soutient le développement durable, Des livraisons fréquentes du travail, Une attention continuelle à l'excellence technique. Le développement est itératif, progressive, et entraîné par les commentaires des utilisateurs, La livraison d un système parfait est moins important que de livrer un système qui répond aux besoins d affaires actuels; Client / fonctionnalité centrée sur des cycles itératifs, Développement et inspection régulière pour s assurer que le système est à jour. L équipe détermine les caractéristiques de chaque sprint à partir d'un carnet de «backlog» de produits en évolution, La création est un incrément de logiciels potentiellement livrable au cours de chaque sprint. Les principes et les pratiques d autonomie, de diversité et de flexibilité. Les meilleures architectures, exigences et conceptions émergent de l'auto-organisation des équipes, La construction des projets autour d'individus motivés, leur donner l'environnement et le soutien dont ils ont besoin, et leur faire confiance pour faire le travail, L équipe réfléchit sur la façon de devenir plus efficace et adapte son comportement, Les gens d'affaire et les développeurs doivent travailler ensemble tous les jours. L équipe doit maintenir la flexibilité et être ouverte aux changements. Les équipes doivent avoir les habilitées à prendre des décisions du projet sans attendre l'approbation de niveau supérieur, Interactions continues et collaboration entre toutes les parties prenantes du projet. Les équipes petites, dynamiques et autonomes sont efficaces, Multiples esprits inter-fonctionnels sont toujours appliqués à chaque décision de conception. Les équipes déterminent le nombre des caractéristiques dans le backlog de produit pour lesquelles ils veulent s'engager durant le prochain sprint, les équipes auto-organisationnelles et inter-fonctionnelles traversent les différentes phases / sprints. 16

26 Les approches agiles XP (Beck et Andres, 2005) Les principes et les pratiques pour développer avec agilité La plus haute priorité est de continuellement satisfaire les changements des besoins des clients, Consultation rapide des utilisateurs et de leurs commentaires. Les principes et les pratiques d autonomie, de diversité et de flexibilité. Aligner l autorité et le contrôle de l équipe avec les responsabilités pour faire avancer les choses, La programmation en binôme: deux développeurs se complètent au niveau des compétences et du travail Modèle de Lee et Xia (2010) Lee et Xia (2010) sont les premiers auteurs qui ont conceptualisé l agilité en deux dimensions : l ampleur de la réponse de l équipe (response extensiveness) et l efficacité de la réponse de l équipe (response efficiency). Ils se sont intéressés à la question de comment ces deux dimensions d agilité sont reliées. Ils ont également identifié les caractéristiques de l équipe en tant qu antécédents de ces dimensions en essayant de répondre à la question : comment l autonomie et la diversité de l équipe influencent-t-elles l agilité du développement logiciel? Finalement, ils ont examiné les impacts des dimensions de l agilité sur la performance en développement en termes d échéancier, de budget et de fonctionnalité. Figure 2 : Le modèle de recherche de Lee et Xia (2010) 17

27 Les principaux construits du modèle de recherche de Lee et Xia (2010) sont les dimensions de l agilité : l ampleur de la réponse de l équipe (response extensiveness) et l efficacité de la réponse de l équipe (response efficiency). Lee et Xia (2010) ont utilisé une approche intégrée qui inclut deux méthodes d analyses quantitative et qualitative des données, composées de cinq phases: (1) des entretiens préliminaires sur le terrain, (2) une collecte des données par enquête, (3) la validation des mesures, (4) tests d'hypothèses, et (5) des études de cas. Les données quantitatives ont été recueillies et analysées au cours des phases 2, 3 et 4, alors que les données qualitatives ont été recueillies et analysées au cours des phases 1 et 5. En fait, les chercheurs ont adopté cette méthode intégrée pour éviter les limites de chaque approche en utilisant à la fois l objectivité des statistiques et une meilleure compréhension du contexte. En ce qui concerne les outils de mesure, Lee et Xia (2010) ont développé une nouvelle mesure pour les deux dimensions d'agilité étant donné qu il n existait aucune mesure dans la littérature. Toutefois, pour l autonomie et la diversité de l équipe, ils ont utilisé des éléments adaptés de la littérature. La performance du développement logiciel a été mesurée par les trois critères traditionnelles : système livré à temps, dans le budget et avec les fonctionnalités requises. L étude de Lee et Xia (2010) a permis de valider la majorité de leurs hypothèses: L'autonomie de l'équipe a un effet négatif ( , p <.01) sur l ampleur de la réponse et un effet positif (0,247, p <.01) sur l'efficacité de la réponse, appuyant H1b et H2. La diversité de l'équipe a un effet positif (0,261, p <.01) sur l ampleur de la réponse, appuyant H3. Cependant, la diversité des équipes ne montre pas un effet significatif sur l'efficacité des interventions, par conséquent l hypothèse H4 n est pas supportée. L ampleur de la réponse a un effet négatif ( , p <.01) sur l'efficacité de la réponse, supportant H5. L ampleur de la réponse a un effet positif (0,396, p <.01) sur la fonctionnalité du logiciel, appuyant H6c. L ampleur de la réponse n'a aucun effet significatif sur l'achèvement à temps ou dans le budget, ce qui montre que les hypothèses H6a ou H6b ne sont pas appuyées. 18

28 L'efficacité de la réponse démontre des effets positifs sur l'achèvement dans les délais (0,362, p <.01), l'achèvement dans le budget (0,325, p <.01), et la fonctionnalité du logiciel (0,298, p <.01), alors les trois hypothèses H7a, H7B et H7C sont supportées. Les résultats de Lee et Xia (2010) sont résumés dans la Figure 3. Figure 3 : Les résultats de Lee et Xia (2010) Lee et Xia (2010) ont examiné les effets de l'ampleur de la réponse et l'efficacité de la réponse sur la performance globale de développement de logiciels en combinant les trois mesures du rendement. Ils ont constaté que l ampleur de la réponse et l'efficacité de la réponse avaient des effets positifs sur la performance globale de développement. Les résultats qualitatifs des études de cas sont venus confirmer les résultats quantitatifs et les expliquer. Par exemple, selon les cas étudiés, la diversité ralentit la réponse de l'équipe en raison des conflits et des communications coûteuses, ce qui peut expliquer le résultat obtenu pour l hypothèse 4. Les approches Agiles recommandent l auto-organisation et l autonomie des équipes avec des membres inter-fonctionnelles et diverses. Cependant, aucune justification théorique ou empirique n a été fournie à l'appui de ce principe. Lee et Xia (2010) fournissent de l évidence empirique que l'autonomie et la diversité des équipes sont des variables importantes que les organisations peuvent contrôler afin d ajuster leur agilité de développement de logiciels. Plus important encore, l'autonomie et la diversité des équipes n augmentent pas universellement l'agilité dans le développement de logiciels. Les résultats suggèrent que l augmentation de 19

29 l'autonomie sans augmenter la diversité peut entraîner une diminution de l ampleur de la réponse, et que seule l'autonomie augmente l efficacité de la réponse et non la diversité. Les résultats suggèrent qu'une équipe de développement logiciel a besoin de gérer son autonomie et sa diversité en se basant sur la dimension d'agilité que l'équipe doit aborder. L équipe doit être au courant d'un effet négatif potentiel de l auto-organisation sur leur capacité de répondre à un large éventail de changements. Ces résultats suggèrent que l autonomie des équipes peut limiter leurs réponses aux changements des besoins afin de répondre aux objectifs du projet tels que le temps et le coût. Cependant, les recherches ne devraient pas écarter complètement la possibilité que l'autonomie puisse en fait augmenter l ampleur de la réponse puisque les équipes autonomes, en théorie, sont libres de choisir leurs actions dans les deux sens. Les recherches futures devraient étudier plus cette relation. En outre, les résultats suggèrent deux effets opposés de la diversité des équipes sur l'efficacité de la réponse. Bien que la diversité puisse entraîner des conflits et de la communication coûteuse, elle peut accélérer le processus de réponse de l équipe, grâce à l'expertise et les compétences disponibles. Ces résultats expliquent en partie l'effet non significatif de la diversité sur l'efficacité de la réponse puisque ses effets positifs et négatifs peuvent être annulés Modèle de recherche Le modèle de recherche de cette présente étude se basera principalement sur le modèle de Lee et Xia (2010) qui a déjà étudié l influence des caractéristiques soit l autonomie et la diversité de l équipe sur les deux dimensions des approches agiles : l ampleur de la réponse de l équipe (response extensiveness) et l efficacité de la réponse de l équipe (response efficiency) Justificatif de l ajout de la flexibilité Dans l objectif d apporter une amélioration au modèle de Lee et Xia (2010), la caractéristique de la flexibilité de l équipe sera ajoutée au modèle. En fait, selon la revue de littérature effectuée, plusieurs auteurs mentionnent la pertinence de l effet de la flexibilité sur le rendement de l équipe de projet dans le contexte des approches agiles (voir Tableau 6), cependant il n y a pas d étude ayant considéré clairement la flexibilité comme une caractéristique antécédente potentielle de l équipe de projet TI. 20

30 En effet, comme Lee et Xia (2005) notent dans un autre article, la flexibilité représente La capacité de l'équipe à répondre de façon efficace et efficiente aux changements d'activité et de la technologie. Ceci est relié aux dimensions des approches agiles qui seront étudiées dans ce travail de recherche (ampleur et efficacité) Modèle de recherche proposé Dans ce contexte, le modèle de recherche proposé dans ce mémoire est comme suit : Figure 4 : Le modèle de recherche du mémoire Le modèle se compose de huit hypothèses. Bien que HA1, HA2, HA3 et HA4 aient déjà été validées par Lee et Xia (2010), elles seront testées afin de revérifier leurs résultats. L autonomie de l équipe influence l ampleur de la réponse de l équipe aux changements demandés par le client. En fait, l'autonomie facilite la créativité dans la résolution des problèmes et améliore l'apprentissage en équipe dans des environnements incertains (Imai et al., 1985). Dans le but d être agile et adaptable, une équipe doit également être disposée et apte à prendre des risques, et d'expérimenter par itérations essai-erreur (Lee et Xia, 2010). Par conséquent, une équipe autonome a plus de chance d expérimenter librement et chercher des solutions sur une large étendue de changements des besoins des utilisateurs, d où l hypothèse HA1a. 21

31 Hypothèse HA1a: L autonomie de l équipe du projet a une influence positive sur l ampleur de la réponse de l équipe aux changements des requis des utilisateurs. Toutefois, l autonomie risque aussi d influencer négativement l ampleur de la réponse de l équipe (Lee et Xia 2010). Si une équipe a un niveau élevé d'autonomie, elle a plus de latitude de refuser les demandes de changement des utilisateurs, afin d'atteindre les objectifs de temps et de coût. Par conséquent, l'équipe peut être plus sélective dans ses réponses aux changements des besoins. En revanche, si une équipe a peu d'autonomie, il peut finir par recevoir l'ordre de répondre à chaque demande de changement. Dans leurs entretiens préliminaires sur le terrain, Lee et Xia (2010) ont constaté que les équipes très autonomes étaient souvent sélectives dans le traitement des demandes de changement. Donc, Hypothèse HA1b: L autonomie de l équipe du projet a une influence négative sur l ampleur de la réponse de l équipe aux changements des requis des utilisateurs. D un autre côté, une équipe autonome peut détecter et répondre efficacement aux changements de besoins à travers des interactions directes et étroites avec les utilisateurs, sans attendre l'approbation du gestionnaire. Ainsi, une plus grande autonomie permet à l'équipe de réduire les délais, les coûts et les ressources nécessaires aux exigences de changement et d'apporter les changements nécessaires au système. D où l hypothèse HA2. Hypothèse HA2 : L autonomie de l équipe du projet a une influence positive sur l efficacité de la réponse de l équipe aux changements des requis des utilisateurs En ce qui concerne la réponse aux changements des exigences, elle est essentiellement un processus de résolution de problèmes parce qu un changement reflète un besoin d affaire complexe ou un problème technique. Pour être agile, une équipe de logiciel devrait être capable de développer des solutions efficaces aux différents problèmes complexes. En effet, une équipe avec des membres ayant des compétences diverses et des perspectives d'apprentissage et d'innovation variées, génère davantage de solutions alternatives à des problèmes complexes (Campion et al., 1993; Watson et al., 1993.). L'accès à de vastes réseaux externes et à des communautés peut faciliter l'acquisition et le développement de nouvelles connaissances et compétences qui sont nécessaires pour répondre aux changements des exigences. Divers profils 22

32 fonctionnels aident l'équipe de logiciels à comprendre le contexte des différents changements des besoins (Lee et Xia, 2010). Par conséquent, une équipe diversifiée est plus capable de traiter une large étendue de changements des exigences: Hypothèse HA3 : La diversité de l équipe du projet a une influence positive sur l ampleur de la réponse de l équipe aux changements des requis des utilisateurs La diversité des équipes peut influencer négativement l'efficacité de la réponse de l équipe. La théorie de l'identité sociale et la théorie de l auto-catégorisation (Turner et al., 1987) suggèrent qu en raison de la catégorisation intergroupe et des identités différentes parmi les membres de l équipe, la diversité diminue la cohésion d'équipe et l'intégration (Webber et Donahue, 2001), ce qui peut causer des échecs de communication (Miller et al., 1998), et augmenter les conflits (Pelled et al., 1999). En conséquence, une équipe diversifiée est susceptible d investir plus de temps, de coût et des efforts dans la communication et la coordination des tâches afin de prendre de bonnes décisions et de comprendre les demandes de modification, de développer des stratégies d'intervention, et de mettre en œuvre des réponses appropriées. Hypothèse HA4 : La diversité de l équipe du projet a une influence négative sur l efficacité de la réponse de l équipe aux changements des requis des utilisateurs Une équipe de développement logiciel flexible à la capacité d improviser pour résoudre les problèmes en temps réel (Harris et al., 2009). De plus ces même auteurs précisent que pour agir en improvisation, les développeurs doivent se coordonner les uns avec les autres, respecter les règles du développement (par exemple des directives, la conception et la programmation, des garanties de sécurité et d'assurance), et de produire un résultat cohérent. Si l équipe est flexible et elle a la capacité d improviser, elle pourra répondre aux changements des requis du client plus facilement et trouver des solutions aux problèmes. De plus, De Leeuw et Volberda (1996) suggèrent qu à un niveau intuitif la flexibilité signifie la mobilité, la souplesse ou la rapidité. Volberda (1996) décrit la rapidité comme une des mesures de la flexibilité avec laquelle les organisations peuvent mettre en œuvre des procédures pour répondre aux changements. Par conséquent, plus l équipe sera flexible, plus elle pourra répondre rapidement aux changements et par la suite couvrir un grand nombre de ces derniers. 23

33 Hypothèse HA5 : La flexibilité de l équipe du projet a une influence positive sur l ampleur de la réponse de l équipe aux changements des requis des utilisateurs. Finalement, Lee et Xia (2005) avaient défini la flexibilité de l équipe comme étant la capacité à répondre aux changements de façon efficace et efficiente. De ce fait, plus l équipe est flexible, plus elle pourra s adapter aux nouveaux requis demandés par le client et plus sa réponse sera efficace. En effet, la flexibilité pourra permettre à l équipe de répondre rapidement aux changements ce qui pourra aider à respecter l échéancier du projet. Avison et al. (1995) proposent la flexibilité comme mesure de l amélioration de la qualité des ressources internes. Pour cela Golden et Powell (2000) ont confirmé que la capacité de réagir de manière efficace est considérée comme un élément clé de la flexibilité. Hypothèse HA6 : La flexibilité de l équipe du projet a une influence positive sur l efficacité de la réponse de l équipe aux changements des requis des utilisateurs Tableau 8 : Métrique de la flexibilité (Golden et Powell, 2000) (traduction libre) Référence Anderson (1993) Flexibilité S adapter aux changements avec une dégradation minimale de la performance Bolwijn et Kumpe (1990) Das et Elango (1995) Eppink (1987) Habileté à changer rapidement Habile et rapide, opportun et approprié Capacité de répondre Evans (1991) Augmenter la vitesse de manœuvre Lucas et Olson (1994) Répondre rapidement Monteiro et Macdonald (1996) Upton (1994) Habileté à répondre aux changements Mobilité Upton (1995) Habileté à changer rapidement 24

34 En ce qui concerne les caractéristiques de l équipe considérées, il existe également une interrelation entre elles et il serait pertinent de la valider. Pour ce faire, deux hypothèses d équipes (HE1 et HE2) ont été ajoutées au modèle de recherche. En fait, une équipe autonome a le privilège d avoir une liberté de réagir, de faire des choix et des modifications sans toujours être obligée d attendre l approbation de son supérieur ce qui va lui permettre une facilité et une rapidité à changer ses tâches, rôles ou structure pour répondre aux besoins du client. Dans ce contexte, Langfred (2007) note qu un des avantages de l autogestion de l équipe est sa grande flexibilité dans l adaptation de sa structure à une variété de tâches, situations et conditions. De plus, Molleman (2009) ajoute que dans le cas d une faible autonomie, l utilisation de la flexibilité est susceptible d être contrôlée ce qui va à l encontre du principe de la «flexibilité». Ainsi, HE1 met en valeur la relation entre l autonomie et la flexibilité de l équipe : Hypothèse HE1 : L autonomie de l équipe du projet a une influence positive sur la flexibilité de l équipe. La diversité de l équipe permet d avoir une complémentarité entre ses membres grâce à leurs variétés d expérience, de formation et d expertise. En effet, Keadall (2006) note que les équipes qui peuvent s adapter aux changements sont composées d'individus ayant des niveaux élevés de compétences, d expertise, d'orientation équipe, ouverture à l'expérience et les capacités cognitives. De plus, il indique que cette diversité encourage l ouverture d esprit qui augmente le degré d adaptabilité de l équipe aux changements. Pour cette raison, l hypothèse HE2 supporte le fait que la diversité de l équipe va promouvoir la flexibilité de celle-ci : Hypothèse HE2 : La diversité de l équipe du projet a une influence positive sur la flexibilité de l équipe. 25

35 Chapitre 3 : Méthodologie de recherche Dans la partie méthodologie de recherche, plusieurs points seront abordés. En premier lieu une brève discussion sur le choix de la méthode de recherche adoptée sera présentée. Ensuite, les étapes de la démarche seront détaillées en élaborant un instrument de mesure et en spécifiant les étapes qui seront suivies jusqu à l obtention des résultats. Finalement, l échantillon visé de cette étude sera identifié Justification de la démarche L objectif de cette étude de recherche est de déterminer les caractéristiques d une équipe de projet TI qui permettent d avoir un niveau d agilité élevé. Le cadre théorique développé dans le Chapitre 2 a permis d élaborer des hypothèses qu il sera intéressant de valider à l aide d une enquête par questionnaire. Étant donné que l étude s intéresse à évaluer l agilité de l équipe à intégrer les changements demandés par le client, il ne sera pas possible de cibler des projets à leur début, et donc viser des projets qui sont achevés ou très avancés pour assurer que l équipe a déjà fait face à des changements dans les requis de la part du client. Pour cette raison, une étude transversale réalisée sur des projets achevés serait appropriée afin de tester les hypothèses de notre modèle de recherche. Une enquête par questionnaire permettrait de valider si l autonomie, la diversité et la flexibilité des équipes ont influencé leur agilité. En fait, ce choix méthodologique est basé sur le type de modèle de recherche de cette étude. Il s agit d un modèle de variance, les variables indépendantes desquelles sont les caractéristiques de l équipe et les variables dépendantes sont les deux dimensions de l agilité qui reflètent le comportement de l équipe: l ampleur (Extensiveness of team response) et l'efficacité (Efficiency of team response) de sa réponse. De plus, il est à noter qu une approche par étude de cas a été éliminée puisque selon Yin (2008), il faut choisir l étude de cas lorsque le chercheur considère important de couvrir des conditions contextuelles qui peuvent être très pertinentes au phénomène. Dans le cadre de ce travail, il s agit d analyser l impact des facteurs spécifiques, ce qui rend les éléments contextuels d un projet moins pertinents. De plus, cette étude n est pas de type exploratoire. 26

36 3.2. Les mesures des construits Lee et Xia (2010) ont développé des nouvelles mesures pour les deux dimensions d agilité (efficacité et ampleur de la réponse) étant donné qu il n existait pas de mesure pour ces deux construits. Tel qu ont fait Lee et Xia (2010), l ampleur de la réponse de l équipe sera mesurée par le pourcentage des changements des requis que l équipe a intégrés dans le scope du système, les données d'entrée, les données de sortie, les règles d affaires/ processus, structure des données, et les interfaces utilisateurs (Figure 5 & Questionnaire en Annexe A). En ce qui concerne l'efficacité de la réponse de l équipe (Efficiency of team response), elle sera considérée supérieure quand une équipe a besoin de moins d'effort additionnel que ce qui est prévu en termes de temps, coût et ressources (humaines et matériels) pour intégrer un changement d exigences et vice versa (Figure 5 & Questionnaire en Annexe A). L'autonomie de l équipe de projet sera mesurée par quatre éléments qui ont été adaptés de la littérature antérieure (Breaugh, 1985; Janz et al., 1997; Zmud, 1982). Ces éléments représentent le degré auquel l'équipe du projet a la discrétion, la liberté et l'indépendance dans la prise de décisions liées au projet, tel que le choix des outils / technologies, de fixer les objectifs, gérer les changements de besoins des utilisateurs, et l'affectation de personnel à l'équipe (Figure 5 & Questionnaire en Annexe A). La diversité de l équipe de projet sera mesurée par quatre éléments adaptés de la littérature antérieure (Campion et al., 1993). Ces éléments de mesure représentent la diversité et l'hétérogénéité dans les domaines d'expertise des membres de l'équipe, compétences, expériences de travail antérieures, et aux profils fonctionnels. Plusieurs chercheurs utilisent le résultat de la flexibilité, comme l efficacité et la réponse (responsiveness) (Lee et Xia, 2005) pour la mesurer. Toutefois, il serait important de considérer les antécédents de la flexibilité pour la mesurer. En se basant sur les définitions établies dans la revue de littérature auparavant ainsi que les métriques élaborées dans la littérature (Golden et Powell, 2000) nous mesurerons la flexibilité par quatre éléments qui représentent la capacité et l habilité des membres de l équipe du projet à changer de structure, de rôle, de tâches ainsi que leur ouverture d esprit pour répondre aux changements des requis demandés par le client. En se basant sur les mesures établies pour chaque construit, un instrument de mesure a été élaboré pour faciliter au répondant l évaluation de chaque construit, et ce, en donnant un score 27

37 à chaque valeur de mesure (de 0 à 10). Ainsi le répondant devra évaluer chaque mesure en donnant un score selon ce qu il a vécu dans son projet. Liberté de choix Les caractéristiques de l équipe Les dimensions de l agilité Lee & Xia (2010) Contrôle sur leurs tâches Autonomie dans la manière de traiter le chgt Autonomie de l équipe Scope du projet Liberté dans l assignation du personnel Ampleur de la réponse (response extensiveness ) % accompli du changement Données Input du système Différentes expertises Données Output du système Compétences complémentaires Variété d expériences Variété des formations Diversité de l équipe Efficacité de la réponse (response efficiency) Effort additionnel pour le changement Règles d affaires/ Processus Données de la structure Changement de la structure Interface utilisateur Changement des rôles Changement des tâches Ouverture d esprit Flexibilité de l équipe Légende de l instrument de mesure Mesure Construit Figure 5: Le modèle de recherche et ses mesures 3.3. Design de l étude Le design de recherche consiste en un plan d action qui permet d aller d un point initial qui correspond aux questions de recherche de départ auxquelles le chercheur veut répondre, à un point final qui correspond aux conclusions et réponses à ces questions (Yin, 2008). Sans un design défini, il est difficile de comprendre la démarche de recherche et de reproduire ses résultats. En plus, le fait de démontrer les étapes suivies s avère essentiel afin d établir de la rigueur et de l objectivité dans la démarche du chercheur (Holliday, 2002). La Figure 2 illustre les étapes de la méthodologie adoptée. L approche s inspire à la fois de Yin (2008) et de Larsson 28

38 (1993), et elle se divise en trois grandes phases: (1) la définition et conception du modèle, (2) la collecte et analyse des données (3) l analyse globale et conclusion sur les leçons apprises. Définition et conception du modèle Collecte et analyse Analyse et conclusion Développer un modèle de recherche Développer un questionaire Diffusion du questionnaire Collecte des données Analyse de la fiabilité et de la validité des donnès Analyse des donnès Cloture Figure 6 : Méthodologie de recherche La méthodologie de recherche élaborée se compose de plusieurs étapes : 1. Développer un modèle de recherche À la base du modèle de recherche se pose trois questions: 1) la définition de la question de recherche, 2) la spécification des fondements théoriques et 3) la définition des unités de mesure pour l analyse. Ces étapes sont déjà couvertes dans les chapitres précédents. 2. Développer un questionnaire En se basant sur les différentes mesures identifiées auparavant, un questionnaire sera élaboré pour permettre aux répondants d évaluer chaque item afin de mesurer les variables indépendantes et dépendantes du modèle de recherche. Il est à noter que le questionnaire inclura aussi des données démographiques pour connaître le profil des répondants. 3. Diffusion du questionnaire L objectif de cette phase est d obtenir un échantillon de projets développés en approche agile, d où l intérêt de viser un grand nombre de répondants. Pour cette raison, il serait pertinent de diffuser le questionnaire à grande échelle au sein d une organisation, et pour ce faire nous avons ciblé l institut PMI (Project Management Institute) de Montréal. 29

39 4. Collecte des donnés Pendant la diffusion du questionnaire, il serait important de faire un suivi pour expliquer aux répondants la pertinence de l étude et son apport à la recherche ainsi qu à la pratique afin d augmenter le taux de réponse. Après la réception des questionnaires remplis, il faut saisir toutes les données et les nettoyer pour garder seulement celles pertinentes à l étude. 5. Analyse de la fiabilité et de la validité des donnés Après la préparation des donnés, nous ferons des tests statistiques afin de vérifier la fiabilité ainsi que la validité des donnés. Pour cette raison, une analyse factorielle sera réalisée afin de vérifier la validité convergente des mesures ainsi qu une matrice de corrélation des construits. La mesure de l alpha de Cronbach sera utilisée pour vérifier la fiabilité des mesures. 6. Analyse des données Après que la validité des mesures ainsi que leur fiabilité seront examinées, nous testerons les hypothèses du modèle de recherche. À cette fin, l approche régression sera utilisée. 7. Clôture À la fin de cette étude, nous porterons attention aux leçons apprises ainsi qu aux contributions potentielles en recherche et à la pratique Méthode de collecte de données Selon Kumar (2005), la collecte de données peut se faire de différentes façons. Il est possible d utiliser des sources secondaires comme des documents ou les sources primaires comme les observations, les entrevues et les questionnaires. Cependant, dans notre étude il n est pas possible d utiliser les sources secondaires. Par conséquent, les sources primaires représentent une source d information plus riche. La source la plus riche est probablement l observation du déroulement du projet. En effet, cette méthode permettrait d identifier le niveau d agilité et les caractéristiques de l équipe. Cependant, les contraintes temporelles de ce travail ne permettent pas d étudier des projets sur 30

40 une longue période du temps. L entrevue est un moyen de collecte de données intéressant puisqu elle permet de connaître beaucoup de détails sur la réalisation des projets en approches agiles. Toutefois, ce n est pas possible dans le cas de cette étude puisqu il s agit d un modèle de recherche des facteurs et non pas un modèle de processus. Ainsi, dans ce mémoire la collecte de données se fera par le biais des questionnaires. Yin (2008) propose de multiplier les sources d évidence afin de consolider la recherche. En effet, il propose de se baser sur plusieurs éléments comme sources d information : La documentation; Les archives; Les entrevues; L observation directe; L observation des participants; Les artéfacts physiques; De ce fait, il est pertinent de noter qu il y aura également la possibilité d avoir recours à d autres méthodes de collecte de données telle que l observation et la consultation de la documentation dans la mesure du possible Échantillon La population visée est celle des gestionnaires de projets informatiques qui ont utilisé une méthodologie agile pour mener à terme leurs projets. Il serait important d obtenir des cas représentant divers profils de développement de logiciels en termes de types de développement du système, les secteurs de l'industrie et la taille du projet Pré-test du questionnaire Avant la distribution du questionnaire pour la collecte des données qui feront l objet d une analyse, le questionnaire a fait l objet d un pré-test par huit gestionnaires de projet qui ont déjà livré des projets en utilisant une approche agile. Le but de ce pré-test était de réduire l ambigüité potentielle des questions. Ces participants à la révision ont été trouvés dans le cercle de contact de mon milieu de travail. Cette approche a permis d assurer que le questionnaire accomplisse les objectifs de recherche, de la bonne compréhension des 31

41 questions, d éliminer toute source d ambigüité pour le répondant et de faciliter la réponse au questionnaire afin de maximiser le nombre de répondants. Commentaires recueillis Les principaux commentaires du pré-test se sont situés au niveau de la terminologie de certains termes et construits qui n ont pas toujours été interprétés de la même façon. Tout d abord au début du questionnaire ce n était pas clair pour les participants qu il fallait choisir «un projet en particulier» pour répondre aux questions. Pour cela, il a été précisé dans le questionnaire de choisir un projet spécifique et voici le correctif apporté «Pour répondre à ce questionnaire, veuillez choisir un projet en particulier dans lequel la méthode agile a été utilisée». En ce qui concerne le concept d ampleur (Extensiveness), il a soulevé beaucoup de questionnement de la part des participants. D après ces derniers, la signification de l «ampleur» tel que présenté dans la question n était pas facilement compréhensible et n était pas claire. Ainsi, les participants ont fait des suggestions qui ont conduit à la modification de la question à deux reprises avec une validation de la part des participants au pré-test. La question initialement posée était : «Concernant l ampleur (extensiveness) de la réponse de l équipe: pour chacune des catégories suivantes, quel est le degré d acceptation et d incorporation des nouveaux requis au projet effectivement réalisé». Suite aux remarques recueillies, la formulation révisée était : «Pour chacune des catégories suivantes, quel est le degré d acceptation et d incorporation des nouveaux requis au projet effectivement réalisé.» La question concernant «la structure de l équipe» n était également pas claire, les participants n ayant pas compris de quelle structure il s agissait (la structure du projet ou de l organisation). Pour cela, elle a été modifiée comme suit : «Quel est le degré auquel les membres de l équipe pouvaient changer la structure de l organisation de l équipe suite à une demande de changement par le client?» pour amener plus de précisions à la notion de la structure. Pour les remarques plus génériques, deux participants ont signalé que la formulation de la question : «À quel point est-ce que?» était lourde. Donc, «est-ce» a été supprimé pour garder uniquement «à quel point». 32

42 Chapitre 4 : Analyse 4.1. Taux de réponse La collecte des données s est effectuée sur une période de 4 mois à partir du mois d août jusqu au mois de novembre 2013 auprès des membres du comité Agile du Québec (environs 1700 membres) qui ont été approchés par courriel à travers un responsable au sein du comité Il y a eu plusieurs accès au questionnaire.. Au début de l envoi du questionnaire, il y a eu 20 réponses et il a fallu envoyer un rappel avec les objectifs de l étude pour inciter les membres du comité Agile du Québec à participer à l étude. Après ce rappel, il a été possible d atteindre 31 réponses. Ce chapitre présente les résultats de l étude ainsi que leur analyse. En premier lieu, un profil des répondants sera réalisé. Ensuite, le profil des projets choisis ainsi que les résultats descriptifs des réponses à tous les éléments du questionnaire (tel que la moyenne, l écart type) seront présentés et commentés. Finalement, une série d analyse sera réalisée : factorielle, de fiabilité, de corrélation et de régression afin de juger des validités convergente et discriminante des différentes mesures ainsi que des hypothèses de recherche Profil des répondants Au début du questionnaire, une question a permis d identifier le rôle du répondant dans le projet et 57% de ceux-ci étaient chef d équipe. Tableau 9-Chef d'équipe projet Vs. Membre d équipe Réponse Nombre % Chef d équipe 18 57% Membre d équipe 13 43% Total % 33

43 La dernière section du questionnaire a permis la collecte de données démographiques sur les répondants. Comme ces questions n étaient pas obligatoires, certains répondants n ont pas répondu à ces questions. Le pourcentage des réponses varie selon la question. Malgré cela, il était possible de faire plusieurs constats tels que la majorité des répondants étaient masculins (86%) et se situaient dans la tranche d âge de 30 ans et plus (58%). Tableau 10-Distribution du sexe des participants Thème Type Nombre % Sexe Femme 5 14% Homme 24 86% Total % De plus, une large majorité de répondants possède un niveau élevé d éducation dont (90%) ayant un diplôme universitaire de premier cycle et 55% ayant une maîtrise. Tableau 11-L'éducation des participants Thème Type Nombre % L'éducation des participants 90% Diplôme universitaire de troisième cycle (doctorat) Diplôme universitaire de deuxième cycle (maîtrise) Diplôme d études supérieures Diplôme universitaire de premier cycle (baccalauréat) Diplôme d école secondaire Diplôme d école élémentaire 0 0% 17 55% 6 19% 5 16% 3 10% 0 0% Total % Ces données indiquent que les répondants sont assez hétérogènes en termes d âge, mais qu ils sont plutôt homogènes du point de vue de leur sexe et leur niveau d éducation. 34

44 4.3. Profil des projets Pour répondre au questionnaire, chaque répondant devait choisir un projet en particulier qu il a réalisé en utilisant une approche agile. Pour cela, les répondants ont choisi des projets TI touchants des systèmes de différents secteurs. Les proportions les plus importantes étaient celles du secteur économique bancaire (23%) et manufacturier (20%). Cinq répondants ont indiqué «Autres» dont 4 du secteur des médias et 1 en comptabilité. Tableau 12-Secteur économique du système Thème : Secteur économique du système Nombre % Agriculture / Énergie 0 0% Secteur bancaire 7 23% Éducation 0 0% Secteur juridique / Assurance 3 10% Secteur militaire 0 0% Secteur manufacturier 6 20% Transport / Santé 3 10% Gouvernement 0 0% Secteur financier 5 17% Distribution (gros et détail) 1 3% Autres 5 17% Total % Le domaine d application du système dominant était marketing et ventes (19%) suivis par finance (17%) et autres domaines (TI, divertissement, approvisionnement, information, BI Master Data Management et divers). Il est intéressant de noter que le total des réponses dépasse 31 (soit le nombre de répondants) car certains projets étaient classés dans plus d un domaine. 35

45 Tableau 13-Domaine d'application du système Thème : Domaine d'application du système Nombre % Administration / humaines 3 8% Comptabilité 2 6% Finance 6 17% Ressources 2 6% Marketing / Ventes 7 19% Planification 5 14% Fabrication 4 11% Recherche et Développement 1 3% Autres 6 17% Total % Les aspects de gestion des projets : Les répondants ont indiqué qu ils étaient essentiellement satisfaits des différents aspects du projet (voir la Table 14). L aspect ayant le plus grand nombre dans la catégorie des insatisfaisants était «La façon dont le projet a été géré» avec 7 insatisfaisants comparativement à 24 satisfaisants. Tableau 14-Les aspects des projets Thème : Les aspects des projets Insatisfaisant Neutre Satisfaisant Total Le processus de développement du système La composition de l équipe de projet Les employés du service TI qui ont travaillé au sein du projet Les autres intervenants qui ont travaillé au sein du projet Le fonctionnement de l équipe du projet La façon dont le projet a été gérée Le système qui a été développé Les coûts des projets : La majorité des projets choisis par les répondants ont été complétés avec des budgets au-dessus des budgets estimés au début du projet (55%).Toutefois, il y a eu une portion non négligeable (19%) qui a été complétée selon le budget prévu. Il y a eu également des projets qui ont été complétés au-dessous du budget (13%). 36

46 Tableau 15-Coûts estimés, le projet complété Thème : Coûts estimés, le Nombre % projet complété Très au-dessous du budget 1 3% Au-dessous du budget 4 13% Selon le budget 6 19% Au-dessus du budget 17 55% Très au-dessus du budget 3 10% Total % L échéancier des projets : la majorité des projets choisis par les répondants se situent dans la catégorie «tél que prévu» (32%) et «plus tard que prévu» (48%). Tableau 16 - L'échéancier, le projet complété Thème : L'échéancier, le Nombre % projet complété Beaucoup plus tôt que 0 0% prévu Plus tôt que prévu 3 10% Tel que prévu 10 32% Plus tard que prévu 15 48% Beaucoup plus tard que 3 10% prévu Total % L envergure des projets. La proportion la plus élevée des projets choisis est celle des projets livrés avec une envergure «plus grande que prévue» (42%) suivi par les projets livrés avec une envergure «telle que prévue» (35%). 37

47 Tableau 17 - L'envergure du projet complété Thème : L'envergure, le projet Nombre % complété Beaucoup plus petite que prévu 0 0% Plus petite que prévu 6 19% Telle que prévu 11 35% Plus grande que prévu 13 42% Beaucoup plus grande que 1 3% prévu Total % Il est important de signaler que les trois paramètres de projet mentionnés ci-dessous, soient l échéancier, le budget et l envergure sont inter-reliés. Pour cela, une grande proportion des projets livrés au-dessus du budget ont également été livrés plus tard que prévu et avec une envergure plus grande que prévue, ce qui concorde avec la littérature sur la gestion des projets. Le succès des projets. Les projets choisis par les répondants ont été majoritairement réussis (58%). Cependant, il y a eu également des projets classés dans la catégorie «a quelque peu échoué» (6%). Figure 7 - Paramètres de gestion des projets 38

48 Tableau 18-Le succès des projets Thème : Le succès des Nombre % projets A échoué 0 0% A quelque peu échoué 2 6% N a ni échoué, ni réussi 1 3% A quelque peu réussi 10 32% A réussi 18 58% Total % En conclusion, en se basant sur les différents aspects (profil des répondants et des projets sélectionnés) présentés ci-dessus, il est possible de conclure que l échantillon des projets obtenus est pertinent puisqu il représente une hétérogénéité pour l intérêt de l étude. L approche agile : Étant donné qu il existe différentes méthodes agile, une question demandait aux répondants de préciser le type d approche qu ils ont appliquée dans les projets choisis pour répondre au questionnaire de l étude. L approche la plus dominante était celle du Scrum (84%). Tableau 19-Approche agile adoptée Thème : Approche agile Nombre % adoptée Scrum 26 84% XP (Extreme 1 3% Programming) DSDM (Dynamic 0 0% System Development Method) Autres (Itératif) 4 13% Total % Le changement en cours de projet : La force des approches agiles est dans les changements des requis en plein réalisation du projet. Pour cela, il y a eu une question pour déterminer un ordre de grandeur des changements demandés dans les projets choisis par les répondants. La majorité des projets ont eu des demandes de changements supérieurs à la moyenne (43%) (La moyenne représente 5 changements sur une échelle de 10). En fait, ce nombre de changements élevé est très pertinent pour l étude. 39

49 Tableau 20-Demandes de changement en cours de réalisation La taille de l équipe de projet : la taille de l équipe est un facteur important dans la gestion des projets. Il est à noter que notre échantillon comportait des projets de taille différente avec une dominance pour les projets impliquant de petites équipes (45%). Thème : Demandes de Nombre % changement en cours de réalisation Inférieur à la moyenne 8 27% Moyenne 9 30% Supérieur à la moyenne 13 43% Total % Tableau 21-La taille de l'équipe projet Thème : La taille de Nombre % l'équipe projet Grande (plus de % personnes) Moyenne (Entre 10 et % personnes) Petite (10 personnes ou 14 45% moins) Total % 4.4. Résultats descriptifs L analyse des données a été effectuée avec les logiciels SPSS et Excel. Les données ont été directement transférées à partir de l outil gérant le questionnaire web (Qualtrics) vers SPSS et Excel. Deux catégories de variables peuvent être distinguées: les caractéristiques de l équipe et les dimensions d agilité. Le tableau 22 présente les statistiques descriptives des items des caractéristiques de l équipe. Les répondants se sont évalués sur une échelle de 0 (aucun) à 10 (beaucoup) concernant le choix des membres de l équipe vis-à-vis des différents construits. Il est à constater que la majorité des items ont des réponses qui dépassent la moyenne du spectre de réponses soit 5/10 étant donné que les moyennes des variables de l autonomie, diversité et flexibilité sont respectivement 7.14, 7.74 et

50 Tableau 22 - Statistiques descriptives des construits indépendants Variable N Moyenne Écart Type Somme Min. Max. Autonomie aut aut aut aut Diversité div div div div Flexibilité flex felx flex flex En ce qui concerne les valeurs minimales, il est important de noter qu à part les valeurs des flex1 et flex2 pour lesquels les répondants ont estimé un niveau très faible dans le cadre de leurs projets (réponse 0), pour tous les autres, les répondants semblaient avoir un niveau assez élevé concernant leurs perceptions des variables liées surtout à l autonomie et la diversité. Pour les valeurs maximales, à part la variable flex1, il y a eu des répondants qui ont estimé qu il y avait un niveau très élevé (réponse 10) concernant les différentes variables liées à l autonomie, diversité et flexibilité. Finalement, pour l écart type, il est important de noter que les écarts types sont à l entour de «2». Il semble également que le construit Diversité est celui ayant les plus petits écarts type. Cependant, les écarts types des construits de l Autonomie et de la Flexibilité sont plus élevés ce qui indique une plus grande disparité dans les réponses. Le Tableau 23 présente les statistiques descriptives des items des dimensions de l agilité soit les deux dimensions «Ampleur» (Effectiveness) et «Efficacité» qui ont été évaluées sur une échelle de 0% à 100%. On peut constater que la majorité des items ont des réponses qui dépassent la moyenne du 41

51 spectre de réponses soit 50% étant donné que les moyennes des variables «Ampleur» (Extensiveness) et «Efficacité» sont respectivement de 7.48 et Tableau 23-Statistiques descriptives des construits dépendants Variable N Moyenne Écart Type Somme Min. Max. Ampleur (Extensiveness) ext_sc ext_di ext_do ext_rg ext_ds ext_iu Efficacité eff_sc eff_di eff_do eff_rg eff_ds eff_iu En ce qui concerne les valeurs minimales, à part la variable Ext_iu (interface utilisateur) pour toutes les autres variables les répondants ont estimé qu il y avait de l effort supplémentaire requis relié aux dimensions de l agilité évaluées. Pour les valeurs maximales, à part les variables liées aux données entrantes et sortantes, les répondants ont estimé qu il y avait «beaucoup d effort supplémentaire (100%)» requis pour gérer les changements liés aux différentes dimensions de l agilité. Finalement, pour l écart type, il est important de noter que les écarts types sont assez élevés ce qui indique que les réponses sont assez disparates Analyse de fiabilité L analyse de fiabilité examine le comportement des items à l intérieur d une mesure. Une mesure fiable est une mesure répétable, c est-à-dire les items évoluent de façon constante au sein du construit et 42

52 d un répondant à l autre. Pour cette validation, la mesure de l alpha de Cronbach sera utilisée. Elle peut varier de 0.0 à 1.0. Plus l alpha de Cronbach est proche de 1.0 meilleur est la fiabilité du construit. Les résultats de l alpha de Cronbach (Tableau 24) indiquent que la fiabilité des mesures est excellente dans le cas des trois premiers construits «Ampleur» (Extensiveness), «Efficacité» et «Autonomie» puisque l alpha de Cronbach est supérieur à 0.8. Par contre la fiabilité des mesures des construits «Diversité» et «Flexibilité» est moyenne puisque l alpha de Cronbach est inférieur à 0,7 mais l écart n est pas grand. Tableau 24 - Résultats Alpha de Cronbach Construits Variables Alpha de Cronbach Ampleur ext_sc, ext_di, ext_do, ext_rg, 0.92 ext_ds, ext_iu Efficacité eff _sc, eff _di, eff _do, eff_rg, 0.93 eff _ds, eff _iu Autonomie Aut1, Aut2, Aut3, Aut Diversité Div1, Div2, Div3, Div Flexibilité Flex1, Flex 2, Flex 3, Flex Corrélations Dans le but de vérifier le lien entre les différents construits du modèle, une matrice de corrélation a d abord été calculée. Pour faire l analyse des corrélations, chaque construit est représenté par un score qui est calculé par la moyenne des items de chaque construit. Il est acceptable d utiliser les scores de chaque construit puisque les résultats de l analyse factorielle ont conclu à une convergence des items de chaque construit et les valeurs du Alpha de Cronbach ont démontré la fiabilité des mesures. Le score de chaque construit a été calculé tel qu indiqué dans le Tableau 25, et par la suite la matrice de corrélations Pearson (r) a été calculé. 43

53 Tableau 25 - Les scores des construits Construits Ampleur Efficacité Autonomie Diversité Variables Moyenne (ext_sc, ext_di, ext_do, ext_rg, ext_ds, ext_iu) Moyenne (eff _sc, eff _di, eff _do, eff_rg, eff _ds, eff _iu) Moyenne (Aut1, Aut2, Aut3, Aut4) Moyenne (Div1, Div2, Div3, Div4) Flexibilité Moyenne (Flex1, Flex 2, Flex 3, Flex 4) Tableau 26- Corrélation des construits Ampleur Ampleur Efficacité Autonomie Diversité Flexibilité Efficacité 0.40* Autonomie 0.45* 0.59** Diversité 0.59** 0.49** 0.51** Flexibilité 0.64** 0.51** 0.46** 0.47** * p<0.05, ** p<0.01 Il est intéressant de noter que toutes les corrélations entre les construits du modèle de recherche sont significatives. La matrice de corrélation entre tous les items est présentée dans l Annexe B Analyse de régression Finalement, ayant examiné la validité, la convergence et la fiabilité des mesures du modèle nous testerons maintenant les hypothèses de recherche. À cette fin, des analyses de régressions linéaires ont été effectuées entre les construits (nous utiliserons les scores de chaque construit tels qu ils ont été définis lors de l analyse de corrélation). En fait, une régression linéaire permet d étudier le lien entre une variable dépendante et une ou plusieurs variables indépendantes. Pour cela, il y aura plusieurs régressions réalisées afin de tester les différentes hypothèses du modèle de recherche. Dans le but 44

54 d interpréter chaque régression linéaire, une attention particulière sera apportée au R2 ajusté ainsi qu au degré de signification statistique nommé p pour «P-value». Le R2 ajusté est pertinent pour l analyse des hypothèses de la recherche dans le cadre de ce travail. En effet, les répondants ne représentent pas toute la population des gestionnaires de projets qui ont utilisé une approche agile mais plutôt un petit échantillon. Plus la valeur du R2 ajusté s approche de 1, plus le lien associatif entre les variables concernées par la régression est fort. Le degré de signification statistique nommé p pour «P-value» indique la probabilité que le hasard puisse être à l origine des résultats obtenus. Le «P-value» doit être inférieur à 0.05 pour qu une relation soit jugée significative. Trois analyses de régression multiples ont été réalisées : Tableau 27 - Régression multiple Régression multiple Variable dépendante Variables indépendantes Analyse de régression multiple n 1 Ampleur Autonomie, Diversité, Flexibilité Analyse de régression multiple n 2 Efficacité Autonomie, Diversité, Flexibilité Analyse de régression multiple n 3 Flexibilité Autonomie, Diversité Analyse de régression n 1 (Ampleur = Autonomie, Diversité, Flexibilité) Cette première analyse de régression vise à tester les hypothèses suivantes : Hypothèse HA1a & Ha1b: L autonomie de l équipe du projet a une influence positive ou négative sur l ampleur de la réponse de l équipe aux changements des requis des utilisateurs. Hypothèse HA3 : La diversité de l équipe du projet a une influence positive sur l ampleur de la réponse de l équipe aux changements des requis des utilisateurs. Hypothèse HA5 : La flexibilité de l équipe du projet a une influence positive sur l ampleur de la réponse de l équipe aux changements des requis des utilisateurs. Les résultats de la régression : 45

55 Tableau 28 - Résultats de la régression: Ampleur = Autonomie, Diversité, Flexibilité Hypothèses Lien Beta standardisé HA 1a & b Autonomie Ampleur 0.08 (0.662) HA 3 Diversité Ampleur 0.59 * (0.043) HA 5 Flexibilité Ampleur 0.64 ** (0.009) Résultat Pas supportée Supportée Supportée R 2 = 52% R 2 (ajusté) = 47% Significativité (0.000) N =31; Les valeurs t sont en parenthèse. *p < 0.05 **p < 0.01 Les résultats indiquent que 47% de la variance dans «Ampleur» est expliquée par les trois caractéristiques : autonomie, diversité et flexibilité. En plus, la valeur de «p-value» est très inférieure de 0.05 ce qui démontre une relation très significative entre les trois caractéristiques de l équipe et l ampleur de la réponse. De plus, étant donnée que les hypothèses HA3 (Beta = 0.59, p<0.05) et HA5 (Beta = 0.64, p<0.01) sont supportées indiquent que la diversité et la flexibilité ont une influences significative sur l ampleur. Analyse de régression n 2 (Efficacité = Autonomie, Diversité, Flexibilité) Cette deuxième analyse de régression vise à tester les hypothèses suivantes : Hypothèse HA2 : L autonomie de l équipe du projet a une influence positive sur l efficacité de la réponse de l équipe aux changements des requis des utilisateurs. Hypothèse HA4 : La diversité de l équipe du projet a une influence négative sur l efficacité de la réponse de l équipe aux changements des requis des utilisateurs. Hypothèse HA6 : La flexibilité de l équipe du projet a une influence positive sur l efficacité de la réponse de l équipe aux changements des requis des utilisateurs Les résultats de la régression : 46

56 Tableau 29 - Résultats de la régression: Efficacité = Autonomie, Diversité, Flexibilité Hypothèses Lien Beta standardisé HA 2 Autonomie Efficacité 0.471** (0.033) HA 4 Diversité Efficacité (0.328) HA 6 Flexibilité Efficacité 0.37 (0.162) Résultat Supportée Pas supportée Pas supportée R 2 = 44% R 2 (ajusté) = 38% Significativité (0.001) N =31; Les valeurs t sont en parenthèse. *p < 0.05 **p < 0.01 Les résultats indiquent que 38% de la variance dans l «Efficacité» est expliquée par les trois caractéristiques : autonomie, diversité et flexibilité. En plus, la valeur de «p-value» est très inférieure de 0.05 ce qui démontre une relation significative entre les trois caractéristiques de l équipe et l efficacité de la réponse. De plus, l hypothèse HA2 (Beta = 0.59, p<0.01) est supportée ce qui indique que l autonomie a une influence significative sur l efficacité. Analyse de régression n 3 (Flexibilité = Autonomie, Diversité) Cette troisième analyse de régression vise à tester les hypothèses suivantes : Hypothèse HE1 : L autonomie de l équipe du projet a une influence positive sur la flexibilité de l équipe. Hypothèse HE2 : La diversité de l équipe du projet a une influence positive sur la flexibilité de l équipe. Les résultats de la régression : Tableau 30 - Résultats de la régression: Flexibilité = Autonomie, Diversité Hypothèses Lien Beta standardisé HE 1 Autonomie Flexibilité (0.117) HE 2 Diversité Flexibilité (0.100) Résultat Pas supportée Pas supportée R 2 = 29% R 2 (ajusté) = 24% Significativité (0.009) N =31; Les valeurs t sont en parenthèse. *p < 0.05 **p <

57 Les résultats indiquent que 24% de la variance dans la «Flexibilité» est expliquée par les deux caractéristiques : autonomie, diversité. En plus, la valeur de «p-value» est très inférieure de 0.05 ce qui indique une relation significative entre les deux caractéristiques (autonomie et diversité) et la flexibilité des membres de l équipe. Figure 8: Les résultats des trois régressions 48

58 Chapitre 5 : Discussion et Conclusion La dernière partie de ce travail de recherche consiste en une discussion des résultats obtenus selon les objectifs et la méthodologie de cette étude. Elle comprendra une vision critique des résultats par rapport aux difficultés qui ont été rencontrées ce qui permettra de présenter certaines limites de l étude. Finalement, des pistes de recherches futures, les contributions théoriques et pratiques de ce travail seront exposées Discussion des résultats Le principal objectif de ce travail de recherche était de déterminer l influence de trois caractéristiques de l équipe sur les dimensions de l agilité, d où la question de recherche suivante : L autonomie, la diversité et la flexibilité influencent-t-elles l agilité dans les projets TI? En effet, ce mémoire a mis l emphase sur les caractéristiques de l équipe du projet qui peuvent influencer l agilité. Pour ce faire, trois caractéristiques ont été sélectionnées : l autonomie, la diversité et la flexibilité. Dans le but de vérifier leur influence sur l agilité, deux dimensions de celle-ci ont été prises en considération : l efficacité et l ampleur de la réponse de l équipe. Pour ce faire, le modèle de recherche s est basé principalement sur le modèle de Lee et Xia (2010) qui a étudié l influence de l autonomie et la diversité de l équipe sur les deux dimensions des approches agiles, soit l ampleur (response extensiveness) et l efficacité (response efficiency) de la réponse de l équipe. Dans l objectif d apporter une amélioration au modèle de Lee et Xia (2010), nous avons ajouté la flexibilité de l équipe à leur modèle. En fait, notre revue de littérature a identifié plusieurs chercheurs ayant noté l importance de la flexibilité dans le contexte des approches agiles. Cependant, aucune étude empirique n a encore considéré la flexibilité comme une caractéristique antécédente potentielle de l équipe de projet TI. Dans le but de vérifier les hypothèses du modèle de recherche une validation a été effectué à l aide d une enquête par questionnaire auprès des gestionnaires de projets ayant complété des projets TI avec une approche agile. La collecte des données s est effectuée auprès des membres du comité agile du Québec. Par la suite, les données recueillies ont été analysées avec l outil SPSS par le biais d analyses descriptives, de fiabilité, de corrélation et finalement de régression afin de tester la validité, la fiabilité des mesures et les hypothèses de recherche. 49

59 Le sommaire comparatif des résultats obtenus dans cette étude et celle de Lee et Xia (2010) est présenté dans le Tableau 31. Tableau 31- Sommaire comparatif des résultats Les hypothèses Résultats Lee et Xia (2010) Résultats de ce travail de recherche Constats HA1a et HA1b La relation entre l autonomie et l ampleur de la réponse au changement (Response Extensiveness) ** Résultat non significatif HA2 La relation entre l autonomie et l efficacité de la réponse au changement (Response Efficiency) HA3 La relation entre la diversité et l ampleur de la réponse au changement (Response Extensiveness) 0.247** 0.472* 0.261** 0.590* HA4 La relation entre la diversité et l efficacité de la réponse au changement (Response Efficiency) Le résultat obtenu dans cette étude est en accord avec celui obtenu par Lee et Xia (2010). Le résultat obtenu dans cette étude est en accord avec celui obtenu par Lee et Xia (2010). Résultat non significatif HA5 La relation entre la flexibilité et l ampleur de la réponse au changement (Response Extensiveness) ** Ajout au modèle & Résultat significatif HA6 La relation entre la flexibilité et l efficacité de la réponse au changement (Response Efficiency) Résultat non significatif HE1 La relation entre l autonomie et la flexibilité Résultat non significatif HE2 La relation entre la diversité et la flexibilité Résultat non significatif * p < 0.05, ** p<0.01 Les résultats indiquent que les hypothèses HA2 et HA3 ont été appuyées et concordent avec l étude de Lee et Xia (2010) avec un «beta» un peu plus élevée (p<0.05). De plus HA5 qui constitue quant à elle un ajout au modèle a aussi été supportée (p <0.01) et démontre que la flexibilité avait un effet positif sur la réponse de l équipe aux demandes de changement. Cependant, certains résultats n étaient pas 50

60 significatifs (HA1a et HA1b, HA4, HA6 HE1 et HE2) ce qui pourrait s expliquer entre autre à cause de la taille réduite de l échantillon. L effet de l autonomie En ce qui concerne l influence de l autonomie sur l ampleur de la réponse de l équipe aux changements des requis des utilisateurs, le modèle de recherche de cette étude a deux hypothèses (HA1a et HA1b) possibles pour l influence de l autonomie : un effet positif et un effet négatif comme il a été considéré dans l étude de Lee et Xia (2010). Cependant, aucun effet ni positif ni négatif n était significatif, nous ne pourrons pas ainsi tirer de conclusion au sujet des hypothèses HA1 et HA1b. Pour la deuxième hypothèse (HA2), l autonomie de l équipe du projet a une influence positive sur l efficacité de la réponse de l équipe aux changements des requis demandés par les utilisateurs. Notre étude a observé un effet positif qui concorde avec celui de Lee et Xia (2010). En effet, une équipe autonome peut détecter et répondre efficacement aux changements de besoins à travers des interactions directes et étroites avec les utilisateurs, sans attendre l'approbation du gestionnaire. Ainsi, une plus grande autonomie permet à l'équipe de développement logiciel de réduire les délais, les coûts et les ressources nécessaires aux exigences de changement et d'apporter les changements nécessaires au système. L effet de la diversité Pour la caractéristique de la diversité de l équipe du projet, l hypothèse (HA3) était que la diversité aurait une influence positive sur l ampleur de la réponse de l équipe aux changements des requis qui seraient demandés par les utilisateurs. Le résultat obtenu est en concordance avec celui de Lee et Xia (2010). Pour être agile, une équipe de logiciel devrait être capable de développer des solutions efficaces aux différents problèmes complexes. En effet, une équipe avec des membres ayant des compétences diverses et des perspectives d'apprentissage et d'innovation variées est en mesure de générer plus de solutions alternatives à des problèmes complexes (Campion et al., 1993; Watson et al., 1993.) Divers profils fonctionnels aident l'équipe de logiciels à comprendre le contexte des différents changements des besoins (Lee et Xia, 2010). Par conséquent, une équipe diversifiée est plus capable de traiter une large étendue de changements des exigences. Ceci indique aussi que les membres des équipes des projets qui ont fait l objet de collecte de données de ce mémoire avaient des profils diversifiés. 51

61 Les résultats obtenus concernant l hypothèse de la diversité (effet positif sur l ampleur de la réponse) permettent ainsi de déduire que les membres des équipes des projets qui ont fait l objet de collecte de données dans ce travail avaient des profils diversifiés qui leur a permis d être complémentaires pour trouver des solutions aux problèmes complexes et traiter un grand nombre de changements. Selon l hypothèse HA4, la diversité de l équipe du projet devrait avoir une influence négative sur l efficacité de la réponse de l équipe aux changements des requis des utilisateurs. Cependant, l hypothèse HA4 n a pas été appuyée puisque le résultat observé n était pas significatif. Toutefois, la diversité diminue la cohésion d'équipe et l'intégration (Webber et Donahue, 2001), ce qui peut causer des échecs de communication (Miller et al., 1998), et augmenter les conflits (Pelled et al., 1999). En conséquence, une équipe diversifiée est susceptible de consommer plus de coûts et des efforts dans la communication et la coordination des tâches afin de prendre de bonnes décisions et de comprendre les demandes de modification, de développer des stratégies d'intervention, et de mettre en œuvre des réponses appropriées. Toutefois, cette explication théorique n a pas pu être validée en pratique, puisque dans les deux études (ce travail de recherche et celui de Lee et Xia (2010)) la diversité a eu un effet positif sur l efficacité de la réponse. Ce résultat permet de constater que malgré que les équipes étudiées fussent diversifiées, il est possible que leur collaboration et leur communication fussent efficaces. L effet de la flexibilité Il est important de noter que la caractéristique de la flexibilité est un ajout au modèle de recherche de l étude de Lee et Xia (2010). Les résultats obtenus indiquent une influence positive de la flexibilité de l équipe du projet sur l ampleur de la réponse de l équipe aux changements des requis des utilisateurs, ce qui confirme l hypothèse HA5. Si l équipe est flexible et elle a la capacité d improviser, elle pourra répondre aux changements des requis du client plus facilement et trouver des solutions aux problèmes. De plus, De Leeuw et Volberda (1996) suggèrent qu à un niveau intuitif la flexibilité signifie la mobilité, la souplesse ou la rapidité. Par conséquent, plus l équipe sera flexible, plus elle pourra répondre rapidement aux changements et couvrir un grand nombre de ces derniers. Par contre, l hypothèse HA6 qui stipule que la flexibilité de l équipe du projet a une influence positive sur l efficacité de la réponse de l équipe aux changements des requis des utilisateurs n a pu être confirmée puisque le résultat n était pas significatif. 52

62 Les effets des trois caractéristiques d équipe Dans cette section, il serait pertinent d examiner l effet des trois caractéristiques de l équipe (autonomie, diversité et flexibilité) sur les deux dimensions de l agilité. En ce qui concerne les résultats du pourcentage de la variance expliquée (R 2 ) par les caractéristiques de l équipe sur les dimensions de l agilité, ils sont résumés dans le Tableau 32. Tableau 32 - L influence des caractéristiques de l'équipe sur les dimensions de l'agilité Les dimensions d agilité (variables dépendantes) Ampleur Efficacité Résultats de Lee et Xia Résultats de ce travail de (2010) R 2 recherche R 2 14% (de combien l autonomie et la diversité expliquent l ampleur de la réponse) 26% (de combien l autonomie et la diversité expliquent l efficacité de la réponse) 47% (de combien l autonomie, la diversité et la flexibilité expliquent l ampleur de la réponse) 38% (de combien l autonomie, la diversité et la flexibilité expliquent l efficacité de la réponse) Constats Le résultat obtenu dans cette étude est plus élevé que celui de Lee et Xia (2010). Le résultat obtenu dans cette étude est plus élevé que celui de Lee et Xia (2010). Ainsi, l influence conjointe des trois caractéristiques sur l ampleur de la réponse de l équipe, le résultat obtenu dans ce travail de recherche (47%) est supérieur à celui obtenu dans l étude de Lee et Xia (2010) (14%). Ce résultat est explicable avec l ajout d une nouvelle caractéristique de l équipe au modèle qui est la flexibilité. Ce résultat permet de constater que la flexibilité a une influence additionnelle sur l ampleur de la réponse d une équipe qui travaille en mode agile. Quant au résultat de l influence conjointe des trois caractéristiques sur l efficacité de la réponse de l équipe, il est aussi supérieur (38%) par rapport au résultat de l étude de Lee et Xia (2010) (26%). Ce résultat indique que l ajout de la caractéristique flexibilité au modèle est pertinent puisque la valeur de l influence a augmenté. Ces deux résultats permettent de conclure que la flexibilité est une caractéristique d équipe pertinente à prendre en considération dans le contexte de projet agile. 53

63 L effet sur la flexibilité Par contre, le résultat de l influence des deux caractéristiques combinées (autonomie et diversité) sur la flexibilité est significatif et le pourcentage de la variance expliquée (R 2 ) est de 24% de la variance de la flexibilité. Ce résultat permet d observer qu il y a une relation entre ces caractéristiques. En fait, ce résultat montre un lien entre les caractéristiques de l équipe flexibilité et autonomie, diversité, qu il faut analyser en profondeur pour clarifier le type de la relation Limites de l étude Il faut noter qu il y a des différences entre la présente étude et celle de Lee et Xia (2010) au niveau de la taille d échantillon, ainsi que le milieu de collecte des données (la culture). Tableau 33- Les éléments de différence entre les études Les éléments de différences Étude Lee et Xia (2010) Étude de ce travail de recherche Importance de l élément de différence La taille de l échantillon Élevé Secteur du projet (le Finance/Assurance et Secteur bancaire et Faible plus dominant) manufacture manufacture Culture USA Canada Qc Moyen Il est à noter qu une des limites majeures de la présente étude est la taille de l échantillon. En effet, avoir seulement 31 répondants (N=31) n a pas permis de tester la validité des mesures au travers de l analyse factorielle pour vérifier la convergence des différents items de chaque construit du modèle de recherche. En plus, le nombre limité a aussi limité les analyses à une série de régressions (au lieu des méthodes plus sophistiquées comme l analyse par équations structurelles). De plus, la petite taille de notre échantillon limite aussi la possibilité de généraliser nos résultats. Les deux dimensions d agilité (Ampleur et Efficacité) n étaient pas claires pour les gestionnaires des projets qui ont répondu aux questionnaires. Certes, grâce à l étape pré-test il a été possible de voir que les gestionnaires des projets n étaient pas à l aise avec l interprétation de ces deux concepts, et en conséquence nous avons simplifié les questions afin de faciliter la compréhension, mais il est difficile de connaître le niveau de compréhension des répondants par rapport à ces deux concepts. Ceci aurait pu influencer également les réponses obtenues lors de la collecte des données. 54

64 D un autre cote, lors des analyses, il a été constaté qu il y avait des fortes corrélations entre les variables du modèle de recherche, surtout entre les caractéristiques de l équipe (autonomie, diversité et flexibilité). Ces inter-corrélations élevées risquent d avoir influencé les résultats obtenus Contributions théoriques et pratiques Contribution théorique : Cette étude se base principalement sur le modèle de recherche de Lee et Xia (2010). Cependant, l ajout d une nouvelle variable (flexibilité) à leur modèle de recherche représente une contribution. De plus les résultats obtenus viennent confirmer ceux obtenus par Lee et Xia (2010) ainsi que d ajouter l impact potentiel la nouvelle variable (flexibilité). Contribution pratiques : les approches agiles sont utilisées de plus en plus dans la gestion des projets informatiques. Ce travail de recherche propose des caractéristiques comme la flexibilité et l autonomie qu il serait utile de chercher dans le profil des personnes qui constitueront une équipe projet et en même temps viser des profils complémentaires entres les membres de l équipe pour assurer une plus grande diversité. Par conséquent, ce travail pourrait aider les gestionnaires des projets à faire des meilleurs choix des membres de l équipe qui travailleront en approche agile pour assurer une couverture plus adéquate au niveau de la flexibilité, l autonomie et la diversité Piste de recherches futures Ce travail représente seulement le début d une réflexion concernant la relation entre la flexibilité et l agilité ainsi que les autres caractéristiques de l équipe. Dans un but d obtenir des résultats qui peuvent être généralisés, il est possible de revalider le modèle en élargissant la collecte des données à un grand nombre de participants afin d obtenir un plus grand échantillon qui permettra des analyses statistiques plus approfondies. Il sera également intéressant d une part, d approfondir l étude de l influence de la flexibilité sur les dimensions d agilité, et ce, en essayant de considérer d autres construits que ceux utilisés dans cette présente étude étant donné la nouveauté de cette caractéristique. D autre part, à cause de la colinéarité entre les caractéristiques (autonomie, flexibilité et diversité) de l équipe, il serait pertinent d étudier la flexibilité en l isolant dans un modèle de recherche à part. 55

65 5.5. Conclusion Dans un contexte d affaires changeant et incertain, les approches de gestion de projet agiles constituent une méthodologie appropriée pour gérer les projets TI. Ainsi, notre recherche a essayé d amener des éléments pour aider les gestionnaires de projet de choisir les profils adéquats des membres de l équipe projet qui travailleront en approche agile. La méthodologie adoptée pour réaliser ce travail était basée sur une collecte de données par le biais des questionnaires ce qui a permis de tester les hypothèses du modèle de recherche. Les résultats obtenus indiquaient l influence des caractéristiques de l équipe (autonomie, diversité et flexibilité) sur les dimensions de l agilité (l ampleur et l efficacité de la réponse de l équipe aux changements) ainsi les caractéristiques (autonomie, diversité) sur la flexibilité. Cependant, les résultats statistiques ne permettaient pas de généraliser cette relation. Ainsi, les résultats ainsi obtenus pourraient s avérer utiles pour guider les gestionnaires dans leurs choix des membres de l équipe, mais également ils pourront représenter de nouvelles pistes de recherche future qu il faut approfondir concernant la relation entre les caractéristiques de l équipe et l agilité et principalement «la flexibilité». 56

66 Annexe A: Questionnaire de collecte des données 57

67 L impact des caractéristiques de l équipe sur l agilité des équipes de développement de systèmes TI. Ce questionnaire porte sur le projet en technologie de l information que vous avez réalisé en méthodologie agile Si vous avez géré un projet de développement ou d implantation d un système en méthodologie agile, nous vous prions de répondre aux questions qui figurent dans ce questionnaire. Nous vous remercions de votre précieuse collaboration. Si vous désirez des informations supplémentaires, veuillez contacter Henri Barki Professeur agrégé, Technologie de l information École des Hautes Études Commerciales 5255, avenue Decelle, Montréal, Québec H3T 1V6 (514) Wafaa Toumi Étudiante en maîtrise des sciences de gestion en TI École des Hautes Études Commerciales Wafaa.toumi@hec.ca (514)

68 Instructions 1. Veuillez répondre à chacune des questions suivantes en vous basant sur vos impressions personnelles et en choisissant la réponse qui reflète le mieux votre opinion. 2. Dans ce questionnaire : Le terme «système» fait référence au système d information identifié sur la couverture du questionnaire. Le terme «projet» fait référence à l ensemble du processus du développement du système en question, y compris l initiation du projet, son développement, son implantation ainsi que sa gestion. Le terme «utilisateur» désigne l ensemble des individus qui utilisent le système ou utiliseront le système à l avenir, le client. Le terme «équipe de développement» désigne l ensemble des individus qui ont travaillé au sein du projet. 3. Vous trouverez que certaines questions traitent de sujet délicat. L objectif de cette recherche est de mieux comprendre ces sujets et de fournir des recommandations qui s avéraient utiles aux projets futurs. 4. Pour assurer l entière confidentialité de vos réponses, les chercheurs seront les seuls à voir vos réponses. De plus, le questionnaire sera anonyme. Il n y a aucun moyen identificateur qui permettrait d identifier le répondant. 5. Notre recherche n a pas comme but de faire l analyse ou la description d organisations ou d individus spécifiques. Tous les résultats et les analyses renverront à des tendances générales et aux moyennes ressortant de notre échantillon. 6. Nous vous sommes très reconnaissants de votre précieuse collaboration. 59

69 Questions générales sur le projet Pour répondre à ce questionnaire, veuillez choisir un projet en particulier dans lequel la méthode agile a été utilisée. Étiez-vous un des membres de l équipe de projet? Oui Non Étiez-vous le chef de l équipe de projet? Oui Non Veuillez encercler le chiffre qui correspond le mieux à votre niveau de satisfaction concernant les aspects suivants : Insatisfaisant Le processus de développement du système La composition de l équipe de projet Les employés du service TI qui ont travaillé au sein du projet Les autres intervenants qui ont travaillé au sein du projet Le fonctionnement de l équipe du projet La façon dont le projet a été gérée Le système qui a été développé Neutre Satisfaisant Veuillez cocher la case qui correspond le mieux à ce qui s est passé durant le projet Par rapport aux coûts estimés, le projet a été complété : Très au-dessous du budget Au-dessous du budget Selon le budget Au-dessus du budget Très au-dessus du budget Par rapport à l échéancier, le projet a été complété : Beaucoup plus tôt que prévu Plus tôt que prévu Tel que prévu 60

70 Plus tard que prévu Beaucoup plus tard que prévu Par rapport aux spécifications, l envergure du projet complété a été : Beaucoup plus petite que prévu Plus petite que prévu Telle que prévu Plus large que prévu Beaucoup plus large que prévu En général, considérez-vous que le projet : A échoué A quelque peu échoué N a ni échoué, ni réussi A quelque peu réussi A réussi 61

71 Questions à propos du processus de développement Veuillez cocher la case qui correspond le mieux à votre approche adopté pour le développement et la gestion du projet : Scrum XP (Extreme Programming) DSDM (Dynamic System Development Method) Autres (veuillez préciser) : Veuillez encercler le chiffre qui correspond le mieux à vos opinions concernant comment s est produit le projet Ne sais À quel point est-ce que Les utilisateurs ont demandé des changements en cours pas de réalisation du projet? Pas du tout Beaucoup Pour chacune des catégories suivantes, quel est le degré d acceptation et d incorporation des nouveaux requis au projet effectivement réalisés. Ne sais pas N/A Le scope du projet : 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Les données d entrée (Input) 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Les données de sortie (Output) 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Les règles d affaires/processus 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Les données de la structure 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% L interface utilisateur 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 62

72 Pour chacune des catégories suivantes, quel est l effort additionnel (comparativement a l'effort prévu) requis par l équipe pour effectuer les changements demandés par le client : (L effort inclus le temps, cout, personnel et ressources.) Le scope du projet : 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Les données d entrée (Input) 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Les données de sortie (Output) 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Les règles d affaires/processus 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Les données de la structure 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% L interface utilisateur 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 63

73 Questions à propos de l équipe du projet Veuillez cocher la case qui correspond le mieux à ce qui s est passé durant le projet Quelle était la taille de l équipe du projet? Grande (plus de 20 personnes) Moyenne (20>nombre> 10) Petite (10 personnes ou moins) Veuillez encercler le chiffre qui correspond le mieux à vos opinions concernant comment s est produit le projet À quel point les membres de l équipe avaient la liberté de choisir les procédures et les méthodes à utiliser dans la réalisation des tâches du projet? Pas du tout Beaucoup Ne sais pas À quel point les membres de l équipe pouvaient contrôler sur leurs tâches planifiées du projet? Pas du tout Beaucoup À quel point les membres de l équipe avaient de l autonomie dans la manière de traiter le changement demandé par le client? Pas du tout Beaucoup À quel point les membres de l équipe avaient la liberté de choix dans l allocation des tâches du projet? Pas du tout Beaucoup À quel point les membres de l équipe avaient différentes expertises (par exemple : langage de programmation, matériels, changements organisationnel, analyse,etc.)? Pas du tout Beaucoup 64

74 À quel point les membres de l équipe avaient des compétences complémentaires entre eux? Pas du tout Beaucoup À quel point les membres de l équipe avaient une variété d expériences (par exemple : différents types de projets, type de client, secteur économique, etc.)? Pas du tout Beaucoup À quel point l ensemble de l équipe possédait une variété de formations? Pas du tout Beaucoup Quel est le degré auquel les membres de l équipe pouvaient changer la structure de l organisation de l équipe suite à une demande de changement par le client? Pas du tout Beaucoup Quel est le degré auquel les membres de l équipe pouvaient changer leurs rôles suite à une demande de changement par le client? Pas du tout Beaucoup Quel est le degré auquel les membres de l équipe pouvaient changer leurs tâches planifiées suite à une demande de changement par le client? Pas du tout Beaucoup Quel était le degré d ouverture d esprit des membres de l équipe vis-à-vis les changements demandé par le client? Pas du tout Beaucoup 65

75 Questions à propos du système et vous-même Veuillez indiquer le secteur économique dans lequel œuvre le système Agriculture Secteur bancaire Éducation Énergie Secteur juridique Secteur militaire Secteur manufacturier Assurance Transport Gouvernement Secteur financier Santé Distribution (gros et détail) Autres (veuillez préciser) : Veuillez indiquer la ou les catégories qui décrivent le mieux le domaine d application du système Administration Comptabilité Finance Ressources humaines Marketing/Ventes Planification Fabrication Recherche et Développement Autres (veuillez préciser) : Votre âge : ans Votre sexe : Homme Femme Veuillez spécifier le plus haut degré d éducation que vous avez obtenu. Diplôme d école élémentaire Diplôme de CEGEP (baccalauréat) Diplôme d études supérieures (maîtrise) Diplôme d école secondaire Diplôme universitaire de premier cycle Diplôme universitaire de deuxième cycle Diplôme universitaire de troisième cycle (doctorat) 66

76 Annexe B: Tableau des corrélations entre tous les items 67

Méthodes Agiles et gestion de projets

Méthodes Agiles et gestion de projets Méthodes Agiles et gestion de projets Eric LELEU Consultant Solutions Collaboratives Contact ericleleu@nordnet.fr Site Personnel http://home.nordnet.fr/~ericleleu Blog http://ericleleu.spaces.live.fr La

Plus en détail

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Conduite de projets SI Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Agilité : de quoi parle-t-on? Agilité de l entreprise Urbanisme Architectures SOA Agilité du SI ERP Plateformes applicatives agiles

Plus en détail

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

Gestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique» Gestion de projet Agile Module 4.2 - «Gérer et organiser un projet informatique» Sommaire Introduction Principes et méthodes Agiles Scrum 2 Introduction Gestion de projet : démarche structurante assurant

Plus en détail

25/12/2012 www.toubkalit.ma

25/12/2012 www.toubkalit.ma 25/12/2012 www.toubkalit.ma 1 Définition Exemple des méthodes agiles Valeurs Principes Le cycle itératif et incrémental (Itération/Sprint) Schéma de travail Méthode Scrum. Méthode XP (Extreme programming).

Plus en détail

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php PLAN Objectif et

Plus en détail

Les méthodes Agiles Introduction. Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008

Les méthodes Agiles Introduction. Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008 Les méthodes Agiles Introduction Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008 Les méthodes Agiles Le contexte Le Manifeste Agile Une tentative de définition

Plus en détail

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

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

Plus en détail

Méthodes de développement

Méthodes de développement 1 / 9 Méthodes de développement Méthodes agiles 1 - Introduction... 2 2 -Le manifeste agile et les méthodes agiles... 2 2.1 Le manifeste agile... 2 2.2 Les méthodes agiles... 3 3 - Caractéristiques communes

Plus en détail

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

Méthodes agiles. www.businessinteractif.com CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS. Jean-Louis Bénard jlb@businessinteractif. Méthodes agiles www.businessinteractif.com Jean-Louis Bénard jlb@businessinteractif.fr CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS 0 20 mai 2002 Sommaire Méthodes agiles : une réponse à un malaise?

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

Avant propos. Parcours de lecture : combien de sprints vous faut il?

Avant propos. Parcours de lecture : combien de sprints vous faut il? Avant propos Depuis plus d une dizaine d années, je conseille des entreprises et je forme des étudiants sur les méthodes itératives et agiles. Depuis cinq ans, cet effort porte presque exclusivement sur

Plus en détail

Les méthodes itératives. Hugues MEUNIER

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

Plus en détail

Modernisation et gestion de portefeuilles d applications bancaires

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

Plus en détail

Guide de Préparation. EXIN Agile Scrum. Foundation

Guide de Préparation. EXIN Agile Scrum. Foundation Guide de Préparation EXIN Agile Scrum Foundation Édition Décembre 2014 Droits d auteur 2014 EXIN Tous droits réservés. Aucune partie de cette publication ne saurait être publiée, reproduite, copiée, entreposée

Plus en détail

La solution IBM Rational pour une ALM Agile

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

Plus en détail

Conditions gagnantes pour démarrer sa transition Agile

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

Plus en détail

Gestion Projet. Cours 3. Le cycle de vie

Gestion Projet. Cours 3. Le cycle de vie Gestion Projet Cours 3 Le cycle de vie Sommaire Généralités 3 Séquentiel 7 Itératif/Incrémental 17 Extreme Programming 22 Que choisir? 29 Etats Transverse 33 Cours 3 2006-2007 2 Généralités Cours 3 2006-2007

Plus en détail

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

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM Méthodes agiles & SCRUM 1/ Pourquoi les méthodes agiles? Définition d une méthode agile. Fondamentaux. Quand les utiliser? 2/ SCRUM En quoi est-ce une méthode agile? Sprints et releases. Le Product Owner.

Plus en détail

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

Soyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique Soyez agile Dans l industrie du logiciel, la gestion de projet est confrontée à de nombreux défis. Le principal est de pouvoir assurer l adéquation d un produit et de ses fonctionnalités avec les besoins

Plus en détail

Les Méthodes Agiles. description et rapport à la Qualité. Benjamin Joguet Rémi Perrot Guillaume Tourgis

Les Méthodes Agiles. description et rapport à la Qualité. Benjamin Joguet Rémi Perrot Guillaume Tourgis Les Méthodes Agiles description et rapport à la Qualité Benjamin Joguet Rémi Perrot Guillaume Tourgis 1 Plan Présentation générale d'agile Qu'est ce qu'une méthode Agile? Le manifeste Les valeurs Les principes

Plus en détail

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

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

Plus en détail

Jean-Pierre Vickoff www.vickoff.com

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

Plus en détail

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

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

Plus en détail

Introduction Les processus traditionnels extreme Programming Conclusion. extreme Programming. vers plus d agilité. F. Miller francois.miller@inpg.

Introduction Les processus traditionnels extreme Programming Conclusion. extreme Programming. vers plus d agilité. F. Miller francois.miller@inpg. vers plus d agilité F. Miller francois.miller@inpg.fr FC INPG Octobre 2008 - version 1.0 Introduction Contexte Le monde bouge économie des moyens (humains, financier,...) ; recherche de plus d efficacité

Plus en détail

Génie logiciel (Un aperçu)

Génie logiciel (Un aperçu) (Un aperçu) (sommerville 2010) Laurent Pérochon INRA URH 63122 St Genès Champanelle Laurent.perochon@clermont.inra.fr Ensemble d activités conduisant à la production d un logiciel Sur un échantillon de

Plus en détail

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

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

Plus en détail

Impartition réussie du soutien d entrepôts de données

Impartition réussie du soutien d entrepôts de données La force de l engagement MD POINT DE VUE Impartition réussie du soutien d entrepôts de données Adopter une approche globale pour la gestion des TI, accroître la valeur commerciale et réduire le coût des

Plus en détail

CHAPITRE 3 : LES METHODES AGILES?

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

Plus en détail

Enquête 2014 de rémunération globale sur les emplois en TIC

Enquête 2014 de rémunération globale sur les emplois en TIC Enquête 2014 de rémunération globale sur les emplois en TIC Enquête 2014 de rémunération globale sur les emplois en TIC Les emplois repères de cette enquête sont disponibles selon les trois blocs suivants

Plus en détail

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

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

Plus en détail

Josée St-Pierre, Ph. D. Directrice Laboratoire de recherche sur la performance des entreprises

Josée St-Pierre, Ph. D. Directrice Laboratoire de recherche sur la performance des entreprises LES PME manufacturières sont-elles prêtes pour l ERP? Éditorial InfoPME est publié par le Laboratoire de recherche sur la performance des entreprises (LaRePE) Institut de recherche sur les PME Université

Plus en détail

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

Architecture pragmatique pour la gestion du cycle de vie des applications (ALM) Architecture pragmatique pour la gestion du cycle de vie des applications (ALM) Concepts Agile appliqués à l architecture et à la conception Jean-Louis Maréchaux jl.marechaux@ca.ibm.com Jean-Louis Maréchaux

Plus en détail

Livre Blanc Oracle Mars 2013. Le guide ultime de la réussite d un Bureau des Projets (PMO) orienté business

Livre Blanc Oracle Mars 2013. Le guide ultime de la réussite d un Bureau des Projets (PMO) orienté business Livre Blanc Oracle Mars 2013 Le guide ultime de la réussite d un Bureau des Projets (PMO) orienté business Introduction 1 Qu est-ce qu un PMO orienté business? 2 Les six facteurs clés de succès de l alignement

Plus en détail

Processus d Informatisation

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

Plus en détail

backlog du produit Product Owner

backlog du produit Product Owner Méthodes agiles : Définition: selon Scott Ambler «Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées

Plus en détail

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

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

Plus en détail

Règles d engagement. Présentation Diapositives Bibliographie Questions Les vertus de la marche

Règles d engagement. Présentation Diapositives Bibliographie Questions Les vertus de la marche Règles d engagement Présentation Diapositives Bibliographie Questions Les vertus de la marche Plan Rappels sur l agilité Scrum : une implantation de l agilité Scrum ou XP? Conclusion Historique sélectif

Plus en détail

Méthodologies SCRUM Présentation et mise en oeuvre

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

Plus en détail

Le management des risques de l entreprise Cadre de Référence. Synthèse

Le management des risques de l entreprise Cadre de Référence. Synthèse Le management des risques de l entreprise Cadre de Référence Synthèse SYNTHESE L incertitude est une donnée intrinsèque à la vie de toute organisation. Aussi l un des principaux défis pour la direction

Plus en détail

ISBN-13 : 978-2-922325-43-0 Dépôt légal : Bibliothèque et Archives nationales du Québec, 2009

ISBN-13 : 978-2-922325-43-0 Dépôt légal : Bibliothèque et Archives nationales du Québec, 2009 REMERCIEMENTS AUX PARTENAIRES Cette étude a été réalisée grâce à la participation financière de la Commission des partenaires du marché du travail et du ministère de l Éducation, du Loisir et du Sport.

Plus en détail

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Classe de terminale de la série Sciences et Technologie du Management et de la Gestion Préambule Présentation Les technologies de l information

Plus en détail

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

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

Plus en détail

Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES

Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES Quelques constats Etude du Standish Group Seul 1/3 des projets informatiques sont qualifiés de succès 50 % sont livrés et opérationnels, mais sont sortis du

Plus en détail

LOG2420 Analyse et conception d interfaces utilisateur

LOG2420 Analyse et conception d interfaces utilisateur LOG2420 Analyse et conception d interfaces utilisateur Processus de développement centré utilisateur 1/36 LOG2420 Analyse et conception d interfaces utilisateur Processus de développement centré utilisateur

Plus en détail

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

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

Plus en détail

Notre programme de formations

Notre programme de formations PROGRAMME DE FORMATION 2013 Notre programme de formations Reconnue comme spécialiste en gestion de projets, SIRIUS Conseils compte une vingtaine de cours spécialisés dans son programme de formation. Soucieux

Plus en détail

WHITE PAPER Une revue de solution par Talend & Infosense

WHITE PAPER Une revue de solution par Talend & Infosense WHITE PAPER Une revue de solution par Talend & Infosense Master Data Management pour les données de référence dans le domaine de la santé Table des matières CAS D ETUDE : COLLABORATION SOCIALE ET ADMINISTRATION

Plus en détail

Scrum/XP adapté au BI/DW

Scrum/XP adapté au BI/DW Scrum/XP adapté au BI/DW Marc-Éric Larocque, PMP, MBA, CBIP, PSM marc-eric.larocque@procimaexperts.com Jean-François Pilon, CBIP jean-francois.pilon@procimaexperts.com PROCIMAEXPERTS.COM Introduction Objectifs

Plus en détail

Agile 360 Product Owner Scrum Master

Agile 360 Product Owner Scrum Master Agile 360 Product Owner Scrum Master Lead Technique Equipe Agile Conception Agile Leadership Agile Software Craftmanship Test Driven Development Catalogue 2013 Liste des formations Formation Agile 360

Plus en détail

Agilitéet qualité logicielle: une mutation enmarche

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

Plus en détail

Flex Multipath Routing

Flex Multipath Routing Flex Multipath Routing Regroupement des liens privés et publics pour les réseaux étendus (WAN) d entreprise Flex Multipath Routing (FMR) Regroupement des liens privés et publics pour les réseaux étendus

Plus en détail

1. Considérations sur le développement rapide d'application et les méthodes agiles

1. Considérations sur le développement rapide d'application et les méthodes agiles Chapitre 1 Introduction 1. Considérations sur le développement rapide d'application et les méthodes agiles 1.1 Rappel Longtemps les méthodes en cascade ou en V ont été opposées aux démarches empiriques

Plus en détail

XP : plus qu'agile. Extreme Programming v2 et Développement Responsable. Thierry Cros

XP : plus qu'agile. Extreme Programming v2 et Développement Responsable. Thierry Cros XP : plus qu'agile Extreme Programming v2 et Développement Responsable Thierry Cros Retrouvez cette présentation sur le site http://thierrycros.net Licence CC-BY-NC-SA XP : plus qu'agile Pourquoi XP Installer

Plus en détail

Programmation Agile Mise en oeuvre via Scrum et l'extreme Programming (XP)

Programmation Agile Mise en oeuvre via Scrum et l'extreme Programming (XP) Programmation Agile Mise en oeuvre via Scrum et l'extreme Programming (XP) B. Mermet 2010 Plan La programmation Agile et L'artisanat du logiciel Mise en œuvre avec Scrum Mise en œuvre avec l'extreme Programming

Plus en détail

Maîtrise d ouvrage agile

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

Plus en détail

LES tests d'acceptation

LES tests d'acceptation dans la série : b.d. agile! Idée et dessins par Anis berejeb : www.berejeb.com LES tests d'acceptation reflexions, experimentations... réussites et échecs... apprentissage et amelioration. à Partager avec

Plus en détail

IFT3913 Qualité du logiciel et métriques. Chapitre 2 Modèles de processus du développement du logiciel. Plan du cours

IFT3913 Qualité du logiciel et métriques. Chapitre 2 Modèles de processus du développement du logiciel. Plan du cours IFT3913 Qualité du logiciel et métriques Chapitre 2 Modèles de processus du développement du logiciel Plan du cours Introduction Modèles de processus du développement du logiciel Qualité du logiciel Théorie

Plus en détail

RECHERCHE EXPLORATOIRE (2) SUR LES CRITÈRES DE SUCCÈS DES PROJETS DES PETITES ET MOYENNES ENTREPRISES

RECHERCHE EXPLORATOIRE (2) SUR LES CRITÈRES DE SUCCÈS DES PROJETS DES PETITES ET MOYENNES ENTREPRISES RECHERCHE EXPLORATOIRE (2) SUR LES CRITÈRES DE SUCCÈS DES PROJETS DES PETITES ET MOYENNES ENTREPRISES Julie Bérubé (berj23@uqo.ca) Programme de maîtrise en gestion de projet, UQO RÉSUMÉ Les critères de

Plus en détail

MÉTHODOLOGIE DE L ASSESSMENT CENTRE L INSTRUMENT LE PLUS ADÉQUAT POUR : DES SÉLECTIONS DE QUALITÉ DES CONSEILS DE DÉVELOPPEMENT FONDÉS

MÉTHODOLOGIE DE L ASSESSMENT CENTRE L INSTRUMENT LE PLUS ADÉQUAT POUR : DES SÉLECTIONS DE QUALITÉ DES CONSEILS DE DÉVELOPPEMENT FONDÉS MÉTHODOLOGIE DE L ASSESSMENT CENTRE L INSTRUMENT LE PLUS ADÉQUAT POUR : DES SÉLECTIONS DE QUALITÉ ET DES CONSEILS DE DÉVELOPPEMENT FONDÉS 1. Introduction Placer la «bonne personne au bon endroit» représente

Plus en détail

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

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

Plus en détail

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

Méthode Agile de 3 ème génération. 2008 J-P Vickoff PUMA Essentiel Méthode Agile de 3 ème génération 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Quelques principes Agiles Principales pratique Agile de pilotage Structure

Plus en détail

JOURNÉE THÉMATIQUE SUR LES RISQUES

JOURNÉE THÉMATIQUE SUR LES RISQUES Survol de Risk IT UN NOUVEAU RÉFÉRENTIEL DE GESTION DES RISQUES TI GP - Québec 2010 JOURNÉE THÉMATIQUE SUR LES RISQUES 3 mars 2010 - Version 4.0 Mario Lapointe ing. MBA CISA CGEIT mario.lapointe@metastrategie.com

Plus en détail

Augmenter la vélocité Agile avec l usine-service sur Azure

Augmenter la vélocité Agile avec l usine-service sur Azure Augmenter la vélocité Agile avec l usine-service sur Azure Jean-Louis Lalonde, Ing., M.Ing. Président et Chef de la direction Groupe AZUR Avril 2015 Montréal, Canada SOMMAIRE EXÉCUTIF Notre expérience

Plus en détail

Retour d expérience implémentation Scrum / XP

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

Plus en détail

L enseignement de méthodes agiles dans un contexte d apprentissage actif

L enseignement de méthodes agiles dans un contexte d apprentissage actif L enseignement de méthodes agiles dans un contexte d apprentissage actif Ruben González-Rubio Eugène Morin Balkrishna Sharma Gukhool Groupe ɛ X it C1-3019 Département de génie électrique et de génie informatique

Plus en détail

RAPPORT EXÉCUTIF DE LA FIRME DE CONSULTANTS GARTNER

RAPPORT EXÉCUTIF DE LA FIRME DE CONSULTANTS GARTNER A Demande R-3491-2002 RAPPORT EXÉCUTIF DE LA FIRME DE CONSULTANTS GARTNER HYDRO-QUÉBEC ÉVALUATION DU PROJET SIC ET RECOMMANDATIONS, 7 AOÛT 2002 Original : 2002-09-20 HQD-2, Document 1 (En liasse) Rapport

Plus en détail

Le cycle de développement des produits à la Société GRICS : une nouvelle approche

Le cycle de développement des produits à la Société GRICS : une nouvelle approche Le cycle de développement des produits à la Société GRICS : une nouvelle approche Par : Denis Bessette Développement des systèmes Société GRICS Plan de la présentation 1. Agile et la planification stratégique

Plus en détail

Gestion de projets et de portefeuilles pour l entreprise innovante

Gestion de projets et de portefeuilles pour l entreprise innovante LIVRE BLANC Novembre 2010 Gestion de projets et de portefeuilles pour l entreprise innovante accélérer le taux de rendement de l innovation James Ramsay Consultant principal, Gouvernance de la zone Europe,

Plus en détail

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

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

Plus en détail

Faire simplement mieux

Faire simplement mieux Faire simplement mieux Roch Beauchemin Colloque SOQUIBS et AQIISTI 2010 BEAUCHEMIN BOUCHARD ASSOCIÉS INC 1 Faire simplement mieux Dans le contexte actuel de l informatisation, du degré d avancement de

Plus en détail

Manuel de recherche en sciences sociales

Manuel de recherche en sciences sociales Résumé de QUIVY R; VAN CAMPENHOUDT L. 95, "Manuel de recherches en sciences sociales", Dunod Cours de TC5 du DEA GSI de l intergroupe des écoles Centrales 11/2002 Manuel de recherche en sciences sociales

Plus en détail

Misereor a-t-elle besoin «d études de base»? Document d information à l intention des partenaires

Misereor a-t-elle besoin «d études de base»? Document d information à l intention des partenaires Misereor a-t-elle besoin «d études de base»? Document d information à l intention des partenaires Texte allemand : EQM/Misereor, janvier 2012 Traduction : Service des langues de MISEROR, mars 2012 Ce document

Plus en détail

CATALOGUE)FORMATION)2015)

CATALOGUE)FORMATION)2015) CATALOGUE)FORMATION)2015) Intitulé(de(formation( Code( Agiliser)vos)processus) F010$ Fondamentaux)du)Lean) F021$ Résolution)de)problème) F022$ Lean)Six)Sigma) F023$ Mesures)et)indicateurs) F030$ Assurance)qualité,)vérification,)validation)

Plus en détail

2. Activités et Modèles de développement en Génie Logiciel

2. Activités et Modèles de développement en Génie Logiciel 2. Activités et Modèles de développement en Génie Logiciel Bernard ESPINASSE Professeur à l'université d'aix-marseille Plan Les Activités du GL Analyse des besoins Spécification globale Conceptions architecturale

Plus en détail

Presses des MINES - TRANSVALOR, 60, boulevard Saint-Michel - 75272 Paris Cedex 06 - France

Presses des MINES - TRANSVALOR, 60, boulevard Saint-Michel - 75272 Paris Cedex 06 - France Valérie Fernandez, Thomas Houy, Carine Khalil, Les méthodes agiles en développement informatique, Paris : Presses des Mines, collection Vademecum, 2013. Presses des MINES - TRANSVALOR, 60, boulevard Saint-Michel

Plus en détail

Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET

Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET Glossaire La terminologie propre au projet, ainsi que les abréviations et sigles utilisés sont définis dans le Glossaire. Approbation Décision formelle, donnée

Plus en détail

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude INF 1250 INTRODUCTION AUX BASES DE DONNÉES Guide d étude Sous la direction de Olga Mariño Télé-université Montréal (Québec) 2011 INF 1250 Introduction aux bases de données 2 INTRODUCTION Le Guide d étude

Plus en détail

Consultation sur le projet de mise à jour des indicateurs PEFA, 7 août 2014

Consultation sur le projet de mise à jour des indicateurs PEFA, 7 août 2014 Consultation sur le projet de mise à jour des indicateurs PEFA, 7 août 2014 Madame, Monsieur Le Programme «Dépenses publiques et Responsabilité financière» (PEFA), lancé en 2001, a mis en place un cadre

Plus en détail

Mobiliser aujourd'hui les dirigeants humanitaires mondiaux de demain

Mobiliser aujourd'hui les dirigeants humanitaires mondiaux de demain Mobiliser aujourd'hui les dirigeants humanitaires mondiaux de demain Michael Dickmann Emma Parry Ben Emmens Christine Williamson Septembre 2010 People In Aid Cranfield University, School of Management

Plus en détail

DESCRIPTION DE POSTE. Directeur, Intégrité des programmes (IP)

DESCRIPTION DE POSTE. Directeur, Intégrité des programmes (IP) DESCRIPTION DE POSTE Titre du poste Directeur, Intégrité des programmes (IP) Composante organisationnelle Finances, gestion du risque et administration et bureau du Dirigeant principal des finances Titre

Plus en détail

Comment mettre en oeuvre une gestion de portefeuille de projets efficace et rentable en 4 semaines?

Comment mettre en oeuvre une gestion de portefeuille de projets efficace et rentable en 4 semaines? DOSSIER SOLUTION Package CA Clarity PPM On Demand Essentials for 50 Users Comment mettre en oeuvre une gestion de portefeuille de projets efficace et rentable en 4 semaines? agility made possible CA Technologies

Plus en détail

Why Software Projects Escalate: The Importance of Project Management Constructs

Why Software Projects Escalate: The Importance of Project Management Constructs Why Software Projects Escalate: The Importance of Project Management Constructs Why Software Projects Escalate: The Importance of Project Management Constructs 1. Introduction 2. Concepts de la gestion

Plus en détail

Certification Scrum Master

Certification Scrum Master avec Jeff Sutherland Les méthodes Agiles représentent indéniablement une approche nouvelle et différente dans la conduite de projets. Au lieu de suivre un plan à la lettre en assignant des tâches à une

Plus en détail

UML est-il soluble dans les méthodes agiles?

UML est-il soluble dans les méthodes agiles? Pascal ROQUES Valtech Training UML est-il soluble dans les méthodes agiles? octobre 07 Résumé On entend beaucoup parler actuellement de deux approches ayant l'air fondamentalement opposées : l'approche

Plus en détail

d évaluation Objectifs Processus d élaboration

d évaluation Objectifs Processus d élaboration Présentation du Programme pancanadien d évaluation Le Programme pancanadien d évaluation (PPCE) représente le plus récent engagement du Conseil des ministres de l Éducation du Canada (CMEC) pour renseigner

Plus en détail

Enseignement au cycle primaire (première partie)

Enseignement au cycle primaire (première partie) Ligne directrice du cours menant à une qualification additionnelle Enseignement au cycle primaire (première partie) Annexe D Règlement 184/97 Qualifications requises pour enseigner Normes d exercice de

Plus en détail

LES CRITÈRES D'ATTRIBUTION ET RÈGLES D APPLICATION DE RÉMUNÉRATIONS ADDITIONNELLES POUR LES EMPLOYÉS COUVERTS PAR L UNITÉ SCRC

LES CRITÈRES D'ATTRIBUTION ET RÈGLES D APPLICATION DE RÉMUNÉRATIONS ADDITIONNELLES POUR LES EMPLOYÉS COUVERTS PAR L UNITÉ SCRC LES CRITÈRES D'ATTRIBUTION ET RÈGLES D APPLICATION DE RÉMUNÉRATIONS ADDITIONNELLES POUR LES EMPLOYÉS COUVERTS PAR L UNITÉ SCRC PRÉPARÉ PAR LE COMITÉ PATRONAL SUR L'ÉGALITÉ SALARIALE LE 30 JANVIER 2006

Plus en détail

A-t-on le temps de faire les choses?

A-t-on le temps de faire les choses? A-t-on le temps de faire les choses? A-t-on le temps de faire les choses? Un parcours de 25 ans dans le domaine des Systèmes d'information de 6 grandes entreprises Consultante depuis 19 ans Mission / contrats

Plus en détail

Maîtriser les mutations

Maîtriser les mutations Maîtriser les mutations Avec UNE Supply chain AGILE La réflexion porte ses fruits www.cereza.fr TALAN Group Notre savoir-faire : maîtriser les mutations et en faire une force pour l entreprise Cereza,

Plus en détail

Plan d action SMB d une Approche Agile de la BITM Pour les PME

Plan d action SMB d une Approche Agile de la BITM Pour les PME Plan d action SMB d une Approche Agile de la BITM Pour les PME Personnel, processus et technologie nécessaires pour élaborer une solution rapide, souple et économique Copyright 2013 Pentaho Corporation.

Plus en détail

Cours Ephec Niv. 2 : Technique et gestion de projet. Par Monsieur Bertieaux Année Académique 2014-2015. Quelles sont les 4 valeurs Agiles?

Cours Ephec Niv. 2 : Technique et gestion de projet. Par Monsieur Bertieaux Année Académique 2014-2015. Quelles sont les 4 valeurs Agiles? Cours Ephec Niv. 2 : Technique et gestion de projet Par Monsieur Bertieaux Année Académique 2014-2015 Réponse aux questions du cours, slide Cours 2_2_Scrum Quelles sont les 4 valeurs Agiles? 1. «Les personnes

Plus en détail

Intelligence d affaires nouvelle génération

Intelligence d affaires nouvelle génération Intelligence d affaires nouvelle génération Sept étapes vers l amélioration de l intelligence d affaires par l entremise de la recherche de données À PROPOS DE CETTE ÉTUDE Les approches traditionnelles

Plus en détail

Quels outils pour prévoir?

Quels outils pour prévoir? modeledition SA Quels outils pour prévoir? Les modèles de prévisions sont des outils irremplaçables pour la prise de décision. Pour cela les entreprises ont le choix entre Excel et les outils classiques

Plus en détail

Agile @ Germe Grenoble 4 22/06/2012. Intervenant: Bruno Sbille

Agile @ Germe Grenoble 4 22/06/2012. Intervenant: Bruno Sbille Agile @ Germe Grenoble 4 22/06/2012 Intervenant: Bruno Sbille 1 Agile @ Germe 2 Bruno Sbille Blog Agile: http://brunosbille.com Coach & Formateur Blog Coaching Personnel: http://brunosbille.com/coachdevie

Plus en détail

FORMATION CONTINUE SUR L UTILISATION D EXCEL DANS L ENSEIGNEMENT Expérience de l E.N.S de Tétouan (Maroc)

FORMATION CONTINUE SUR L UTILISATION D EXCEL DANS L ENSEIGNEMENT Expérience de l E.N.S de Tétouan (Maroc) 87 FORMATION CONTINUE SUR L UTILISATION D EXCEL DANS L ENSEIGNEMENT Expérience de l E.N.S de Tétouan (Maroc) Dans le cadre de la réforme pédagogique et de l intérêt que porte le Ministère de l Éducation

Plus en détail

Introduction au génie logiciel

Introduction au génie logiciel Introduction au génie logiciel Guillaume Laurent ENSMM 2007 G. Laurent (ENSMM) Introduction au génie logiciel 2007 1 / 36 Plan du cours 1 Problématique du génie logiciel 2 Méthodes de développement logiciel

Plus en détail

Kanban et son utilisation à la Société GRICS

Kanban et son utilisation à la Société GRICS Kanban et son utilisation à la Société GRICS Par : Serge Pelletier Directeur de l informatique Richard Salette Chef d équipe Serveurs et réseau Vous vous apprêtez à entendre parler d une expérience continue

Plus en détail

{ mathieu boisvert / michel céré ; }

{ mathieu boisvert / michel céré ; } Introduction à l agilité Les grands principes Session du 4 avril 2013 { mathieu boisvert / michel céré ; } Qui sommes- nous? mathieu boisvert Coach Agile Chargé de cours Auteur d un livre michel céré Coach

Plus en détail

ITIL V2. La gestion des changements

ITIL V2. La gestion des changements ITIL V2 La gestion des changements Création : novembre 2004 Mise à jour : août 2009 A propos A propos du document Ce document de référence sur le référentiel ITIL a été réalisé en 2004 et la traduction

Plus en détail