méthodologie pour un cours en équipe

Question

J'ai besoin d'une méthodologie pour organiser mon équipe pour une mission universitaire. Je suis un étudiant universitaire et j'ai déjà de l'expérience en programmation. Mon expérience de travail en équipes de plus de 2 personnes sur un projet relativement important est que tout se fait habituellement très rapidement et très mal la semaine dernière à cause de problèmes de planification, d'organisation et de communication. En janvier, je devrais faire un projet de programmation (assez difficile pour mes compétences) (application Java sur Oracle) dans une équipe de 6 personnes. Je connais déjà les membres de mon équipe et j'ai été élu chef de projet. Il ne sera pas réaliste de s'attendre à ce que les gens se réunissent pour un temps significatif - tout le monde est libre à un moment différent et probablement rien de plus qu'une réunion d'une heure par semaine est réaliste. Les gens travaillent dur et sont dévoués au succès, mais chacun a sa propre situation. Le travail le plus souvent distribué est la voie à suivre. J'ai regardé XP, Scrum, mais ils ont tous besoin de s'asseoir ensemble (improbable), visant le développement à plein temps d'un projet (les gens ont d'autres tâches et des emplois à temps partiel) et la participation des clients (nous allons avoir des spécifications écrites et, en ce qui concerne l'expérience, les courriels du tuteur recevront une réponse au mieux dans 2-3 jours).

Des suggestions comment organiser les gens et diviser le travail? Je suis sérieux sur la recherche sur ce sujet, car il y aura beaucoup plus de ce genre de travaux plus tard.

Toute aide appréciée.

Answer 1

J'étais l'un des leaders d'un projet d'équipe (6 personnes) l'année dernière à l'université. Basé sur mon expérience, j'ai quelques points clés. Alors que les forums, le chat en ligne, l'email, les messages de validation SVN, etc. sont de très bons mécanismes de communication (et je les recommande), rien n'est plus important que les réunions hebdomadaires. Celles-ci devraient impliquer de déléguer/discuter/surveiller les tâches, parler des questions générales et de la situation dans son ensemble, prendre des décisions de groupe, et simplement utiliser votre application et identifier les problèmes avec elle en tant que groupe. En faisant cela, il devient immédiatement évident où les gens sont à leurs tâches, où ils peuvent être confus, et s'ils comprennent ce qui doit être fait.Ceci est crucial car le sentiment d'être «perdu» et de ne pas savoir par où commencer est souvent le plus grand obstacle à la progression, plutôt que la paresse. Et d'ailleurs, les décisions de groupe sont mieux faites en personne où vous pouvez échanger des idées les uns des autres ... et tout cela contribue à établir un sentiment de propriété partagée.

