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, dans un tableau de bord, différentes informations en fonction de la période, de l’extension et de la branche choisies. En effet, pour chaque équipe, il montre la contribution quantitative apportée par chaque membre en termes de lignes de code et de commits. Nous retrouvons aussi, dans le tableau, un indicateur d’activité de chaque membre de l’équipe calculée à partir de l’évaluation de la régularité et de la dernière activité de chaque membre de l’équipe. Les résultats obtenus lors de l’utilisation de Gitanalysis sur les dépôts Git créés dans le cadre d’un cours nous ont permis de constater que l’on peut distinguer trois types d’équipe : les équipes fonctionnelles, les équipes passagèrement dysfonctionnelles et les équipes dysfonctionnelles.
Figure 5.9 – Év aluatio n des com binaison s p oss ibles des équip es formées de 4 et de 3 mem bres
5.6.1 Équipe fonctionnelle
Comme rappel, une équipe est dite fonctionnelle lorsque tous les membres de l’équipe sont actifs. L’indicateur d’activité de chaque membre et celle de l’équipe sont symbolisés par une flèche verte. Une équipe est également fonctionnelle lorsqu’elle est composée de membres actifs et de membres à surveiller et que ce sont les membres actifs qui sont majoritaires. L’indicateur d’activité de chaque membre est symbolisé par une flèche colorée soit en vert soit en jaune et l’indicateur d’activité de l’équipe est symbolisée par une flèche verte. Ainsi, en faisant l’analyse du dépôt de la Figure 5.10:
Figure 5.10 – Activité d’une équipe fonctionnelle composée des membres actifs avec travail bien réparti (extrait du tableau de bord généré par Gitanalysis)
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ées et supprimées soit respectivement 38.79%et 26.58% et ait fait le même nombre de commits que « . . . in » soit 11 sur un total de 35 commits, le reste de l’équipe a presque contribué de la même façon. En effet, nous pouvons voir que la répartition des tâches a été bien faite car tous les membres ont fait des contributions significatives. L’équipe est donc productive et ne demande pas l’intervention du professeur.
Il peut cependant exister des cas où une équipe soit composée de membres actifs qui ne contribuent pas au même degré comme l’illustre la Figure 5.11:
Nous pouvons constater que l’équipe « Commando » remplit également la première condition où 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 fait un travail régulier, il n’a presque pas contribué. En effet, il a ajouté 8.09% des lignes de code, supprimé 7.59% et fait 31 commits sur un total de 109. Nous pouvons imaginer que
Figure 5.11 – Activité d’une équipe fonctionnelle composée des membres actifs avec travail mal réparti (extrait du tableau de bord généré par Gitanalysis)
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 code aprè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 le membre qui a le plus contribué et même « . . . ar » aurait été considéré comme avoir apporté de grosses contributions. « . . . det » fait probablement partie de la catégorie des membres qui font un 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’est une partie d’une fonction qui l’est. L’équipe est donc productive bien qu’un de ses membres soit 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écessaire d’analyser les activités lues plus en détails. La Figure 5.12pré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)
Ici, et d’après l’indicateur d’activité, l’équipe « Mindstorm » remplit très bien la deuxième condition 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 respectivement 39.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, il a ajouté 9.76% des lignes de code, supprimé 8.52% et fait 5% des commits. On voit facilement que la régularité du membre influe sur la contribution qu’il apporte. En effet, moins il est ré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 de l’é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 encore que la moité est active et que l’autre moitié est à surveiller. L’indicateur d’activité de chaque membre est symbolisé par une flèche colorée soit en jaune ou soit en vert et en jaune tandis que l’indicateur d’activité de l’équipe est symbolisée par une flèche jaune. Ainsi, en faisant l’analyse de la Figure5.13, nous pouvons constater que l’équipe « Constructeurs » remplit très bien 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éparti leur travail car ils ont presque contribué de la même manière. « . . . EG1 » a supprimé plus de 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 soit 79%. Cela vient confirmer que l’on ne peut pas évaluer un membre de l’équipe en considérant uniquement un critère. En effet, en regardant seulement les commits, on aurait pensé que c’est
« . . . lan » qui a le plus contribué car il a fait presque le triple des commits. En réalité, cela est faux car les deux ont apporté des contributions significatives. Cette équipe est donc productive bien 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 bord généré par Gitanalysis)
L’équipe « Studio » remplit très bien la troisième condition où la moitié des membres est active et 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 fait plus de commits, soit 53 commits sur 110 (48%). Nous pouvons aussi remarquer qu’un des membres à 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’équipe a fait des contributions significatives. Cette équipe est en général productive mais 2 membres devraient ê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écessairement pas dire qu’elle a des problèmes de répartition de travail comme nous le montre la Figure5.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 » qui en a fait plus. Cependant, il faut noter que la différence n’est pas très importante avec les autres membres que ce soit pour les lignes de code ajoutées, celles supprimées ou encore les commits. En effet, le travail de l’équipe est bien réparti car chacun a apporté des contributions significatives. Cette équipe est également productive bien qu’elle ait besoin d’être surveillée par le professeur car la majorité des membres commencent à faire un travail irrégulier.
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 de l’équipe est à risque. L’indicateur d’activité de l’un des membres ainsi que celui de l’équipe sont symbolisés par des flèches rouges.
L’équipe « Gaff » de la Figure5.16est une équipe dysfonctionnelle car elle est composée d’un membre à risque et de 2 membres actifs.
Figure 5.16 – Activité d’une équipe dysfonctionnelle composée d’un abandon (extrait du tableau 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 au reste de l’équipe. En effet, il ajouté 6.9% des lignes de code, supprimé 8.27% des lignes de code et fait 6 commits sur un total de 90 soit 7%. De plus, il n’a pas fait de récente contribution car sa dernière actvité a été faite il y a 62 jours soit plus de 2 mois. On peut alors rapidement en 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é bien faite car ils ont tous les deux fait des contributions significatives. Ainsi, bien que l’équipe soit productive Gitanalysis permet de mettre en évidence les abandons.
Il est possible qu’un ou plusieurs membres d’une équipe utilisent différents ordinateurs pour partager leur travail et que ces ordinateurs soient configurés avec des noms différents. Si le membre utilise plus d’un ordinateur avec des configurations différentes, il peut biaiser le classement de l’équipe en la faisant apparaître comme dysfonctionnelle. Un exemple de cette situation est illustré par la Figure5.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ée de 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 travail irrégulier. En réalité, c’est la même personne qui a changé d’ordinateur pour partager son travail et les ordinateurs qu’il a utilisé étaient configurés avec des noms différents. A part ce biais, nous voyons que c’est « . . . ande » qui a le plus contribué avec 59.15% des lignes de code ajoutées, 76.78% des lignes de code supprimées et 95 commits sur un total de 164 soit 58%. Les autres 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 lignes de code, a supprimé 1.87% des lignes de code et a fait 11 commits. Cette équipe demande l’intervention du professeur car c’est seulement la moitié de l’équipe qui est régulier et qui fait des contributions significatives. Le professeur devrait aussi tenir compte des autres critères tels 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 contribue pas assez, faute sûrement d’une mauvaise organisation de l’équipe comme nous allons le voir dans la Figure 5.18.
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 de l’intervention du professeur car c’est une seule personne qui travaille régulièrement et qui fait des contributions significatives.