Programmation avec un groupe de personnes que je n'ai jamais rencontrées

J'ai été affecté à un projet de groupe de mon cours d'informatique AP et je dois travailler avec trois autres personnes. Je ne leur ai jamais parlé auparavant, je n'ai aucune idée de leur niveau de compétence et tout ce que j'ai, c'est leur adresse électronique. La tâche, résumée, est la suivante:

"En tant qu'équipe, vous devrez compléter au moins trois modules par classe ...."

Je vais essayer de devenir "capitaine d'équipe" car aucun d'entre eux n'a tenté de se contacter mais je suis curieux de savoir comment procéder. Je leur ai envoyé un e-mail et leur ai demandé s'ils préféraient utiliser des méthodes de communication différentes, mais une fois que nous aurons démarré le projet, je devrai déterminer qui fait quoi.

Que devrais-je faire? Comment puis-je "prendre en charge" et diriger trois personnes que je n'ai jamais rencontrées?

Voici un extrait de la mission actuelle:

Par conséquent, vous devrez discuter des différents rôles que chaque membre de l'équipe jouera dans ce projet au début de la semaine. Vous pouvez communiquer via Pronto (ou Blackboard IM), un courrier électronique, un wiki, un groupe Google, un blog ou toute autre méthode que vous jugez utile. Si un membre du groupe n'engage pas le groupe d'ici la fin de la semaine, informez votre instructeur et il vous fournira des instructions supplémentaires.
...
Également à la fin du projet, une évaluation de l'équipe consistera à évaluer la contribution de chaque membre de l'équipe à l'achèvement de ce projet, ainsi qu'une note.

Edit: Beaucoup de gens ont suggéré que je les rencontre dans un café ou quelque chose comme ça. Le seul problème est que nous sommes tous dans des états différents. Je me suis aussi rendu compte que l'un d'entre eux n'est pas autorisé à utiliser Facebook / Skype / Twitter, alors je dois recourir à la messagerie via Yahoo Messenger et des courriels.

Le responsable de ce projet sera la personne qui prendra la relève au début du processus.

Cela s'applique à la plupart des choses de la vie - pas seulement au développement de logiciels. Quand tout le monde court comme des poulets sans tête, celui qui réfléchit, avance et dit: " Voici ce que nous allons faire et comment nous allons le faire ." est généralement la personne considérée en tant que chef de file pour le reste du projet. N'oubliez pas qu'en faisant cela, vous prenez la responsabilité du succès ou de l'échec ultime du projet.

Vous voulez mener ce projet? Voici deux choses que vous pouvez commencer immédiatement à faire pour avoir un impact important.

1. Utilisez un outil de gestion de projet tel que Trello , envoyez des invitations à tout le monde et commencez à attribuer des parties du projet aux personnes.
2. Générez une base de données de bogues et commencez à ajouter des tâches et des bogues. Encore une fois, commencez à assigner.
3. Configurez un référentiel de contrôle de version et enregistrez un bon morceau de code initial sur lequel tout le monde peut travailler. Refuser de traiter avec toute autre forme de contrôle de code.
4. Offrez d'aider les gens à se lancer dans le développement en leur montrant comment utiliser le système de contrôle de version et la base de données de bogues.
5. Envoyez des courriels hebdomadaires détaillant l'état du projet et les progrès de la semaine précédente.

Aucune de ces étapes n'est particulièrement ardue ni ne prend beaucoup de temps, mais elles vous feront gagner énormément de temps . De plus, votre équipe se parlera et s'habituera à vous voir diriger.

La réponse de Jarrod Nettles résume assez bien ce que j'allais suggérer. Je vais donc ajouter quelques éléments de ce qui a fonctionné lors de mes expériences récentes dans une situation similaire.

Je suggérerais de trouver un moyen de parler avec eux vocalement plutôt que par courrier électronique. Si vous n'êtes pas dans la même zone, procurez-les tous sur Skype. Si vous êtes dans le coin, rendez-vous dans un café ou quelque chose du genre. Parler en personne lors des premières réunions vous amènera à prendre des décisions et à faire le travail ensuite; Les fils de messagerie permettent à ceux qui sont timides ou souvent pas devant leur ordinateur de retarder le processus - nous savons tous à quel point les étudiants peuvent être paresseux!

Lors de votre première réunion, j'essaierais de connaître votre groupe avant d'essayer de poursuivre le projet - mais n'ignorez pas le projet! 10 ou 20 minutes passées à briser la glace sont probablement suffisantes parmi 4 personnes.

Quand il s’agit de parler du projet, je suggérerais de faire le point sur ce que vous pensez que le projet implique. Je pense qu'il est important que vous expliquiez clairement que c'est votre compréhension, et non que vous leur disiez exactement quoi faire. Tout le monde devrait être en mesure d’exprimer ses pensées et ses idées s’il en a, et vous devriez sortir de cette première réunion avec une compréhension assez décente de ce que vous pensez, en tant que groupe, que le projet implique.

