Git pour l’évaluation et le suivi du travail collaboratif
favorisant le développement des compétences
transversales
Mémoire
Mélissa Clarisse Ntirandekura
Maîtrise en Informatique
Maître ès sciences (M. Sc.)
Québec, Canada
Git pour l’évaluation et le suivi du travail collaboratif
favorisant le développement des compétences
transversales
Mémoire
Mélissa Clarisse Ntirandekura
Sous la direction de:
Résumé
Le travail en équipe est un des moyens pour développer les compétences transversales at-tendues dans l’industrie, en particulier dans le domaine informatique. Aussi, au cours d’une formation académique, c’est l’une des occasions où l’étudiant a l’opportunité de les dévelop-per. Cependant, la réussite d’un travail en équipe dépend entre autres du choix des outils facilitant le travail collaboratif, l’organisation, la collaboration et la gestion des conflits. La possibilité de pouvoir évaluer objectivement aussi bien le travail individuel que celui collabo-ratif des membres de l’équipe doit davantage faire partie de ce choix. Cette évaluation peut en l’occurrence être faite en termes de contributions. Parmi ces outils nous proposons de re-tenir le système de gestion de version Git. En effet, c’est un des systèmes les plus utilisés dans l’industrie et permet d’en tirer de nombreux avantages autant pour les étudiants que pour les enseignants, sans oublier les possibilités de minimisation des coûts reliés au matériel didactique. Aussi, l’utilisation de Git dans le cadre de travaux d’équipe, donne accès à toute l’information relative aux activités qui sont consignées dans son historique. En effet toute action est associée à son auteur, à la date à laquelle elle a été effectuée. En disposant de ces données, il s’agit alors de définir les critères à appliquer pour faire une analyse et établir un jugement. Nous proposons dans ce mémoire un inventaire des critères d’évaluation potentiels et identifions les plus pertinents en termes d’évaluation de la régularité et de contribution quantitative en tenant compte des biais qu’ils peuvent induire. Aussi, une des difficultés que peuvent rencontrer les enseignants au moment de produire une évaluation est non seulement de pouvoir évaluer les contributions, mais également de pouvoir en faire un suivi régulier, tout particulièrement lorsque les équipes sont nombreuses. Nous proposons alors un outil de support basé sur les critères que nous avons identifiés offrant un aperçu général et facilitant l’accès aux détails. Son évaluation dans le cadre d’un cours nous a permis d’identifier différents profils d’équipe ainsi que les limites d’utilisation d’un tel outil pour établir un jugement.
Abstract
Teamwork is one of the ways to develop the transversal competencies expected in industry, especially in the field of Information Technology. However, the success of teamwork dur-ing programmdur-ing courses depends on the choice of tools that facilitates collaborative work, organization and conflict management. Objectively evaluating both the individual and the collaborative work must be a great part of this choice. Among these tools, we propose to retain the version control system Git. Indeed, it is one of the most used systems in the in-dustry and reaps many benefits for both students and teachers, including the minimization of cost of educational materials. Also, Git facilitates teamwork’s evaluation by giving access to information recorded in its history. It then becomes necessary to define the criteria to be applied to make an analysis and a judgment. We propose in this thesis an inventory of the potential evaluation criteria and identify the most relevant ones in terms of evaluation of the regularity and quantitative contribution considering the biases that they induce. Moreover, one of the difficulties that teachers may encounter when producing an assessment is not only to evaluate contributions, but also to be able to monitor them regularly, especially when teams are numerous. We then recommend a support tool based on the criteria we identified, offering a general overview and facilitating access to details. Its evaluation as part of a course allowed us to identify different team profiles as well as the limits to use of such a tool to make a judgment.
Table des matières
Résumé iii
Abstract iv
Table des matières v
Liste des tableaux vii
Liste des figures viii
Remerciements xii 1 Introduction 1 1.1 Contexte et motivation. . . 1 1.2 Problématique . . . 1 1.3 Objectif et méthodologie . . . 2 1.4 Organisation . . . 3
2 Le travail d’équipe comme moyen de développer les compétences trans-versales 4 2.1 Introduction. . . 4
2.2 Les compétences transversales et l’enseignement . . . 5
2.3 Évaluation des compétences transversales dans l’enseignement . . . 7
2.4 Conclusion . . . 11
3 Évaluation de la contribution individuelle au travail d’équipe 12 3.1 Définition de l’évaluation . . . 12
3.2 Différentes techniques d’évaluation du travail d’équipe . . . 13
3.3 Les différents critères considérés comme une contribution lors du travail d’équipe . . . 19
3.4 Conclusion . . . 28
4 Git comme outil de support du travail d’équipe 29 4.1 Introduction. . . 29
4.2 Présentation de Git. . . 30
4.3 Utilisation de Git dans l’enseignement . . . 30
4.4 Git et l’évaluation de la contribution individuelle au travail d’équipe . . . . 34
5 Un outil pour l’évaluation objective du travail d’équipe 46
5.1 Introduction. . . 46
5.2 Définition et objectif général. . . 46
5.3 Les outils utilisés par Gitanalysis . . . 47
5.4 Les critères considérés comme une contribution par Gitanalysis . . . 48
5.5 Fonctionnalités de Gitanalysis . . . 48
5.6 Résultats et analyses . . . 57
5.7 Limites de Gitanalysis et recommandations . . . 65
5.8 Conclusion . . . 68
Conclusion 70
Liste des tableaux
2.1 Qualités développées lors du travail en équipe . . . 10
3.1 Exemple d’outil d’évaluation par les paires . . . 16
Liste des figures
3.1 Exemple d’outil d’évaluation par les pairs . . . 14
4.1 Activité en termes de lignes de code de chaque auteur dans le temps sur la
branche principale master (générée par Pepper) . . . 35
4.2 Activité en termes de commits dans le temps sur la branche principale mas-ter pour l’ensemble des auteurs puis de chaque auteur pris individuellement
(générée par Github à partir d’un dépôt public) . . . 35
4.3 Activité en termes de commits dans le temps sur la branche principale mas-ter pour l’ensemble des auteurs puis de chaque auteur pris individuellement
(générée par Gitlab à partir d’un dépôt public) . . . 36
4.4 Résultat de la commande git pour illustrer les auteurs du dépôt . . . 37
4.5 Résultat de la commande git pour illustrer les dates des 5 derniers commits . . 37
4.6 Contribution en termes de pourcentage des commits de chaque auteur sur la
branche principale master (générée par Pepper) . . . 38
4.7 Le nombre de commits contribués par auteur et par période en termes de
pour-centages (générée par Pepper) . . . 39
4.8 Contribution en termes de commits et de LOC (Lines of code) de chaque auteur
(générée par Gitstats) . . . 39
4.9 Contribution en termes de commits et de LOC de chaque auteur (générée par
Gitinspector) . . . 40
4.10 Résultat de la commande git pour illustrer le nombre de commits par auteur . 40
4.11 LOC accumulées au fil du temps par chaque auteur (générée par Gitstats) . . . 41
4.12 LOC accumulées au fil du temps par chaque auteur (générée par Pepper) . . . 41
4.13 Résultat de la commande git pour illustrer le nombre de fichiers modifiés et de
LOC ajoutées et supprimées par commit pour un auteur spécifique . . . 42
4.14 Résultat de la commande git pour illustrer les fichiers ajoutés, supprimés et
modifiés par un auteur et selon les extensions choisies . . . 43
5.1 Extrait du tableau de bord de Gitanalysis pour une période de deux mois sur
les fichiers java . . . 49
5.2 Choix de Gitanalysis . . . 50
5.3 Exemple de contribution quantitative d’un membre de l’équipe pour environ 4
mois sur les fichiers java par Gitanalysis . . . 51
5.4 Exemple de contribution quantitative d’une équipe pour environ 4 mois sur les
fichiers java . . . 51
5.5 Evalation du membre de l’équipe sur la régularité par Gitanalysis . . . 53
5.7 Suivi d’un membre moins régulier sur des périodes différentes par Gitanalysis . 54
5.8 Suivi d’un membre irrégulier sur des périodes différentes par Gitanalysis . . . . 55
5.9 Évaluation des combinaisons possibles des équipes formées de 4 et de 3 membres 58
5.10 Activité d’une équipe fonctionnelle composée des membres actifs avec travail
bien réparti (extrait du tableau de bord généré par Gitanalysis) . . . 59
5.11 Activité d’une équipe fonctionnelle composée des membres actifs avec travail
mal réparti (extrait du tableau de bord généré par Gitanalysis) . . . 60
5.12 Activité d’une équipe fonctionnelle composée des membres actifs et à surveiller
(extrait du tableau de bord généré par Gitanalysis) . . . 60
5.13 Activité d’une équipe passagèrement dysfonctionnelle composée des membres à
surveiller (extrait du tableau de bord généré par Gitanalysis) . . . 61
5.14 Activité d’une équipe passagèrement dysfonctionnelle composée d’une moitié de membres actifs et d’une autre moitié de membres à surveiller (extrait du
tableau de bord généré par Gitanalysis) . . . 62
5.15 Activité d’une équipe passagèrement dysfonctionnelle composée de membres à surveiller majoritaires et d’un membre actif (extrait du tableau de bord généré
par Gitanalysis). . . 63
5.16 Activité d’une équipe dysfonctionnelle composée d’un abandon (extrait du
ta-bleau de bord généré par Gitanalysis) . . . 63
5.17 Activité d’une équipe dysfonctionnelle composée de membres représentés
plu-sieurs fois (extrait du tableau de bord généré par Gitanalysis) . . . 64
5.18 Activité d’une équipe dysfonctionnelle composée de membres actifs et à risque
(extrait du tableau de bord généré par Gitanalysis) . . . 65
5.19 Exemple de configurations différentes de nom pour la même personne (générée
par Pepper) . . . 66
5.20 Evaluation de l’équipe avant les examens intra par Gitanalysis. . . 67
À mes parents, mes soeurs, mes frères et à François pour votre amour et votre soutien permanent, je dédie ce mémoire.
L’informatique, ça fait gagner beaucoup de temps... à condition d’en avoir beaucoup devant soi !
Remerciements
Le présent mémoire a été possible grâce au soutien, à la collaboration et à la contribution de plusieurs personnes à qui je voudrais témoigner toute ma reconnaissance.
En premier lieu, je voudrais adresser toute ma gratitude à mon directeur de recherche, le professeur Thierry Eude, pour son encadrement, ses judicieux conseils, sa disponibilité, sa patience et ses encouragements qui ont contribué à la réalisation de ce mémoire.
En deuxième lieu, je voudrais remercier le professeur Jonathan Gaudreault ainsi que Jean Bouchard, Martin Savoie et Kento Otomo-Lauzon pour avoir accepté de participer à la pré-sentation de l’application qui a été le fruit de cette recherche. Vos interventions m’ont permis d’améliorer l’application.
En troisième lieu, je voudrais remercier les professeurs Jonathan Gaudreault et Luc Lamon-tagne pour avoir accepté d’examiner ce mémoire.
En quatrième lieu, je tiens à témoigner toute ma gratitude à mes parents et à François Lemay qui ont toujours été là pour moi.
Enfin, je voudrais exprimer ma reconnaissance envers les amis, les professeurs, les collègues et la famille qui m’ont apporté leur support moral et intellectuel tout au long de ma démarche.
Chapitre 1
Introduction
1.1
Contexte et motivation
De nos jours, dans le monde professionnel, le développement des compétences transversales est primordial, ceci pour augmenter ses chances d’être embauché, mais également pour maintenir une employabilité durable. Aussi, au cours d’une formation académique, le travail en équipe est l’une des meilleures façons d’acquérir et de consolider les compétences transversales. En effet, lors du travail en équipe, l’étudiant a l’occasion de développer différentes compétences transversales telles que la communication, l’analyse, le jugement critique, la collaboration, l’autonomie, la prise de responsabilité, le leadership, . . . recherchées par les employeurs. Il faut aussi noter que dans le domaine de l’informatique, le développement d’un projet se fait souvent en équipe demandant ainsi aux participants de collaborer tout au long de celui-ci. Cependant, la réussite d’un travail en équipe dépend entre autres du choix des outils facilitant le travail collaboratif, de l’organisation des coéquipiers, de leur collaboration et de leur gestion des conflits [14]. De plus, il est important de pouvoir évaluer objectivement aussi bien le travail individuel que celui collaboratif des membres de l’équipe. Ainsi, c’est dans le cadre d’un support à un travail en équipe efficace, productif et pouvant être évalué objectivement, que des outils de travail collaboratif en informatique et en génie logiciel apparaissent indispensables et sont proposés dans la présente recherche.
1.2
Problématique
En choisissant le travail d’équipe comme un moyen de développer les compétences transver-sales, il faut remarquer que son évaluation objective n’est pas triviale. En effet, elle demande de choisir de bons outils de collaboration qui permettent de recueillir les mesures objectives qui serviront ainsi lors de l’évaluation. Lanubile et al. ont proposé l’utilisation de plusieurs outils pour faciliter le travail d’équipe [31]. Il s’agit notamment des systèmes de gestion de version, des outils de communication, des applications web, . . . Ainsi, l’une des difficultés est
de choisir parmi ces outils, celui qui facilite le travail d’équipe et son évaluation objective. Une fois ce choix fait, il s’agit ensuite d’identifier les critères pouvant être considérés pour quantifier les contributions lors du travail d’équipe. En effet, on trouve dans la littérature différents auteurs ayant proposé plusieurs critères de contribution. Aussi, la problématique à laquelle on s’intéresse consiste à choisir ceux qui permettent de faire une évaluation objective du travail d’équipe. Ainsi, au cours de l’évaluation objective, on cherche alors à répondre aux questions suivantes :
— Quelle est la contribution apportée par chaque membre de l’équipe ? — Est-ce-que chaque membre contribue régulièrement ou irrégulièrement ? — Quelles sont les équipes les plus actives et celles qui le sont moins ?
En disposant d’un outil permettant de faire un suivi régulier rapidement de chaque équipe, un professeur sera plus à même d’identifier une équipe qui traverse une période de conflit sans que l’un de ses membres n’ait besoin de le notifier, ce qui est un obstacle en soit, puisqu’en général, les étudiants n’osent pas le faire.
1.3
Objectif et méthodologie
L’objectif de notre recherche consiste dans un premier temps à montrer la place des compé-tences transversales dans l’éducation, plus précisément en Informatique et en génie logiciel, et à montrer la place du travail d’équipe dans le développement des compétences transversales. Dans un deuxième temps, il s’agit de proposer des outils de travail collaboratif. Notre objectif final est alors de permettre d’évaluer objectivement aussi bien les contributions individuelles que celles de l’équipe et de pouvoir suivre régulièrement le travail fait par chaque équipe. Les travaux proposés se décomposent 5 parties :
— montrer que le travail d’équipe est un moyen de développer les compétences transversales — étudier les différents critères qui pourraient être considérés comme une contribution lors
du travail d’équipe
— proposer un système de gestion de versions distribué comme outil de support du travail d’équipe
— développer une application web qui récupérerait automatiquement les données stockées dans les dépôts partagés et faciliterait l’évaluation objective et le suivi du travail d’équipe — analyser les résultats obtenus
1.4
Organisation
Dans le chapitre 2, nous présentons d’abord les compétences transversales et montrons l’avan-tage de développer ces dernières. Ensuite, nous présentons les techniques pour introduire et évaluer les compétences transversales dans l’enseignement. Pour terminer, nous proposons le travail d’équipe comme un moyen de développer les compétences transversales.
Dans le chapitre 3, nous abordons l’évaluation du travail d’équipe. Nous commençons par dé-finir l’évaluation selon la revue de littérature. Nous présentons par la suite les différentes tech-niques utilisées pour évaluer le travail d’équipe. Nous terminons par une présentation des dif-férents critères pouvant être considérés comme des contributions lors du travail d’équipe ainsi qu’un classement de ces derniers selon la pertinence lors de l’évaluation du travail d’équipe. Dans le chapitre 4, nous présentons la manière d’organiser le travail d’équipe. Nous com-mençons par présenter Git comme un outil de collaboration. Par la suite, nous montrons les avantages de son utilisation dans l’enseignement. Nous terminons par une présentation de Git comme un outil d’évaluation du travail d’équipe.
Dans le chapitre 5, nous introduisons l’outil que nous avons développé : Gitanalysis. Nous commençons par montrer les outils qui ont été utilisés par Gitanalysis pour pouvoir analyser et évaluer le travail d’équipe ainsi que les critères qui ont été considérés lors de cette évaluation. Par la suite, la récupération des dépôts Git, l’évaluation de la contribution quantitative et la détermination de l’indicateur d’activité de l’équipe sont présentées comme les différentes fonctionnalités offertes par Gitanalysis. A la fin du chapitre, nous faisons une analyse des résultats obtenus lors de l’évaluation des équipes. Les biais potentiels sur l’évaluation sont alors énumérés ainsi que les recommandations à suivre pour éviter ces biais.
A la fin de ce mémoire, nous présentons une conclusion composée de la démarche qui a été suivie et de la contribution qui a été apportée ainsi que les perspectives.
Chapitre 2
Le travail d’équipe comme moyen de
développer les compétences
transversales
2.1
Introduction
La meilleure façon d’outiller les étudiants à faire face au monde professionnel en augmen-tant leur chance d’être embauchés mais également de garder leur emploi est de les aider à développer les compétences transversales tout au long de leur vie estudiantine. Selon Sicilia [51], les compétences transversales peuvent être définies comme n’étant pas des compétences spécifiques à un domaine particulier mais comme étant applicables dans différents domaines ; soient des compétences transférables et réutilisables d’un domaine à un autre. Par ailleurs, selon Tardif [53], une compétence transversale est : « un savoir-agir complexe prenant appui sur la mobilisation et la combinaison efficaces d’une variété de ressources internes et externes à l’intérieur d’une famille de situations ». Or dans le monde actuel où la technologie évolue rapidement et le chômage est présent, nous pouvons ainsi noter l’importance d’introduire les compétences transversales dans l’éducation. En effet, Finot [18] a montré que les employeurs rechercheraient plus les compétences transversales que les compétences techniques du fait que ces dernières sont souvent spécifiques à un domaine particulier par opposition aux compétences transversales qui sont applicables et réutilisables dans plusieurs domaines. De plus, Gonzàlez et al. [23] considèrent que les compétences transversales sont indispensables dans la formation académique des étudiants afin de les préparer à « leur rôle futur dans la société en termes d’employabilité et de citoyenneté ».
Parmi les compétences transversales qu’un étudiant devrait posséder à la fin de sa formation académique, nous pouvons retenir celles proposées par Laliberté [30]. Il s’agit notamment d’être capable de communiquer oralement ou par écrit de manière efficace, d’être capable
d’analyser et de résoudre les problèmes, d’avoir un esprit de coopération, d’avoir un esprit critique, d’être capable de prendre des décisions, d’être capable de comprendre la relation que l’homme entretient avec l’environnement et d’être capable de comprendre le monde actuel avec tous les enjeux économiques, politiques et sociaux auxquels les hommes font face au quotidien. On pourrait ajouter « la capacité d’organisation et de planification » proposées par Chauvigné et al. [11], « la conduite et la gestion de projets » proposées par Tardif et Dubois [54] et « la gestion du temps et le souci de la qualité du travail » proposés par Sicilia [51].
En résumé, en plus des compétences techniques, il apparaît essentiel que les enseignants intro-duisent un moyen de développer et d’évaluer les compétences transversales dans le cadre de leur cours. En effet, à la fin de la formation académique, les étudiants devraient être capables de bien communiquer, de travailler en équipe, d’avoir un esprit de jugement, d’analyse et de résolution de problèmes,. . .
2.2
Les compétences transversales et l’enseignement
Les compétences tranversales peuvent être abordées de différentes façons dans l’enseignement. Aussi, parmi celles proposées dans la littérature, nous retiendrons l’approche « active learning » et l’approche basée sur le corpus SWEBOK1.
2.2.1 L’approche « Active learning »
Yanaze et al. [63] proposent de commencer par connaître les compétences transversales les plus recherchées sur le marché du travail avant de proposer une méthode pour les développer chez l’étudiant. Après avoir étudiés différentes offres d’emplois publiées sur le site de IEEE2 dans le domaine de génie logiciel et génie électrique, ils ont observé que :
— La communication était demandée par 74,17% des emplois. Pour la majorité des emplois, il s’agissait d’une communication orale et verbale pour bien représenter la compagnie, travailler en équipe ou interagir avec les clients.
— Le travail en équipe était demandé par 49,25% des emplois dont 35,74% spécifiaient d’être un leader du groupe.
— La facilité d’adaptation dans différents domaines et disciplines était demandée par 23,72% des emplois.
— La capacité d’analyser et de résoudre des problèmes étaient demandée par 21,92% des emplois.
Le fait d’avoir identifié la communication comme la compétence la plus recherchée dans la plupart des emplois, montre que cette compétence est essentielle chez les ingénieurs.
1. Software Engineering Body of Knowledge 2. Institute of Electrical and Electronics Engineers
Comme la communication, le travail en équipe, la compétence dans différentes disciplines, l’analyse et la résolution de problèmes sont les principales compétences transversales recher-chées sur le marché du travail, l’une des approches proposée par l’auteur est l’« active lear-ning ». Cette approche place l’étudiant au centre du processus d’apprentissage où il doit in-teragir et être engagé durant son apprentissage. Parmi les méthodes utilisées par l’« active learning » nous retrouvons les discussions en classe, les exercices écrits, l’apprentissage en équipe, les débats entre étudiants, les réflexions sur une vidéo, l’apprentissage par les jeux en groupe, le « learning cell » ou encore le « think-pair- share ». En effet, le « learning cell » est une méthode de l’« active learning » où deux étudiants se posent des questions et y ré-pondent de manière alternative sur un sujet donné [58]. Le « think-pair- share » est quant à elle une autre méthode d’apprentissage où les étudiants sont appelés à travailler sur un sujet de manière individuelle et de partager par la suite leur réflexion à toute la classe.
2.2.2 L’approche basée sur le corpus SWEBOK
Il existe peu d’approches documentées qui expliquent comment développer les compétences transversales spécifiquement dans le cadre de cours en génie logiciel. Aussi, Sicilia [51] propose une approche basée sur le corpus SWEBOK. Le SWEBOK est le document de base de l’IEEE-Computer-Society pour la normalisation en génie logiciel [61].
Afin de développer les compétences transversales chez les étudiants, ce corpus propose d’abord de rendre plus spécifique les compétences transversales. En effet, avant de commencer à ensei-gner un cours, il faut que l’enseignant puisse dégager les compétences transversales spécifiques à son cours. Or, les compétences transversales étant définies comme des compétences qui peuvent être transférées et réutilisées dans différents domaines ; donc non spécifiques à un do-maine, l’hypothèse qu’elles soient toutefois développées et évaluées dans un contexte spécifique reste valide. C’est dans ce contexte que l’auteur soutient que les compétences transversales devraient être développées dans le cadre d’un cours spécifique rendant ainsi ces compétences plus spécifiques.
Aussi, il propose une manière d’évaluer ces compétences transversales qui diffère de celle pour évaluer les compétences techniques propres au cours. L’exemple qui a été donné servant de référence est celui de développer le travail en équipe dans un programme de génie logiciel. L’auteur a proposé que cette compétence soit développée durant la deuxième année où les relations interpersonnelles et sociales sont plus importantes chez les étudiants et après que ces derniers aient eu une base en programmation. Ainsi évaluer si l’étudiant travaille en équipe consisterait à évaluer son comportement, son sens de responsabilité et son attitude positive face aux autres membres de l’équipe. En peu de mots, il s’agirait d’évaluer comment l’étudiant interagit avec les autres membres de l’équipe.
Au cours de cette section, nous venons de voir que l’approche « Active learning » et l’approche basée sur le corpus SWEBOK sont les deux approches que nous pouvons retenir comme moyen d’introduire les compétences transversales dans l’enseignement. Ils permettent chez l’étudiant de développer l’esprit de coopération, d’analyse, de critique, . . . Cependant, il faut noter qu’il ne suffit pas d’introduire ces compétences transversales dans l’enseignement mais qu’il faut aussi pouvoir les évaluer.
2.3
Évaluation des compétences transversales dans
l’enseignement
2.3.1 Différentes méthodes proposées
L’évaluation des compétences transversales dans le cadre d’un cours n’est pas toujours facile à réaliser et est souvent plus subjective qu’objective. Par exemple pour évaluer si un étudiant a un jugement critique, le professeur va souvent regarder comment l’étudiant réagit dans une situation donnée et le noter ainsi de façon subjective.
Selon Berthiaume [4], tout exercice qui permet à l’étudiant de faire une analyse, une synthèse ou une évaluation est une bonne façon d’évaluer les compétences transversales. Il s’agit entre autres de donner aux étudiants des exercices exigeants des réponses à développement, des rédactions, des projets à réaliser ou une présentation orale avec ou sans discussion.
De façon plus détaillée, Rico et al. [47] proposent des techniques pour développer la pensée critique, le travail en équipe, l’innovation et l’entrepreneuriat. Pour commencer avec la pensée critique, le fait de poser un problème et de proposer par la suite différentes solutions permettent à l’étudiant de développer son jugement critique et de travailler dans l’abstraction pour refléter des situations réelles. En effet, l’étudiant peut utiliser une vidéo, une page web, un blog ou un forum de discussion pour essayer de trouver les articles qui ont traités le même problème et ainsi choisir parmi les différentes sources la meilleure solution. A travers cet exercice, il faut noter que les compétences telles que la recherche d’information, l’analyse, la critique, la synthèse et l’évaluation sont ainsi développées. Une fois que la meilleure solution au problème a été choisie, l’étudiant est invité à la partager avec ses camarades de classe ainsi qu’avec l’enseignant. Cela peut se faire de différentes manières soit en classe soit à travers des plateformes de discussions permettant à l’étudiant de développer d’autres compétences telles que la collaboration et la communication et d’améliorer les compétences telles que l’analyse, la synthèse et l’évaluation. Par la suite, pour développer la compétence « travail en équipe », les étudiants sont invités à former des équipes, à trouver un moyen de communication approprié pour discuter et un outil de collaboration pour partager leur solution. Il faut noter que bien que le travail en équipe favorise la collaboration entre les étudiants, il demande un travail individuel en premier lieu. En effet, avant de partager son opinion ou sa solution aux autres, l’étudiant doit faire une
recherche personnelle afin de dégager les points pertinents qui devraient être mentionnés lors de la rencontre avec ses collègues ou son professeur. Ensuite, le travail d’équipe permet aux étudiants de travailler ensemble à travers les discussions, les présentations, les échanges de points de vue, les comparaisons, les critiques et la participation active de chacun. Et tout cela, dans le but de trouver la meilleure solution au problème qu’ils essaient ensemble de résoudre. Le travail en équipe permet ainsi de développer la collaboration et le respect des opinions différentes.
Pour terminer, l’innovation et l’entrepreneuriat peuvent être développés à travers la démons-tration d’un leadership. En effet, dans le cadre d’un travail d’équipe, le leader doit être capable d’organiser son équipe, de répartir les tâches entre les membres de l’équipe et d’encourager chacun de finir les tâches qui lui ont été attribuées. Il doit aussi s’assurer que le travail final soit original et de qualité avec des idées innovatrices.
Sanchez et al. [49] ont proposé d’évaluer quatre compétences transversales lors de la dernière année académique. Il s’agit de la communication orale et écrite dans une langue étrangère comme l’anglais, la rédaction de la documentation et des rapports dans la langue maternelle (c’était l’espagnol dans l’article), une bonne communication orale dans la langue maternelle et la capacité interpersonnelle. Ainsi lors de l’évaluation de la communication orale et écrite dans une langue étrangère, le superviseur doit s’assurer que l’étudiant est capable de recher-cher l’information écrite dans la langue étrangère, d’extraire les sources les plus importantes, de rédiger des rapports et de présenter les résultats de ses recherches dans la langue étrangère. Lors de la rédaction de la documentation et des rapports dans la langue maternelle, le super-viseur doit s’assurer de l’absence des fautes d’orthographe, d’un bon choix de format pour le document, d’une bonne organisation et compréhension des idées présentées par l’étudiant. En peu de mots, il s’agit de regarder le fond et la forme du document. Être capable d’expliquer et de défendre clairement ses idées en choisissant les mots appropriés est une façon d’évaluer la communication orale dans la langue maternelle. Et pour les capacités interpersonnelles, le superviseur doit s’assurer que l’étudiant possède les compétences sociales, l’intelligence émo-tionnelle et l’empathie.
Il faut remarquer que le travail d’équipe ou l’esprit de coopération est une des compétences qui a été cité par plusieurs auteurs [51, 63,30, 54,47, 49]. En effet, elle peut être considérée comme une super compétence transversale car elle englobe d’autres compétences telles que la communication, la capacité de faire une analyse et une synthèse, la résolution de problème, . . . Par exemple, lors d’un travail d’équipe, les membres sont appelés à communiquer régulièrement afin de faire avancer leur travail. Ils sont aussi appelés à résoudre les problèmes au sein de l’équipe afin de gérer les conflits et à avoir un esprit critique afin de fournir un travail de qualité. C’est pour ces raisons que nous l’avons retenu comme le moyen de développer les compétences transversales dans notre travail de recherche. Nous le décrivons plus en détails dans ce qui suit.
2.3.2 Le travail d’équipe
De nos jours, le travail d’équipe est une des compétences les plus recherchées aussi bien par les employeurs que par les organismes d’accréditation. En effet, la plupart des projets de développement des logiciels dans l’industrie se font en équipe [35,36,55]. Aussi, il a été noté que les nouveaux employés, dans le domaine de développement de logiciel, ne communiquaient pas toujours correctement et étaient inexpérimentés à travailler en équipe. Une des raisons de cette inexpérience est que la plupart des programmes de formation académique favorise plus le travail individuel que le travail d’équipe [36]. C’est pourquoi, une bonne communication orale et écrite, une capacité d’analyse et surtout une capacité d’interaction avec les autres sont les clés d’une employabilité durable.
Alves et al. [1] ont montré que l’on peut tirer plusieurs avantages des travaux d’équipe. Leur étude consistait à recueillir la perception des étudiants de travailler en équipe dans le cadre d’un cours. Ainsi, le premier avantage qu’il en est ressorti était que le travail d’équipe avait permis aux étudiants de mieux comprendre leur cours car ils pouvaient mettre en pratique ce qu’ils avaient appris. L’évaluation des paires était le second avantage. En effet, le fait d’avoir un retour d’appréciation de la part de ses collègues permettait à l’étudiant d’améliorer la qualité de son travail et de développer son jugement critique. Plusieurs autres qualités ont été citées par [35,36,55]. Elles sont présentées dans la Table 2.1.
Cependant, selon Alves et al. [1], des inconvénients existent aussi lors d’un travail en équipe. En effet, les étudiants trouvaient qu’ils fournissaient beaucoup plus d’efforts et de temps pour réaliser un projet en équipe que pour réaliser un projet individuellement. Les mêmes propos avaient été recueillis auprès des enseignants qui dirigeaient les équipes. En effet, selon les enseignants, il fallait beaucoup plus d’efforts et de temps pour guider les étudiants et répondre à leurs questions [35]. Ces désavantages sont une évidence car gérer différentes façons de penser n’est pas toujours facile et entraîne souvent des conflits entre les membres de l’équipe qui doivent à leur tour être gérés.
Capacité à s’intégrer facilement Capacité à comprendre les autres
Capacité à respecter les idées et l’attitude d’autrui Capacité à écouter les autres
Capacité à travailler avec les autres et dans la diversité Capacité à s’engager pour réaliser le projet de groupe Capacité à s’adapter aux changements d’horaire Capacité à être flexible lors du partage des tâches
Capacité à proposer de nouvelles idées en tenant compte de celles proposées par d’autres Capacité à remettre les travaux à temps
Capacité à offrir du support aux autres Capacité à motiver ses coéquipiers
Capacité à assumer ses responsabilités en cas d’erreurs
Capacité à trouver les liens qui se trouvent entre les disciplines Capacité à aborder les problèmes de différentes manières Capacité à apprécier le travail, les idées et le savoir des autres Capacité à vouloir apprendre de nouvelles choses
Capacité à proposer de bons alternatives
Capacité à comprendre les différentes sources d’information et à pouvoir les expliquer aux autres
Capacité à planifier, à suivre l’exécution et à évaluer un projet Capacité à solliciter le support des autres
Table 2.1 – Qualités développées lors du travail en équipe
Vu l’importance de travailler en équipe, différents auteurs des articles [35,36,55] ont proposé ce qu’il faudrait faire pour améliorer le travail d’équipe et avoir un bon rendement, soient :
— utiliser les principes de l’agilité — avoir une bonne organisation — être motivé à réussir
— bien définir les objectifs du projet — définir les tâches de chaque membre — être une équipe solidaire
— créer un réseau de communication
— utiliser les outils de collaboration pour permettre à tous les membres de l’équipe de partager leur travail
— planifier le projet et faire son suivi
— participer activement (cela concerne chaque membre de l’équipe) — rédiger des rapports concis
— être un leader
— mesurer la contribution de l’équipe — partager les idées
— faire des rencontres d’équipe productives
— tenir compte des remarques faites par les autres membres — être ouvert à différentes façons de résoudre les problèmes.
En résumé, le travail d’équipe est une compétence que les étudiants devraient développer durant leur formation académique afin d’augmenter leur chance de trouver un emploi à la fin de leurs études. C’est aussi une compétence qui permet de développer bien d’autres compétences transversales telles que l’analyse, la communication, le jugement critique, . . . Vu les qualités que l’on peut développer en travaillant en équipe, on pourrait facilement dire que le travail d’équipe est un des moyens de développer les compétences transversales. Cependant, il faut noter que l’évaluation de la contribution individuelle et celle de l’équipe est importante et n’est pas toujours facile à faire. Elle fera ainsi le sujet du chapitre suivant.
2.4
Conclusion
Au cours de ce chapitre, nous avons vu différentes définitions des compétences transversales qui ont été proposées dans la littérature. Celle que nous pouvons retenir et qui est commune aux différentes définitions est que les compétences transversales ne sont pas spécifiques à un domaine en particulier mais plutôt transférables facilement d’un domaine à un autre. Aussi, nous avons vu différentes techniques qui peuvent être utilisées comme moyen d’introduction des compétences transversales dans l’enseignement. Il s’agit notamment de l’approche « Active learning » où l’étudiant est placé au centre du processus d’apprentissage et l’approche basée sur le corpus SWEBOK où l’enseignant est invité à définir les compétences transversales qui seront développées par l’étudiant pour chaque cours et à déterminer un moyen de pouvoir évaluer ces compétences. Pour terminer, malgré les différentes méthodes proposées pour éva-luer les compétences transversales, il apparaît que le travail d’équipe est une des meilleures méthodes car il permet de développer plusieurs compétences simultanément.
Aussi, pour évaluer le travail d’équipe, il est nécessaire d’avoir recours à différentes techniques et critères qui peuvent être considérés comme une contribution lors du travail d’équipe. C’est ce que nous proposons d’étudier dans le chapitre qui suit.
Chapitre 3
Évaluation de la contribution
individuelle au travail d’équipe
3.1
Définition de l’évaluation
« L’évaluation est une démarche qui vise à donner de la valeur, prendre du recul, émettre un constat sur une situation, et prendre des décisions, au regard des objectifs de départ et des finalités de l’action. » [46]. Par exemple, dans le cadre d’un travail d’équipe effectué par des étudiants dans un cours de développement de logiciels, l’enseignant peut évaluer la contribution apportée par chaque membre de l’équipe afin de déterminer les membres qui travaillent régulièrement et ceux qui travaillent irrégulièrement et ainsi agir en conséquence. Selon Romainville [48], dans l’enseignement, « évaluer consiste à mesurer puis à apprécier, à l’aide de critères, l’atteinte des objectifs d’enseignement, en trois étapes. La première étape réside dans le recueil systématique, valide et fidèle d’informations appropriées aux objectifs d’enseignement. C’est la phase d’observation et/ou de recueil de données. La deuxième étape consiste à interpréter les informations recueillies à l’aide de critères. C’est la phase d’analyse. Celle-ci débouche sur la troisième étape, à savoir l’établissement de conclusions et/ou la prise de décisions. C’est la phase du jugement à proprement parler. »
Lors de l’évaluation, l’on peut se baser sur des mesures objectives donnant lieu à une évaluation objective ou des mesures subjectives donnant lieu à une évaluation subjective. Par mesure objective, il faut comprendre des mesures que l’on peut quantifier et donner des mesures exactes [3]. Le nombre de fichiers créés, le nombre de soumission dans un système de gestion de version (commits1) [60] ou le nombre de fonctions ajoutées sont des exemples de mesure objective.
Par contre, les mesures subjectives sont des mesures que l’on ne peut pas quantifier donc
1. validation : action d’envoyer ses modifications locales vers le référentiel central afin, d’une part, de mettre à disposition les modifications apportées à un document et, d’autre part, d’insérer de façon cohérente ces modifications dans l’historique des modifications.
non exactes. Elles proviennent souvent d’une estimation faite par l’évaluateur. Une évaluation sur la complexité du code ou de l’expérience des développeurs sont des exemples de mesure subjective [3].
Selon Treude et al. [56], une mesure objective est celle qui peut être mesurée automatiquement par des outils. Il s’agit entre autres du nombre de lignes de code, de tâches, de commits, . . . Par contre, pour une mesure subjective, dans le cas d’une même activité, différents évaluateurs vont donner différentes évaluations donc différentes opinions. Les exemples cités sont l’évaluation de la qualité du code, de la créativité, . . .
A partir des différentes définitions, nous pouvons voir qu’il est important de faire une éva-luation afin de prendre des décisions, de suggérer des améliorations à faire, de mesurer la productivité, . . . Nous pouvons aussi voir que les évaluations se font à partir des mesures qui peuvent être objectives ou subjectives selon qu’elles sont faites par des outils ou par des individus. Dans la section suivante, nous allons présenter différentes techniques qui ont été proposées pour évaluer le travail d’équipe.
3.2
Différentes techniques d’évaluation du travail d’équipe
3.2.1 L’évaluation par les paires
Falchikov et al. [16] la définissent comme étant le fait qu’un étudiant évalue le travail des autres étudiants à partir de critères d’évaluation souvent établies par l’enseignant. Cette éva-luation permet aux étudiants d’améliorer leur apprentissage d’où son utilisation dans l’« active learning » (cf. l’approche « Active learning » dans 2.2.1). Le réseau de valorisation de l’en-seignement de l’Université Laval propose un exemple d’outil d’évaluation par les paires où l’étudiant commence par écrire les noms de ses coéquipiers comme illustré par la Figure 3.1
et évalue, par la suite, chaque coéquipier en se basant sur les différents critères proposés dans la Table 3.1.
Lors d’un travail en équipe, l’évaluation par les paires est également proposée par Brooks et al. [7] comme un moyen de réduire le problème du passager clandestin lorsque elle faite dès le début du travail, régulièrement et que les critères d’évaluation sont bien définis. En effet, en premier lieu, lorsque l’évaluation est faite dès le début du travail d’équipe, elle permet à chaque membre de l’équipe de voir comment les autres coéquipiers évaluent sa contribution au sein de l’équipe et de fixer une stratégie pour améliorer son travail. Elle permet aussi d’adopter de bonnes pratiques techniques dès le début du travail ce qui conduira finalement à un bon travail. En deuxième lieu, une évaluation unique aura un impact sur les membres de l’équipe pour une courte période tandis que si elle est faite de façon régulière, chaque membre pourra reconsidérer son travail et l’améliorer au fur et à mesure de l’avancement du travail d’équipe. Enfin, une évaluation basée sur des critères standards clairs permet d’avoir une rétroaction efficace et compréhensible par tous.
Figure 3.1 – Exemple d’outil d’évaluation par les pairs
Durant les rencontres, le membre I II III IV . . . participait toujours activement. 3 3 3 3 . . . participait quand on le sollicitait ; le reste du temps, il restait
silen-cieux, quoiqu’attentif.
2 2 2 2
. . . semblait distrait et peu intéressé, montrait des signes d’impatience ou d’ennui.
1 1 1 1
. . . n’était présent que de corps (style zombie). 0 0 0 0 En dehors des rencontres, le membre I II III IV . . . manifestait une grande disponibilité. 3 3 3 3 . . . était relativement disponible. 2 2 2 2
. . . était peu disponible. 1 1 1 1
. . . avait un degré de disponibilité si faible que le travail de l’équipe en était entravé.
0 0 0 0
Le membre I II III IV
. . . a souvent pris le leadership, motivait l’équipe et donnait des idées. 3 3 3 3 . . . a pris quelquefois le leadership. 2 2 2 2 . . . a rarement pris le leadership. 1 1 1 1
. . . s’est laissé porter par les autres membres de l’équipe. 0 0 0 0 Durant les rencontres, le membre I II III IV . . . était très centré sur la tâche, ce qui a aidé l’équipe à être efficace. 3 3 3 3 . . . était centré sur la tâche. 2 2 2 2 . . . était peu centré sur la tâche. 1 1 1 1 . . . était « déconnecté » et avait visiblement hâte que les rencontres se
terminent.
0 0 0 0
Le membre I II III IV
. . . était souriant, ouvert, spontané ; a beaucoup contribué à la bonne humeur au sein de l’équipe.
3 3 3 3
. . . contribuait à établir un climat de travail positif sans être le boute-en-train de l’équipe.
2 2 2 2
. . . était d’humeur plutôt maussade. 1 1 1 1 . . . nuisait au travail de l’équipe par ses remarques et agissements
désa-gréables.
0 0 0 0
Le membre I II III IV
. . . exprimait son point de vue avec calme et assurance et écoutait celui des autres attentivement.
3 3 3 3
. . . n’exprimait pas son point de vue mais écoutait celui des autres. 2 2 2 2 . . . exprimait son point de vue mais écoutait peu celui des autres. 1 1 1 1 . . . exprimait son point de vue avec agressivité et rejetait celui des autres. 0 0 0 0
Le membre I II III IV
. . . tentait toujours de trouver des compromis qui permettaient de rallier tous les points de vues exprimés.
3 3 3 3
. . . acceptait souvent de faire des compromis. 2 2 2 2 . . . acceptait rarement de faire des compromis. 1 1 1 1 . . . était fermé à tout compromis ; considérait que ses idées étaient les
meilleures et qu’il avait toujours raison.
0 0 0 0
Le membre I II III IV
. . . était toujours prêt à aider un autre membre de l’équipe ; offrait son aide et faisait preuve d’une très grande générosité.
3 3 3 3
. . . répondait quelquefois aux demandes d’aide de ses coéquipiers (ères). 2 2 2 2 . . . répondait rarement aux demandes d’aide de ses coéquipiers (ères). 1 1 1 1 . . . ne répondait jamais aux demandes d’aide de ses coéquipiers (ères). 0 0 0 0
Le membre I II III IV
. . . était prêt à assumer n’importe quelle responsabilité au sein de l’équipe.
. . . était prêt à s’acquitter de ses responsabilités, mais dans une certaine mesure seulement.
2 2 2 2
. . . a attendu que les tâches les plus exigeantes soient assumées par d’autres avant de se proposer.
1 1 1 1
. . . a attendu qu’on lui impose une tâche, qu’il n’a accepté que par obli-gation.
0 0 0 0
Le membre I II III IV
. . . arrivait bien préparé à chacune des rencontres, en vue d’apporter sa contribution à l’équipe ; j’estime que le travail de ce membre est d’une grande qualité.
3 3 3 3
. . . arrivait à chacune des rencontres avec un minimum de préparation ; j’estime que le travail de ce membre est d’une qualité moyenne.
2 2 2 2
. . . arrivait peu préparé à chacune des rencontres ; j’estime que le travail de ce membre est d’une qualité médiocre.
1 1 1 1
. . . arrivait à chacune des rencontres sans aucune préparation ; j’estime que ce membre s’est laissé porté par l’équipe.
0 0 0 0
Table 3.1 – Exemple d’outil d’évaluation par les paires
3.2.2 La technique « RepGrid »
Siau et al. [50] proposent d’utiliser la technique de RepGrid pour évaluer le travail d’équipe. Cette technique utilise une approche qualitative qui consiste en premier lieu à recruter des par-ticipants qui vont faire l’évaluation. En deuxième lieu, ces parpar-ticipants vont suggérer différents critères d’évaluation. Pour chaque critère d’évaluation, une phrase expliquant le contexte est donnée avec son opposé. Par exemple, lors de l’évaluation de la communication dans l’équipe, le participant va former deux types de description sur ce critère : une bonne capacité à com-muniquer vs peu d’aptitudes pour la communication. Le fait d’avoir deux types de description pour chaque critère permet de faciliter l’évaluation des personnes et de comprendre ce que l’on veut évaluer. En dernier lieu, des liens sont faits entre les critères d’évaluation et les per-sonnes qui seront évaluées. Au cours de cette étape, chaque participant retient les perper-sonnes avec lesquelles il a travaillé en équipe afin de pouvoir les évaluer. Par exemple, un participant pourra évaluer, par rapport à la communication, deux membres avec lesquels il a travaillé en équipe en les classant comme de bons communicateurs ou mauvais communicateurs.
Ainsi, en se basant sur une expérience faite avec 21 participants et sachant que ces derniers ont dressé une liste de toutes les caractéristiques qui devraient être considérées lors de l’évaluation d’un travail d’équipe, Siau et al. ont identifié 8 catégories. Il s’agit d’évaluer l’attitude, l’orien-tation vers le travail d’équipe, les connaissances, la personnalité, les capacités cognitives, les capacités de communication, les capacités de gestion et l’orientation vers le professionnalisme.
L’attitude et la personnalité sont évaluées afin de déterminer si une personne est capable de travailler dans une structure sociale. Les capacités cognitives permettent de voir comment les personnes sont capables de résoudre les problèmes. Vu que les développeurs travaillent en collaboration avec les clients pour lesquels ils font les développements de logiciels, ils doivent être professionnels dans leur travail d’où l’évaluation de l’orientation vers le professionnalisme. Ces développeurs doivent également non seulement avoir des connaissances techniques liées au développement des logiciels mais aussi ils doivent connaitre les règles d’affaire afin de sa-tisfaire les besoins commerciaux de leur client. L’évaluation des capacités de communication et de l’orientation vers le travail d’équipe est aussi importante car la plupart des projets de développement de logiciels se font en équipe.
3.2.3 La technique « Team Contribution System »
Farrell et al. [17] ont proposé un système nommé TCS2 comme une solution pour évaluer aussi bien la contribution de l’équipe que la contribution individuelle. Ce système propose, lors d’un travail d’équipe, de soumettre trois types de document dont le rapport de contribution, l’évaluation des paires et un compte rendu de toutes les rencontres d’équipe.
En premier lieu, dans le rapport de contribution, chaque membre de l’équipe doit préciser la durée de chacune de ses tâches pour réaliser le projet. En additionnant ces périodes de temps, le superviseur du projet peut avoir une idée approximative du temps que chaque membre de l’équipe a accordé au projet.
Une évaluation par les paires intervient en second lieu. Chaque membre est alors invité à évaluer les autres membres de l’équipe. Il s’agit plus précisément d’observer comment chacun interagit et coopère avec les autres membres de l’équipe. L’évaluation des paires doit aussi montrer la valeur ajoutée apportée au projet par chaque membre de l’équipe. Cependant, elle est plus subjective si on la compare à la contribution en termes de temps et de tâches qui peuvent être mesurées. Farrell et al. indiquent par ailleurs que si le rapport de contribution et l’évaluation des paires sont soumis au superviseur régulièrement, et ce dès le début du projet, ce dernier peut détecter rapidement les problèmes auxquels font face l’équipe et ainsi intervenir.
En dernier lieu, un compte rendu des rencontres d’équipe complète le processus. Les auteurs proposent que l’équipe devrait faire des rencontres hebdomadaires et que le compte rendu devrait être rendu accessible à tous les membres de l’équipe ainsi qu’au superviseur. Cela permet à tous d’être incité à participer, à discuter sur différents points du projet, à se partager les tâches et surtout à voir si chacun a atteint les objectifs qu’il s’est fixé. A partir de ce compte rendu, le superviseur a l’occasion de voir les membres qui participent au projet, de voir les présences et les absences lors des rencontres et d’avoir un moyen de voir si réellement chacun
réalise son travail.
3.2.4 Rémunération fictive
Herbert [26] propose une autre forme d’évaluation du travail d’équipe. Il s’agit d’inviter chaque membre à rémunérer, en termes d’argent virtuel, le travail que chaque coéquipier a produit. Par exemple, un membre va répartir 100$ fictifs entre ses coéquipiers selon la qualité et la quantité de travail effectué par chacun. Cette évaluation peut ainsi permettre de voir les membres qui ont plus travaillés sur le projet car ils seront plus rémunérés. Cependant les auteurs soulignent que ces évaluations sont subjectives et peuvent être biaisées. Par exemple, dans une équipe, on peut très bien trouver des sous-groupes internes qui peuvent s’évaluer mutuellement négativement en cas de mésentente.
Nous venons de voir qu’il existe plusieurs techniques que l’on peut utiliser pour évaluer le tra-vail d’équipe dont l’évaluation par les paires, la technique « RepGrid », la technique « TCS » et la rémunération fictive. Lors de l’évaluation par les paires, les étudiants développent leur esprit critique car ils sont appelés à évaluer leurs camarades. Elle permet aussi d’améliorer leur apprentissage et de réduire le problème du passager clandestin grâce au retour d’appré-ciation de leurs coéquipiers. Posséder de bonnes capacités cognitives, une bonne attitude, des connaissances dans plusieurs domaines et de bonnes aptitudes à communiquer ont été considé-rées par la technique « RepGrid » comme les caractéristiques clé qu’un membre d’une équipe devrait avoir dans un projet de développement de logiciel. La technique « TCS » permet quant à elle de vérifier l’honnêteté de chaque membre lors de l’évaluation de ses coéquipiers et de son évaluation personnelle. En effet, du côté des étudiants, elle permet à chacun de voir ses progrès et ceux des autres ainsi que les améliorations qui devraient être faites. Du côté des superviseurs, elle permet de voir la contribution faite par chaque membre de l’équipe, celle faite par l’ensemble des membres de l’équipe et ainsi d’avoir une vue globale sur le travail déjà effectué. La rémunération fictive quant à elle permet de voir le degré de contribution de chaque membre. En effet, si un membre reçoit la plus grande rémunération cela veut dire qu’il est le plus grand contributeur. Or pour pouvoir évaluer la contribution faite par chaque membre de l’équipe, il faut se baser sur des critères que nous allons voir dans la section suivante.
3.3
Les différents critères considérés comme une contribution
lors du travail d’équipe
Lors du travail de développement de logiciels en équipe ou individuel, il est important de mesurer la contribution de chaque développeur afin d’évaluer l’état d’avancement du travail ou la productivité. Cela permet aussi d’avoir une idée sur ceux qui contribuent le plus et leur domaine d’expertise. En effet, lors de l’analyse du travail, on peut trouver que certains contribuent plus lors de la définition de nouvelles méthodes tandis que d’autres sont plus intéressés à corriger les bogues. Plusieurs mesures de contribution sont proposées dans la littérature. Il s’agit d’étudier celles qui sont le plus souvent évoquées et d’identifier les plus pertinentes.
3.3.1 Différents critères de contribution et leurs limites
Le nombre de lignes de code ajoutées, modifiées ou supprimées est considéré par plusieurs auteurs comme une mesure de contribution [56,42,13,34,57,24]. Selon Nguyen et al. [43], c’est la mesure la plus utilisée dans l’industrie car elle permet d’estimer le coût de développement d’un logiciel donné. De plus, elle est facile à déterminer car le début et la fin de chaque ligne de code est visible et elle est indépendante du langage de programmation. Cependant, toutes les lignes de code écrites ne sont pas significatives ou ne contribuent pas au code. C’est le cas pour les lignes vides ou les commentaires. Aussi, Nguyen et al. [43] proposent de les omettre lorsqu’on compte les lignes de code.
Kalliamvakou et al. ou encore Lima et al. proposent quant à eux de les combiner avec d’autres mesures telles que le temps accordé à la communication et à la manipulation des outils de développement ou au nombre de fonctions ou encore au nombre de tâches complété par chaque membre de l’équipe lors de l’évaluation du travail d’équipe [24, 34]. Les différents systèmes de gestion de versions peuvent compter le nombre de lignes de code ajoutées, modifiées ou supprimées dans un code source. Le système le plus courant actuellement étant Git. Aussi, on peut citer des outils basés sur ce système tels que Gitinspector, Pepper, Gitstats ainsi que les commandes système.
Le nombre de commits peut aussi être utilisé comme une mesure de contribution [56,42,34,39,
41,24]. Selon Lawrance et al. [32], un commit est une manière de notifier qu’un changement a été apporté dans un fichier suivi par un système de gestion de versions. Cependant la définition d’un commit est propre à chaque système de gestion de versions. En effet, un commit fait sur CSV3 concerne une modification apportée dans un seul fichier tandis que pour Git, un commit peut faire objet de plusieurs modifications dans des fichiers différents. Un commit donne plusieurs informations sur la modification apportée telles que la date à laquelle la modification a été apportée, les fichiers pour lesquels on a apporté les modifications, l’auteur
de ces modifications, les lignes modifiées, . . . . Il existe aussi différentes raisons pour lesquelles un commit est fait. Nous pouvons citer entre autres l’ajout ou la modification d’un fichier, l’ajout d’un nouveau répertoire, l’ajout ou la modification d’un code qui corrige les bogues ou de celui qui fait des tests ou encore de celui qui définit des méthodes, des modules, des classes, . . . Cependant selon Lima et al. [34], la considération du nombre de commits a été mise en question comme un indicateur de contribution car ceux qui font plus de commits ne sont pas nécessairement ceux qui travaillent le plus. En effet, lors de la correction d’un bogue, on pourrait observer une situation où le développeur ferait un commit pour chaque tâche obtenant ainsi plusieurs crédits pour avoir fait plusieurs commits à la fin du travail par opposition à une situation où le développeur ferait un seul commit lorsque tout son code fonctionne correctement obtenant ainsi un seul crédit à la fin du travail. Dans les deux situations, il faut remarquer que les deux développeurs auront atteint les mêmes objectifs bien que le nombre de commits diffère. De plus, un commit avec une description vide est une mauvaise contribution car elle ne permet pas aux autres membres de l’équipe de comprendre la raison pour laquelle le commit a été fait. Aussi, les outils tels que Gitinspector, Pepper, Gitstats et les commandes Git permettent de facilement connaître le nombre de commits. Ceci pour chaque développeur.
Le nombre de « pull request »4 peut aussi être utilisé comme une mesure de contribution [56,39,41,57]. En effet, ils permettent aux développeurs de contribuer sur les dépôts dont ils sont ou ne sont pas auteurs. Dans le premier cas où le développeur fait partie des auteurs du dépôt, un « pull request » notifie à un ou plusieurs mainteneur(s)5[62] qu’une contribution a été proposée pour être revisée. Il faut noter que c’est une manière de s’organiser sous Git où les développeurs préfèrent travailler sur leur propre branche6plutôt que sur la branche principale.
Ainsi, si la contribution proposée lors du « pull request » est pertinente et ne contient pas de bogues, elle est intégrée dans la branche principale par le(s) mainteneur(s) [2]. Dans l’autre cas où le développeur veut contribuer dans un dépôt Git dont il n’est pas auteur, les outils de gestion des dépôts Git tels que ceux disponibles avec Github, Bitbucket et Gitlab donnent la possibilité de faire un « fork »7. Le développeur fait ainsi un « fork » pour pouvoir le cloner en local où il peut apporter toutes les modifications jugées pertinentes. Pour éviter la gestion de conflits, il est conseillé de travailler en local sur une autre branche que celle principale. Une fois la branche prête, elle est poussée sur le fork et à partir de ce dernier, l’auteur envoie un « pull request » au dépôt original. Il s’agit de notifier aux mainteneur(s) du dépôt original que des modifications ont été apportées sur un ou plusieurs des fichiers de leur dépôt. Comme dit précédémment, les mainteneurs vont réviser les modifications apportées et les intégrer dans leur dépôt si elles sont pertinentes [19]. En peu de mots, le « pull request » permet à celui
4. C’est l’action de soumettre sa contribution à un projet Git
5. Personne chargé de faire évoluer le logiciel, de corriger les bogues, d’accepter les correctifs proposés par d’autres contributeurs
6. Dans les systèmes de gestion de versions, créer une branche signifie diverger de la ligne principale de développement et continuer à travailler sans se préoccuper de cette ligne principale.
qui le fait d’avoir une révision et un retour de sa contribution avant que cette dernière soit intégrée dans la branche principale. Les outils tels que Gitlab, Github et Bitbucket peuvent mesurer le nombre de « pull request ».
La participation au forum est aussi une autre mesure de contribution proposée par [39, 41,
57,24]. En plus des lignes de code, selon [24], le temps accordé à la communication devrait être considéré comme une forme de contribution. En effet, la coordination des différentes activités d’un projet de développement requiert une bonne communication entre les membres de l’équipe [56]. La communication est la clé du succès du travail de développement. Elle permet en l’occurrence de connaître les bloquants, de donner des suggestions, de savoir ce que les autres ont déjà produit et ainsi d’avoir une idée générale sur l’état d’avancement du projet [56].
Le fait de reporter un bogue ou de le corriger peut aussi être une autre mesure de contribution [42, 34, 24]. Il faut remarquer que le report d’un bogue se fait souvent à travers un moyen de communication tel que les courriels ou les échanges dans les forums de discussion tandis que la correction du bogue se fera plus à travers un commit qui va indiquer les changements apportés (dans le cas où l’équipe utilise un système de gestion de versions comme moyen de partage de fichiers). En effet, comme la correction des bogues se trouvent dans les commits, il s’agira de vérifier toutes les descriptions de commit qui l’indique.
Les tests sont aussi une autre mesure de contribution [56, 42, 57]. Selon Tsay et al. [57], si un « pull request » comporte des tests cela signifie que celui qui contribue est rigoureux dans son travail, ce qui est généralement apprécié par les évaluateurs. Ainsi les contributions incluant des tests ont plus de chances d’être acceptées. Un moyen pour le vérifier consiste à rechercher si parmi les fichiers proposés dans le « pull request », certains comportent le mot « test ». En effet, comme les tests se trouvent dans les fichiers modifés, il s’agit d’aller vérifier les descriptions des commits indiquant qu’un test a été fait.
Enfin, nous pouvons distinguer deux types de classement pour les critères que nous venons d’énoncer : ceux qui ont un rapport avec le code et ceux qui ont un rapport avec l’organisation du travail. Il faut remarquer qu’à l’intérieur du code, certains critères mesurent plus la quantité de travail effectuée tel que le nombre de lignes de code tandis que d’autres mesurent plus la qualité du code tel que les tests. Ainsi, le classement de ces différents critères peut être celui présenté dans la Table 3.2.
Code Organisation du travail
Quantité Qualité Tâches
Commits Tests Story points8(agilité) Fonctionnalités ou méthodes Commentaires Stories9(agilité) Lignes de code Versions Estimés
Pull request Revues de code Buts
Modules Bogues Perspectives
Classes Documentation Echéances
Forks Heures de travail
Fichiers Cas d’utilisation
Activités Projets
Participation au forum Wiki
Table 3.2 – Classement des critères pouvant être utilisé comme mesure de contribution
3.3.2 Critères retenus
Parmi les critères de contribution, ceux que nous avons retenus comme étant les plus intéres-sants pour l’évaluation du travail d’équipe sont :
1. Commits :
Ils donnent plusieurs informations sur les modifications apportées par chaque membre de l’équipe telles que la date à laquelle le changement a été apporté, les fichiers pour lesquels on a apporté les modifications, l’auteur de ces modifications, les lignes pour lesquelles on a apporté du changement, . . .
2. Fonctionnalités ou méthodes, modules et classes :
Ils permettent à l’évaluateur de plus facilement remarquer qui, parmi les membres tra-vaille sur les tâches les plus complexes.
3. Les lignes de codes :
Elles permettent de voir les membres qui contribuent plus ou moins au projet. 4. Le nombre de fichiers :
Il est un bon indicateur de contribution individuelle mais il devrait être accompagné par d’autres critères comme par exemple le nombre de commits. En effet, un membre peut travailler sur un seul fichier durant tout le long du projet et contribuer au même degré que celui qui a créé plusieurs fichiers. En effet, cela dépend des tâches assignées à chacun.
8. Les Story Points sont une mesure relative basée sur la perception, par l’équipe projet, de la taille du travail à réaliser. La détermination de cette taille est basée sur un niveau de compréhension de la complexité et donc de l’effort nécessaire à la réalisation.
9. Technique permettant de formaliser synthétiquement les besoins sans perdre de vue l’essentiel : le besoin concerne QUI, en QUOI il consiste et dans quel BUT.
5. Les « story points » :
Ils peuvent indiquer la complexité des tâches à effectuer et ainsi voir ceux qui ont choisi de travailler sur des tâches plus complexes.
6. Les « pull requests » :
Ils permettent de voir les modifications qui ont été proposées par les membres de l’équipe et leur degré de participation.
7. La participation au forum :
Elle permet de remarquer les membres qui communiquent le plus dans l’équipe ou qui prennent le temps de donner des explications ou des directives aux autres.
Aussi, après avoir proposé les critères les plus pertinents lors de l’évaluation du travail, nous devons rappeler que les lignes de code peuvent être comptabilisées de nombreuses façons, offrant des informations diversifiées sur les contributions apportées lors du travail d’équipe. C’est pourquoi nous proposons de les étudier en détails dans la section suivante.
3.3.3 Lignes de code source
3.3.3.1 Définition
« Une ligne de code, ou ligne de code source (SLOC10 en anglais) est une métrique logicielle servant à mesurer la taille d’un programme informatique en dénombrant le nombre de lignes de son code source. Les lignes de code sont habituellement employées pour quantifier l’effort qui sera exigé pour développer un programme informatique, ainsi que pour estimer la valeur d’un logiciel produit. » [59].
3.3.3.2 Les variantes du SLOC et leurs limites
Toutes les lignes d’un code source ne correspondent pas au même degré de contribution. Aussi, il existe plusieurs variantes du SLOC et seulement certaines d’entre elles peuvent être considérées comme une mesure de contribution lors d’un travail en équipe de développement de logiciels :
— Les lignes physiques :
Elles sont définies par Bhatt et al. [5] comme étant les lignes de code qui composent un programme incluant les commentaires. Lors d’un travail en équipe, le nombre de lignes de code par auteur est un bon indicateur de contribution et d’évaluation. Cependant les commentaires vides constituent un biais car ils ne devraient pas être comptabilisés comme une contribution. Différents outils tels que Gitstats, Pepper, Gitinspector, Un-derstand, JHawk, AOPMetrics et Analizo peuvent mesurer les lignes physiques qui se trouvent dans un code source.
