Программирование с группой людей, которых я никогда не встречал

Мне поручили групповой проект из моего курса информатики в AP, и я должен работать с тремя другими людьми. Я никогда не разговаривал с ними раньше, я понятия не имею об их уровне квалификации, и все, что у меня есть, это их адрес электронной почты. Подведение итогов:

«В команде вы пройдете минимум три Модуля в классе ....»

Я собираюсь попытаться стать «капитаном команды», потому что никто из них не пытался связаться друг с другом, но мне любопытно: как это сделать? Я написал им по электронной почте и спросил, есть ли какие-либо методы общения, которые они предпочитают, вместо того, чтобы переписываться друг с другом по электронной почте, но как только мы начнем проект, мне придется выяснить, кто чем занимается.

Что я должен делать? Как мне «взять на себя ответственность» и вести трех человек, которых я никогда не встречал?

Вот выдержка из фактического назначения:

Поэтому вам нужно будет обсудить различные роли, которые каждый член команды будет выполнять в этом проекте в начале недели. Вы можете общаться через Pronto (или Blackboard IM), электронную почту, вики, группу Google, блог или любым другим способом, который вы считаете нужным. Если участник группы не вступает в группу до конца недели, сообщите об этом своему инструктору, и он предоставит дополнительные рекомендации.
...
Также в конце проекта будет проведена оценка команды, в которой вы оцените вклад каждого члена команды в завершение этого проекта вместе с предложенной оценкой.

Изменить: Многие люди предложили мне встретиться с ними в кафе или что-то в этом роде. Проблема только в том, что мы все в разных штатах. Я также понял, что одному из них не разрешено использовать Facebook / Skype / Twitter, поэтому я вынужден прибегнуть к обмену сообщениями через Yahoo Messenger и электронную почту.

Лидером этого проекта будет человек, который поднимается и берет на себя ответственность в начале.

Это относится к большинству вещей в жизни - не только к разработке программного обеспечения. Когда все остальные бегают как цыплята без головы, человек, который все обдумывает, делает шаг вперед и говорит: « Это то, что мы собираемся сделать, и вот как мы собираемся это сделать ». обычно это человек, которого считают лидером остальной части проекта. Имейте в виду, что, делая это, вы берете на себя ответственность за конечный успех или провал проекта.

Вы хотите возглавить этот проект? Вот пара вещей, которые вы можете начать делать прямо сейчас, чтобы оказать большое влияние.

1. Используйте инструмент управления проектами, такой как Trello, и отправляйте приглашения всем и начинайте распределять части проекта среди людей.
2. Создайте базу данных ошибок и начните добавлять задачи и ошибки - опять же, просто начните назначать.
3. Настройте репозиторий контроля версий и отметьте хороший начальный кусок кода, с которым каждый может работать. Отказаться от любой другой формы контроля кода.
4. Предложите людям помочь начать разработку, показав им, как использовать систему контроля версий и базу данных ошибок.
5. Разошлите еженедельные электронные письма, детализирующие статус проекта и прогресс предыдущей недели.

Ни один из этих шагов не является особенно трудным или трудоемким, но в будущем он значительно сэкономит время. Кроме того, это заставит вашу команду говорить друг с другом, и они привыкнут видеть вас ответственными.

Ответ Джаррода Неттлса во многом суммирует то, что я собирался предложить, поэтому я добавлю кое-что из того, что сработало в моем недавнем опыте в аналогичной ситуации.

Я бы предложил найти способ поговорить с ними вокально, а не по электронной почте. Если вы не в том же районе, получите их все по скайпу. Если вы находитесь в этом районе, встретите их в кафе или где-нибудь еще. Личные разговоры на первых встречах приведут к тому, что вы на самом деле будете принимать решения и выполнять работу тогда и там; темы электронной почты позволяют тем, кто стесняется или часто не за компьютером, задерживать процесс - мы все знаем, какими ленивыми могут быть студенты!

На вашей первой встрече я бы попытался познакомиться с вашей группой, пытаясь продолжить работу над проектом, но не игнорируйте проект! 10 или 20 минут потраченного льда, вероятно, достаточно для 4 человек.

Когда речь заходит о проекте, я бы посоветовал разобраться с тем, что, по вашему мнению, подразумевается в проекте. Я думаю, важно, чтобы вы дали понять, что это ваше понимание, а не случай, когда вы говорите им, что делать. Каждый должен иметь возможность бросить свои мысли и идеи на ринг, если они есть, и вы должны уйти с этой первоначальной встречи с достаточно приличным пониманием того, что вы, как группа, чувствуете, что проект влечет за собой.