Il n'existe pas de meilleure façon de formuler, de déléguer et de surveiller les tâches. Mais il est important que vous puissiez diviser et paralléliser (autant que possible) la charge de travail en tâches de taille raisonnable et identifier les dépendances entre elles. Notre groupe a maintenu un fichier TODO dans notre dépôt qui consistait en une liste de tâches, de dates et de bogues. Nous avons hiérarchisé les tâches en fonction de facteurs tels que les exigences obligatoires ou facultatives (pensez MoSCoW), si elles étaient sur le chemin critique, combien de risque/incertitude leur était attaché, etc. Nous avons affecté une ou deux personnes à la plupart des tâches. sur leurs forces et s'ils voulaient réellement faire la tâche, mais nous avons également laissé certaines tâches ouvertes à quiconque les voulait (c'est potentiellement dangereux aussi). Quelques-uns d'entre nous, les programmeurs les plus forts, ont également joué des «rôles flottants», ce qui signifie que nous pouvions aider avec n'importe quelle tâche. Un point clé est que les descriptions de tâches doivent contenir tout ce qui a été discuté lors de la réunion ... le quoi, le pourquoi et quelques phrases de "comment" comme un kickstart (c.-à-d. "Pour accomplir ceci, vous voudrez peut-être lire blablabla") ... tout ce qui en fait facile pour vos coéquipiers de glisser dans une tâche.

Answer 2

Quelques réflexions:

• Communication - peut-être utiliser IRC ou un wiki
• Affectation de personnes à des tâches - vous devez savoir où les forces et les faiblesses des gens se trouvent, briser le projet en morceaux et affecter Surveillance en conséquence - un gros problème avec les projets où les gens travaillent à distance est qu'ils ne peuvent pas faire le travail à temps; vous devez réfléchir à la façon de garder le contrôle (par exemple, utiliser le contrôle de version, et regarder les check-ins) - pour que cela fonctionne, tout le monde doit l'acheter à l'avance
• Réserve stratégique - ça pourrait être ça vaut la peine d'avoir une personne (peut-être vous si vous êtes le programmeur le plus fort) qui accomplit des tâches que d'autres personnes trouvent difficile d'empêcher les autres de s'embourber

Answer 3

Bien que n'étant pas un projet de programmation, je suis actuellement un poste similaire à vous - chef de groupe élu dans une affectation de groupe de 5 personnes. Nous aurons terminé deux semaines plus tôt, donc je dirais que le groupe a été un succès. Quelques choses que je l'ai fait, en tant que chef de groupe, pour faire en sorte que ce qui est arrivé (je dessine aussi sur l'expérience de la gestion de projets dans une situation « monde réel », ont donc peut-être un peu plus d'avantage):

• Set règles de base de l'offset. Assurez-vous que tout le monde sait ce que l'on attend d'eux: la présence aux réunions, les échéances de travail, que faire en cas de difficulté. Nous avons un système à notre université où les gens peuvent être retirés des groupes s'ils ne «pèsent pas» leur poids. Si votre université a une chose similaire, les mesures prises pour vous d'initier cette procédure doivent également être décrites. Par exemple, manquez deux réunions et vous serez 'cardé jaune'. Mlle un autre, alors c'est un 'carton rouge'.
• Divisez l'affectation en blocs gérables, puis choisissez une ligne de temps. Si vous savez déjà ce qui devrait être fait chaque semaine, il sera beaucoup plus facile d'assigner des tâches chaque semaine. Ou, bien sûr, quelle que soit la période que vous choisissez.
• Réunions.Il devrait y avoir une réunion initiale où tout ce qui précède est décidé, probablement une réunion plutôt longue (notre première réunion a duré 90 minutes). Lors de cette réunion, définissez les tâches à accomplir avant la prochaine réunion. Ensuite, lors de chaque réunion subséquente, validez le travail effectué par chaque personne, en veillant à ce qu'il soit complet et correct. Et puis, bien sûr, déléguer les tâches à accomplir pour la prochaine réunion. Et ainsi de suite ...
• Chaque personne, paire ou autre, devrait partir et faire le travail elle-même, indépendamment. Parce que les temps de réunion sont si courts (tout comme les nôtres), ils doivent s'assurer que tout est terminé, que les plans sont faits et que les tâches sont déléguées.
• Communication. J'ai mis en place un forum pour que les membres de mon groupe communiquent sur le travail qu'ils font et téléchargent le matériel complété. J'ai aussi un sous-forum spécifique où les gens peuvent poster tout problème qu'ils pourraient avoir - avec une règle qu'ils devraient le faire dans le temps de la prochaine réunion - afin que d'autres puissent aider, ou des tâches peuvent être réaffectées. Il est important que chaque réunion comporte un compte rendu et un ordre du jour pour la prochaine réunion. Je les ai téléchargés sur le forum afin que tous ceux qui ont manqué une réunion ne soient pas laissés dans l'ignorance et sachent exactement ce qu'ils doivent faire.

Parce que votre projet est un projet de programmation, ce qui suit pourrait bien aider le séjour de groupe organisé et cohérent:

• Dès le début - de préférence à la première réunion - briser votre programme en « modules » ou des classes/procédures/peu importe; En gros, des blocs de code autonomes, gérables et à écrire. Ceux-ci peuvent ensuite être assignés à quelqu'un chaque semaine. Pour vous assurer que vous ne perdrez pas de temps à changer de code plus tard, décidez de vos variables globales, le cas échéant. Il peut être judicieux de décider également des méthodes et des propriétés de chaque classe avant le début du codage.
• Comme suggéré par sgolodetz, vous pouvez également utiliser le contrôle de version pour garder une trace du code lors de son écriture. Encore une fois, si vous faites cela, assurez-vous que les règles/directives sont en place pour quand et à quelle fréquence mettre à jour.
• Peut-être organiser que les personnes travaillant sur des tâches connexes se rencontrent entre les réunions pour s'assurer que leur code s'intègre bien. De cette façon, ils peuvent travailler ensemble pour s'assurer que le code de chaque personne «coopère» avec celui de l'autre.

Je pense que la clé ici doit être organisée. Ayez un plan strict et détaillé et respectez-le autant que possible.

À l'université, au moins, je pense qu'il est important d'avoir une certaine dose de cruauté - rappelez-vous que si les gens ne pèsent pas, cela affectera aussi votre note. Il se peut que ce soit moi, mais une fois que les règles sont établies, elles doivent être respectées et brisées (ex: Ne pas terminer le travail ou ne pas laisser savoir aux gens que vous vous battez, ne vous présentez pas aux réunions, etc.) dans le système 'carte' - comme cela aurait été convenu au début. C'est votre avenir sur la ligne, alors ne laissez pas les gens qui s'en foutent compromettre cela.

Answer 4

D'abord, configurez un système de contrôle de version pour le projet. Cela sert le but du code qui a été vérifié est disponible pour toute l'équipe, vous pouvez revenir à des versions antérieures si quelqu'un brise quelque chose, et tous les magasins professionnels décent utilisent le contrôle de la source, donc c'est une compétence professionnelle, il est bon d'être dans l'habitude d'utiliser.

Maintenant vous avez un moyen de vérifier la progression. Si Joe n'a rien repris, vous savez qu'il ne fait pas le travail. Si Sally quitte Mid_term, vous avez un enregistrement de tout ce qu'elle a déjà fait.

Une autre chose que vous voulez faire est de revoir le code. Le code de tout le monde est examiné par une ou plusieurs autres personnes. Vous apprendrez beaucoup de cela et c'est une compétence nécessaire pour le développeur professionnel.

Planifiez ce qui doit être fait dans quel ordre. Assurez-vous que les personnes qui développent les éléments dont tout le reste dépend sont les développeurs les plus fiables de votre équipe et qu'ils respecteront leurs échéances précoces ou que personne d'autre ne sera en mesure de faire leur part.

Réunions d'avancement hebdomadaires et n'ayez pas peur d'appeler quelqu'un pour ne pas faire sa part. Le plus tôt vous identifier une personne ne tire pas son poids, le plus tôt vous pouvez résoudre le problème.