Git pour l’évaluation et le suivi du travail collaboratiffavorisant le développement des compétences

transversales

Mémoire

Mélissa Clarisse Ntirandekura

Maîtrise en InformatiqueMaître ès sciences (M. Sc.)

Québec, Canada

© Mélissa Clarisse Ntirandekura, 2018

Git pour l’évaluation et le suivi du travail collaboratiffavorisant le développement des compétences

transversales

Mémoire

Mélissa Clarisse Ntirandekura

Sous la direction de:

Thierry Eude, directeur de recherche

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’uneformation 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 outilsfacilitant le travail collaboratif, l’organisation, la collaboration et la gestion des conflits. Lapossibilité 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 peuten 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ésdans l’industrie et permet d’en tirer de nombreux avantages autant pour les étudiants quepour les enseignants, sans oublier les possibilités de minimisation des coûts reliés au matérieldidactique. Aussi, l’utilisation de Git dans le cadre de travaux d’équipe, donne accès à toutel’information relative aux activités qui sont consignées dans son historique. En effet touteaction est associée à son auteur, à la date à laquelle elle a été effectuée. En disposant de cesdonnées, il s’agit alors de définir les critères à appliquer pour faire une analyse et établir unjugement. Nous proposons dans ce mémoire un inventaire des critères d’évaluation potentielset identifions les plus pertinents en termes d’évaluation de la régularité et de contributionquantitative en tenant compte des biais qu’ils peuvent induire. Aussi, une des difficultés quepeuvent rencontrer les enseignants au moment de produire une évaluation est non seulementde 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 desupport basé sur les critères que nous avons identifiés offrant un aperçu général et facilitantl’accès aux détails. Son évaluation dans le cadre d’un cours nous a permis d’identifier différentsprofils d’équipe ainsi que les limites d’utilisation d’un tel outil pour établir un jugement.

iii

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 programming courses depends on the choice of tools that facilitates collaborative work,organization and conflict management. Objectively evaluating both the individual and thecollaborative work must be a great part of this choice. Among these tools, we propose toretain 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 minimizationof cost of educational materials. Also, Git facilitates teamwork’s evaluation by giving accessto information recorded in its history. It then becomes necessary to define the criteria to beapplied to make an analysis and a judgment. We propose in this thesis an inventory of thepotential evaluation criteria and identify the most relevant ones in terms of evaluation of theregularity and quantitative contribution considering the biases that they induce. Moreover,one of the difficulties that teachers may encounter when producing an assessment is not onlyto evaluate contributions, but also to be able to monitor them regularly, especially when teamsare numerous. We then recommend a support tool based on the criteria we identified, offeringa general overview and facilitating access to details. Its evaluation as part of a course allowedus to identify different team profiles as well as the limits to use of such a tool to make ajudgment.

iv

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 11.1 Contexte et motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Objectif et méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Le travail d’équipe comme moyen de développer les compétences trans-versales 42.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Les compétences transversales et l’enseignement . . . . . . . . . . . . . . . . 52.3 Évaluation des compétences transversales dans l’enseignement . . . . . . . . 72.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Évaluation de la contribution individuelle au travail d’équipe 123.1 Définition de l’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Différentes techniques d’évaluation du travail d’équipe . . . . . . . . . . . . 133.3 Les différents critères considérés comme une contribution lors du travail

d’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Git comme outil de support du travail d’équipe 294.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Présentation de Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Utilisation de Git dans l’enseignement . . . . . . . . . . . . . . . . . . . . . 304.4 Git et l’évaluation de la contribution individuelle au travail d’équipe . . . . 344.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

v

5 Un outil pour l’évaluation objective du travail d’équipe 465.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2 Définition et objectif général . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.3 Les outils utilisés par Gitanalysis . . . . . . . . . . . . . . . . . . . . . . . . 475.4 Les critères considérés comme une contribution par Gitanalysis . . . . . . . 485.5 Fonctionnalités de Gitanalysis . . . . . . . . . . . . . . . . . . . . . . . . . . 485.6 Résultats et analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.7 Limites de Gitanalysis et recommandations . . . . . . . . . . . . . . . . . . 655.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Conclusion 70

Bibliographie 73

vi

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 . . . . . . . . . . . . . . . . . . . . . 163.2 Classement des critères pouvant être utilisé comme mesure de contribution . . . 22

vii

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 labranche 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 . . . . . . . . . 374.5 Résultat de la commande git pour illustrer les dates des 5 derniers commits . . 374.6 Contribution en termes de pourcentage des commits de chaque auteur sur la

branche principale master (générée par Pepper) . . . . . . . . . . . . . . . . . . 384.7 Le nombre de commits contribués par auteur et par période en termes de pour-

centages (générée par Pepper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.8 Contribution en termes de commits et de LOC (Lines of code) de chaque auteur

(générée par Gitstats) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.9 Contribution en termes de commits et de LOC de chaque auteur (générée par

Gitinspector) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.10 Résultat de la commande git pour illustrer le nombre de commits par auteur . 404.11 LOC accumulées au fil du temps par chaque auteur (générée par Gitstats) . . . 414.12 LOC accumulées au fil du temps par chaque auteur (générée par Pepper) . . . 414.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 . . . . . . . 424.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 surles fichiers java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Choix de Gitanalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3 Exemple de contribution quantitative d’un membre de l’équipe pour environ 4

mois sur les fichiers java par Gitanalysis . . . . . . . . . . . . . . . . . . . . . . 515.4 Exemple de contribution quantitative d’une équipe pour environ 4 mois sur les

fichiers java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.5 Evalation du membre de l’équipe sur la régularité par Gitanalysis . . . . . . . . 535.6 Suivi d’un membre régulier sur des périodes différentes par Gitanalysis . . . . . 53

viii

5.7 Suivi d’un membre moins régulier sur des périodes différentes par Gitanalysis . 545.8 Suivi d’un membre irrégulier sur des périodes différentes par Gitanalysis . . . . 555.9 Évaluation des combinaisons possibles des équipes formées de 4 et de 3 membres 585.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) . . . . . . . . . 595.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) . . . . . . . . . 605.12 Activité d’une équipe fonctionnelle composée des membres actifs et à surveiller

(extrait du tableau de bord généré par Gitanalysis) . . . . . . . . . . . . . . . . 605.13 Activité d’une équipe passagèrement dysfonctionnelle composée des membres à

surveiller (extrait du tableau de bord généré par Gitanalysis) . . . . . . . . . . 615.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 dutableau 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éepar Pepper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.20 Evaluation de l’équipe avant les examens intra par Gitanalysis . . . . . . . . . . 675.21 Evaluation de l’équipe durant les examens intra par Gitanalysis . . . . . . . . . 68

ix

À mes parents, mes soeurs, mesfrères et à François pour votre

amour et votre soutienpermanent, je dédie ce mémoire.

x

L’informatique, ça fait gagnerbeaucoup de temps... à conditiond’en avoir beaucoup devant soi !

Mireille Sitbon

xi

Remerciements

Le présent mémoire a été possible grâce au soutien, à la collaboration et à la contribution deplusieurs personnes à qui je voudrais témoigner toute ma reconnaissance.

En premier lieu, je voudrais adresser toute ma gratitude à mon directeur de recherche, leprofesseur Thierry Eude, pour son encadrement, ses judicieux conseils, sa disponibilité, sapatience 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 JeanBouchard, 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 permisd’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 Lemayqui ont toujours été là pour moi.

Enfin, je voudrais exprimer ma reconnaissance envers les amis, les professeurs, les collègues etla famille qui m’ont apporté leur support moral et intellectuel tout au long de ma démarche.

xii

Chapitre 1

Introduction

1.1 Contexte et motivation

De nos jours, dans le monde professionnel, le développement des compétences transversales estprimordial, ceci pour augmenter ses chances d’être embauché, mais également pour maintenirune employabilité durable. Aussi, au cours d’une formation académique, le travail en équipeest l’une des meilleures façons d’acquérir et de consolider les compétences transversales. Eneffet, lors du travail en équipe, l’étudiant a l’occasion de développer différentes compétencestransversales telles que la communication, l’analyse, le jugement critique, la collaboration,l’autonomie, la prise de responsabilité, le leadership, . . . recherchées par les employeurs. Ilfaut aussi noter que dans le domaine de l’informatique, le développement d’un projet se faitsouvent 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 facilitantle travail collaboratif, de l’organisation des coéquipiers, de leur collaboration et de leur gestiondes conflits [14]. De plus, il est important de pouvoir évaluer objectivement aussi bien le travailindividuel 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 outilsde travail collaboratif en informatique et en génie logiciel apparaissent indispensables et sontproposé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 demandede choisir de bons outils de collaboration qui permettent de recueillir les mesures objectivesqui serviront ainsi lors de l’évaluation. Lanubile et al. ont proposé l’utilisation de plusieursoutils pour faciliter le travail d’équipe [31]. Il s’agit notamment des systèmes de gestion deversion, des outils de communication, des applications web, . . . Ainsi, l’une des difficultés est

1

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 pourquantifier les contributions lors du travail d’équipe. En effet, on trouve dans la littératurediffé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 objectivedu travail d’équipe. Ainsi, au cours de l’évaluation objective, on cherche alors à répondre auxquestions 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 sansque l’un de ses membres n’ait besoin de le notifier, ce qui est un obstacle en soit, puisqu’engé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 objectiffinal est alors de permettre d’évaluer objectivement aussi bien les contributions individuellesque 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 lorsdu travail d’équipe

— proposer un système de gestion de versions distribué comme outil de support du travaild’équipe

— développer une application web qui récupérerait automatiquement les données stockéesdans les dépôts partagés et faciliterait l’évaluation objective et le suivi du travail d’équipe

— analyser les résultats obtenus

— proposer des perspectives à ce travail de recherche.

2

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 letravail 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 ainsiqu’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 lesavantages de son utilisation dans l’enseignement. Nous terminons par une présentation de Gitcomme un outil d’évaluation du travail d’équipe.

Dans le chapitre 5, nous introduisons l’outil que nous avons développé : Gitanalysis. Nouscommenç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 etla détermination de l’indicateur d’activité de l’équipe sont présentées comme les différentesfonctionnalités offertes par Gitanalysis. A la fin du chapitre, nous faisons une analyse desrésultats obtenus lors de l’évaluation des équipes. Les biais potentiels sur l’évaluation sontalors é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.

3

Chapitre 2

Le travail d’équipe comme moyen dedévelopper les compétencestransversales

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étencesspé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 appuisur 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 évoluerapidement et le chômage est présent, nous pouvons ainsi noter l’importance d’introduire lescompétences transversales dans l’éducation. En effet, Finot [18] a montré que les employeursrechercheraient plus les compétences transversales que les compétences techniques du fait queces dernières sont souvent spécifiques à un domaine particulier par opposition aux compétencestransversales qui sont applicables et réutilisables dans plusieurs domaines. De plus, Gonzàlezet al. [23] considèrent que les compétences transversales sont indispensables dans la formationacadémique des étudiants afin de les préparer à « leur rôle futur dans la société en termesd’employabilité et de citoyenneté ».

Parmi les compétences transversales qu’un étudiant devrait posséder à la fin de sa formationacadémique, nous pouvons retenir celles proposées par Laliberté [30]. Il s’agit notammentd’être capable de communiquer oralement ou par écrit de manière efficace, d’être capable

4

d’analyser et de résoudre les problèmes, d’avoir un esprit de coopération, d’avoir un espritcritique, d’être capable de prendre des décisions, d’être capable de comprendre la relation quel’homme entretient avec l’environnement et d’être capable de comprendre le monde actuel avectous 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 « lagestion 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 deleur cours. En effet, à la fin de la formation académique, les étudiants devraient être capablesde bien communiquer, de travailler en équipe, d’avoir un esprit de jugement, d’analyse et deré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 SWEBOK 1.

2.2.1 L’approche « Active learning »

Yanaze et al. [63] proposent de commencer par connaître les compétences transversales lesplus recherchées sur le marché du travail avant de proposer une méthode pour les développerchez l’étudiant. Après avoir étudiés différentes offres d’emplois publiées sur le site de IEEE 2

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écifiaientd’être un leader du groupe.

— La facilité d’adaptation dans différents domaines et disciplines était demandée par23,72% des emplois.

— La capacité d’analyser et de résoudre des problèmes étaient demandée par 21,92% desemplois.

Le fait d’avoir identifié la communication comme la compétence la plus recherchée dans laplupart des emplois, montre que cette compétence est essentielle chez les ingénieurs.

1. Software Engineering Body of Knowledge2. Institute of Electrical and Electronics Engineers

5

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’« activelearning » 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 jeuxen 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 sujetde 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étencestransversales spécifiquement dans le cadre de cours en génie logiciel. Aussi, Sicilia [51] proposeune 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’abordde 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 quipeuvent ê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écifiquereste valide. C’est dans ce contexte que l’auteur soutient que les compétences transversalesdevraient être développées dans le cadre d’un cours spécifique rendant ainsi ces compétencesplus 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 deré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ù lesrelations interpersonnelles et sociales sont plus importantes chez les étudiants et après que cesderniers aient eu une base en programmation. Ainsi évaluer si l’étudiant travaille en équipeconsisterait à évaluer son comportement, son sens de responsabilité et son attitude positiveface aux autres membres de l’équipe. En peu de mots, il s’agirait d’évaluer comment l’étudiantinteragit avec les autres membres de l’équipe.

6

Au cours de cette section, nous venons de voir que l’approche « Active learning » et l’approchebasée sur le corpus SWEBOK sont les deux approches que nous pouvons retenir comme moyend’introduire les compétences transversales dans l’enseignement. Ils permettent chez l’étudiantde développer l’esprit de coopération, d’analyse, de critique, . . . Cependant, il faut noter qu’ilne suffit pas d’introduire ces compétences transversales dans l’enseignement mais qu’il fautaussi pouvoir les évaluer.

2.3 Évaluation des compétences transversales dansl’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 étudianta un jugement critique, le professeur va souvent regarder comment l’étudiant réagit dans unesituation 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èseou une évaluation est une bonne façon d’évaluer les compétences transversales. Il s’agit entreautres de donner aux étudiants des exercices exigeants des réponses à développement, desré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éecritique, le travail en équipe, l’innovation et l’entrepreneuriat. Pour commencer avec la penséecritique, 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éterdes situations réelles. En effet, l’étudiant peut utiliser une vidéo, une page web, un blog ou unforum de discussion pour essayer de trouver les articles qui ont traités le même problème et ainsichoisir parmi les différentes sources la meilleure solution. A travers cet exercice, il faut noterque les compétences telles que la recherche d’information, l’analyse, la critique, la synthèse etl’é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. Celapeut se faire de différentes manières soit en classe soit à travers des plateformes de discussionspermettant à l’étudiant de développer d’autres compétences telles que la collaboration et lacommunication 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 outilde collaboration pour partager leur solution. Il faut noter que bien que le travail en équipefavorise 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

7

recherche personnelle afin de dégager les points pertinents qui devraient être mentionnés lorsde 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 depoints 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 opinionsdiffé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 capabled’organiser son équipe, de répartir les tâches entre les membres de l’équipe et d’encouragerchacun de finir les tâches qui lui ont été attribuées. Il doit aussi s’assurer que le travail finalsoit 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èreannée académique. Il s’agit de la communication orale et écrite dans une langue étrangèrecomme 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 maternelleet la capacité interpersonnelle. Ainsi lors de l’évaluation de la communication orale et écritedans 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 ledocument, d’une bonne organisation et compréhension des idées présentées par l’étudiant. Enpeu de mots, il s’agit de regarder le fond et la forme du document. Être capable d’expliqueret de défendre clairement ses idées en choisissant les mots appropriés est une façon d’évaluerla communication orale dans la langue maternelle. Et pour les capacités interpersonnelles, lesuperviseur 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étencesqui a été cité par plusieurs auteurs [51, 63, 30, 54, 47, 49]. En effet, elle peut être considéréecomme une super compétence transversale car elle englobe d’autres compétences telles que lacommunication, 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èrementafin de faire avancer leur travail. Ils sont aussi appelés à résoudre les problèmes au sein del’équipe afin de gérer les conflits et à avoir un esprit critique afin de fournir un travail dequalité. C’est pour ces raisons que nous l’avons retenu comme le moyen de développer lescompétences transversales dans notre travail de recherche. Nous le décrivons plus en détailsdans ce qui suit.

8

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 parles employeurs que par les organismes d’accréditation. En effet, la plupart des projets dedé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 communiquaientpas toujours correctement et étaient inexpérimentés à travailler en équipe. Une des raisons decette inexpérience est que la plupart des programmes de formation académique favorise plus letravail individuel que le travail d’équipe [36]. C’est pourquoi, une bonne communication oraleet écrite, une capacité d’analyse et surtout une capacité d’interaction avec les autres sont lesclé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 cadred’un cours. Ainsi, le premier avantage qu’il en est ressorti était que le travail d’équipe avaitpermis aux étudiants de mieux comprendre leur cours car ils pouvaient mettre en pratique cequ’ils avaient appris. L’évaluation des paires était le second avantage. En effet, le fait d’avoirun retour d’appréciation de la part de ses collègues permettait à l’étudiant d’améliorer laqualité 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 pourréaliser un projet en équipe que pour réaliser un projet individuellement. Les mêmes proposavaient été recueillis auprès des enseignants qui dirigeaient les équipes. En effet, selon lesenseignants, 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 pensern’est pas toujours facile et entraîne souvent des conflits entre les membres de l’équipe quidoivent à leur tour être gérés.

9