На будущих (регулярных) встречах вы можете начать более подробно рассматривать различные элементы проекта; посмотрите, что именно нужно делать, какие ресурсы и сколько времени потребуется и кто что может сделать. Разделите часть дальше, если это необходимо. Возможно, попытаться установить некоторые мягкие сроки?

У кого-нибудь из вас есть опыт работы с группой людей, с которыми вы никогда не встречались в Интернете, и вы не можете встретиться с ними лично, но должны завершить проект вместе?

Добавьте к этому недофинансирование, нелепые сроки и продажи по маркетингу, и это звучит примерно как 65% проектов по разработке программного обеспечения в реальном мире.

Вероятно, вам лучше всего было бы, если бы люди добровольно предлагали те части, которые им было бы интересно делать, вместо того, чтобы брать на себя ответственность в одностороннем порядке и распределять задания. Все они, вероятно, сидят и думают о том, как они должны взять на себя ответственность. Или как они могут получить беднягу, который слишком заботится о том, чтобы выполнять всю групповую работу, чтобы они могли ездить на его классе.

Первое, что нужно сделать в подобных случаях, - это установить систему отслеживания проблем и научиться ее использовать.

Для более фундаментального представления о том, как управлять разработкой, как вы описали, мой любимый справочник относится к статье Мартина Фаулера « Использование гибкого процесса разработки программного обеспечения в оффшорной разработке» . В этой статье изложены основы и расширенные концепции настройки распределенного командного взаимодействия:

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

Для вашего проекта вы точно не сможете следовать всем упомянутым там советам и хитростям (например, для вас, скорее всего, не будет послов или контактных визитов :), но в любом случае это стоит изучить.

• Для многих команд, имеющих все вышеперечисленное, наверняка было бы излишним. Тем не менее, я считаю действительно полезным иметь такой подробный контрольный список , чтобы даже пропущенные элементы проверялись и имели четко задокументированные причины отклонения, просто чтобы убедиться, что ничего важного не пропущено.

Вы не сказали нам, сколько у вас есть времени для этого или языка, на котором вы работаете (я бы сказал, что один класс очень маленький, но, возможно, на вашем языке это намного больше).

Прежде всего, иметь работающий продукт любой ценой.

Если проект длится две недели или меньше, предположим, что вы будете единственным, кто что-то делает, и будете очень рады любой помощи, которую вы получите. Попробуйте составить расписание для всех, но убедитесь, что, если никто ничего не сделает, у вас все еще будет рабочий продукт. Даже если кто-то что-то делает, не полагайтесь на его продолжение: будьте готовы к тому, что кто-нибудь выпадет в любой момент.

Если у вас есть более одной недели, рассмотрите планирование дня недели, когда продукт должен быть отмечен как веха, и придерживайтесь его как можно больше. Убедитесь, что у вас есть что-то, что вы можете обойти, и проверьте недостатки: если худшее дойдет до худшего, это будет то, что вы сдадите. Каждый, который вы создадите, вы увидите, насколько вы могли бы улучшить вещи, которые будут мотивировать вас идти на. Не планируйте слишком далеко вперед: конечно, вам нужно иметь представление о том, чем вы закончите, но сохраняйте свои наиболее конкретные планы на короткий срок.

Обратите внимание, что эти два частично совпадают: это сделано намеренно, так как две недели, на мой взгляд, являются серой областью, в которой трудно выполнить две итерации, но рискованно работать только за одну итерацию.

Я предполагаю наихудший случай, когда вы будете работать с людьми, плохо знакомыми с программированием. Мой общий совет:

