UE Projet M2 TIW

Responsable de l’UE : Emmanuel Coquery

Les informations sur cette page sont suceptibles d’évoluer

Principe

Il s’agit, en travaillant en groupes conséquents (environ 6 personnes), d’effectuer un développement logiciel. L’accent sera mis sur les aspects suivants:

• organisation du groupe
• suivi de l’avancée du projet
• gestion des imprévus et estimation de leurs impacts
• maintenabilité de l’application

Organisation

Calendrier

Semaine du 21/10

• 23/10 matin:
  • constitution des groupes (cf groupes)
  • choix des sujets
  • désignation d’un chef de projet pour chaque groupe (chargé en particulier de communiquer à l’extérieur du groupe, par exemple avec le responsable de l’UE)
  • réflexions sur les rôles de chacun dans le projet
• 24/10 matin:
  • réflexions initiales sur le projet:
    • identification des contraintes fonctionnelles / non fonctionnelles
    • choix des technologies utilisées
  • identification des besoins en formation au sein de l’équipe
  • auto-formation sur les technologies du projet
• 25/10 matin:
  • mise en place d’un projet embryonnaire par les sachants techniques:
    • applications vide (page d’accueil)
    • système de build, packaging, etc
    • système de test automatisé
    • connexion aux bases de données le cas échéant
    • documentation / aide à la mise en place de l’environnement de développement sur les machines des différents membres du groupe
  • auto-formation sur les technologies du projet
  • à partir de 10h45: point avec le responsable de l’UE pour chaque groupe

Groupes

Les groupes sont à constituer selon les contraintes suivantes :

• au moins un membre de chaque catégorie (la catégorie de chaque étudiant est indiquée dans tomuss dans l’UE projet, si aucune catégorie n’est indiquée, cela correspond à la catégorie E)

Selon le nombre d’étudiants présents concrètement, on respectera les contraintes suivantes sur les groupes:

Si ces contraintes ne sont pas satisfiables, faire au plus proche, les groupes seront ensuite validés définitivement le 25/10.

Les attributions de rôles au sein des groupes seront systématiquement doubles. Chaque personne se verra attribuer un rôle technique et un rôle organisationnel. Chaque groupe est libre des choix de rôles à pourvoir, dans la limite des contraintes suivantes:

• pas de doublons dans les rôles organisationnels
• chaque groupe doit posséder:
  • un chef de projet
  • un architecte
  • des référents techniques sur les technologies principales du projet
  • un responsable qualité

Le rôle de développeur est particulier et est endossé par chacun des membres de l’équipe.

Quelques rôles organisationnels possibles :

• chef de projet: assure la communication avec le client (ici le responsable de l’UE) et le suivi du projet
• assistant chef de projet: aide au suivi du projet, en particulier sur la construction d’indicateurs de progression
• responsable qualité: décide les normes de qualité et mets en place l’outillage permettant de garantir/mesure la qualité
• scrummaster (ou assimilé): anime les différentes réunions au sein de l’équipe, assure la fluidité de la communication au sein de l’équipe
• responsable de la documentation: décide et met en place les outils de documentation code, développement, utilisateur
• product owner: décide des orientations du projet, typiquement en termes de fonctionnalités, est responsable de l’écriture des spécifications (e.g. user stories)
• web designer: gère la charte graphique de l’application et met en place les maquettes de l’interface de l’application.
• UX designer: assure que l’application est ergonomique.

Quelques rôles techniques possibles :

• développeur
• architecte: responsable de l’organisation technique du projet, de la décomposition de l’application en “modules”, de la faisabilité technique des solutions envisagées.
• référent technique: personne ayant l’expertise la plus élevée sur un produit / framework / bibliothèque donné.
• responsable qualité: assure la qualité du code, en mettant en place des conventions de formattage de code, des indicateurs de qualité comme la couverture du code par les tests unitaires, des outils de linting, etc.
• ops: chargé du déploiement de l’application et de son suivi opérationnel (monitoring). Peut également aider à la mise en place des pipelines d’intégration continue.

Ces rôles sont des suggestions et il est possible d’introduire d’autres rôles, par exemple issus de l’expérience passée en entreprise.

Il est à noter qu’être responsable ne veut pas dire faire à la place des autres. Il s’agit plutôt de préconiser, voire décider des normes et des (bonnes) pratiques à adopter au sein du projet. Il peut aussi mettre en place des outils afin d’aider l’équipe à respecter ces conventions. À titre d’exemple, ce n’est pas au responsable qualité de corriger le code de ses collègues. Par contre, il aura un rôle de surveillance et devra éventuellement agir, par exemple en alertant l’équipe sur une dérive de qualité.

Sujets proposés