Capacité à s’intégrer facilementCapacité à comprendre les autresCapacité à respecter les idées et l’attitude d’autruiCapacité à écouter les autresCapacité à travailler avec les autres et dans la diversitéCapacité à s’engager pour réaliser le projet de groupeCapacité à s’adapter aux changements d’horaireCapacité à être flexible lors du partage des tâchesCapacité à proposer de nouvelles idées en tenant compte de celles proposées par d’autresCapacité à remettre les travaux à tempsCapacité à offrir du support aux autresCapacité à motiver ses coéquipiersCapacité à assumer ses responsabilités en cas d’erreursCapacité à trouver les liens qui se trouvent entre les disciplinesCapacité à aborder les problèmes de différentes manièresCapacité à apprécier le travail, les idées et le savoir des autresCapacité à vouloir apprendre de nouvelles chosesCapacité à proposer de bons alternativesCapacité à comprendre les différentes sources d’information et à pouvoir les expliquer auxautresCapacité à planifier, à suivre l’exécution et à évaluer un projetCapacité à 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 departager leur travail

— planifier le projet et faire son suivi

— participer activement (cela concerne chaque membre de l’équipe)

— rédiger des rapports concis

— récompenser l’équipe

10

— ê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évelopperdurant leur formation académique afin d’augmenter leur chance de trouver un emploi à la fin deleurs études. C’est aussi une compétence qui permet de développer bien d’autres compétencestransversales telles que l’analyse, la communication, le jugement critique, . . . Vu les qualitésque l’on peut développer en travaillant en équipe, on pourrait facilement dire que le travaild’équipe est un des moyens de développer les compétences transversales. Cependant, il fautnoter que l’évaluation de la contribution individuelle et celle de l’équipe est importante etn’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 transversalesqui ont été proposées dans la littérature. Celle que nous pouvons retenir et qui est communeaux différentes définitions est que les compétences transversales ne sont pas spécifiques à undomaine 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’introductiondes compétences transversales dans l’enseignement. Il s’agit notamment de l’approche « Activelearning » où l’étudiant est placé au centre du processus d’apprentissage et l’approche baséesur le corpus SWEBOK où l’enseignant est invité à définir les compétences transversales quiseront 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 meilleuresmé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 techniqueset critères qui peuvent être considérés comme une contribution lors du travail d’équipe. C’estce que nous proposons d’étudier dans le chapitre qui suit.

11

Chapitre 3