Dans les prochaines réunions (régulières), vous pourrez commencer à examiner plus en détail différents éléments du projet. Regardez ce qui doit être fait exactement, quelles ressources et combien de temps il faudra, et qui peut faire quoi. Séparez la pièce si nécessaire. Peut-être essayer de fixer des délais serrés?

Est-ce que l'un de vous a déjà travaillé avec un groupe de personnes que vous n'avez jamais rencontré en ligne et que vous ne pouvez pas les rencontrer en personne, mais que vous devez terminer un projet ensemble?

Ajoutez à cela un budget insuffisant, des délais ridicules et une vente à la mer. Cela ressemble à environ 65% des projets de développement de logiciels dans le monde réel.

Vous seriez probablement mieux servi en faisant en sorte que les gens se portent volontaires pour les tâches qui les intéresseraient plutôt que de prendre en charge de façon unilatérale et d’assigner des tâches. Ils sont probablement tous assis là à réfléchir à la manière dont ils devraient se prendre en charge. Ou comment ils peuvent avoir un pauvre nid qui se soucie trop de faire tout le travail de groupe pour qu'ils puissent monter sur son grade.

La première chose à faire dans des cas comme celui-ci est d'établir un système de suivi des problèmes et d'apprendre à l'utiliser.

Pour une introduction plus fondamentale sur la façon de gérer le développement, comme vous l'avez décrit, ma référence préférée est l'article de Martin Fowler intitulé Utilisation d'un processus logiciel agile avec développement offshore . Cet article décrit les concepts de base et avancés de la configuration d'une communication d'équipe distribuée:

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

Pour votre projet, vous ne serez certainement pas en mesure de suivre tous les conseils et astuces qui y sont mentionnés (par exemple, il n'y aura probablement pas d'ambassadeurs ni de visites de contact pour vous :) mais cela vaut la peine d'étudier quand même.

• Pour beaucoup d'équipes ayant tout ce qui précède constituerait à l'excès une certitude. Néanmoins, j'estime qu'il est vraiment utile de disposer d'une liste de contrôle complète comme celle-ci - afin que même les éléments ignorés soient vérifiés et que les motifs de refus soient clairement documentés - afin de m'assurer que rien d'important n'a été oublié.

Vous ne nous avez pas dit combien de temps vous avez pour cela, ni la langue dans laquelle vous travaillez (je dirais qu'une seule classe est très petite, mais peut-être que dans votre langue, c'est beaucoup plus).

Tout d'abord, avoir un produit qui fonctionne à tout prix.

Si le projet dure deux semaines ou moins, supposez que vous serez le seul à faire quelque chose et soyez très heureux de toute aide que vous obtiendrez. Essayez de planifier des choses pour tout le monde, mais assurez-vous que si personne ne fait rien, vous aurez toujours un produit qui fonctionne. Même si quelqu'un fait quelque chose, ne comptez pas sur lui pour continuer: soyez prêt à ce que quiconque abandonne à tout moment.

Si vous avez plus d'une semaine, envisagez de planifier un jour de la semaine où le produit doit être marqué comme un jalon et respectez-le autant que possible. Assurez-vous d'avoir quelque chose que vous pouvez contourner et vérifier les carences de: si le pire venait à se produire, ce sera ce que vous rendrez. Chaque création que vous créez, vous verrez à quel point vous pouvez améliorer les choses, ce qui vous motivera à aller sur. Ne planifiez pas trop loin en avant: bien sûr, vous devez avoir une idée de ce que vous allez obtenir, mais gardez vos plans les plus spécifiques à court terme.

Remarquez que ces deux domaines se chevauchent un peu: c'est intentionnel, car, à mon avis, deux semaines constituent une zone d'ombre où il est difficile de faire deux itérations, mais le fait de travailler dans une itération est risqué.

Je présume que dans le pire des cas, vous travaillerez avec des personnes très novices en programmation. Mon conseil général serait:

• Conservez une liste des fonctionnalités que vous souhaitez implémenter prochainement et les personnes qui y travailleront. Jarrod a suggéré Trello, et je soutiens tout à fait cela: si vos coéquipiers ne sont pas très expérimentés, cela vous aidera beaucoup. Vous pouvez essayer de garder les insectes ici aussi.
• Dans une équipe de quatre personnes, vous avez besoin d'un contrôle de version. Cela peut rendre les autres plus réticents à contribuer s’ils ne savent pas comment le faire, mais cela en vaut la peine.
• Toute dépendance externe peut effrayer les débutants. Si vous écrivez des tests unitaires, dites aux gens qu’ils ne doivent pas s’inquiéter de les interrompre. Dites aux gens qu’ils ne devraient pas s’inquiéter de casser le gabarit, surtout au début. Il est beaucoup plus difficile de corriger les personnes qui ne commettent aucun code que celles qui commettent du code buggy.
• Vérifiez si les choses suggérées ici s’appliquent vraiment à vous. "Intégration continue" est un terme sophistiqué - pour un petit programme, cela pourrait signifier "ce programme s'exécute et toutes les fonctionnalités peuvent être utilisées". Avez-vous même des sites? La scission en équipes vous aide-t-elle?
• YAGNI, cent fois plus. Si vous devez le faire, écrivez à l’avance des choses que vous ferez vous-même. Faites-le fonctionner, puis refactorisez-le, sinon vous ne réussirez pas à le faire fonctionner.
• Refactor. Une fois que cela fonctionne, prenez le temps de le réparer. N'oubliez pas que vos coéquipiers devront également lire votre code: une journée passée à réparer des pièces laides et à remplacer des solutions simples par des solutions plus performantes ne sera pas une journée perdue.
• Gardez un oeil sur toutes les parties. En parcourant les listes de modifications et en lisant de temps à autre le code des autres, vous vous assurez que tout est conforme aux normes de qualité que vous estimez devoir appliquer et vous assure qu'il n'est pas aussi difficile de plonger si la personne décède.
• N'hésitez pas à travailler sur la chose la plus importante, par opposition à la chose que vous avez désignée. Si quelqu'un est en retard, prenez-en une note écrite quelque part et faites-le vous-même. Demandez-leur d'abord, mais allez-y s'ils ne répondent pas ou si vous posez la question une ou deux fois et que vous sentez qu'ils ne le feront toujours pas.
• Concentrez-vous sur quelque chose dont vous êtes fier. Même si cela s'écarte de la mission. Même si vous devez couper de grandes fonctionnalités en faveur de rendre ce que vous avez plus lisse. Chaque itération pense "Suis-je fier de cela?", Et lors de la prochaine itération, essayez de résoudre ce problème.

J'ai eu un projet qui a échoué horriblement récemment; vous pouvez lire mes pensées sur les raisons pour lesquelles cela a échoué si vous le souhaitez, mais ceci résume comment je ferais une chose pareille si j'avais une autre chance de le faire.

La réponse de Jarrod Nettles est bonne. J'ajouterais ceci:

1. Attendez-vous à ce qu'au moins une des trois autres personnes soit complètement inutile.
2. Acceptez simplement le fait que vous aurez l’impression que vous accomplissez la majeure partie (ou la totalité) du travail, mais tout le monde aura le même crédit. Toute tentative visant à rendre les choses "justes" ne fera que provoquer des conflits inutiles et vous ralentir.
3. Restez en contact avec tous les membres de l'équipe qui sont bons. Il est difficile de trouver de telles personnes et vous voudrez à nouveau travailler avec elles.

J'ai été dans une position similaire à plusieurs reprises, car je suis sûr que beaucoup de gens. L'essentiel est cependant de faire de votre mieux pour contenter tout le monde et le rendre heureux. Je pense donc qu'il est bon que vous souhaitiez assumer la tâche de chef d'équipe, mais comme quelqu'un mentionné ci-dessus - vous devez faire preuve de prudence à cet égard. peut penser qu'ils devraient plutôt faire le travail.

Je sais que vous avez dit que personne n'avait pris l'initiative de se contacter, mais parfois, ces situations peuvent être difficiles pour des personnes, comme vous avez dit que vous travaillez avec des personnes que vous n'avez jamais rencontrées et qu'il peut être difficile de communiquer, etc.

Je commencerais par envoyer un e-mail adressant tout le monde et leur indiquant qui vous êtes, comment le projet devrait être traité et faire savoir que vous souhaitez diriger le projet en prenant la responsabilité de la définition des rôles, des objectifs, des délais, du temps de communication et des réunions ( si désiré / souhaité) et mises à jour du projet.

Bien que vous ne puissiez pas complètement influencer les autres, vous pouvez savoir qui fait quoi et qui ne le fait pas. La délégation de tâches permet de répartir le travail de manière égale ou appropriée entre des personnes possédant des compétences ou des niveaux différents.

De cette façon, si certains travaux ne sont pas effectués, vous pouvez vous charger de les répartir entre les personnes qui souhaitent réellement y travailler. De cette façon, vous ne vous retrouverez pas avec un projet en échec à la fin et vous aurez des traces d'essayer de communiquer les dates, les heures et toutes les informations pertinentes que vous pourrez montrer à la fin si quelque chose ne va pas. Toutes les choses qui vous gardent dans le droit si certaines personnes ne tirent pas leur poids.

En termes de conseils:

Personnellement, j'aime un environnement de travail collaboratif disponible ici: https://docs.google.com/

Cela vous permet de partager des documents Word, des feuilles de calcul, etc. C'est un excellent moyen de travailler en collaboration. Je ne peux pas souligner à quel point c'est utile parfois. Je l'utilise avec des gens avec qui je travaille qui ne sont pas dans le pays pour le moment.

J'espère que cela a aidé quelqu'un, il y a tellement d'aspects à diriger un projet que nous pourrions poursuivre éternellement, mais cela dépend de tellement de choses. Au moins c'est un tout petit peu pour aider.