• Держите список функций, которые вы хотите реализовать в ближайшее время, и кто будет над ними работать. Джаррод предложил Trello, и я полностью поддерживаю это: если ваши товарищи по команде не очень опытны, это очень поможет. Вы также можете попытаться сохранить ошибки там.
• В команде из четырех человек вам нужен контроль версий. Это может заставить других неохотно вносить свой вклад, если они не знают, как это сделать, но это того стоит.
• Любые внешние зависимости могут отпугнуть новичков. Если вы пишете модульные тесты, скажите людям, что они не должны беспокоиться о том, чтобы их сломать. Скажите людям, что они не должны беспокоиться о нарушении сборки, особенно сначала. Гораздо сложнее исправлять людей, которые не фиксируют какой-либо код, чем тех, кто фиксирует код с ошибками.
• Проверьте, действительно ли предложенные здесь вещи относятся к вам. «Непрерывная интеграция» - это причудливый термин - для небольшой программы это может означать «эта программа работает и все функции могут быть использованы». У вас даже есть сайты? Помогает ли разделение на команды?
• ЯГНИ, в сто раз больше. Если вам действительно нужно, напишите заранее о функциях, которые вы будете делать сами. Заставьте это работать, затем реорганизуйте, иначе вы не сможете заставить его работать.
• Рефакторинг. Как только он заработает, потратьте некоторое время на его исправление. Не забывайте, что вашим товарищам по команде тоже придется читать ваш код: день, потраченный на исправление уродливых частей и замену простых решений на более эффективные, не тратит впустую день.
• Следите за всеми частями. Сканирование журналов изменений и время от времени чтение чужого кода помогает убедиться, что все соответствует стандартам качества, которые, по вашему мнению, вы должны применять, и гарантирует, что не так сложно погрузиться, если человек выпадет.
• Не стесняйтесь работать над самой важной вещью, в отличие от вашей назначенной вещи. Если кто-то отстает от графика, запишите это где-нибудь и сделайте это сами. Спросите их сначала, но продолжайте, если они не отвечают, или если вы спрашиваете один или два раза и затем чувствуете, что они все еще не сделают это.
• Сосредоточьтесь на создании чего-то, чем вы гордитесь. Даже если это отклоняется от задания. Даже если вам придется сократить большие функции, чтобы сделать то, что у вас есть, более плавным. На каждой итерации вы думаете: «Горжусь ли я этим?», И на следующей итерации попытайтесь исправить это.

У меня был проект, который недавно ужасно провалился; Вы можете прочитать мои мысли о том, почему это не удалось, если хотите, но это суммирует, как бы я сделал что-то подобное, если бы у меня был еще один шанс.

Ответ Джаррода Неттла хорош. Я бы добавил это:

1. Ожидайте, что по крайней мере один из трех других будет совершенно бесполезен.
2. Просто примите, что вы почувствуете, что выполняете большую часть (или всю) работу, но каждый получит равный кредит. Любая попытка сделать вещи «честными» приведет только к ненужному конфликту и замедлит вас.
3. Оставайтесь на связи с любыми хорошими членами команды. Таких людей трудно найти, и вам захочется поработать с ними снова.

Я был в подобном положении несколько раз, так как я уверен, что много людей. Однако главное - сделать все возможное, чтобы все были довольны и счастливы, поэтому я думаю, что это хорошо, что вы хотите взять на себя задачу руководителя группы, как, например, кто-то упоминал выше - к этому нужно подходить осторожно, как к кому-то еще. может чувствовать, что они должны делать работу вместо этого.

Я знаю, что вы сказали, что никто не взял на себя обязательство связываться друг с другом, но иногда такие ситуации могут быть трудными для людей, например, вы сказали, что работаете с людьми, с которыми никогда не встречались, и может быть трудно общаться и т.д.

Я бы начал с электронного письма, просто обращающегося ко всем и сообщающего им, кто вы, как вы чувствуете, что проект должен быть адресован, и сообщаю, что вы хотите возглавить проект, взяв на себя ответственность за определение ролей, цели, сроков, времени общения, встреч ( при желании / желании) и обновления проекта.

Хотя вы не можете полностью влиять на других людей, вы можете отслеживать, кто что делает, а кто нет. Делегирование работы позволяет распределить работу равномерно или соответствующим образом людям с различными наборами навыков или уровней.

Таким образом, если определенная работа не выполняется, вы можете взять ее на себя, чтобы разделить работу между людьми, которые действительно стремятся работать над ней. Таким образом, в конце вы не получите неудачный проект, и у вас будут записи о попытках сообщить даты, время и всю соответствующую информацию, которую вы сможете показать в конце, если что-то пойдет не так. Все вещи, которые держат вас в правильном положении, если некоторые люди не тянут свой вес.

С точки зрения советов:

Я лично люблю совместную рабочую среду, найденную здесь: https://docs.google.com/

Это позволяет вам обмениваться текстовыми документами, электронными таблицами и т. Д. Это отличный способ совместной работы. Не могу не подчеркнуть, насколько это полезно иногда. Я использую это с некоторыми людьми, с которыми я работаю, которых нет в стране в настоящее время.

Надеюсь, это кому-то помогло, есть много аспектов руководства проектом, которые мы могли бы продолжать вечно, но это просто зависит от многих вещей. По крайней мере, это немного, чтобы помочь.