Évaluation de la contributionindividuelle 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, émettreun constat sur une situation, et prendre des décisions, au regard des objectifs de départet 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 lacontribution apportée par chaque membre de l’équipe afin de déterminer les membres quitravaillent 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 étaperéside dans le recueil systématique, valide et fidèle d’informations appropriées aux objectifsd’enseignement. C’est la phase d’observation et/ou de recueil de données. La deuxième étapeconsiste à 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 prisede 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 évaluationobjective ou des mesures subjectives donnant lieu à une évaluation subjective. Par mesureobjective, 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(commits 1) [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, demettre à disposition les modifications apportées à un document et, d’autre part, d’insérer de façon cohérenteces modifications dans l’historique des modifications.

12

non exactes. Elles proviennent souvent d’une estimation faite par l’évaluateur. Une évaluationsur la complexité du code ou de l’expérience des développeurs sont des exemples de mesuresubjective [3].Selon Treude et al. [56], une mesure objective est celle qui peut être mesurée automatiquementpar des outils. Il s’agit entre autres du nombre de lignes de code, de tâches, de commits, . . . Parcontre, pour une mesure subjective, dans le cas d’une même activité, différents évaluateurs vontdonner différentes évaluations donc différentes opinions. Les exemples cités sont l’évaluationde 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 laproductivité, . . . Nous pouvons aussi voir que les évaluations se font à partir des mesuresqui peuvent être objectives ou subjectives selon qu’elles sont faites par des outils ou par desindividus. 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 desautres é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’« activelearning » (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.1et évalue, par la suite, chaque coéquipier en se basant sur les différents critères proposés dansla Table 3.1.

Lors d’un travail en équipe, l’évaluation par les paires est également proposée par Brooks etal. [7] comme un moyen de réduire le problème du passager clandestin lorsque elle faite dèsle 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 ausein de l’équipe et de fixer une stratégie pour améliorer son travail. Elle permet aussi d’adopterde bonnes pratiques techniques dès le début du travail ce qui conduira finalement à un bontravail. En deuxième lieu, une évaluation unique aura un impact sur les membres de l’équipepour une courte période tandis que si elle est faite de façon régulière, chaque membre pourrareconsidé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étroactionefficace et compréhensible par tous.

13

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 oud’ennui.

1 1 1 1

. . . n’était présent que de corps (style zombie). 0 0 0 0En 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

14

. . . s’est laissé porter par les autres membres de l’équipe. 0 0 0 0Durant 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 seterminent.

0 0 0 0

Le membre I II III IV. . . était souriant, ouvert, spontané ; a beaucoup contribué à la bonnehumeur 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 celuides 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 0Le membre I II III IV. . . tentait toujours de trouver des compromis qui permettaient de ralliertous 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 lesmeilleures 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 sonaide 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 0Le membre I II III IV. . . était prêt à assumer n’importe quelle responsabilité au sein del’équipe.

3 3 3 3

15

. . . était prêt à s’acquitter de ses responsabilités, mais dans une certainemesure seulement.

2 2 2 2

. . . a attendu que les tâches les plus exigeantes soient assumées pard’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 sacontribution à l’équipe ; j’estime que le travail de ce membre est d’unegrande 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 travailde ce membre est d’une qualité médiocre.

1 1 1 1

. . . arrivait à chacune des rencontres sans aucune préparation ; j’estimeque 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 participants vont suggérer différentscritères d’évaluation. Pour chaque critère d’évaluation, une phrase expliquant le contexte estdonné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 descriptionpour chaque critère permet de faciliter l’évaluation des personnes et de comprendre ce quel’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 personnesavec lesquelles il a travaillé en équipe afin de pouvoir les évaluer. Par exemple, un participantpourra é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 ontdressé une liste de toutes les caractéristiques qui devraient être considérées lors de l’évaluationd’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, lescapacités de communication, les capacités de gestion et l’orientation vers le professionnalisme.

16

L’attitude et la personnalité sont évaluées afin de déterminer si une personne est capable detravailler dans une structure sociale. Les capacités cognitives permettent de voir commentles personnes sont capables de résoudre les problèmes. Vu que les développeurs travaillent encollaboration 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éesau 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 communicationet de l’orientation vers le travail d’équipe est aussi importante car la plupart des projets dedé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é TCS 2 comme une solution pour évalueraussi bien la contribution de l’équipe que la contribution individuelle. Ce système propose, lorsd’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 laduré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 del’é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 chacuninteragit et coopère avec les autres membres de l’équipe. L’évaluation des paires doit aussimontrer la valeur ajoutée apportée au projet par chaque membre de l’équipe. Cependant, elleest plus subjective si on la compare à la contribution en termes de temps et de tâches quipeuvent être mesurées. Farrell et al. indiquent par ailleurs que si le rapport de contributionet l’évaluation des paires sont soumis au superviseur régulièrement, et ce dès le début duprojet, ce dernier peut détecter rapidement les problèmes auxquels font face l’équipe et ainsiintervenir.

En dernier lieu, un compte rendu des rencontres d’équipe complète le processus. Les auteursproposent que l’équipe devrait faire des rencontres hebdomadaires et que le compte rendudevrait être rendu accessible à tous les membres de l’équipe ainsi qu’au superviseur. Celapermet à tous d’être incité à participer, à discuter sur différents points du projet, à se partagerles tâches et surtout à voir si chacun a atteint les objectifs qu’il s’est fixé. A partir de ce compterendu, le superviseur a l’occasion de voir les membres qui participent au projet, de voir lesprésences et les absences lors des rencontres et d’avoir un moyen de voir si réellement chacun

2. Team Contribution System

17

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 chaquemembre à 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 laquantité de travail effectué par chacun. Cette évaluation peut ainsi permettre de voir lesmembres qui ont plus travaillés sur le projet car ils seront plus rémunérés. Cependant lesauteurs 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’évaluermutuellement 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 leuresprit critique car ils sont appelés à évaluer leurs camarades. Elle permet aussi d’améliorerleur 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, desconnaissances 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 équipedevrait 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 deson évaluation personnelle. En effet, du côté des étudiants, elle permet à chacun de voir sesprogrès et ceux des autres ainsi que les améliorations qui devraient être faites. Du côté dessuperviseurs, elle permet de voir la contribution faite par chaque membre de l’équipe, cellefaite 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 chaquemembre. En effet, si un membre reçoit la plus grande rémunération cela veut dire qu’il est leplus grand contributeur. Or pour pouvoir évaluer la contribution faite par chaque membre del’équipe, il faut se baser sur des critères que nous allons voir dans la section suivante.

18

3.3 Les différents critères considérés comme une contributionlors du travail d’équipe

Lors du travail de développement de logiciels en équipe ou individuel, il est important demesurer la contribution de chaque développeur afin d’évaluer l’état d’avancement du travailou la productivité. Cela permet aussi d’avoir une idée sur ceux qui contribuent le plus etleur domaine d’expertise. En effet, lors de l’analyse du travail, on peut trouver que certainscontribuent plus lors de la définition de nouvelles méthodes tandis que d’autres sont plusintéressés à corriger les bogues. Plusieurs mesures de contribution sont proposées dans lalittérature. Il s’agit d’étudier celles qui sont le plus souvent évoquées et d’identifier les pluspertinentes.

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 plusieursauteurs comme une mesure de contribution [56, 42, 13, 34, 57, 24]. Selon Nguyen et al. [43], c’estla mesure la plus utilisée dans l’industrie car elle permet d’estimer le coût de développementd’un logiciel donné. De plus, elle est facile à déterminer car le début et la fin de chaque lignede code est visible et elle est indépendante du langage de programmation. Cependant, toutesles lignes de code écrites ne sont pas significatives ou ne contribuent pas au code. C’est le caspour les lignes vides ou les commentaires. Aussi, Nguyen et al. [43] proposent de les omettrelorsqu’on compte les lignes de code.Kalliamvakou et al. ou encore Lima et al. proposent quant à eux de les combiner avec d’autresmesures telles que le temps accordé à la communication et à la manipulation des outils dedéveloppement ou au nombre de fonctions ou encore au nombre de tâches complété par chaquemembre de l’équipe lors de l’évaluation du travail d’équipe [24, 34]. Les différents systèmesde gestion de versions peuvent compter le nombre de lignes de code ajoutées, modifiées ousupprimées dans un code source. Le système le plus courant actuellement étant Git. Aussi, onpeut citer des outils basés sur ce système tels que Gitinspector, Pepper, Gitstats ainsi que lescommandes 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éfinitiond’un commit est propre à chaque système de gestion de versions. En effet, un commit faitsur CSV 3 concerne une modification apportée dans un seul fichier tandis que pour Git, uncommit peut faire objet de plusieurs modifications dans des fichiers différents. Un commitdonne plusieurs informations sur la modification apportée telles que la date à laquelle lamodification a été apportée, les fichiers pour lesquels on a apporté les modifications, l’auteur

3. Concurrent versions system

19

de ces modifications, les lignes modifiées, . . . . Il existe aussi différentes raisons pour lesquellesun 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 boguesou de celui qui fait des tests ou encore de celui qui définit des méthodes, des modules, desclasses, . . . Cependant selon Lima et al. [34], la considération du nombre de commits a été miseen question comme un indicateur de contribution car ceux qui font plus de commits ne sontpas nécessairement ceux qui travaillent le plus. En effet, lors de la correction d’un bogue, onpourrait observer une situation où le développeur ferait un commit pour chaque tâche obtenantainsi plusieurs crédits pour avoir fait plusieurs commits à la fin du travail par opposition à unesituation où le développeur ferait un seul commit lorsque tout son code fonctionne correctementobtenant ainsi un seul crédit à la fin du travail. Dans les deux situations, il faut remarquer queles 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 permetpas 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 permettentde 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 ilssont ou ne sont pas auteurs. Dans le premier cas où le développeur fait partie des auteurs dudé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ù lesdéveloppeurs préfèrent travailler sur leur propre branche 6 plutôt que sur la branche principale.Ainsi, si la contribution proposée lors du « pull request » est pertinente et ne contient pas debogues, elle est intégrée dans la branche principale par le(s) mainteneur(s) [2]. Dans l’autrecas où le développeur veut contribuer dans un dépôt Git dont il n’est pas auteur, les outils degestion des dépôts Git tels que ceux disponibles avec Github, Bitbucket et Gitlab donnent lapossibilité de faire un « fork » 7. Le développeur fait ainsi un « fork » pour pouvoir le cloneren local où il peut apporter toutes les modifications jugées pertinentes. Pour éviter la gestionde conflits, il est conseillé de travailler en local sur une autre branche que celle principale. Unefois 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 quedes modifications ont été apportées sur un ou plusieurs des fichiers de leur dépôt. Comme ditprécédémment, les mainteneurs vont réviser les modifications apportées et les intégrer dansleur 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 Git5. Personne chargé de faire évoluer le logiciel, de corriger les bogues, d’accepter les correctifs proposés par

d’autres contributeurs6. 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.7. C’est copié, sur le même serveur, un dépôt Git dont on n’est pas auteur

20

qui le fait d’avoir une révision et un retour de sa contribution avant que cette dernière soitintégrée dans la branche principale. Les outils tels que Gitlab, Github et Bitbucket peuventmesurer 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érentesactivités d’un projet de développement requiert une bonne communication entre les membresde l’équipe [56]. La communication est la clé du succès du travail de développement. Ellepermet en l’occurrence de connaître les bloquants, de donner des suggestions, de savoir ce queles 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 moyende communication tel que les courriels ou les échanges dans les forums de discussion tandisque la correction du bogue se fera plus à travers un commit qui va indiquer les changementsapportés (dans le cas où l’équipe utilise un système de gestion de versions comme moyen departage de fichiers). En effet, comme la correction des bogues se trouvent dans les commits, ils’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 rigoureuxdans son travail, ce qui est généralement apprécié par les évaluateurs. Ainsi les contributionsincluant 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érifierles descriptions des commits indiquant qu’un test a été fait.

Enfin, nous pouvons distinguer deux types de classement pour les critères que nous venonsd’énoncer : ceux qui ont un rapport avec le code et ceux qui ont un rapport avec l’organisationdu 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 laqualité du code tel que les tests. Ainsi, le classement de ces différents critères peut être celuiprésenté dans la Table 3.2.

21

Code Organisation du travailQuantité Qualité TâchesCommits Tests Story points8(agilité)Fonctionnalités ou méthodes Commentaires Stories9(agilité)Lignes de code Versions EstimésPull request Revues de code ButsModules Bogues PerspectivesClasses Documentation EchéancesForks Heures de travailFichiers Cas d’utilisation

ActivitésProjetsParticipation au forumWiki

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 membrede l’équipe telles que la date à laquelle le changement a été apporté, les fichiers pourlesquels on a apporté les modifications, l’auteur de ces modifications, les lignes pourlesquelles 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 membrepeut travailler sur un seul fichier durant tout le long du projet et contribuer au mêmedegré 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 dutravail à 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 besoinconcerne QUI, en QUOI il consiste et dans quel BUT.

22

5. Les « story points » :

Ils peuvent indiquer la complexité des tâches à effectuer et ainsi voir ceux qui ont choiside 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’équipeet leur degré de participation.

7. La participation au forum :

Elle permet de remarquer les membres qui communiquent le plus dans l’équipe ou quiprennent 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, nousdevons 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 (SLOC 10 en anglais) est une métrique logicielleservant à mesurer la taille d’un programme informatique en dénombrant le nombre de lignesde son code source. Les lignes de code sont habituellement employées pour quantifier l’effortqui sera exigé pour développer un programme informatique, ainsi que pour estimer la valeurd’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 êtreconsidérées comme une mesure de contribution lors d’un travail en équipe de développementde logiciels :

— Les lignes physiques :

Elles sont définies par Bhatt et al. [5] comme étant les lignes de code qui composent unprogramme incluant les commentaires. Lors d’un travail en équipe, le nombre de lignesde code par auteur est un bon indicateur de contribution et d’évaluation. Cependantles commentaires vides constituent un biais car ils ne devraient pas être comptabiliséscomme une contribution. Différents outils tels que Gitstats, Pepper, Gitinspector, Un-derstand, JHawk, AOPMetrics et Analizo peuvent mesurer les lignes physiques qui setrouvent dans un code source.

10. Source Lines Of Code

23

— Les lignes logiques :

Elles sont définies par Park [45] comme étant le nombre d’instructions exécutables pré-sentes dans un code source. Lors d’un travail en équipe, les lignes logiques ne sont pasun bon indicateur de contribution. Par exemple, avec l’instruction « If A then B » quiest généralement considérée comme une ligne physique est cependant considérée commedeux lignes logiques du fait que A et B correspondent à deux instructions exécutables.Compter le nombre de lignes logiques présente donc un biais lors de l’évaluation de lacontribution individuelle car chaque membre travaille sur un problème différent. L’ou-til Understand est capable de mesurer les lignes logiques qui se trouvent dans un codesource.

— Les lignes vides :

Bhatt et al. [5] suggèrent qu’elles ne devraient pas être comptées comme une contributionlors de l’évaluation du travail d’équipe bien que ces dernières servent souvent à rendrele code plus lisible. L’outil Understand est capable de mesurer les lignes vides qui setrouvent dans un code source.

— Le nombre total des lignes de codes :

Il est défini par Bhatt et al. [5] comme étant le nombre total de lignes physiques y comprisles lignes vides. Cependant comme décrit précédemment les lignes et les commentairesvides constituent un biais et ne devraient pas être comptés comme une contribution. Lesoutils tels que Gitstats, Pepper, Gitinspector, Understand, Metrics 1.3.6 et AOPMetricspeuvent mesurer le nombre total des lignes de codes qui se trouvent dans un code source.

— Les instructions physiques exécutables :

Elles sont définies par Bhatt et al. [5] comme étant le nombre total de lignes de code sansles commentaires et les lignes vides. Elles constituent un bon indicateur de contributionlors de l’évaluation du travail d’équipe.

— Les instructions logiques exécutables :

Elles sont définies par Park [45] comme étant le nombre total d’instructions qui ont étéexécutées. Elles ne constituent pas un bon indicateur de contribution lors de l’évaluationdu travail d’équipe car les lignes logiques définies comme étant le nombre d’instructionsexécutables présentes dans un code source constituent déjà un biais comme décrit pré-cédemment. L’outil Understand est capable de mesurer les instructions logiques exécu-tables qui se trouvent dans un code source.

— Les commentaires :

Ce sont des lignes de code que l’on retrouve dans les programmes. Elles ne sont nicompilées ni interprétées et ont pour but de donner de plus amples informations à celuiqui lit le code. Cités par [5, 13, 44], ils constituent un bon indicateur de contribution lorsde l’évaluation du travail d’équipe si ces derniers sont explicites et donnent un messageclair à celui qui consulterait le code. Cependant, les commentaires vides constituent un

24

biais et ne devraient pas être considérés comme une contribution. Les outils Understandet JHawk peuvent mesurer les commentaires qui se trouvent dans un code source.

— Le nombre de mots que l’on retrouve dans un commentaire :

Défini par Bhatt et al. [5], il ne constitue pas un indicateur de contribution car la manièred’écrire diffère d’une personne à une autre.

— Les commentaires en entête :

Définis par Bhatt et al. [5] comme étant les commentaires que l’on retrouve en entête,ils constituent un bon indicateur de contribution lors de l’évaluation du travail d’équipesi ces derniers sont explicites et donnent un message clair à celui qui consulterait lecode. Cependant, les commentaires vides constituent un biais et ne devraient pas êtreconsidérés comme une contribution.

— Les mots que l’on retrouve dans les commentaires en entête :

Définis par Bhatt et al. [5], ils ne constituent pas un indicateur de contribution lors del’évaluation du travail d’équipe car cela ne représente pas un indicateur objectif.

— La complexité cyclomatique :

Décrit dans [5, 44, 15], elle est définie par McCabe [40] comme étant le nombre de« chemins » linéairement indépendants au travers d’un programme représenté sous laforme d’un graphe. Cet indicateur mesure la qualité du code fourni car elle permetde voir si ce dernier est facile à comprendre et à maintenir. Lors de l’évaluation dutravail d’équipe, on devrait généralement tenir compte de la qualité du code mais celaconstituerait un biais car l’expérience de travail des différents auteurs est différentepénalisant plus les auteurs inexpérimentés. De plus la complexité du code peut dépendredu contexte, pénalisant ainsi les personnes travaillant sur les fonctionnalités complexes.Les outils Borland Together, Understand, Metrics 1.3.6, JHawk, Analizo et SDMetricspeuvent mesurer la complexité cyclomatique d’un code source.

— Le nombre de modules :

Défini par de Aquino et al. [13], il ne peut pas être considéré comme un indicateur decontribution lors de l’évaluation du travail d’équipe car chaque membre travaille sur unproblème spécifique et différent de celui des autres membres. Or pour chaque problèmeà résoudre, le nombre de modules à définir diffère selon le contexte. Ainsi cet indicateurconstituerait un biais lors de l’évaluation de la contribution individuelle car elle dépenddu résultat d’analyse du problème fait par chaque membre. Les outils Metrics 1.3.6 etAnalizo peuvent mesurer le nombre de modules qui se trouvent dans un code source.

— Le nombre de classes :

Défini par de Aquino et al. [13], il ne peut pas être considéré comme un indicateur decontribution lors de l’évaluation du travail d’équipe car comme décrit précédemment ildépend du résultat d’analyse du problème à résoudre. Les outils Understand, Metrics

25

1.3.6, Analizo et SDMetrics peuvent mesurer le nombre de classes qui se trouvent dansun code source.

— Le nombre de méthodes :

Défini par Alberto et al. [44], il ne peut pas être considéré comme un indicateur decontribution lors de l’évaluation du travail d’équipe car comme décrit précédemmentil dépend du résultat d’analyse du problème à résoudre. Les outils Understand, CKJM,Metrics 1.3.6, JHawk et Analizo peuvent mesurer le nombre de méthodes qui se trouventdans un code source.

— Le nombre d’attributs :

Défini par Alberto et al. [44], il ne peut pas être considéré comme un indicateur decontribution lors de l’évaluation du travail d’équipe car comme décrit précédemment ildépend du résultat d’analyse du problème à résoudre. Les outilsMetrics 1.3.6, Analizo etSDMetrics peuvent mesurer le nombre d’attributs qui se trouvent dans un code source.

— Le nombre de constantes :

Défini par Alberto et al. [44], il ne peut pas être considéré comme un indicateur decontribution lors de l’évaluation du travail d’équipe car comme décrit précédemmentil dépend du résultat d’analyse du problème à résoudre. L’outil JHawk est capable demesurer le nombre de constantes qui se trouvent dans un code source.

— Les méthodes pondérées par classe :

Elles sont définies par Kumar et al. [28] comme étant la somme des complexités desméthodes qui se trouvent dans une classe. Cet indicateur a pour but de mesurer lacomplexité du code or dans un travail d’équipe, vu l’expérience de travail qui diffère etdu résultat d’analyse du problème qui diffère aussi, il ne peut pas être considéré commeun indicateur de contribution. Les outils CKJM, Metrics 1.3.6, JHawk, AOPMetrics,CCCC, Analizo et Rational Software Analyzer peuvent mesurer les méthodes pondéréesdans un code source.

— La dépendance entre les objets :

Elle est définie par Kumar et al. [28] comme étant le nombre d’objets qui dépendent d’unobjet donné. Il mesure la complexité du code. Or comme vu précédemment, l’expériencede travail et le résultat d’analyse du problème sont différents d’un membre à un autre,on ne peut donc pas la considérer comme un bon indicateur de contribution lors dutravail d’équipe. Les outils CKJM, Metrics 1.3.6, JHawk, AOPMetrics, CCCC, Analizoet Rational Software Analyzer peuvent mesurer la dépendance des objets dans un codesource.

— La profondeur de l’héritage :

Elle est définie par Kumar et al. [28] comme étant la hauteur maximale dans la hiérar-chie d’une classe. Elle mesure aussi la complexité du code. Or, comme vu précédemment,elle n’est pas un bon indicateur de contribution lors de l’évaluation du travail d’équipe

26

car l’expérience de travail et le résultat d’analyse du problème à résoudre diffèrent d’unmembre à un autre. Les outils CKJM, Metrics 1.3.6, JHawk, AOPMetrics, CCCC, Ana-lizo, Rational Software Analyzer et SDMetrics peuvent mesurer la profondeur de l’héri-tage dans un code source.

— Le nombre d’enfants dans une classe :

Il est défini par Kumar et al. [28] comme étant le nombre de descendants immédiatsd’une classe. Il mesure aussi la complexité du code. Or vu l’expérience de travail et lerésultat d’analyse du problème qui diffèrent d’un membre à un autre, il ne peut pasêtre considéré comme un indicateur de contribution. Les outils CKJM, Metrics 1.3.6,JHawk, AOPMetrics, CCCC, Analizo, Rational Software Analyzer et SDMetrics peuventmesurer le nombre d’enfants.

— La réponse d’une classe :

Elle est définie par Kumar et al. [28] comme étant le nombre de méthodes qui s’exécutentlorsqu’un objet de la classe reçoit un message. Elle mesure aussi la complexité du code. Orvu l’expérience de travail et le résultat d’analyse du problème qui diffèrent d’un membreà un autre, elle ne peut pas être considérée comme un indicateur de contribution aussi.Les outils CKJM,Metrics 1.3.6, JHawk, AOPMetrics, CCCC, Analizo, Rational SoftwareAnalyzer et SDMetrics peuvent mesurer la réponse d’une classe.

— Le manque de cohésion des méthodes :

Il est défini par Lopez [38] comme étant, pour une classe donnée, le fait que tous ses attri-buts ne soient pas employés par ses méthodes. Cet indicateur ne peut pas être considérécomme étant un critère de contribution lors de l’évaluation du travail d’équipe car le ré-sultat d’analyse du problème diffère d’un membre à un autre. Les outils CKJM, Metrics1.3.6, JHawk, AOPMetrics, CCCC, Analizo, Rational Software Analyzer et SDMetricspeuvent mesurer la manque de cohésion dans les méthodes.

3.3.3.3 Les variantes pertinentes à considérer dans le domaine de génie logiciel

Aussi, parmi les variantes citées ci-haut celles qui apparaissent les plus pertinentes pour évaluerla contribution lors du travail d’équipe sont :

— Les lignes physiques

— Le total des lignes de codes

— Les instructions physiques exécutables

— Les commentaires

— Les commentaires en entête

Etant donné que les définitions de ces variantes ont de nombreux points communs, celles quenous retiendrions pour l’évaluation du travail d’équipe sont :

27

— Les lignes de code effectives c.à.d. les instructions physiques exécutables car elles necontiennent ni les commentaires ni les lignes vides qui peuvent constitués un biais.

— Les commentaires, les commentaires en entête en sont un sous-ensemble.

3.4 Conclusion

Au cours de ce chapitre, nous venons de voir qu’il existe plusieurs manières d’évaluer le travaild’équipe. Il s’agit entre autres de l’évaluation par les paires, la technique « RepGrid », latechnique « TCS » et la rémunération en termes d’argent du travail individuel de chaquemembre de l’équipe. Nous avons aussi vu différents critères pouvant être considérés commeune contribution lors du travail d’équipe dont les plus importants à retenir sont les lignes decode, les commits, les « pull request », la participation au forum, les fichiers, les modules, lesméthodes, les classes et les « story point ». Vu qu’il existe plusieurs variantes des SLOC, cesont les lignes de code effectives et les commentaires les plus pertinents à tenir en compte lorsde l’évaluation objective du travail d’équipe. Aussi, tous ces critères peuvent être mesurés àpartir d’un système de gestion de version. Nous retiendrons le plus couramment utilisé : Git. Ilpeut alors être considéré comme un outil de support du travail d’équipe dans l’enseignement.Nous le présentons dans le chapitre suivant.

28

Chapitre 4

Git comme outil de support du travaild’équipe

4.1 Introduction

Afin d’être efficace et productif, le travail en équipe demande d’utiliser des outils qui faci-litent la communication et le partage des idées. De plus, vu que les membres d’une équipe netravaillent pas toujours en même temps sur le projet d’équipe ou encore que leur rythme detravail n’est pas forcément le même, un outil qui permet de partager les idées pouvant êtreconsultées à n’importe quel moment est nécessaire. En effet, cela permet à chaque membre del’équipe de participer et de commenter le travail fait par ses coéquipiers.

C’est dans ce cadre que différents outils ont été proposés par Lanubile et al. [31]. Il s’agit entreautres :

— des systèmes de gestion de versions tels que Git, Subversion, Mercurial, . . .

— des systèmes de suivi des bugs tels que Jira, Bugzilla, . . .

— des outils de gestion et de construction des projets logiciels tels que Maven et Cruise-Control

— des outils de conception tels qu’Artisan Studio, Rational Software Modeler, . . .

— des centres d’information tels que les FAQ, KnowledgeTree, les différents guides, . . .

— des outils de communication tels que WebEx, WorkSpace3D, les forums, . . .

— des applications Web telles que WordPress, Twitter, LinkedIn, . . .

— des environnements de développement en équipe tels que Google Code, Github, Gitlab,. . .

Dans la suite de notre travail, c’est le système de gestion de versions distribué Git qui a étéchoisi comme outil de travail collaboratif.

29

4.2 Présentation de Git

Git a été créé en 2005 par Linus Torvald ; le fondateur du projet Linux, à la suite d’une rupturede contrat entre le projet Linux et BitKeeper. Les objectifs que Git devait atteindre à saconception étaient les suivants : être rapide, avoir un design simple, permettre le développementnon-linéaire, être distribué et pouvoir gérer efficacement de gros projets tel que Linux.

Parmi les raisons qui nous ont poussé à choisir Git et à le proposer comme outil de travailcollaboratif dans l’enseignement sont qu’en premier lieu, il utilise un protocole de partage defichiers de bas niveau ; il est assez facilement compréhensible par les étudiants de différentsniveaux d’étude [27]. En deuxième lieu, Git permet de garder l’historique de son projet sur sonordinateur personnel et de le partager en même temps sur un serveur à distance, ce qui peutégalement être utilisé comme un moyen de sauvegarde de son projet [10, 37, 52]. En troisièmelieu, des outils qui intègrent Git ont été développés pour faciliter le partage et la gestion deversion [52, 27, 25]. En dernier lieu, l’analyse des dépôts Git permet de récupérer différentesinformations sur la contribution apportée par chaque membre de l’équipe. Il s’agit notammentdes informations sur :

— les commits

— les lignes de code ajoutées ou supprimées

— les fichiers ajoutés, modifiés et supprimés

— les branches ajoutées ou supprimées, . . .

De plus, Git est utilisé aussi bien dans l’enseignement que dans le monde professionnel pourgérer efficacement le travail asynchrone et distribué, fait par plusieurs développeurs de logicielset cela sans contrainte sur la dispersion géographique. Dans la section suivante nous allonsvoir l’intérêt d’utiliser Git dans l’enseignement.

4.3 Utilisation de Git dans l’enseignement

4.3.1 Les avantages de Git chez les étudiants

Motivés à apprendre à leurs étudiants à utiliser un outil de gestion de version de plus en plusutilisé dans le monde professionnel, plusieurs auteurs ont choisi d’utiliser Git dans le cadrede leur cours [29, 27, 25]. Il ont pu démontrer que l’introduction de Git comme un moyende résolution des exercices et de diffusion de leur solution pouvait apporter de nombreuxavantages pour les étudiants.

En effet, parmi les avantages de l’utilisation de Git dans le cadre d’un cours, nous pouvonsnoter en premier lieu que les étudiants peuvent démontrer qu’ils travaillent régulièrement surles travaux à travers les commits qu’ils font. Par exemple, dans [27], les étudiants commencent

30

par importer l’exercice proposé par le professeur sur leur machine personnelle. Par la suite,ils doivent faire des commits réguliers pour montrer les modifications importantes apportéesà leur travail. Enfin, la solution de l’exercice est exportée sur un dépôt auquel le professeura accès. Comme Git garde l’historique de toutes les modifications, il est ainsi facile pour leprofesseur d’identifier les étudiants qui s’impliquent dans leur travail et ceux qui ne le font pas[29]. En faisant des contributions régulières, l’étudiant démontre qu’il s’implique régulièrementpour résoudre les exercices du cours. Il est aussi amené à revoir souvent sa matière et ainsimieux la comprendre.

En deuxième lieu, lors d’un travail en équipe, les étudiants ont la possibilité de faire descommentaires sur le travail fait par leurs camarades de classe [27] et de soulever des questionssur des forums de discussion [25]. Ils peuvent aussi voir les critiques de leur camarade ou deleur professeur leur permettant ainsi de s’améliorer dans leurs travaux ultérieurs. Par exempledans [29], le professeur a la possibilité de modifier le code de chaque étudiant et d’ajouter descommentaires pertinents pour soit résoudre un bogue ou soit proposer une meilleure approchede résolution du problème.

En troisième lieu, un autre point pertinent soulevé par les étudiants impliqués dans les travauxde Kelleher et al. [27] est celui de pouvoir retrouver le travail qu’on avait supprimé par mégardegrâce à l’historique de Git. Il faut cependant noter que cela demande de faire des commitsréguliers c.à.d. à chaque modification apportée dans un fichier.

En quatrième lieu, grâce à la création illimitée des branches dans Git, les étudiants sontcapables d’écrire différents scénarios à partir du code initial et ainsi expérimenter différentessolutions qui peuvent être fusionnées plus tard dans la branche principale comme solutionfinale.

En cinquième lieu, Git permet de mieux organiser le travail d’équipe. En effet, Git offre auxétudiants la possibilité de travailler hors connexion, de continuer leur travail individuel surleur ordinateur et de pouvoir partager par la suite leur travail sur le serveur central accessiblepar le professeur et tous les membres de l’équipe.

En conclusion, l’utilisation de Git, dans le cadre de cours, présente de nombreux avantages.En effet, elle permet aux étudiants de mieux comprendre leur matière grâce aux contributionsindividuelles et régulières, au travail d’équipe et à l’accessibilité des différentes versions ducours. Dans la section suivante, nous allons montrer que l’utilisation de Git présente égalementde nombreux avantages pour les professeurs.

4.3.2 Les avantages de Git chez les professeurs

Git présente de nombreux avantages pour les étudiants mais également pour les enseignants.En effet, l’utilisation de Git peut permettre aux professeurs de plus facilement faire un suivi

31

régulier de leurs étudiants. Par exemple, dans [27, 25], les étudiants doivent envoyer unenotification à leur professeur après avoir déposé leur travail sur le serveur central. Ainsi, dans[27], les étudiants envoient un courriel contenant le lien de leur dépôt privé pour notifier auprofesseur qu’ils ont déposé leur travail tandis que dans [25], les étudiants envoient un « pullrequest » comme une notification au professeur. Le professeur peut ensuite réviser le travailde chaque étudiant avec une possibilité de faire des commentaires progressivement sur uneou plusieurs parties du travail. Les étudiants reçoivent ainsi un retour d’appréciation de leurprofesseur et peuvent améliorer leur travail à partir des commentaires.

A partir de ce suivi régulier, les professeurs sont aussi capables de remarquer les étudiants quicontribuent le plus et ceux qui contribuent le moins lors du travail d’équipe. Par ailleurs, ilest également plus facile pour les professeurs de détecter les formes de plagiat. Par exemple,Kelleher [27] indique que si, soudainement, une solution est proposée par un étudiant qui nefait généralement pas de commits réguliers, cela est souvent lié à une forme de plagiat.

4.3.3 Autre avantage de Git : une minimisation des coûts du matérieldidactique

Git peut non seulement être considéré comme un outil de support à l’enseignement maisaussi, il peut apporter des bénéfices matériels. En effet, en premier lieu, les outils de gestiondes dépôts Git offerts en ligne sont pour la plupart gratuits. Il s’agit notamment de Gitlab,Github ou Bitbucket pour les plus connus. Aussi, Kelleher [27] a montré que ces outils offrentun nombre illimité de dépôts privés ou publics lorsqu’on s’inscrit en tant qu’étudiant et unespace de stockage qui servirait ainsi de sauvegarde.

En deuxième lieu, Laadan et al. [29] ont souligné que l’utilisation de Git permettait de diminuerconsidérablement les coûts liés aux ressources informatiques pour l’enseignement. En effet, ilpermet aux étudiants de travailler dans un même environnement et d’avoir le même codede départ fourni par le professeur à moindre coût. Sinon, il faudrait prévoir une équipe detechniciens qui installeraient et maintiendraient ces environnements avec les coûts que celaimplique. De plus, avec Git, on peut travailler sur ou hors campus permettant à l’étudiant decontinuer son travail chez lui dans les mêmes conditions qu’à l’université. Pour terminer, enutilisant les outils de gestion des dépôts Git, les universités peuvent réduire leurs besoins destockage, et par là même leurs coûts.

4.3.4 Les avantages de Git dans le développement des compétencestransversales

En plus d’être un moyen de rationalisation matériel, Git est aussi un excellent outil de déve-loppement des compétences transversales lors du travail d’équipe comme nous le détailleronsdans les paragraphes suivants.

32

En premier lieu, Git permet de développer une bonne communication entre les membres del’équipe. En effet, à partir de la description du commit, chaque membre de l’équipe comprendrapidement les modifications apportées aussi bien dans le présent que dans le passé [12]. Parailleurs, on apprend à expliquer aux autres membres de l’équipe la raison d’avoir procédé parune méthode donnée. Et la meilleure équipe qui va progresser avec un projet suivi par Git estcelle qui sait bien communiquer pour éviter les conflits et organiser son travail.

En deuxième lieu, Git permet de proposer de nouvelles idées en tenant compte de cellesproposées par d’autres. En effet, il permet, à chaque membre, de suivre le travail de sescoéquipiers ainsi que leurs commentaires afin d’améliorer son travail par après.

En troisième lieu, Git permet de développer la gestion de conflit, le jugement critique, l’analyse,la prise de décision et la résolution de problèmes. Modifier les mêmes lignes de code dans unmême fichier entraîne des conflits sous Git [8]. Et si 2 fichiers de 2 membres sont en conflitsous Git, les 2 membres devront trouver ensemble lequel des 2 fichiers à garder pour résoudrele conflit [9]. Mais cela demande une analyse, un jugement critique et de prendre la bonnedécision. Par ailleurs, afin d’éviter d’être constamment en conflit, les membres d’une équipedoivent avoir une bonne organisation et une bonne communication.

En quatrième lieu, Git offre également la création de branches illimitées ce qui favorise letravail d’équipe et le travail individuel [6]. En effet, pour éviter de rendre dysfonctionnel letravail fait par d’autres coéquipiers, chaque membre peut créer sa propre branche pour essayerde nouvelles fonctionnalités ou pour résoudre un bogue [33]. Et une fois que son travail aboutià de bons résultats, il peut le fusionner dans la branche principale afin que les autres membrespuissent voir les ajouts ou modifications apportés. Dans le cas où le travail n’a pas aboutià de bons résultats, le membre peut abandonner la branche sans aucune conséquence sur letravail d’équipe. Par ailleurs, les commentaires faits par les autres membres de l’équipe ou parle professeur dans les fichiers permettent de comprendre les erreurs commis et d’améliorer sontravail individuel. Ainsi, Git permet de faire un travail individuel, à son rythme et ensuite dele partager au reste de l’équipe.

En cinquième lieu, Git permet de faire la comparaison de l’écart entre le résultat anticipé etle résultat concrètement obtenu et avoir le feedback du professeur. En effet, chaque membrede l’équipe :

— peut consulter l’historique du projet et évaluer les résultats obtenus au cours du temps,

— peut avoir un feedback du professeur en tout temps en utilisant les « pull request », lescourriels ou les commentaires,

— peut se servir du travail fait par les autres pour améliorer ses connaissances.

En sixième lieu, Git permet de s’engager activement dans le développement des projets. Eneffet, à partir des expériences menées par [29, 25], l’introdution de Git, dans le cadre de cours,

33

a démontré que les étudiants interagissaient plus et s’impliquaient plus dans la réussite de leurtravail.

En dernier lieu, il n’y a pas meilleur outil que Git pour construire son portfolio au fur et amesure que l’on avance dans sa formation académique :

— il garde l’historique et permet de retourner en arrière,

— il permet de suivre son évolution ainsi que les corrections apportées au projet au coursdu temps,

— il permet de créer autant de dépôts que de projets et autant de branches que de fonc-tionnalités ajoutées ou améliorées.

Nous pouvons voir que l’utilisation de Git permet de développer différentes compétences trans-verales telles que la communication, l’organisation, la gestion de conflits,. . . Cependant, il estincontournable de pouvoir évaluer ces compétences, C’est-ce que nous proposons d’étudierdans la section suivante.

4.4 Git et l’évaluation de la contribution individuelle autravail d’équipe

Au cours de notre recherche, nous nous intéressons à pouvoir évaluer le travail d’équipe enutilisant le système de gestion de versions distribué Git. Parmi les critères qui devraient êtreretenus lors de l’évaluation du travail d’équipe, nous pouvons citer la régularité de l’équipe,la contribution de chaque membre de l’équipe en termes de quantité de travail soumis et lacollaboration entre les membres de l’équipe. Il s’agit alors de recenser les moyens proposésdans la littérature pour estimer les différents critères d’évaluation du travail d’équipe.

4.4.1 L’évaluation de la régularité de l’équipe

Afin de pouvoir évaluer la régularité de l’équipe, en se basant sur les dépôts Git, l’utilisationd’une illustration visuelle ou le résultat de commandes Git spécifiques peuvent nous permettred’observer le degré de contribution dans le temps de chaque membre de l’équipe par rapportau reste de l’équipe en termes de lignes de code ou de commits.

Par exemple, le logiciel Pepper permet de représenter graphiquement l’activité en termes delignes de code de chaque auteur dans le temps sur une branche spécifique. Tel qu’illustré dansla Figure 4.1, on peut observer que si nous considérons que le dépôt a existé de Septembre 2014à Octobre 2016, nous pouvons voir que seul l’auteur « . . . ude 1 » a contribué régulièrementdu début à la fin de l’existence du dépôt. Par contre, le reste de l’équipe a contribué soit au

1. Dans la suite du mémoire, pour des raisons de confidentialité, les noms sont masqués et trois points desuspension remplacent la première partie du nom.

34

début « . . . dwi », « . . . d1 » et « . . . rn ») ou soit à la fin de la période considérée (« . . . are »et « . . . ime »).

Figure 4.1 – Activité en termes de lignes de code de chaque auteur dans le temps sur labranche principale master (générée par Pepper)

Github, quant à lui, permet de visualiser l’activité de chaque auteur dans le temps en termesde commits. La Figure 4.2 présente des graphiques nous permettant de voir pour chaquecontributeur, la période durant laquelle il a été plus actif. Par exemple, nous voyons que« hazendaz » a plus contribué de 2014 à 2017 , « velo » de 2012 à 2015 , « ctubbsii » de 2015à 2017 et « elrodro83 » deux fois seulement en 2016 et en 2017 [20].

Figure 4.2 – Activité en termes de commits dans le temps sur la branche principale masterpour l’ensemble des auteurs puis de chaque auteur pris individuellement (générée par Githubà partir d’un dépôt public)

35

Gitlab permet de disposer du même type de représentation, mais sous une forme différente.La Figure 4.3 en présente un exemple. Ainsi, à partir de ce graphique, nous pouvons voir quele membre « Achilleas » a contribué régulièrement du début jusque vers la fin la fin du projettandis que « Winniehell » a contribué au début du projet et « Florian » à la fin du projet [21].

Figure 4.3 – Activité en termes de commits dans le temps sur la branche principale masterpour l’ensemble des auteurs puis de chaque auteur pris individuellement (générée par Gitlabà partir d’un dépôt public)

En plus des illustrations visuelles, la commande :

git log -n 5 --author="authorName" --date=short --pretty =\%cd

nous permet d’avoir les dates des 5 derniers commits de chaque auteur. L’analyse du résultatà ces différentes dates nous permet de déduire si l’auteur est régulier ou irrégulier. Cependant,avant de lancer cette commande sur un dépôt Git, il faut d’abord connaître les différentsauteurs de ce dépôt. C’est possible en utilisant la commande :

git log --date=short --pretty =\%cn

qui donnerait, par exemple, le résultat présenté dans la Figure 4.4.

36

Figure 4.4 – Résultat de la commande git pour illustrer les auteurs du dépôt

Il faut remarquer que pour avoir de bons résultats, il faudrait traiter la liste des auteurs afind’enlever les doublons.

En remplaçant, dans la première commande, « authorName » successivement par « ...tel »,« ...essi » et « ...g15 » ; noms provenant de la Figure 4.4, nous aurons les résultats présentésdans la Figure 4.5.

Figure 4.5 – Résultat de la commande git pour illustrer les dates des 5 derniers commits

Ainsi, en analysant les 5 derniers commits des 3 auteurs, nous pouvons voir que l’auteur« . . . essi » est le plus régulier avec une moyenne d’une journée entre les commits tandis queque « . . . g15 » est l’auteur le plus irrégulier avec une moyenne de 6 jours entre les commits.

37

4.4.2 L’évaluation quantitative de la contribution de chaque membre del’équipe

En plus d’avoir une vue dans le temps des contributions relatives à l’ensemble, il est importantde pouvoir connaître les contributions détaillées de chaque membre en terme de volume.

Aussi, dans les dépôts Git, nous retrouvons plusieurs informations pouvant être utilisées dontles commits, les lignes de codes et les fichiers. En effet, elles peuvent facilement être comptéespar différents outils et ainsi être considérées dans l’évaluation des contributions en termes dequantité de travail.

4.4.2.1 Les commits

Le nombre de commits par auteur peut être considéré comme une contribution individuelle etquantifiable. Aussi, l’utilisation de graphiques qui illustrent la contribution de chaque auteuren termes de pourcentage est un bon moyen de repérer rapidement les auteurs qui ont le pluscontribués. De tels graphiques peuvent par exemple être générés à l’aide de Pepper, commeillustré dans la Figure 4.6. A partir de ce graphique, nous pouvons voir que c’est « . . . ell » qui ale plus contribué au projet avec 59% des commits faits pendant la durée d’observation, tandisque les contributions de « . . . etta » et « . . . art » apparaissent marginales avec respectivement1% et 2%.

Figure 4.6 – Contribution en termes de pourcentage des commits de chaque auteur sur labranche principale master (générée par Pepper)

38

Pepper permet aussi de représenter le nombre de commits en termes de pourcentage parpériode (année, mois ou semaine) et par auteur. C’est alors une solution pour repérer lesauteurs qui ont le plus contribués relativement aux autres, pour une période donnée, commeillustré dans la Figure 4.7 :

Figure 4.7 – Le nombre de commits contribués par auteur et par période en termes depourcentages (générée par Pepper)

Visualiser dans un tableau le nombre de commits et le nombre de lignes de codes ajoutées etsupprimées par auteur est aussi un bon moyen de voir les contributions individuelles. Ce typede représentation peut alors être plus complète et détaillée. La Figure 4.8, générée par Gitstatillustre un tel type de synthèse. En effet, ce tableau classe les auteurs en fonction du nombrede commits et c’est « Heikki » qui est placé en tête car il est le principal contributeur sur ledépôt avec une participation de 87,85% en termes de commits comparé au reste de l’équipequi a moins de 3% de participation [22].

Figure 4.8 – Contribution en termes de commits et de LOC (Lines of code) de chaque auteur(générée par Gitstats)

39

La Figure 4.9 présente un autre exemple de résultat par l’utilisation de Gitinspector. A partirde ce tableau, nous pouvons observer que c’est « . . . ell » qui a fait le plus de commits sur ledépôt soit 108 commits par rapport à « . . . etta » qui en a fait seulement 7.

Figure 4.9 – Contribution en termes de commits et de LOC de chaque auteur (générée parGitinspector)

Il est toujours possible d’utiliser des données brutes en utilisant par exemple la commande :

git shortlog -s

qui permet de connaître le nombre de commits par auteur depuis la création du dépôt commeillustré à la Figure 4.10 :

Figure 4.10 – Résultat de la commande git pour illustrer le nombre de commits par auteur

Ainsi, partir de ces résultas, nous voyons dans l’exemple que c’est « . . . els » qui a contribuéle plus avec 167 commits.

4.4.2.2 Les lignes de code

Comme les commits, les lignes de code peuvent également être considérées comme une contri-bution quantitative en vue de comparer l’effort fourni par chaque membre de l’équipe.

Les Figures 4.8 et 4.9 montrent très bien le nombre de lignes de codes ajoutées et suppriméespar chaque auteur.

Aussi, un graphique représentant le nombre de lignes de code accumulées au fil du temps parchaque auteur permet de pouvoir facilement comparer le travail individuel de chaque auteur.C’est ce que propose Gitstats dans la Figure 4.11 [22].

40

Figure 4.11 – LOC accumulées au fil du temps par chaque auteur (générée par Gitstats)

A partir de la Figure 4.11, nous remarquons qu’il y a une grande différence de lignes ajoutéesentre « Heikki » et le reste de l’équipe. Cela nous permet de déduire que « Heikki » est le plusgrand contributeur.

La Figure 4.12 présente un autre exemple de dépôt pour lequel c’est également une seulepersonne qui a le plus contribué soit « . . . ude ».

Figure 4.12 – LOC accumulées au fil du temps par chaque auteur (générée par Pepper)

41

Pour terminer avec les lignes de code, la commande :

git log --author="authorName" --oneline --shortstat

permet de voir pour chaque commit le nombre de fichiers qui ont fait l’objet d’une modification,le nombre de lignes de code ajoutées et supprimées comme illustré à la Figure 4.13 :

Figure 4.13 – Résultat de la commande git pour illustrer le nombre de fichiers modifiés et deLOC ajoutées et supprimées par commit pour un auteur spécifique

Mais il faut remarquer, que pour chaque auteur, il faudra additionner par la suite tous lescommits et toutes les lignes ajoutées et supprimées afin d’avoir le nombre total de commits, delignes ajoutées et supprimées, ce qui nécessitera un développement supplémentaire spécifique.

4.4.2.3 Les fichiers

Le nombre de fichiers par auteur est aussi une autre forme de contribution individuelle etquantitative qui peut être considérée au même titre que les commits et les lignes de code.

La commande :

git log --oneline --pretty="format:" --name -status --author="

authorName" --since="date1" --before="date2" -- ls -files "*.

docx" "*.png" "*.java"

permet de connaître les fichiers qui ont été ajoutés (A), modifiés (M) et supprimées (S) selonles extensions choisies comme illustrée par la Figure 4.14 :

42

Figure 4.14 – Résultat de la commande git pour illustrer les fichiers ajoutés, supprimés etmodifiés par un auteur et selon les extensions choisies

Il faut noter que cette commande permet de faire une analyse aussi bien pour des fichiersbinaires que pour des fichiers textes.

4.4.3 La collaboration entre les membres de l’équipe

La collaboration entre les membres de l’équipe est un autre critère qui devrait être consi-déré lors de l’évaluation du travail d’équipe. Et l’analyse des branches et des revues de codepeuvent illustrer qu’il existe une collaboration dans l’équipe comme nous le verrons dans lesparagraphes suivants.

4.4.3.1 Les branches

Git offre la possibilité de créer une branche secondaire à partir de la branche principale.Cette branche secondaire est une copie de la branche principale et permet à son auteur detravailler indépendamment sans affecter le travail des autres. Cette branche secondaire estsouvent créée pour fixer des bogues ou pour ajouter de nouvelles fonctionnalités. Lorsqueles développements faits sur cette branche sont jugés stables et fonctionnels, elle peut êtrefusionnée avec la branche principale. Cela veut dire que lors de la fusion, la branche principalecontiendra aussi les changements apportés dans la branche secondaire.

43

Git offre la possibilité de créer un nombre illimité de branches secondaires permettant ainsid’augmenter la productivité des développeurs [33].

C’est ainsi que Lee et al. [33] ont proposé l’outil Git Branch Analyser qui permet de récupérertoutes les branches qui ont été créées sur un dépôt Git et d’en faire une analyse statistique etgraphique. En effet, cet outil commence tout d’abord par récupérer un historique des commitsdu dépôt. Ensuite, il récupère toutes les branches qui ont été créées dans le journal du dépôtainsi que l’historique des commits pour chaque branche. Enfin, à partir d’un graphe, il établitles relations qui existent entre les branches. Cela permet ainsi de répondre aux questions quand,où et combien de branches ont été créées et fusionnées au cours d’un projet de développementde logiciels. De plus, ce graphe permet d’établir les relations qui existent entre les différentsdéveloppements modulaires.

L’outil est ainsi capable de récupérer le nombre de commits, de committers 2, de lignes decodes ajoutées ou modifiées lors du dernier commit. Mais, il est aussi possible d’établir lesliens entre les différentes tâches faites par les développeurs à partir des flux de travail. Eneffet, étant donné que les branches sont souvent créées pour fixer des bogues ou pour ajouterde nouvelles fonctionnalités et que le flux de travail représente soit la création d’une branche oula fusion de deux branches, il est ainsi plus facile d’établir les liens entre les différentes tâchesde développement modulaire. Lee et al. ont ainsi pu montrer que l’analyse des branches, enutilisant l’outil Git Branch Analyser, donne des informations sur l’historique de développementdes projets et les interactions entre les développeurs.

4.4.3.2 La revue de code

La revue de code à travers les « pull request » entraîne souvent une discussion entre la per-sonne qui fait le « pull request » et la personne qui accepte le « pull request ». En effet, il s’agitd’une situation où une personne demande aux mainteneurs d’un dépôt Git de tenir en compteles modifications qu’il propose en les intégrant dans la branche principale. Les mainteneursdoivent ainsi réviser les modifications proposées avant de les accepter ou de les rejeter. Il fautremarquer que durant la période de revue de code, les mainteneurs peuvent communiqueravec la personne auteur du « pull request » afin de clarifier différents points jugés non compré-hensibles engageant ainsi une collaboration entre ces différentes personnes [41]. L’analyse descanaux de communication durant cette période peut alors être considérée comme un moyend’évaluer le travail d’équipe.

2. Auteur d’un commit

44

4.5 Conclusion

Au cours de ce chapitre, nous venons de voir que Git est un excellent outil pour organiser letravail d’équipe en raison de la facilité de son utilisation, de l’historique ainsi que de la teneurdes informations qu’il garde. Nous avons également vu que l’utilisation de Git, dans le cadrede l’enseignement, présente plusieurs avantages. En effet, du côté des étudiants, Git permetd’organiser leur travail d’équipe, de démontrer leur travail régulier, d’avoir un retour d’appré-ciation de leurs camarades de classe, de retrouver l’historique des modifications apportées etd’expérimenter différents scénarios de leur travail grâce à la création des branches. Du côtédes professeurs, Git permet de faire un suivi régulier du travail fait par les étudiants. Git estaussi un excellent moyen de réduire les coûts du matériel didactique et de développer diffé-rentes compétences transversales telles que la communication, le jugement critique, l’analyse,... . Enfin, nous avons vu que la régularité de l’équipe, la contribution quantitative de chaquemembre de l’équipe et la collaboration entre les membres de l’équipe sont les critères à prendreen compte lors de l’évaluation d’un travail d’équipe organisé sous Git. C’est ainsi que nousnous sommes basés sur ces différents critères que nous venons d’invoquer pour développer unoutil d’évaluation du travail d’équipe qui fera le sujet du chapitre suivant.

45

Chapitre 5

Un outil pour l’évaluation objectivedu travail d’équipe

5.1 Introduction

Après avoir recensé les moyens possibles pour évaluer le travail en équipe dans les coursde programmation, ceci en utilisant Git comme nous l’avons fait, il s’agissait de valider noshypothèses quant au choix des meilleurs critères à retenir ainsi que d’identifier les biais poten-tiellement induits par ceux-ci. Pour cela, nous avons développé un outil que nous avons appelé« Gitanalysis ».

5.2 Définition et objectif général

Cet outil a été conçu dans le but d’évaluer objectivement et de suivre régulièrement un travaild’équipe organisé sous Git. Présenté sous la forme d’un tableau de bord, il permet d’avoirune vision globale de la régularité et de la contribution quantitative de toutes les équipes etleurs membres. En effet, l’outil est capable, à partir des mesures objectives et de la périoded’analyse choisie, de montrer la contribution quantitative apportée par chaque membre del’équipe, d’évaluer la régularité et la dernière activité de chaque membre de l’équipe.

Gitanalysis est une application web qui a été développée en python et qui est compatible avecles serveurs Stash et Gitlab. Nous nous sommes intéressés à ces deux types de serveurs carpour le premier, l’université Laval gère les dépôts Git des étudiants avec ce type de serveur.Par ailleurs, comme de nos jours, il existe de plus en plus des services en ligne qui gèrent desdépôts Git, nous avons choisi d’ajouter le logiciel libre Gittab pour apporter plus de souplessedans l’utilisation.

46

5.3 Les outils utilisés par Gitanalysis

Au cours du chapitre précédent, nous avons vu qu’il existe plusieurs outils d’analyse statis-tique pour les dépôts Git capables de générer différents rapports mais certains ne sont géné-ralement pas autonomes, c’est-à-dire qu’ils dépendent des sites sur lesquels ils sont hébergés.Par exemple, les services web d’hébergement tels que Github et Gitlab offrent ce genre d’outil.Cependant, pour pouvoir les exploiter, il faut que d’une part que les dépôts Git soient crééssur ces services, et d’autre part accepter que ces services ne peuvent pas être automatisés ouadaptés à des contraintes très spécifiques. Des alternatives à ces services Web sont par exempleles outils comme Pepper, Gitstats et Gitinspector qui sont installables localement et donc plusautonomes.

En effet, Pepper est un outil qui génère différents rapports sous forme de graphiques relatifsmettant en évidence les contributions quantitatives de chaque auteur du dépôt Git et desgraphiques temporels mettant en évidence la régularité de chaque auteur. Cependant, il nedonne pas des détails absolus sur les contributions des auteurs ni le choix des types de fichierslors de la production de ses rapports.

Aussi, Gitstats permet de générer des tableaux détaillés avec des valeurs absolues sur lescontributions quantitatives de chaque auteur du dépôt Git. Il propose aussi des graphiquestemporels mettant en évidence la régularité de chaque auteur. Cependant, tout comme Pepper,il ne permet pas non plus de choisir le type des fichiers lors de la production de ses rapports.

Enfin, Gitinspector produit des rapports sous forme de tableaux ou graphiques absolus mettanten évidence la contribution quantitative de chaque auteur du dépôt. Il permet aussi de choisirle type de fichiers à analyser lors de la production de ses rapports, permettant d’éviter le biaisimpliqué par la présence dans le dépôt de fichiers générés automatiquement. Malheureusement,il ne produit pas de graphique temporel mettant en évidence la régularité de chaque auteurdu dépôt Git.

Les commandes Git quant à elles permettent de générer des rapports sur l’activité des auteursdans le temps mettant en évidence la régularité de ces derniers. Elles permettent aussi degénérer des rapports sur la contribution quantitative apportée par chaque auteur du dépôt etde choisir les types de fichiers à analyser comme le fait Gitinspector.

Il apparaît donc que la solution la plus simple pour disposer d’un outil pour pouvoir évaluerla régularité ainsi que les contributions respectives des membres des équipes, est de se tournervers un développement combinant l’utilisation de Gitinspector et des commandes Git. C’estpourquoi, Gitanalysis appelle des fonctions de Gitinspector pour générer les résultats de l’éva-luation de la contribution quantitative apportée par chaque membre de l’équipe et celle detoute l’équipe. Par ailleurs des commandes Git sont utilisées pour générer différents rapportsde Gitanalysis lors de l’évaluation de la régularité des membres de l’équipe.

47

5.4 Les critères considérés comme une contribution parGitanalysis

Il est important d’avoir des critères de contribution sur lesquels on peut se baser pour évaluer letravail d’équipe. Et comme vu dans le chapitre 3, il en existe plusieurs que l’on peut considérerdépendamment de la manière dont le travail d’équipe est organisé. En utilisant Git comme outild’organisation pour les travaux d’équipe ainsi que Gitinspector et les commandes Git pouranalyser les dépôts Git , ce sont les commits et les lignes de codes qui ont été sélectionnées pourdéfinir une contribution lors de l’analyse et de l’évaluation du travail d’équipe par Gitanalysis.

En effet, en premier lieu, les dates des quatre plus récents commits ont été utilisées lors del’évaluation effectuée par Gitanalysis pour estimer la régularité de chaque membre de l’équipe.De plus, la date du dernier commit a été utilisée pour déterminer la dernière activité dumembre. Par ailleurs, le nombre de commits par membre montre le degré de participation dece dernier par rapport aux autres membres.

En deuxième lieu, le nombre de lignes de code ajoutées et supprimées a été utilisé par Gita-nalysis pour mesurer la contribution quantitative de chaque membre de l’équipe. Cependant,il faut noter que les lignes vides, les commentaires vides ou les commentaires non explicitesconstituent un biais en ajoutant des crédits non mérités. Ils ne devraient pas être considéréscomme des contributions.

5.5 Fonctionnalités de Gitanalysis

Gitanalysis offre plusieurs fonctionnalités comme nous le verrons au cours de cette section. Ila également pu être évalué dans le cadre d’un cours de projets en génie logiciel dans lequelles étudiants sont amenés à travailler en équipe en utilisant Git. Nous en présentons ici lesrésultats que nous analysons par la suite. Un extrait du tableau de bord est présenté dans laFigure 5.1. Cet extrait a été obtenu à partir des dépôts Git des étudiants suivant ce cours.

48

Figure 5.1 – Extrait du tableau de bord de Gitanalysis pour une période de deux mois surles fichiers java

5.5.1 Outil de récupération des dépôts Git en local

Gitanalysis permet, par l’utilisation de la fonction git clone, de récupérer en local les dépôtsGit sur lesquels on veut faire l’analyse. Cela permet ainsi de pouvoir éventuellement fairel’analyse et l’évaluation des dépôts Git tout en étant hors ligne. Dans le cas d’une mise à jour

49

de dépôts préalablement clonés, Gitanalysis nous permet d’exécuter des commandes git pullsur les dépôts concernés.

5.5.2 Outil d’évaluation de la contribution quantitative du travaild’équipe

Après avoir récupéré les dépôts Git en local, Gitanalysis permet de choisir les types de fichiersà analyser ainsi que la période pour laquelle on veut faire l’analyse. En effet, comme illustrépar la Figure 5.2, l’outil permet d’analyser les fichiers textes tels que .java, .c, .py, ... Il fautnoter que ce choix des fichiers à analyser permet d’inclure les fichiers créés réellement par lesétudiants et d’exclure ceux générés automatiquement par des outils qui fausseraient l’analysecomme par exemple les fichiers textes générés par Doxygen 1. Par ailleurs, il est possible dechoisir la branche sur laquelle on veut faire l’analyse.

Figure 5.2 – Choix de Gitanalysis

5.5.2.1 Évaluation de la contribution quantitative de chaque membre del’équipe

Lors de l’analyse des dépôts, la contribution apportée par chaque membre de l’équipe estdeterminée puis présentée comme illustré dans la Figure 5.3 2. Par exemple, pour le membre« . . . lay », les critères retenus sont le nombre de commits soit 48, le nombre de lignes de code

1. Générateur de documentation sous licence libre capable de produire une documentation logicielle (enhtml, latex, ...) à partir du code source d’un programme.

2. Dans la suite du mémoire, les entêtes du tableau de bord ont été reproduits pour faciliter la lecture desextraits utilisés pour l’illustration des différents cas analysés.

50

ajoutées (3380) et supprimées (1178), le pourcentage de lignes de code ajoutées et suppriméespar rapport au reste de l’équipe soit respectivement 37.07% et 33.2% ainsi que la moyenne delignes de code ajoutées et supprimées par commit soit 94.

Figure 5.3 – Exemple de contribution quantitative d’un membre de l’équipe pour environ 4mois sur les fichiers java par Gitanalysis

5.5.2.2 Évaluation de la contribution quantitative de l’équipe

La contribution de toute l’équipe est déterminée à partir de la contribution apportée parchaque membre de cette équipe. Par exemple, comme le montre la Figure 5.4, le nombre totalde lignes de code ajoutées et supprimées par tous les membres de l’équipe est respectivementde 9119 et 3548. Quant au nombre total de commits faits par ces membres, il est de 125.

Figure 5.4 – Exemple de contribution quantitative d’une équipe pour environ 4 mois sur lesfichiers java

5.5.3 Outil de détermination de l’indicateur d’activité du travail d’équipe

Une fois l’analyse des contributions quantitatives faites, une évaluation de la régularité et dela dernière activité de chaque membre de l’équipe sont calculées. Les résultats de ces deuxévaluations permettent par la suite de déterminer l’indicateur d’activité de chaque membre del’équipe ainsi que celui de l’équipe.

51

5.5.3.1 Évaluation de la régularité et de la dernière activité de chaque membrede l’équipe

Pour chaque membre de l’équipe, Gitanalysis calcule la moyenne des écarts entre les 4 derniersjours où des commits ont été faits afin de déterminer la régularité. Il calcule aussi le nombre dejours écoulés entre la date du dernier commit et la date d’analyse qui est par défaut la date dujour sinon la date que l’utilisateur sélectionne afin de déteminer la dernière activité de chaquemembre de l’équipe. Chaque membre est alors classé comme étant soit un membre régulier,soit un membre moins régulier ou soit un membre irrégulier. En effet, pour chaque membrede l’équipe, si la régularité se trouve dans l’intervalle de [0,7], le membre est considéré commeétant régulier. Celui-ci fait des commits dans des délais inférieurs à une semaine en moyenne.Si la régularité se retrouve dans l’intervalle de [8,10], il est considéré comme un membre moinsrégulier. Le membre passe plus d’une semaine sans apporter une nouvelle contribution, il estconsidéré comme un membre ayant commencé à prendre du retard. Enfin, si la régularité setrouve dans l’intervalle de [11,∞[, il est considéré comme étant un membre irrégulier. En effet,si le membre passe plus de 10 jours sans apporter de nouvelles contributions, il rencontrerapotentiellement des difficultés pour combler son retard.

Quant à la dernière activité, elle est considérée récente si elle se trouve dans l’intervalle de[0,7], contemporaine si elle se trouve dans l’intervalle de [8,10] et ancienne si elle se trouvedans l’intervalle de [11,∞[.

N.B. : Nous avons choisi les intervalles sur une échelle d’une semaine car, dans notre situation,la périodicité des séances de cours est d’une semaine. Mais, ces intervalles peuvent être changésà volonté selon des seuils jugés plus pertinents. Et si le membre n’a fait qu’un seul commit nepermettant pas ainsi de calculer sa régularité, un trait représentera sa régularité.

Aussi, trois couleurs sont associées aux trois différents intervalles. La couleur verte est associéeà l’intervalle de [0,7], la couleur jaune à l’intervalle [8,10] et la couleur rouge à l’intervalle[11,∞[. Une illustration de la manière dont Gitanalysis évalue chaque membre de l’équipe estdonné dans la Figure 5.5. On observe que les membres de cette équipe sont réguliers. En effet,la régularité de « . . . lay », de « . . . ert » et de « . . .ma » sont respectivement de 2 jours, 1 jouret de 2 jours appartenant toutes dans l’intervalle de [0,7] des membres réguliers. De plus, lesdernières activités de « . . . lay », « . . . ert » et « . . .ma » sont respectivement de 2 jours, 3 jourset 3 jours confirmant une activité récente.

Ainsi, la classification des membres de l’équipe en fonction de leur régularité et de leur dernièreactivité a permis de déterminer l’indicateur d’activité des membres de l’équipe comme nousle verrons en détail dans la section suivante.

52

Figure 5.5 – Evalation du membre de l’équipe sur la régularité par Gitanalysis

5.5.3.2 Détermination de l’indicateur d’activité de chaque membre de l’équipe

En fonction de sa régularité et de sa dernière activité, chaque membre est classé comme étantun membre actif, un membre à surveiller ou un membre à risque. En effet, les figures 5.6, 5.7et 5.8 vont nous permettre de bien comprendre cette classification.

Figure 5.6 – Suivi d’un membre régulier sur des périodes différentes par Gitanalysis

Sur la Figure 5.6, nous pouvons voir que le membre a fait ses 4 derniers commits dans unepériode comprise entre [0,7]. C’est donc un membre régulier. Si le suivi de Gitanalysis est faitentre [0,7] jours après que le membre ait fait son dernier commit (le quatrième), sa dernièreactivité sera récente. Par exemple dans notre cas le suivi a été fait 3 jours après son derniercommit (SUIVI 1). Le membre ne donnera donc aucune raison de commencer à le surveillerou de s’inquiéter et sera classé comme membre actif. En effet, vu qu’il contribue régulièrementet que son dernier commit date du 11 Avril, nous pouvons facilement prédire que, d’aprèsses habitudes, son prochain commit sera fait au plus tard le 18 Avril. Si le second suivide Gitanalysis est fait entre [8,10] jours après son dernier commit, sa dernière activité seracontemporaine. Dans notre cas, le suivi a été fait 9 jours après le dernier commit (SUIVI 2). Ace moment, le membre aura passé plus d’une semaine sans avoir fait une nouvelle contributionet aura même dépassé la date prévue de son prochain commit de 1 à 3 jours. Dans notreexemple, le membre a dépassé la date prévue du prochain commit de 2 jours. Mais vu que

53

c’est généralement un membre régulier, on ne va pas commencer à le surveiller ou à s’inquiéter.Il sera toujours classé comme membre actif. Par contre, si le suivi de Gitanalysis est fait plusde 10 jours après son dernier commit, la dernière activité du membre sera ancienne. Dansnotre exemple, le suivi a été fait 12 jours après le dernier commit (SUIVI 3). Nous pouvonsvoir que le membre commence à prendre du retard et perd son rythme de travail. Il donne desraisons de le surveiller et sera donc classé comme membre à surveiller. Et si le suivi indiqueplus de 14 jours d’inactivité, le membre sera classé comme membre à risque. En effet, il donnedes raisons de s’inquiéter et devrait être contacté par l’enseignant.

Figure 5.7 – Suivi d’un membre moins régulier sur des périodes différentes par Gitanalysis

Sur la Figure 5.7, nous pouvons voir que le membre a fait ses 4 derniers commits dans unepériode comprise entre [8,10]. C’est donc un membre moins régulier. Si le suivi de Gitanalysisest fait entre [0,7] jours après que le membre ait fait son dernier commit (le quatrième), sadernière activité sera récente. Par exemple dans notre cas le suivi a été fait 5 jours après sondernier commit (SUIVI 1). Ici, le membre donne déjà des raisons de le surveiller car c’est unmembre moins régulier et le suivi a été fait très tôt pour donner des raisons de s’inquiéter. Eneffet, vu qu’il contribue moins régulièrement et que son dernier commit date du 28 Avril, nouspouvons facilement prédire que son prochain commit sera fait au plus tard le 08 Mai. On ne saitpas si le membre va s’améliorer en contribuant avant la date prévue de son prochain commitou si sa situation va se détériorer en contribuant irrégulièrement. Dans ce cas, le membre seraclassé comme étant un membre à surveiller. Si le second suivi de Gitanalysis est fait entre[8,10] jours après son dernier commit, sa dernière activité sera contemporaine. Dans notre cas,le suivi a été fait 8 jours après le dernier commit (SUIVI 2). A ce moment, le membre aurapassé plus d’une semaine sans avoir fait une nouvelle contribution mais sera en avance de 1ou 2 jours de la date prévue de son prochain commit. Dans notre exemple, le membre n’a pasencore dépassé la date prévue du prochain commit. En effet, le suivi a été fait en avance de2 jours de sa date prévue du prochain commit. Mais vu que c’est généralement un membremoins régulier, on va continuer à le surveiller et sera donc classé comme membre à surveiller.Par contre, si le suivi de Gitanalysis montre que le membre a passé plus de 10 jours sans avoir

54

apporté une nouvelle contribution, la dernière activité du membre sera ancienne. Dans notreexemple, le suivi a été fait 12 jours après le dernier commit (SUIVI 3). Nous pouvons voir quele membre accuse un retard considérable et que sa situation se détériore. Il donne des raisonsde s’inquiéter et sera donc classé comme membre à risque. Le membre devrait être contactépar l’enseignant.

Figure 5.8 – Suivi d’un membre irrégulier sur des périodes différentes par Gitanalysis

Sur la Figure 5.8, nous pouvons voir que le membre a fait ses 4 derniers commits dans unepériode comprise entre [11,∞[. C’est donc un membre irrégulier. Si le suivi de Gitanalysisest fait entre [0,7] jours après que le membre ait fait son dernier commit (le quatrième), sadernière activité sera récente. Par exemple dans notre cas le suivi a été fait 4 jours après sondernier commit (SUIVI 1). Ici, le membre donne déjà des raisons de s’inquiéter car c’est unmembre irrégulier mais le suivi a été fait très tôt. On ne sait pas si le membre va s’amélioreren contribuant avant la date prévue de son prochain commit ou s’il va continuer à accuser duretard dans son travail. En effet, vu qu’il contribue irrégulièrement et que son dernier commitdate du 06 Mai, nous pouvons facilement prédire que son prochain commit sera fait à partirdu 17 Mai. Dans ce cas, on va continuer à surveiller durant une semaine et le membre seraclassé comme étant un membre à surveiller. Si le second suivi de Gitanalysis est fait entre[8,10] jours après son dernier commit, sa dernière activité sera contemporaine. Dans notre cas,le suivi a été fait 8 jours après le dernier commit (SUIVI 2). A ce moment, le membre aurapassé plus d’une semaine sans avoir fait une nouvelle contribution mais sera en avance de 1,2 ou 3 jours de la date prévue de son prochain commit. Dans notre exemple, le membre n’apas encore dépassé la date prévue du prochain commit. En effet, le suivi a été fait en avancede 3 jours de sa date prévue du prochain commit. Mais vu que c’est généralement un membreirrégulier, il continue à accuser du retard et donne des raisons de s’inquiéter. Il sera doncclassé comme membre à risque et l’enseignant devrait le contacter. Par contre, si le suivi deGitanalysis montre que le membre a passé plus de 10 jours sans avoir apporté une nouvellecontribution, la dernière activité du membre sera ancienne. Dans notre exemple, le suivi a étéfait 12 jours après le dernier commit (SUIVI 3). Nous pouvons voir que le membre continue à

55

accuser du retard et que sa situation ne s’est pas améliorée. Il donne des raisons de s’inquiéteret sera donc classé comme membre à risque. Le membre devrait être contacté par l’enseignant.

En résumé, un membre est classé comme membre :

1. actif :

a) lorsqu’il est classé membre régulier et que l’analyse de Gitanalysis nous montre quesa dernière activité est récente.

b) lorsqu’il est classé membre régulier et que l’analyse de Gitanalysis nous montre quesa dernière activité est contemporaine.

2. à surveiller :

a) Lorqu’il est classé membre régulier et que l’analyse de Gitanalysis nous montre quesa dernière activité est ancienne de moins de 15 jours.

b) Lorsqu’il est classé membre moins régulier et que l’analyse de Gitanalysis nousmontre que sa dernière activité est récente.

c) Lorsqu’il est classé membre moins régulier et que l’analyse de Gitanalysis nousmontre que sa dernière activité est contemporaine.

d) Lorsqu’il est classé membre irrégulier et que l’analyse de Gitanalysis nous montreque sa dernière activité est récente.

3. à risque :

a) Lorqu’il est classé membre régulier et que l’analyse de Gitanalysis nous montre quesa dernière activité est ancienne de plus de 14 jours.

b) Lorsqu’il est classé membre moins régulier et que l’analyse de Gitanalysis nousmontre que sa dernière activité est ancienne.

c) Lorsqu’il est classé membre irrégulier et que que l’analyse de Gitanalysis nousmontre que sa dernière activité est contemporaine.

