- 05.06.2016
Tout d'abord, je suis réellement désolé de la latence de correction dont vous avez été victimes.
Sur la qualité du code : S'il y a globalement une amélioration par rapport au premier semestre, la conception de vos systèmes est encore très limite, d'un point de vue "orientation objet". Vous avez trop tendance a écrire du code "qui marche" et à vous en contenter, là où on va attendre d'un ingénieur une capacité à refactorer ce code fonctionnel pour le rendre meilleur. Vous vous arrêtez souvent trop tôt dans cette démarche, et si vous n'investissez pas plus dans le code et la technique pour aller plus loin sur certains points (modélisation, héritage, généricité, reflexivité pour certains, ...), vous risquez de vous heurter à un plafond de verre pour la suite de vos études et de votre vie professionnelle.
Sur la conduite de projet : Là on tombe plus volontiers dans le film catastrophe. Il faut que vous preniez conscience que pour la suite de vos études dans le département vous serez obligé de travailler en équipe, en utilisant des outils de suivi pour vous synchroniser. On travaillera plus précisément la spécification et l'estimation pendant les projets de 4A, cependant il vous restera une grosse marche a franchir l'an prochain sur ce point car le cours de GL est considéré acquis pour un certains nombre de cours par la suite. A l'échelle de la promo, vous laissez trop peu de tickets pour que quelqu'un d'autre que vous puisse travailler efficacement sur le projet. Idem pour les tests, la plupart du temps ils existent mais apportent peu de valeur au projet car très difficile a lire et a comprendre.
Sur la satisfaction du client : Un point important sur la matière QGL est la livraison de valeur en continue. A été pris en compte dans la notation:
- votre capacité a livrer (malus pour livraisons ratée en seconde période);
- la valeur de votre livraison finale, i.e., le résultat de votre bot final lors de la retrospective sur toutes les iles;
- la régularité de votre bot sur les différentes livraisons
- Moyenne 9,84/ 20 (stdev: 3,84); min: 0; max: 17,5.
L'évaluation a portée sur:
- 15%: le ticketing
- 10%: la gestion de version
- 20%: la qualité des tests
- 25%: la qualité du code métier
- 30%: la satisfaction client
On voit globalement deux gaussiennes sur les moyennes de projets. Une première centrée sur 7, et une seconde centrée sur 14. Cela correspond a 2 types de projets. Ceux de la première gaussienne, sont "techniques", i.e, correspondent à du code faisant plus ou moins ce qui est demandé par le client, sans plus de reflexion. Les second sont au niveau de ce qui est attendu en fin de 3A, et mettent en avant des capacité de conduite de projet et une démarche d'ingénierie qui dépasse la simple programmation.
Pour basculer de la première a la seconde catégorie, il faut impérativement que vous adaptiez votre manière de faire en considérant que l'objectif n'est pas d'écrire du code, mais bien de développer un produit logiciel, avec toutes les différentes facettes que cela implique. si vous restez "bloqués" sur votre lancée actuelle, vous allez heurter un plafond de verre en 4A, puisque les cours de 4A partent du principe que vous savez généraliser ce que vous avez vu dans votre cursus précédent, et le réutiliser dans d'autres contextes, l'adapter a vos besoins, ...
A gros grain, on voit que la partie "Technique" de vos projets (code metier & test) est souvent "raisonnable". C'est la dimension ingénierie logicielle (donc tout ce qu'il y a dans le travail d'ingénieur en informatique en plus de simplement programmer) qui est encore a travailler pour la majorité des groupes.
Si vous souhaitez plus de détail sur le projet de votre équipe, contactez moi avec les questions que vous vous posez.
- Les tickets sont globalement succints, et mériteraient plus de travail dans leur définition pour les rendre plus utile à l'équipe;
- Il ne reste que 4 tickets open, comment continuer le développement du produit avec si peu d'indications?
- Développement déséquilibré dans l'équipe.
- Bon maintien du lien avec les tickets
- code de bonne qualité, documenté.
- Les tests ne servent pas a vraiment comprendre le projet depuis l'exterieur.
==>> Vous prenez la majorité de vos points sur le code, et trop peu sur la conduite du projet. Il faut progresser sur ce point.
- The tickets will not be usefull for new engineers integrating the teams (no description, ...)
- work is not balanced inside the group. Some resources are key ones, others does not seem to have helped the project
- good links between tasks and commits
- code quality is above average, but could be dramatically improved by taking into account a comprehensive view of the problem. You should decompose your problems into smaller ones, and declare better responsibilities for your classes.
- Be careful when imbricating for / if / for / if / ...
- Tests are ok, but could better help the understanding of the project by being more explicit
- (optional: the name of your team was the best one this year)
==>> There is a huge amount of work in this project. Unfortunately this work looks dissolved inside the project complexity. I am convinced that with a better focus on what is valuable and what is not, you'll really improve the results obtained in a software development project.
- Il y a des pistes a suivre dans le système de tickets, mais pas de description pour savoir quoi faire.
- aucune régularité dans le développement du projet
- bonne idée d'avoir testé les cas exceptionnel et d'utiliser des
expecteddans vos classes. Bonne utilisation des contexte de tests. - Qualité du code déraisonnable. Trop peu de responsabilisation, classes de trop grande complexité. Alors oui ça marche ... mais on attend plus que ça en fin de 3A.
==>> Il faut arriver a aller plus loin, et a livrer du code ayant un niveau de qualité raisonnable, avec la spécification associée. Pensez équipe et "produit logiciel" et pas simplement dèv et "tache a faire", prenez du recul et élargissez vos perspectives.
- Beaucoup de tickets ouverts pour la suite. Description succinte mais existante. Bonne utilsiation des sous taches
- le lien tickets - code est encore trop ténu, Ne commitez pas avec uniquement les nº de tickets, on y comprend rien a la lecture de l'historique;
- disparité dans l'effort de développement au sein de l'équipe
- le code de tests est utile, mais contient trop souvent de la duplication, ce qui le rend peu maintenable. C'est dommage.
- du point de vue du client, aucun contrat n'a jamais été ramené => vous perdez gros la dessus.
==>> Il faut pour la suite cibler ce qui a de la valeur dans votre developpement. Qu'un sujet ne vous intéresse pas, soit. Par contre, si vous fournissez un effort (même minimal), il faut organiser cet effort pour qu'il vous rapporte un retour sur investissement, et maximiser ce retour. En étant plus concentré sur les préoccupations du métier (i.e., faire ce que le client demande), vous auriez pu passer la barre du 10 sans soucis.
- Les tickets ont présents pour la suite, mais pas de description.
- trop peu de lien entre code et tickets. Beaucoup d'activité sur le code non spécifiée.
- disparité dans le développement du projet, une ressource critique.
- du point de vue du client, trop peu de valeur métier livrée (contrats ramenés) => vous perdez gros la dessus.
- Tests compréhensibles, mériteraient d'être ré-écrit pour être plus maintenable (visibilité des attributs par exemple).
- Qualité du code assez horrible par endroit. MissionAssignmenent est beaucoup trop complexe, il faut impérativement arriver a la décomposer en sous classes par stratégies.
==>> Vous perdez très gros sur votre incapacité a récolter des contrats. Il faut être plus distribués dans la manière de répartir le travail dans l'équipe (ou en tout cas dans vos contribution au projet), et surtout remplir l'objectif demandé par le client !
- taches peu décrites, et peu de taches restantes pour la suite
- Beaucoup trop d'activité sur le code qui ne sont pas relié à des taches
- Des commits trop gros, et peu d'exploitation des capacités de versionnement de Git
- Problème de qualité dans le code, beaucoup de code lourd et qui pourrait être refactoré de manière beaucoup plus maintenable et extensible. Par exemple SearchingInlandState est atrocement complexe et devrait être décomposée.
- Tests compréhensible pour rentrer dans le projet,
==>> il faut identifier des taches plus verticale dans votre manière de développer votre projet pour pouvoir livrer de la valeur plus tôt. Ne négligez pas la qualité de votre code.
- Tickets OK, mériteraient plus de rigueur dans le formalisation de la terminaison.
- développement irrégulier, des commits trop gros.
- déséquilibre dans le groupe
- lien entre les tickets et le code OK
- d'un point de vue qualité, c'est très hétérogène. Pas mal d'horreurs (d'un point de vue objet / responsabilisation) dans la classe Island, qui est pourtant cruciale dans le projet
- Vos tests sont ... costaud a lire et a comprendre !
- Très bonne livraison de valeur en continue sur la seconde partie du module (la seule évaluée ici). C'est beaucoup plus discutable sur la première partie.
==>> Bon boulot. Pour vous améliorer, pensez a clarifier vos spécifications dans les tickets et a travailler vos tests pour les rendre utile a la compréhension de votre code.
==>> Bon boulot. Pour vous améliorer, pensez a clarifier vos spécifications dans les tickets et a travailler vos tests pour les rendre utile a la compréhension de votre code.
- bonne description des tickets.
- trop d'activité sur le code qui n'est pas en lien avec les tickets identifiés.
- grosses disparités dans l'implication dans le développement du projet;
- Les tests sont utile pour comprendre le projet, bonne utilisation des before/after
- Qualité OK, mais attention aux nombres magique dans le code et autre constantes en dur.
==>> bon boulot. Dommage que la disparité d'implication dans le projet ait entrainée un ralentissement du projet, vous auriez pu faire quelque chose de bien plus abouti avec plus d'implication de tout le monde.
- les tickets sont présents, mais impossible a comprendre hors de l'équipe. il faut travailler les description, qui sont souvent inexistantes.
- lien code - tache ok. Pensez a être descriptif dans vos messages de commits, l'historique est chaud a lire vu de l'extérieur.
- Vos tests sont un peu brutaux. Utilisez mieux les before/after et les capacité de "code" de vos tests (qui sont des classes comme les autres).
- Mocks utilisés a bon escient, bonne idée
- Pas mal de complexité dans des classes clés du projet (e.g., AirMap). Il faudrait décomposer et mieux responsabiliser (la carte pourrait utiliser des "finders' pour trouver les cases interessante plutôt que d'en porter la responsabilité)
- Coté client, un passage a vide au milieu du demi-semestre qui vous empêche de livrer de la valeur en continue. C'est un peu dommage.
==> C'est un bon projet, mais il manque de régularité dans ce que vous avez été en capacité de livrer. Essayer de mieux vierticaliser vos développement, et de garantir que vous faite "mieux", ou en tout cas "pas moins pire" a chaque itération.
- Spécification light, des tickets pour la suite mais peu décrits.
- Globalement peu de description des taches, et peu de cohésion d'équipe sur la spécification.
- Lien entre le code et les taches trop imprécis. vous devez être capable de relier votre effort de développement a des taches ayant une utilité pour le client.
- Les tests sont un peu bourins et mériterait d'être écrit de manière plus maintenance.
- Problème de responsabilisation / découpage dans le modèle objet. Contracts par exemple ...
- Livraison de valeur après un gros effet tunnel ayant duré tout le semestre.
==>> votre équipe sait développer, vous le prouvez en livrant un truc "raisonnable" a la fin. Seulement ça n'a rien de prévisible, et aucune garantie n'est donné lorsque vous avancez. Ça passe ou ça casse, a coup de nuits blanche et avec un gros rush sur la fin. Ce n'est plus acceptable en fin de 3A.
- beaucoup de tickets pour poursuivre, descriptions inégale cependant.
- répartition inégale dans le code et dans la spec
- lien code - tache qui pourrait être plus renforcé
- implication très inégale des membres de l'équipe dans le dévelopement
- Livraison de valeur après un gros effet tunnel ayant duré tout le semestre.
- Attention aux valeur magique dans le code (Compass). toujours dans compass, il y a un modèle de calcul plus élégant que des switch cases pour faire ce que vous faite. globalement votre code est un peu trop "brut" et mériterait une passe de remise au propre.
==>> Vous perdez beaucoup sur l'absence de livraison de valeur. Ceci étant dit, le travail d'ingénierie logicielle associé à ce projet n'est pas raisonnable en fin de 3A, il faut mieux travailler la spécification et le travail de groupe pour livrer ce qui répond aux demandes du client.
- 2 tickets ouverts pour la suite ? Le projet est réellement terminé ?
- Trop peu de description dans les tickets.
- Implication inégale des membres de l'équipe dans le développement du projet
- Les tests sont ultra-bourins, très répétitifs et lours a lire. Exploitez mieux le fait qu'un test reste du code avant tout.
- La qualité du code "main" est raisonnable. Pensez par contre a mieux travailler votre modèle objet pour le rendre plus manipulable (Memory).
==> avec plus d'implication et plus de rigueur, vous vous en seriez mieux sortis ... c'est dommage.
- Peu de tickets ouverts pour continuer le projet.
- Trop peu de description dans les tickets. Comment les comprendre si on est pas "vous" ? ("Implémenter la manufacture sur les steps terrestres" ?)
- Implication inégale dans le groupe, même si un réveil sur la fin.
- bon lien entre le code et les tickets. Mais les messages de commits, on en parle ? "small motifs", "test v1", ... On perd l'intérêt de l'historique.
- Gros travail sur les tests, c'est perfectible a plein d'endroit mais globalement pas mal
- code de bonne qualité, certains points améliorable comme les stratégies par exemple qui pourraient être modularisée.
==>> c'est un bon projet pour la partie technique. Il faut cependant progresser sur la conduite du projet pour être plus en maitrise de ce que vous faites. Vous ramenez au final peu de contrats, en orientant votre effort de développement sur ce qui a vraiment de la valeur client, vous auriez pu perdre moins de temps sur des détails et livrer un très bon projet.
- Beaucoup de tickets pour la suite, bonne description
- bonne utilisation du ticketing pour spécifier le produit ET les outils développés en // du produit
- cependant de gros déséquilibre / absence d'implication dans le dèv
- lien tache code ok
- dommage de ne pas livrer le dashboard sur la branche principale
- gros travail sur les tests
- Le code reste perfectible sur de nombreux points. Le mieux est l'ennemi du bien. Essayez de bien maitriser les briques de bases pour ne pas construire du code "artificiellement trop complexe": faire simple, c'est compliqué.
- livraison de valeur en continue pour le client, très bien
==>> Le projet aurait pu être excellent. Il y a une problématique de dynamique de groupe qui a conduit a la création de deux projets dans le projets, de manière un peu tardive. Il faut dans un cas accepter d'aller moins vite au début pour que le groupe puisse contribuer dans son ensemble, et dans l'autre cas arriver a rentrer dans une architecture de code qui n'est pas forcément la votre pour pouvoir y contribuer.
- Des tickets pour la suite, souvent bien décrit. Vous avez perdu la DoD que vous mettiez systématiquement dans vos tickets en cours de route, c'est dommage, c'était une bonne idée.
- implication totalement inégale des membres de l'équipe
- le lien entre code et taches n'est pas assez maintenu
- les tests sont bourrins, et mériteraient d'être travaillé de manière plus maintenance. Peu d'utilisation des before/after pour mettre en place des contexte de tests par exemple.
- Des classes sensiblement trop complexe (Contract). La gestion es exception est étrange, et vous reposez beaucoup sur les types de java sans justification (beaucoup de maps).
- Coté livraison de valeur on est pas mal,
==>> Il faut maintenir l'effort de spécification et le lien entre spec et dèv, et investir plus dans la qualité des tests pour la suite.
- tickets existants, et venant avec une DoD.
- Effort non régulier sur le développement du projet.
- La qualité du code n'est pas au niveau. La class eIslandMap cristallise tout ce qu'il ne faut pa faire: grosses responsabilités, mauvaise mndularisation, mauvaise définition du domaine, ... exploitez le paradigme que vous utilisez, ici l'objet, plutôt que d'essayer de faire du procédural a tout prix. On serait en C mon discours serait différent. Mais là vos objets n'en sont pas, et comme le langage est un langage objet, vous ne l'utilisez pas a bon escient.
- Les tests sont confus, et mériteraient un bon coup de nettoyage (des classes vides ou commentées) / refactoring pour être réellement utile. Utilisation des contexte before/after qui pourrait encore s'améliorer. La couverture est très limite.
==> C'est "moyen" au final, sur beaucoup de points. il faut creuser plus, et aller plus au fond des choses pour changer de type de projet et basculer dans la catégorie du dessus. Tant sur le code que sur la conduite du projet.
- Des tickets pour poursuivre, et une description raisonnable.
- Très bonne idée d'avoir réifié la valeur client dans les description.
- Implication inégale des membres de l'équipe
- les tests sont OK, mériterait une meilleure utilisation des contexte before/after
- Complexité totalement déraisonnable de certaines classes (SailorsStrategy par exemple) . Attention a la visibilité des attributs.
- Livraison de valeur au client uniquement sur la fin.
==>> le projet semble s'être essoufflé après le premier semestre, avec un sursaut dans la dernière ligne droite. C'est vraiment dommage, plus de régularité vous aurait permis de livrer un code de meilleure qualité (le temps de refactor), et surtout d;'arriver plus tôt aux objectifs du client.
- Les tickets ne sont pas orienté par le métier de l'utilisateur.
- bonne description des commits dans les logs
- les tests sont inégaux, pas d;utilisation des contextes, beaucoup trop de code commenté. Il faut nettoyer son code, et les tests font parti du code.
- Beaucoup de complexité dans les classes.
- La note de projet tient compte du fait que le projet a été réalisé seul.
==>> Il y a une vraie progression depuis le premier semestre. Cependant il y a ne core beaucoup de travail a accomplir pour arriver à livrer du code de qualité au niveau attendu pour une fin de 3A. Le mauls de 5 points sur la moyenne pour les 6 livraisons ratée n'aident pas non plus. Il faut se concentrer sur ce qui génère du retour sur investissement: il est inutile de mettre de l'effort dans le code tant qu'on arrive pas a le livrer correctement au client.
- Peu de tickets spécifiés pour la suite
- La description des tickets varie énormément de l'un a l'autre, Ça manque de cohérence
- peu de lien entre taches et code.
- déséquilibre dans l'implication dans le code
- Les fichiers devraient être des ressources et non des Files dans les tests.
- Tests ok, pourraient cependant être mieux exploité pour aider a la compréhension du code métier
- Attention a la complexité de vos fonctions ... FindStrategy::findNearestTile -> for/for/if/for/if imbriqués !
- Responsabilisation de vos classes aussi discutable. Est-ce la responsabilité d'une classe décidant de la stratégie a appliquer de savoir calculer où est la case la plus proche ?
- bonne régularité de livraison, a part le petit tunnel de refactoring qui aurait pu être évité.
==>> Le projet aurait pu être excellent. Au final il est "moyen", sur beaucoup de plans. Il faut que vous concentriez vos efforts sur la bonne utilisation des paradigmes à votre disposition. Particulièrement dans votre cas il faut améliorer la qualité du code livré, d'un point de vue objet.
- Des tickets laissé pour la suite, mais une vision à très court terme du produit;
- les descriptions sont inégales, des fois détaillées et complètes, des fois totalement absentes
- Absence d'implication totalement déraisonnable de certains membres de l'équipe dans le code
- Impression d'essoufflement depuis le premier semestre, trop peu d'activité
- Bonne régularité de livraison, mais due a de la chance plus qu'a une réelle amélioration continue du produit.
- Tests ok. attention a la visibilité des éléments, et a les exploiter pour aider a la compréhension du code métier.
- Attention a la responsabilisation de vos classes. Par exemple DroneState.
==>> C'est vraiment dommage. Là aussi, le projet aurait pu être excellent.
- des tickets pour la suite, plutôt bien décrit
- La description des tickets reste globalement inégale. Il faut être plus consistant.
- Qualité du code OK, attention aux convention Java sur des points de détails.
- répartition inégale dans le groupe.
==>> Le projet donne l'impression de s'être essoufflé, et d'une absence de rigueur et de discipline qui aurait permis de le mener a bout. Techniquement ça passe, mais dans la conduite du projet il y a encore beaucoup de progrès a faire.
- Des tickets pour la suite, avec une visibilité plus longue que la moyenne sur ce qui reste a faire.
- Pas de description des tickets sur la fin du projet.
- Répartition inégale dans l'équipe.
- attention dans les messages de commits a être vraiment utile pour le reste de l'équipe. Peu d'intérêt de commuter 3 fois de suite avec le même message.
- Responsabilisation des classes améliorables. Par exemple le finder pourrait être responsabilisé différemment et surtout modularité.
- gros travail sur les tests. Possibilité de nettoyer un peu la base de test pour la rendre plus maintenable.
- bonne livraison de valeur en continue
==>> Le projet est de bonne facture, mais porté par une seule personne dans l'équipe. Il faut plus d'implication globale pour pouvoir aller plus loin et mieux creuser les points durs.
- Seulement 3 tickets a disposition, pas de description. que veux dire "parcourir l'île de manière optimale" ?
- Le système de tickets semble complètement abandonné.
- Ça se voit sur le code, peu de lien entre les codes livrés et les taches.
- Beaucoup de complexité accidentelle dans le code livré, beaucoup de dette au final par accumulation de déviations.
- Grosses disparités dans le développement du produit
- Les tests sont trop légers
- Pas de livraison de valeur au final
==>> J'ai l'impression que tout le monde a perdu son temps dans ce projet, vous coté étudiants et nous coté enseignant. Pas d'implication, et au final si techniquement vous êtes capable de livrer bien mieux que ce que vous avez livré ici, il ne faut pas sous-estimer la nécessité de travailler a plusieurs dans la développement d'un projet. Si tout le monde tire dans des directions différentes, ça s'écroule ...
- quelques tickets pour la suite, mais peu de description. Que veux dire "baisser la dette actuelle" ?
- lien tache code ok.
- déséquilibre dans le groupe
- tests permettant de comprendre le métier. Attention à mieux utiliser le framework, typiquement sur les contextes (before/after).
- attention votre gestion d'exception dans le code. Que vous attrapiez les exceptions pour ne pas mourir a du sens, mais vous devriez logger que de telles exceptions ont eu lieu, vous passez trop de choses sous silence dans l'implèm.
- Attention a la responsabilisation / modularisation de vos classes.