d) Lorsqu’il est classé membre irrégulier et que que l’analyse de Gitanalysis nousmontre que sa dernière activité est ancienne.

5.5.3.3 Détermination de l’indicateur d’activité de l’équipe

Les résultats obtenus lors de l’utilisation de Gitanalysis dans le cadre d’un cours nous ontpermis de distinguer trois types d’équipe :

— Equipe fonctionnelle : lorsque tous les membres sont actifs c.à.d. qu’ils font des contri-butions régulières.

— Equipe passagèrement dysfonctionnelle : c’est lorsque tous les membres de l’équipe sontà surveiller c.à.d. qu’ils font des contributions moins régulières.

— Equipe dysfonctionnelle : c’est lorsque tous les membres sont à risque c.à.d. qu’ils fontdes contributions irrégulières.

56

Comme, nous avons également constaté d’autres situations telles des équipes mixtes composéesà la fois des membres actifs, à surveiller et à risque, nous proposons un tableau des combinai-sons possibles que nous pouvons avoir et des évaluations pouvant être faites en conséquence(Figure 5.9).

Une notion de flèche colorée est associée aux différentes évaluations de l’équipe. En effet,nous représentons une équipe fonctionnelle par une flèche verte, une équipe passagèrementdysfonctionnelle par une flèche jaune et une équipe dysfonctionnelle par une flèche rouge. Deplus, une flèche bleue représente des équipes inactives c.à.d. qu’elles ont été créées par lesétudiants qui n’ont fait aucune activité par après. Cette manière de représenter les différenteséquipes s’est révélée utile dans le suivi du travail d’équipe car elle permet de mettre en évidencecelles présentant des risques. Elle permet ainsi d’aider les professeurs à détecter les équipesqui peuvent avoir besoin de support.Par exemple, comme illustré dans la Figure 5.9, avec une évaluation de chaque équipe quiest faite avec des représentations de flèches colorées, il sera plus facile de repérer rapidementles équipes qui font un travail irrégulier. En effet, les équipes qui ont une flèche rouge devantleur nom d’équipe sont celles qui sont composées des membres qui ont passé plus de 10 jourssans faire de commits. Ces équipes attireront donc une attention particulière de la part duprofesseur qui devrait les contacter afin de savoir les raisons pour lesquelles elles travaillentirrégulièrement et ainsi apporter le support nécessaire dans l’immédiat. Par contre, le niveaud’alerte du professeur diminuera si l’équipe est représentée par une flèche jaune pour ne plusêtre alerté si l’équipe est représentée par une flèche verte ; un signe que l’équipe travaillede façon régulière. Une présentation détaillée des différentes types d’équipe obtenus lors del’application de Gitanalysis sur les dépôts Git créés dans le cadre d’un cours sera faite dansla section des résultats.

5.6 Résultats et analyses

Nous venons de voir différentes fonctionnalités offertes par Gitanalysis. Après avoir récupéréles données à analyser dans les dépôts Git créés par les étudiants, Gitanalysis affiche, dansun tableau de bord, différentes informations en fonction de la période, de l’extension et de labranche choisies. En effet, pour chaque équipe, il montre la contribution quantitative apportéepar chaque membre en termes de lignes de code et de commits. Nous retrouvons aussi, dans letableau, un indicateur d’activité de chaque membre de l’équipe calculée à partir de l’évaluationde la régularité et de la dernière activité de chaque membre de l’équipe. Les résultats obtenuslors de l’utilisation de Gitanalysis sur les dépôts Git créés dans le cadre d’un cours nous ontpermis de constater que l’on peut distinguer trois types d’équipe : les équipes fonctionnelles,les équipes passagèrement dysfonctionnelles et les équipes dysfonctionnelles.

57

Figure5.9–Évaluationde

scombina

ison

spo

ssiblesde

séquipe

sform

éesde

4et

de3mem

bres

58

5.6.1 Équipe fonctionnelle

Comme rappel, une équipe est dite fonctionnelle lorsque tous les membres de l’équipe sontactifs. L’indicateur d’activité de chaque membre et celle de l’équipe sont symbolisés par uneflèche verte. Une équipe est également fonctionnelle lorsqu’elle est composée de membres actifset de membres à surveiller et que ce sont les membres actifs qui sont majoritaires. L’indicateurd’activité de chaque membre est symbolisé par une flèche colorée soit en vert soit en jaune etl’indicateur d’activité de l’équipe est symbolisée par une flèche verte. Ainsi, en faisant l’analysedu dépôt de la Figure 5.10 :

Figure 5.10 – Activité d’une équipe fonctionnelle composée des membres actifs avec travailbien réparti (extrait du tableau de bord généré par Gitanalysis)

Nous pouvons constater que l’équipe « Loutre » remplit très bien la première condition oùtous les membres sont actifs.

Bien que « . . . on » ait fait la plus grande contribution en termes de lignes de code ajoutéeset supprimées soit respectivement 38.79%et 26.58% et ait fait le même nombre de commitsque « . . . in » soit 11 sur un total de 35 commits, le reste de l’équipe a presque contribué dela même façon. En effet, nous pouvons voir que la répartition des tâches a été bien faite cartous les membres ont fait des contributions significatives. L’équipe est donc productive et nedemande pas l’intervention du professeur.

Il peut cependant exister des cas où une équipe soit composée de membres actifs qui necontribuent pas au même degré comme l’illustre la Figure 5.11 :

Nous pouvons constater que l’équipe « Commando » remplit également la première conditionoù tous les membres sont actifs.

En faisant l’analyse des lignes de code ajoutées et supprimées, nous voyons que c’est « . . . det »qui a fait la plus grande contribution par rapport au reste de l’équipe. En effet, il a ajouté50.69% des lignes de code et supprimé 55.52%. Cependant, malgré que « . . . ar » ait faitun travail régulier, il n’a presque pas contribué. En effet, il a ajouté 8.09% des lignes decode, supprimé 7.59% et fait 31 commits sur un total de 109. Nous pouvons imaginer que

59

Figure 5.11 – Activité d’une équipe fonctionnelle composée des membres actifs avec travailmal réparti (extrait du tableau de bord généré par Gitanalysis)

c’est sûrement « . . . det » et « . . . aud » qui se sont chargés du travail que devait effectuer« . . . ar » afin de faire avancer le travail d’équipe. En termes de commit, nous voyons que c’est« . . . aud » qui en a fait plus bien qu’il soit le second contributeur en termes de lignes de codeaprès « . . . det ». Ce qui nous amène à confirmer que l’évaluation basée sur un seul critère peutêtre fausse. En effet, en considérant uniquement les commits, il aurait été considéré comme lemembre qui a le plus contribué et même « . . . ar » aurait été considéré comme avoir apporté degrosses contributions. « . . . det » fait probablement partie de la catégorie des membres qui fontun commit lorsque la majorité des fonctions du code est fonctionnelle tandis que « . . . aud » et« . . . ar » font partie de la catégorie des membres qui font plusieurs commits même lorsque c’estune partie d’une fonction qui l’est. L’équipe est donc productive bien qu’un de ses membressoit potentiellement à surveiller en termes de contribution quantitative.

Dans le cas où l’équipe n’est pas composée que de membres reconnus actifs, il est nécessaired’analyser les activités lues plus en détails. La Figure 5.12 présente un de ces cas.

Figure 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

Ici, et d’après l’indicateur d’activité, l’équipe « Mindstorm » remplit très bien la deuxièmecondition où la majorité des membres sont actifs soit 3 membres actifs et un membre à sur-veiller.

En faisant l’analyse des lignes de code ajoutées et supprimées, nous voyons que c’est « . . . ier »qui a ajouté et supprimé plus de lignes de code et fait plus de commits soit respectivement39.42% et 53.3% et 73 commits sur un total pour l’équipe de 137, soit 53%. Le membre àsurveiller « . . . dre » quant à lui a moins contribué par rapport au reste de l’équipe. En effet, ila ajouté 9.76% des lignes de code, supprimé 8.52% et fait 5% des commits. On voit facilementque la régularité du membre influe sur la contribution qu’il apporte. En effet, moins il estrégulier dans ses commits, moins il contribue en termes de lignes de code et de commits.L’équipe est donc également productive bien qu’un de ses membres soit potentiellement àsurveiller en termes de contribution quantitative et de régularité.

5.6.2 Équipe passagèrement dysfonctionnelle

Comme rappel, une équipe est dite passagèrement dysfonctionnelle lorsque tous les membres del’équipe sont à surveiller ou lorsque l’équipe est composée des membres actifs et des membres àsurveiller et que ce sont ces derniers (les membres à surveiller) qui sont majoritaires ou encoreque la moité est active et que l’autre moitié est à surveiller. L’indicateur d’activité de chaquemembre est symbolisé par une flèche colorée soit en jaune ou soit en vert et en jaune tandisque l’indicateur d’activité de l’équipe est symbolisée par une flèche jaune. Ainsi, en faisantl’analyse de la Figure 5.13, nous pouvons constater que l’équipe « Constructeurs » remplit trèsbien la première condition où tous les membres sont à surveiller :

Figure 5.13 – Activité d’une équipe passagèrement dysfonctionnelle composée des membresà surveiller (extrait du tableau de bord généré par Gitanalysis)

En faisant l’analyse des lignes de code, nous voyons qu’en général les membres ont bien répartileur travail car ils ont presque contribué de la même manière. « . . . EG1 » a supprimé plusde lignes de code soit 56.69% tandis que « . . . lan » en a ajouté plus soit 59.51%. Par contre,en termes de commits, c’est « . . . lan » qui en a fait beaucoup soit 26 sur un total de 33 soit79%. Cela vient confirmer que l’on ne peut pas évaluer un membre de l’équipe en considérantuniquement un critère. En effet, en regardant seulement les commits, on aurait pensé que c’est

61

« . . . lan » qui a le plus contribué car il a fait presque le triple des commits. En réalité, cela estfaux car les deux ont apporté des contributions significatives. Cette équipe est donc productivebien qu’elle ait besoin d’être surveillée par le professeur du fait que les membres commencentà faire un travail irrégulier.

Le cas où la moitié de l’équipe est composée de membres actifs et que l’autre moitié est àsurveiller est illustré par la Figure 5.14.

Figure 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 bordgénéré par Gitanalysis)

L’équipe « Studio » remplit très bien la troisième condition où la moitié des membres est activeet l’autre moitié est à surveiller.

En faisant l’analyse des lignes de code ajoutées et supprimées, nous voyons que c’est « . . . gon »qui a ajouté et supprimé plus de lignes de code soit respectivement 53.89% et 58.4% et faitplus de commits, soit 53 commits sur 110 (48%). Nous pouvons aussi remarquer qu’un desmembres à surveiller n’a que très peu contribué. En effet, il a ajouté 2.56% des lignes de code,en a supprimé 1.38% et a fait 10 commits sur un total de 110 soit 9%. Sinon le reste de l’équipea fait des contributions significatives. Cette équipe est en général productive mais 2 membresdevraient être surveillés à cause de leur travail qui est moins régulier. De plus un des membresà surveiller ne contribue presque pas.

Lorsqu’une équipe est composée d’une majorité de membres à surveiller ne veut nécessairementpas dire qu’elle a des problèmes de répartition de travail comme nous le montre la Figure 5.15.

En faisant l’analyse des lignes de code, nous pouvons observer que « . . . gny » en a supprimé49.66% tandis que « . . . ré » en a ajouté 32.1%. En termes de commit, c’est « . . . exx » quien a fait plus. Cependant, il faut noter que la différence n’est pas très importante avec lesautres membres que ce soit pour les lignes de code ajoutées, celles supprimées ou encore lescommits. En effet, le travail de l’équipe est bien réparti car chacun a apporté des contributionssignificatives. Cette équipe est également productive bien qu’elle ait besoin d’être surveilléepar le professeur car la majorité des membres commencent à faire un travail irrégulier.

62

Figure 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)

5.6.3 Équipe dysfonctionnelle

Comme rappel, une équipe est dite dysfonctionnelle lorsqu’au moins un des membres del’équipe est à risque. L’indicateur d’activité de l’un des membres ainsi que celui de l’équipesont symbolisés par des flèches rouges.

L’équipe « Gaff » de la Figure 5.16 est une équipe dysfonctionnelle car elle est composée d’unmembre à risque et de 2 membres actifs.

Figure 5.16 – Activité d’une équipe dysfonctionnelle composée d’un abandon (extrait dutableau de bord généré par Gitanalysis)

Nous pouvons ici constater que l’équipe « Gaff » est une équipe dysfonctionnelle à cause de« . . . a912 ». On observe que ce dernier n’a pas apporté de grosses contributions par rapport aureste de l’équipe. En effet, il ajouté 6.9% des lignes de code, supprimé 8.27% des lignes de codeet fait 6 commits sur un total de 90 soit 7%. De plus, il n’a pas fait de récente contributioncar sa dernière actvité a été faite il y a 62 jours soit plus de 2 mois. On peut alors rapidementen conclure que ce membre a abandonné le cours. Cependant les autres membres ont continuéà travailler et sont même réguliers. On observe aussi que la répartition du travail a été bienfaite car ils ont tous les deux fait des contributions significatives. Ainsi, bien que l’équipe soitproductive Gitanalysis permet de mettre en évidence les abandons.

63

Il est possible qu’un ou plusieurs membres d’une équipe utilisent différents ordinateurs pourpartager leur travail et que ces ordinateurs soient configurés avec des noms différents. Sile membre utilise plus d’un ordinateur avec des configurations différentes, il peut biaiser leclassement de l’équipe en la faisant apparaître comme dysfonctionnelle. Un exemple de cettesituation est illustré par la Figure 5.17.

Figure 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)

Ici, nous voyons que l’équipe « Sudo » est une équipe dysfonctionnelle car elle est composéede 3 membres à risque et de 2 membres actifs.

Cependant en faisant l’analyse des noms des membres, nous voyons que « . . . ande » et ». . . anDe » semblent représenter la même personne. En effet, comme les noms ont été ortho-graphiés de différentes manières, Gitanalysis considère que ce sont des personnes différentes.Or « . . . anDe » a été évalué par Gitanalysis comme un membre à risque à cause de son travailirrégulier. En réalité, c’est la même personne qui a changé d’ordinateur pour partager sontravail et les ordinateurs qu’il a utilisé étaient configurés avec des noms différents. A part cebiais, nous voyons que c’est « . . . ande » qui a le plus contribué avec 59.15% des lignes de codeajoutées, 76.78% des lignes de code supprimées et 95 commits sur un total de 164 soit 58%. Lesautres membres à risque quant à eux n’ont presque pas contribué. En effet, « . . . on » a ajouté2.3% des lignes de code et fait 2 commits. « . . . urt » quant à lui a ajouté 3.9% des lignesde code, a supprimé 1.87% des lignes de code et a fait 11 commits. Cette équipe demandel’intervention du professeur car c’est seulement la moitié de l’équipe qui est régulier et qui faitdes contributions significatives. Le professeur devrait aussi tenir compte des autres critèrestels que les noms des membres afin de mieux interpréter certaines alertes de Gitanalysis.

Il peut arriver aussi dans une équipe dysfonctionnelle qu’un des membres actifs ne contribuepas assez, faute sûrement d’une mauvaise organisation de l’équipe comme nous allons le voirdans la Figure 5.18.

Ici, l’équipe « DistantGuys » est composé de 2 membres actifs et de 2 membres à risque. Nous

64

Figure 5.18 – Activité d’une équipe dysfonctionnelle composée de membres actifs et à risque(extrait du tableau de bord généré par Gitanalysis)

pouvons voir que c’est « . . . gle » qui a le plus contribué dans l’équipe. En effet, il ajouté 84.84%des lignes de code, en a supprimé 83.38% et a fait 54 commits sur un total de 75 soit 72%.Le reste de l’équipe n’a presque pas contribué. Cette équipe est mal organisée et a besoin del’intervention du professeur car c’est une seule personne qui travaille régulièrement et qui faitdes contributions significatives.

5.7 Limites de Gitanalysis et recommandations

Les résultats obtenus, en faisant l’analyse des différents dépôts Git, nous ont permis de remar-quer que Gitanalysis avait des limites. En effet, selon la manière dont il est utilisé, les résultatsde l’évaluation peuvent être mal interprétés. Aussi, dans cette section, nous présentons les li-mites de Gitanalysis ainsi que des recommandations à considérer lors de son utilisation.

Premièrement, lors de l’analyse de la contribution de chaque membre de l’équipe, la prise encompte de certaines lignes de code ajoutées peut fausser le résultat de l’analyse. En effet, siun membre ajoute la copie d’une librairie, cet ajout sera compté comme une contribution. Or,cela faussera les résultats de l’analyse car le membre aura un crédit pour une contribution deplusieurs lignes ajoutées qu’il n’a en réalité pas écrites lui-même. Aussi, l’enseignant qui faitl’analyse peut remettre en question les résultats obtenus s’il observe un ajout d’un nombre delignes ajoutées anormalement élevé ne correspondant pas à une contribution habituelle d’unindividu.

Deuxièmement, l’analyse prend également en compte le code de départ éventuellement fournipar le professeur. Le membre qui ajoutera ce code se verra attribué un crédit de plusieurs lignesajoutées alors qu’en réalité ce ne sont pas les lignes qu’il a écrites lui-même. Comme dans leparagraphe précédent, les résultats de l’analyse seront erronés et si celui qui fait l’analyse nesait pas d’avance qu’il y a un code de départ qui a été fourni, cette contribution pourrait passerinaperçue par opposition à l’ajout d’une librairie. Cependant, ce défaut peut être facilement

65

corrigé en excluant une période de temps correspondant à une période de démarrage, ceci enchoisissant adéquatement la période d’analyse qui est configurable.

Troisièmement, il est important de définir des conventions d’utilisation de Git. En l’occurrence,si un membre de l’équipe utilise plusieurs ordinateurs pour envoyer son code sur le serveur etque ses ordinateurs sont configurés avec des noms et des courriels différents, l’analyse ne vapas considérer que c’est la même personne qui a partagé son travail et diviser les contributions.En effet, l’analyse est basée sur les commandes de Git qui utilisent le nom et le courriel pourdistinguer les auteurs des dépôts. Un exemple plus concret se trouve dans la Figure 5.19 :

Figure 5.19 – Exemple de configurations différentes de nom pour la même personne (généréepar Pepper)

En analysant la Figure 5.19, nous pouvons très bien voir que les deux premiers noms repré-sentent la même personne. Or, l’analyse les considère comme deux personnes différentes carl’ordre dans lequel les noms ont été écrits est différent. Ainsi, il considère que « Melissa Cla-risse Ntirandekura » a travaillé seulement au début et que « Melissa Ntirandekura Clarisse »a pris ensuite la relève. En réalité, il s’agit de la même personne, mais qui a fait des commitssur des ordinateurs ayant des configurations de noms différentes sur Git. Le respect de laconvention consistant à toujours configurer Git en utilisant le même nom et le même courrielest alors essentiel. Par ailleurs, pour être bien évalué, les membres de l’équipe devraient fairedes commits réguliers, au moins chaque semaine, pour éviter que leurs équipes soient évaluéescomme étant des équipes passagèrement dysfonctionnelles ou dysfonctionnelles.

Quatrièmement, on pourrait considérer les lignes de code modifiées comme étant une grandecontribution lors du travail d’équipe surtout quand la date de la remise du livrable approche.

66

En effet, l’on pourrait considérer le membre qui a modifié plusieurs lignes de code commeétant celui qui a corrigé le travail et par conséquent devant être mieux évalué que le restede l’équipe. Cela n’est pas nécessairement vrai car le membre qui a commencé par ajouterdes lignes de code peut aussi être le plus grand contributeur. En effet, ceux qui ont fait desmodifications à posteriori se sont servis de ses idées.

Cinquièmement, afin de faciliter le travail individuel de chaque membre de l’équipe, les membresdes équipes devraient toujours travailler sur d’autres branches autres que « master » pour en-suite y fusionner leurs branches lorsque leur code est finalisé comme proposé par Bird [6]. Eneffet, créer sa propre branche donne plus de liberté à son auteur. Celui-ci peut modifier le codecomme il le veut et ne craint pas de créer des conflits avec les fichiers des autres membres. Deplus, ces branches individuelles peuvent être utilisées pour essayer de nouvelles fonctionnalitésou pour résoudre un bogue comme proposé par Lee et al. [33]. L’analyse de Gitanalysis seferait donc sur la branche « master » une fois que toutes les branches fonctionnelles y auraientété fusionnées. Cependant, afin de pouvoir comptabiliser les commits qui ont été faits dans lesautres branches que « master », il faudrait prévoir une fonction qui va compter le nombre decommits par auteur dans toutes les branches qui ont été créées sur le dépôt.

Sixièmement, au cours des analyses faites sur les dépôts des étudiants, nous avons remarqué quela période d’analyse influençait l’évaluation de l’équipe comme nous le montre les figures 5.20et 5.21.

Figure 5.20 – Evaluation de l’équipe avant les examens intra par Gitanalysis

La Figure 5.20 nous montre l’équipe « Moka » qui a été suivie par Gitanalysis avant lesexamens intra du 26 Septembre au 13 Octobre 2017. L’équipe est fonctionnelle car tous lesmembres ont fait un travail régulier. Même la répartition du travail a été bien faite car ilsont tous apportés des contributions significatives. Par contre, si le suivi est prolongé durantla période des examens intra c.à.d. du 26 Septembre au 27 Octobre 2017 comme illustré parla Figure 5.21, l’équipe est devenue dysfonctionnelle car leur dernière activité est devenueancienne passant en moyenne de 3 jours à 17 jours. Ce résultat est tout à fait normal car c’estune période où les étudiants passaient leurs examens et n’avaient donc pas d’activité pour le

67

travail d’équipe. Par ailleurs, la période des examens n’est pas la meilleure période pour faireun suivi du travail d’équipe et devrait être exclue de la période d’analyse.

Figure 5.21 – Evaluation de l’équipe durant les examens intra par Gitanalysis

Enfin, les équipes dysfonctionnelles qui comportent au moins un des membres à risque sont àconsidérer avec précaution. Comme nous l’avons constaté, si un des membres change d’ordina-teurs pour partager son travail ou s’il abandonne le cours et passe donc plus de 11 jours sansdémontrer d’activité, il pénalise le reste de l’équipe. En effet, comme Git garde l’historique desfichiers sur le dépôt, Gitanalysis donnera également une évaluation de ce membre. Et même siles autres membres continuent à faire un travail régulier et n’ont pas besoin de l’interventionde l’enseignant, l’équipe sera toujours qualifiée de dysfonctionnelle à cause du membre à risquequi fait toujours partie de l’équipe. Ainsi, pour une équipe dysfonctionnelle, il faudra aller voirle nombre de jours d’inactivité des membres à risque, décider lesquels des membres reflètentun abandon et recalculer l’activité de l’équipe en omettant les membres qui ont abandonné lecours. Par ailleurs, pour des membres qui auraient pu changer d’ordinateur, il faudra vérifierparmi les noms des auteurs s’il n’y en pas qui sont presque similaires donc représentant unemême personne et ainsi recalculer l’activité de l’équipe en tenant compte de ces doublons.

5.8 Conclusion

Au cours de ce chapitre, nous venons de voir que Gitanalysis utilise les lignes de code et les com-mits comme critères d’évaluation. Aussi, Gitanalysis combine des commandes de Gitinspectoret celles de Git afin de pouvoir évaluer la régularité ainsi que les contributions respectivesdes membres des équipes. De plus, il offre plusieurs fonctionnalités. En effet, il permet derécupérer les dépôts Git localement et de faire une évaluation de la contribution quantitativede chaque membre équipe ainsi que celle de l’équipe. Lors de cette évaluation, on peut choi-sir les extensions des fichiers, la branche et la période d’analyse. Gitanalysis permet aussi defaire l’évaluation de la régularité et de la dernière activité de chaque membre de l’équipe. Lesrésultats de ces deux évaluations permettent de déterminer l’indicateur d’activité de chaquemembre et de le classer comme étant soit un membre actif, soit un membre à surveiller ou soit

68

un membre à risque. Les résultats obtenus en analysant les équipes avec Gitanalysis dans lecadre d’un cours nous ont permis de les classer en 3 catégories soient les équipes fonctionnelles,les équipes passagèrement dysfonctionnelles et les équipes dysfonctionnelles. Ainsi, Gitanaly-sis permet de faire un suivi de chaque équipe. En effet, pour des périodes différentes, on peutobserver la manière dont une équipe a évolué. Cependant, nous avons observé certains biais.Par exemple, la considération de certaines lignes de code peut présenter des biais et donner descrédits non mérités aux membres qui les ajoutent au dépôt sur le serveur. En effet, lors du cal-cul de la contribution individuelle en termes de nombre de lignes de code, il serait intéressantde pouvoir exclure les librairies et le code de départ fourni par le professeur. Ainsi, la premièresolution consisterait à faire une liste de tous les fichiers ou les extensions qui représentent unelibrairie ou le code de départ et les exclure lors de l’analyse des dépôts Git. La deuxième solu-tion consisterait à fixer la moyenne des lignes de code qu’un membre de l’équipe peut ajouterpar commit et ainsi exclure de l’analyse, les commits qui ont un nombre fortement supérieurà la moyenne fixée. Avec cette deuxième solution, il faut remarquer que le code de départfourni par le professeur pourrait passer inaperçu et être compté comme une contribution vuque le nombre moyen de lignes de code pourrait être du même ordre de grandeur que pourune contribution réelle. Il faudrait aussi suivre les recommandations proposées afin d’obtenirune bonne évaluation de Gitanalysis. L’analyse des dépôts Git par Gitanalysis a aussi permisd’illustrer différentes évaluations des équipes et des membres des équipes. En effet, nous avonsconstaté que l’outil montre rapidement si les membres de l’équipe ont fait un travail équitableou non permettant ainsi au professeur de confirmer ou d’infirmer une mauvaise évaluationd’un des membres de l’équipe faite par ses coéquipiers. Nous avons aussi observé que pour laplupart des membres, la régularité influençait la contribution quantitative. En effet, moins lemembre était régulier, moins il contribuait significativement. La considération de deux critèresde contribution permet aussi de faire une bonne évaluation de chaque membre de l’équipe. Eneffet, on pourra retenir le cas où un membre fait plusieurs commits sans pour autant avoirajouté ou supprimé plusieurs lignes de code ou encore le cas où un membre fait moins decommits mais ajoute et supprime de nombreuse lignes de code. En considérant uniquementle nombre de commits comme critère d’évaluation, c’est le membre du premier cas qui seraconsidéré comme avoir contribué le plus alors qu’en réalité c’est le membre du deuxième casqui a le plus contribué. Pour terminer, une des suggestions pour améliorer Gitanalysis, seraitde remplacer le calendrier de Gitanalysis par deux curseurs temporels représentant une datede début et une date de fin lors du choix de la période d’analyse afin de repérer facilementles périodes durant lesquelles les étudiants sont plus ou moins actifs. En effet, ces curseursdevraient être sur une échelle où les dates de remise des travaux et les dates importantes dela session seraient mises en évidence.

69

Conclusion

Démarche et contribution

Au cours de notre recherche, nous avons commencé par montrer que le travail d’équipe estun des moyens de développer les compétences transversales. Pour cela, nous avons d’abordmontré que l’introduction des compétences transversales dans l’enseignement est devenue pri-mordiale car elles sont devenues non seulement les critères recherchés par les employeurs lorsde l’embauche mais aussi un moyen de maintenir une employabilité durable. Nous avons parla suite vu que l’approche « active learning » et l’approche basée sur le corpus SWEBOK sontdes techniques qui sont utilisées pour introduire les compétences transversales dans l’enseigne-ment. Pour terminer, nous avons montré que comme le travail d’équipe permet de développerplusieurs autres compétences transversales telles que l’analyse, la communication, le jugementcritique, . . . , il est intéressant de l’introduire comme un moyen de développer les compétencestransversales dans l’enseignement.

Par la suite, nous avons vu qu’il existe plusieurs techniques qui sont utilisées pour évaluer letravail d’équipe telles que l’évaluation par les paires, la technique « RegGrid », la technique« TCS » et la rémunération fictive. Ces techniques permettent aussi bien de voir la contributionde toute l’équipe que celle de chaque membre de l’équipe. Par ailleurs, les lignes de code, lescommits, les « pull request », la participation au forum, les fichiers, les modules, les méthodes,les classes et les story point ont été choisis comme étant les critères les plus pertinents pourreprésenter une contribution lors du travail d’équipe. Mais ces critères dépendent fortement desoutils qui sont utilisés pour organiser ce travail d’équipe. Nous proposons dans cette recherchel’utilisation du système de gestion de version Git comme support. En effet, Git est un excellentoutil pour organiser le travail d’équipe en raison de la facilité de son utilisation, de l’historiqueainsi que de la teneur des informations qu’il conserve. De plus, dans le cadre de l’enseignement,Git présente de nombreux avantages. Du côté des étudiants, Git permet d’organiser leur travaild’équipe, de démontrer leur travail régulier, d’avoir un retour d’appréciation de leurs camaradesde classe, de retrouver l’historique des modifications apportées et d’expérimenter différentsscénarios de leur travail grâce à la création des branches. Du côté des professeurs, Git permetde faire un suivi régulier du travail fait par les étudiants. Git est aussi un excellent moyen deréduire les coûts du matériel didactique et de développer différentes compétences transversales

70

telles que la communication, l’organisation, . . .

Après avoir fait une revue des critères possibles, ceci en utilisant Git, il en ressort que le nombrede commits et de lignes de code sont les critères les plus pertinents à retenir lors de l’évaluationde la régularité de l’équipe et de l’évaluation de la contribution quantitative de chaque membrede l’équipe. Différents outils existent pour produire des rapports statistiques sur les activitésliées aux différentes contributions consignées dans l’historique des dépôts Git. Cependant,il apparaît que la meilleure combinaison pour pouvoir disposer d’informations synthétiséesreste l’association de l’utilisation de l’outil Gitinspector et de commandes Git qui peuventêtre appelées par une application développée à cet effet. Cette association permet de produiredes rapports de contributions d’un ensemble d’équipes, tout en ayant accès aux contributionsindividuelles, ceci en limitant certains biais. Nous avons alors proposé une application type,présentant un tableau de bord des contributions facilitant le suivi. Cet outil de support donneun aperçu rapide à l’enseignant qui l’utilise pour suivre l’évolution des équipes, tout en mettanten évidence des membres en difficulté. Nous avons alors utilisé cette application dans le cadred’un cours de projet en génie logiciel. Les résultats obtenus nous ont permis de constaterqu’en mettant en évidence les contributions quantitatives de chaque membre de l’équipe,leur régularité et leur dernière activité, on peut distinguer trois types d’équipe : les équipesfonctionnelles, les équipes passagèrement dysfonctionnelles et les équipes dysfonctionnelles.Différents scénarios ont pu être étudiés et les limites d’un tel outil identifiées.

Perspectives

Dans les travaux futurs, il serait intéressant de mesurer la collaboration entre les membres del’équipe comme critère d’évaluation. En effet, lors du travail d’équipe, les membres passent untemps considérable à communiquer car ils doivent définir les tâches à réaliser et les partagerentre eux. De plus, au cours de la réalisation des tâches, les membres sont appelés à résoudreles bloquants ou à suggérer différentes solutions afin de présenter un excellent travail. Onpourrait ainsi analyser les branches qui ont été créées par les membres de l’équipe ou les « pullrequest » pour mesurer la collaboration. Il faut noter que pour avoir des résultats pertinents,les étudiants devraient utiliser les branches pour définir chaque nouvelle fonctionnalité ou pourrésoudre les bogues. Les « pull request » devraient aussi être utilisés lors de la revue de code.

De plus, il serait pertinent d’ajouter l’évaluation des paires dans les contributions individuellesde chaque membre. En effet, cela permettrait de voir, pour chaque membre, la manière dont sespaires l’ont évalué selon les critères d’évaluation choisis par le professeur. Il serait égalementpréférable de rendre le plus objective possible cette évaluation des paires.

Lors de l’utilisation de Git comme outil de support du travail d’équipe, si les membres del’équipe choisissent de travailler chacun sur sa branche individuelle et de la fusionner paraprès avec la branche principale lorsqu’il n’y a plus de bogues, il serait intéressant de pouvoir

71

calculer le nombre total de commits faits par chaque membre dans toutes les branches dont ilest auteur.

Il serait également intéressant de pouvoir exclure la période des examens lors de l’analyse faitepar Gitanalysis. En effet, Les étudiants n’ont pas d’activité à faire pour le travail d’équipedurant cette période.

Pour terminer, il serait pertinent d’intégrer les principes agiles lors du travail d’équipe. Parexemple, un graphique d’avancement 3 (burdown chart) devrait être produit par chaque équipepour avoir l’état d’avancement de leur travail.

3. Représentation graphique de l’évolution de quantité de travail restante par rapport au temps sur unepériode de temps donnée

72

Bibliographie

[1] Anabela CarvalhoAlves, DianaMesquita, FranciscoMoreira et Sandra Fernandes :Teamwork in project-based learning : engineering students’ perceptions of strengths andweaknesses. In Proceedings of the Fourth International Symposium on Project Approachesin Engineering Education (PAEE’2012), pages 23–32. Paee’2012, 2012.

[2] Atlassian : Making a pull request. https://www.atlassian.com/ git/ tutorials/making-a-pull-request , 2018. [En ligne ; Page disponible le 05 Mars 2018].

[3] Victor R Basili : Evaluating software development characteristics : Assessment of soft-ware measures in the software engineering laboratory. In Proceedings of the Sixth AnnualSoftware Engineering Workshop, pages 1–24. SOFTWARE ENGINEERING LABORA-TORY GSFC, 1981.

[4] Denis Berthiaume : Compétences transversales et université :repérage et éva-luation. http:// spiralconnect.univ-lyon1.fr/ spiral-files/ download?mode=inline&data=3399915 , 2012. [En ligne ; Page disponible le 10 Novembre 2017].

[5] Kaushal Bhatt, Vinit Tarey, Pushpraj Patel, Kaushal Bhatt Mits et Datana Uj-

jain : Analysis of source lines of code (sloc) metric. International Journal of EmergingTechnology and Advanced Engineering, 2(5):150–154, 2012.

[6] Christian Bird et Thomas Zimmermann : Assessing the value of branches with what-ifanalysis. In Proceedings of the ACM SIGSOFT 20th International Symposium on theFoundations of Software Engineering, FSE ’12, pages 45 :1–45 :11, New York, NY, USA,2012. ACM.

[7] Charles M Brooks et Janice L Ammons : Free riding in group projects and the effectsof timing, frequency, and specificity of criteria in peer assessments. Journal of Educationfor Business, 78(5):268–272, 2003.

[8] Y. Brun, R. Holmes, M. D. Ernst et D. Notkin : Early detection of collaborationconflicts and risks. IEEE Transactions on Software Engineering, 39(10):1358–1375, Oct2013.

73

[9] Yuriy Brun, Reid Holmes, Michael D. Ernst et David Notkin : Proactive detectionof collaboration conflicts. In Proceedings of the 19th ACM SIGSOFT Symposium andthe 13th European Conference on Foundations of Software Engineering, ESEC/FSE ’11,pages 168–178, New York, NY, USA, 2011. ACM.

[10] Scott Chacon et Ben Straub : Pro git. Apress, 2014.

[11] Christian Chauvigné et Jean-Claude Coulet : L’approche par compétences : un nou-veau paradigme pour la pédagogie universitaire ? Revue française de pédagogie. Recherchesen éducation, 172(3):15–28, 2010.

[12] Marco D’Ambros, Michele Lanza et Romain Robbes : Commit 2.0. In Proceedings ofthe 1st Workshop on Web 2.0 for Software Engineering, Web2SE ’10, pages 14–19, NewYork, NY, USA, 2010. ACM.

[13] Gibeon Soares de Aquino Júnior et Silvio Romero de Lemos Meira : Towards effectiveproductivity measurement in software projects. In Software Engineering Advances, 2009.ICSEA’09. Fourth International Conference on, pages 241–249. IEEE, 2009.

[14] Geneviève Duchesne : Expérimenter le travail d’équipe les clés de la réussite. Pédagogiecollégiale, 21(4):31–33, 2015.

[15] Christof Ebert et James Cain : Cyclomatic complexity. IEEE Software, 33(6):27–29,novembre 2016.

[16] Nancy Falchikov et Judy Goldfinch : Student peer assessment in higher education :A meta-analysis comparing peer and teacher marks. Review of educational research,70(3):287–322, 2000.

[17] Vivienne Farrell, Gilbert Ravalli, Graham Farrell, Paul Kindler et David Hall :Capstone project : Fair, just and accountable assessment. In Proceedings of the 17thACM Annual Conference on Innovation and Technology in Computer Science Education,ITiCSE ’12, pages 168–173, New York, NY, USA, 2012. ACM.

[18] Alain Finot : Développer l’employabilité. Insep Editions, 2000.

[19] Github : About pull requests. https:// help.github.com/ articles/ about-pull-requests/ ,2018. [En ligne ; Page disponible le 08 Mai 2018].

[20] GitHub : Contributions to master, excluding merge commits. https:// github.com/revelc/ formatter-maven-plugin/ graphs/ contributors, 2018. [En ligne ; Page disponible le07 February 2018].

[21] Gitlab : Commits to master, excluding merge commits. limited to 6,000 com-mits. https:// gitlab.com/ x_8355118canadainc/ x_8355118canadainc.gitlab.io/ graphs/master , 2018. [En ligne ; Page disponible le 07 February 2018].

74

[22] Gitstats : Authors. http:// gitstats.sourceforge.net/ examples/ gitstats/ authors.html ,2018. [En ligne ; Page disponible le 07 February 2018].

[23] Julia González et Robert Wagenaar : Contribution des universités au processus debologne. Une Introduction, 2007.

[24] Georgios Gousios, Eirini Kalliamvakou et Diomidis Spinellis : Measuring developercontribution from software repository data. In Proceedings of the 2008 InternationalWorking Conference on Mining Software Repositories, MSR ’08, pages 129–132, NewYork, NY, USA, 2008. ACM.

[25] Lassi Haaranen et Teemu Lehtinen : Teaching git on the side : Version control systemas a course platform. In Proceedings of the 2015 ACM Conference on Innovation andTechnology in Computer Science Education, ITiCSE ’15, pages 87–92, New York, NY,USA, 2015. ACM.

[26] Nicole Herbert : Quantitative peer assessment : Can students be objective ? In Pro-ceedings of the ninth Australasian conference on Computing education-Volume 66, pages63–71. Australian Computer Society, Inc., 2007.

[27] John Kelleher : Employing git in the classroom. In Computer Applications and Infor-mation Systems (WCCAIS), 2014 World Congress on, pages 1–4. IEEE, 2014.

[28] Lov Kumar, Sanjay Misra et Santanu Ku. Rath : An empirical analysis of the ef-fectiveness of software metrics and fault prediction model for identifying faulty classes.Computer Standards & Interfaces, 53:1 – 32, 2017.

[29] Oren Laadan, Jason Nieh et Nicolas Viennot : Teaching operating systems using vir-tual appliances and distributed version control. In Proceedings of the 41st ACM technicalsymposium on Computer science education, pages 480–484. ACM, 2010.

[30] Jacques Laliberté : Alverno : une réforme pédagogique riche d’enseignements. Pédagogiecollégiale, 2(4):38–42, mai 1989.

[31] Filippo Lanubile, Christof Ebert, Rafael Prikladnicki et Aurora Vizcaíno : Colla-boration tools for global software engineering. IEEE software, 27(2):52, 2010.

[32] Joseph Lawrance, Seikyung Jung et Charles Wiseman : Git on the cloud in theclassroom. In Proceeding of the 44th ACM Technical Symposium on Computer ScienceEducation, SIGCSE ’13, pages 639–644, New York, NY, USA, 2013. ACM.

[33] HaeJun Lee, Bon-Keun Seo et Euiseong Seo : A git source repository analysis toolbased on a novel branch-oriented approach. In Information Science and Applications(ICISA), 2013 International Conference on, pages 1–4. IEEE, 2013.

75

[34] Jalerson Lima, Christoph Treude, Fernando Figueira Filho et Uirá Kulesza : As-sessing developer contribution with repository mining-based metrics. In Software Mainte-nance and Evolution (ICSME), 2015 IEEE International Conference on, pages 536–540.IEEE, 2015.

[35] Robert Lingard et Shan Barkataki : Teaching teamwork in engineering and computerscience. In Proceedings of the 2011 Frontiers in Education Conference, FIE ’11, pagesF1C–1–1–F1C–5, Washington, DC, USA, 2011. IEEE Computer Society.

[36] Robert W Lingard : Teaching and assessing teamwork skills in engineering and computerscience. Journal of Systemics, Cybernetics and Informatics, 18(1):34–37, 2010.

[37] Jon Loeliger et Matthew McCullough : Version Control with Git : Powerful toolsand techniques for collaborative software development. " O’Reilly Media, Inc.", 2012.

[38] Oduar Mejia Lopez : Visualisation de la cohésion et du couplage du code Java. Thèsede doctorat, Université de Sherbrooke., 2011.

[39] Jennifer Marlow, Laura Dabbish et Jim Herbsleb : Impression formation in onlinepeer production : activity traces and personal profiles in github. In Proceedings of the2013 conference on Computer supported cooperative work, pages 117–128. ACM, 2013.

[40] Thomas JMcCabe : A complexity measure. IEEE Transactions on software Engineering,SE-2(4):308–320, 1976.

[41] Nora McDonald et Sean Goggins : Performance and participation in open sourcesoftware on github. In CHI’13 Extended Abstracts on Human Factors in ComputingSystems, pages 139–144. ACM, 2013.

[42] André N Meyer, Thomas Fritz, Gail C Murphy et Thomas Zimmermann : Soft-ware developers’ perceptions of productivity. In Proceedings of the 22nd ACM SIGSOFTInternational Symposium on Foundations of Software Engineering, pages 19–29. ACM,2014.

[43] Vu Nguyen, Sophia Deeds-Rubin, Thomas Tan et Barry Boehm : A sloc countingstandard. In Cocomo ii forum, pages 1–16, 2007.

[44] Alberto S. Nueez-Varela, Héctor G. Pérez-Gonzalez, Francisco E. Martínez-

Perez et Carlos Soubervielle-Montalvo : Source code metrics : A systematic map-ping study. Journal of Systems and Software, 128:164–197, 2017.

[45] Robert E Park : Software size measurement : A framework for counting source state-ments. Rapport technique, Carnegie-Mellon Univ Pittsburgh Pa Software EngineeringInst, 1992.

76

[46] GRAINE Rhône-Alpes : Evaluation : évaluer, pourquoi et comment ?http:// graine-auvergne-rhone-alpes.org/ index.php/ reperes-pour-monter-un-projet/evaluation.html , 2007. [En ligne ; Page disponible le 10 Novembre 2017].

[47] Mercedes Rico, Julian Coppens, Paula Ferreira, Héctor Sánchez et J EnriqueAgudo : Everything matters : Development of cross-curricular competences in engi-neering through web 2.0 social objects. In Ubiquitous and mobile learning in the digitalage, pages 139–157. Springer, 2013.

[48] Marc Romainville : Objectivité versus subjectivité dans l’évaluation des acquis des étu-diants. Revue internationale de pédagogie de l’enseignement supérieur, 27(2):1–9, 2011.

[49] JL Sanchez, CS Gonzalez et S Alayon : Evaluation of transversal competences inthe final year project in engineering. In EAEEIE Annual Conference (EAEEIE), 2011Proceedings of the 22nd, pages 1–5. IEEE, 2011.

[50] Keng Siau, Xin Tan et Hong Sheng : Important characteristics of software developmentteam members : an empirical investigation using repertory grid. Information SystemsJournal, 20(6):563–580, 2010.

[51] Miguel-Angel Sicilia : How should transversal competence be introduced in computingeducation ? ACM SIGCSE Bulletin, 41(4):95–98, 2010.

[52] Diomidis Spinellis : Git. IEEE software, 29(3):100–101, 2012.

[53] Jacques Tardif : L’évaluation des compétences. Documenter le parcours de développe-ment. Chenelière Éducation, 2006.

[54] Jacques Tardif et Bruno Dubois : De la nature des compétences transversales jusqu’àleur évaluation : une course à obstacles, souvent infranchissables. Revue française delinguistique appliquée, 18(1):29–45, 2013.

[55] Hamid Tohidi : Teamwork productivity & effectiveness in an organization base onrewards, leadership, training, goals, wage, size, motivation, measurement and informationtechnology. Procedia Computer Science, 3:1137–1146, 2011.

[56] Christoph Treude, Fernando Figueira Filho et Uirá Kulesza : Summarizing andmeasuring development activity. In Proceedings of the 2015 10th Joint Meeting on Foun-dations of Software Engineering, pages 625–636. ACM, 2015.

[57] Jason Tsay, Laura Dabbish et James Herbsleb : Influence of social and technicalfactors for evaluating contribution in github. In Proceedings of the 36th internationalconference on Software engineering, pages 356–366. ACM, 2014.

77

[58] Wikipedia : Learning cell — wikipédia, l’encyclopédie libre. https:// en.wikipedia.org/w/ index.php?title=Learning_cell&oldid=805314208 , 2017. [En ligne ; Page disponiblele 04 Décembre 2017].

[59] Wikipédia : Ligne de code — wikipédia, l’encyclopédie libre. http:// fr.wikipedia.org/w/ index.php?title=Ligne_de_code&oldid=105610505 , 2014. [En ligne ; Page disponiblele 27 Septembre 2017].

[60] Wikipédia : Commit — wikipédia, l’encyclopédie libre. https:// fr.wikipedia.org/wiki/Commit , 2016. [En ligne ; Page disponible le 27 Septembre 2017].

[61] Wikipédia : Swebok — wikipédia, l’encyclopédie libre. http:// fr.wikipedia.org/w/ index.php?title=SWEBOK&oldid=141555634 , 2017. [En ligne ; Page disponible le 15 Octobre2017].

[62] Wikipédia : Mainteneur — wikipédia, l’encyclopédie libre. https:// fr.wikipedia.org/wiki/Mainteneur , 2018. [En ligne ; Page disponible le 05 Mars 2018].

[63] L. K. H. Yanaze et R. de Deus Lopes : Transversal competencies of electrical andcomputing engineers considering market demand. In 2014 IEEE Frontiers in EducationConference (FIE) Proceedings, pages 1–4, 2014.

78