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

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

"Як команда ви закінчите мінімум три Модулі до класу ...."

Я спробую стати «капітаном команди», тому що ніхто з них не намагався зв’язатися один з одним, але мені цікаво: як це зробити? Я надіслав їх електронною поштою і запитав, чи існують якісь способи комунікації, які вони віддають перевагу над надсиланням електронної пошти один одному, але коли ми насправді розпочнемо проект, мені доведеться з’ясувати, хто що робить.

Що я повинен зробити? Як я "беру на себе відповідальність" і веду трьох людей, яких я ніколи не зустрічав?

Ось уривок фактичного завдання:

Тому вам потрібно буде обговорити різні ролі кожного учасника команди у цьому проекті на початку тижня. Ви можете спілкуватися через Pronto (або чат на часі), електронну пошту, вікі, групу Google, блог або будь-який інший метод, який вважаєте за потрібне. Якщо член групи не залучить групу до кінця тижня, повідомте про це вашого інструктора, і вони нададуть додаткові рекомендації.
...
Також наприкінці проекту буде проведено оцінку команди, в якій ви оціните внесок кожного члена команди в завершення цього проекту разом із запропонованою оцінкою.

Редагувати: Багато людей запропонували мені зустріти їх у кав’ярні, чи щось подібне. Проблема лише в тому, що всі ми перебуваємо в різних штатах. Я також зрозумів, що одному з них заборонено використовувати Facebook / Skype / twitter, тому мені доводиться вдаватися до обміну ними повідомленнями через Yahoo Messenger та електронну пошту.

Лідером цього проекту стане людина, яка на початку поступає та бере на себе відповідальність.

Це стосується більшості речей у житті - не лише розробки програмного забезпечення. Коли всі інші бігають навколо, як кури без голови, людина, яка все продумає, крокує вперед і каже: " Це ми будемо робити, і це ми будемо робити це ". Зазвичай ця людина вважається лідером решти проекту. Майте на увазі, що тим самим ви берете на себе відповідальність за остаточний успіх або провал проекту.

Ви хочете очолити цей проект? Ось кілька речей, які ви можете почати робити відразу, щоб зробити великий вплив.

1. Використовуйте інструмент управління проектами, як Trello, і надсилайте запрошення всім і починайте призначати частини проекту людям.
2. Створіть базу даних про помилки та почніть додавати завдання та помилки - знову ж таки, просто починайте призначати.
3. Налаштуйте сховище контролю версій і перевірте хороший початковий фрагмент коду, над яким може працювати кожен. Відмовтеся мати справу з будь-якою іншою формою контролю коду.
4. Запропонуйте допомогти людям рухатися з розвитком, показавши їм, як використовувати систему управління версіями та базу даних про помилки.
5. Щотижня надсилайте електронні листи, де детально описується стан проекту та хід попереднього тижня.

Жоден з цих кроків не є особливо важким або трудомістким, але вони будуть величезними економіями часу в дорозі. Крім того, він змусить вашу команду розмовляти між собою, і звикне бачити вас головними.

Відповідь Джаррода Кропиви в значній мірі узагальнює багато того, що я збирався запропонувати, тому я закину частину того, що працювало в моєму недавньому досвіді в подібній ситуації.

Я б запропонував знайти якийсь спосіб поговорити з ними вокально, а не електронною поштою. Якщо ви не перебуваєте в одному районі, заведіть їх у Skype. Якщо ви перебуваєте в цьому районі, зустріньте їх у кав’ярні чи щось таке. Виступаючи особисто на первинних зустрічах, ви приведете до того, що ви фактично приймаєте рішення і працюєте там і там; Нитки електронної пошти дозволяють тим, хто сором’язливий або часто не працює за своїм комп’ютером, затримувати процес - ми всі знаємо, якими можуть бути ліниві студенти!

На вашій першій зустрічі я б спробував познайомитись із вашою групою, намагаючись продовжувати працювати з проектом - але не ігноруйте проект! 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

Що стосується вашого проекту, ви впевнені, що не зможете виконувати всі поради та рекомендації, згадані там (наприклад, послів та візитів для вас, ймовірно, не буде :), але варто все-таки вивчити.

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

Ви не сказали нам, скільки часу у вас є для цього чи мови, якою ви працюєте (я б сказав, що одного класу дуже мало, але, можливо, у вашій мові це набагато більше).

Перш за все, мати працюючий продукт за будь-яку ціну.

Якщо проект триває два тижні або менше, припустіть, що ви будете єдиним, хто щось робить, і будьте дуже раді будь-якій допомозі. Постарайтеся запланувати речі для кожного, але переконайтеся, що якщо ніхто нічого не зробить, у вас все одно буде робочий продукт. Навіть якщо хтось щось робить, не покладайтеся на те, що вони продовжують: будьте готові до того, що хтось випаде в будь-який момент.

Якщо у вас більше одного тижня, розгляньте планування дня тижня, коли продукт слід позначити як важливий етап і дотримуватися цього якомога більше. Переконайтеся, що у вас є щось, про що ви зможете розігнати і перевірити недоліки: якщо найгірше стане гіршим, це буде те, що ви передаєте. Кожен, хто створить, побачить, наскільки ви могли вдосконалити речі, що мотивуватимуть вас йти на. Не плануйте занадто далеко вперед: впевнено, ви повинні мати уявлення про те, чим ви закінчитесь, але зберігайте свої найбільш конкретні плани короткострокові.

Зауважте, що ці двоє перекриваються трохи: це навмисно, оскільки два тижні, на мою думку, трохи сіра зона, де зробити два ітерації важко, але працювати лише в одній ітерації ризиковано.

Я припускаю найгірший випадок, коли ви будете працювати з людьми, дуже новими в програмуванні. Моєю загальною порадою буде:

• Зберігайте список функцій, які ви хочете реалізувати незабаром, і хто буде працювати над ними. Джаррод запропонував Трелло, і я цілком підтримую це: якщо ваші товариші по команді не дуже досвідчені, це дуже допоможе. Ви можете спробувати зберегти помилок і там.
• У команді з чотирьох потрібен контроль версій. Це може змусити інших робити неохоче, якщо вони не знають, як це працювати, але це того варте.
• Будь-які зовнішні залежності можуть відлякати новачків. Якщо ви пишете одиничні тести, скажіть людям, що вони не повинні турбуватися про їх порушення. Скажіть людям, що вони не повинні турбуватися про зрив складання, особливо спочатку. Набагато складніше виправити людей, які не вводять жодного коду, ніж тих, хто робить помилку.
• Перевірте, чи справді запропоновані тут речі. "Постійна інтеграція" - це фантазійний термін - для невеликої програми це може означати "ця програма працює і всі функції можна використовувати". У вас навіть є сайти? Чи допомагає вам розкол на команди?
• ЯГНИ, сто разів більше. Якщо вам справді доведеться, напишіть речі заздалегідь для функцій, які ви будете робити самостійно. Дайте йому працювати, потім рефактор, інакше ви не обійдетеся, щоб він працював.
• Рефактор. Як тільки це працює, витратьте деякий час на його виправлення. Не забувайте, що вашим товаришам по команді доведеться також читати ваш код: день, витрачений на виправлення негарних деталей та заміну простих рішень на більш ефективні, не витрачає день.
• Слідкуйте за всіма частинами. Журнали змін і час від часу читання коду інших людей допомагають переконатися, що все відповідає стандартам якості, які, на вашу думку, слід виконувати, і переконайтеся, що занурюватися в нього не так складно, якщо людина кинеться.
• Не соромтеся працювати над найважливішим, на відміну від призначеного вами речі. Якщо хтось відстає від графіку, запишіть про це десь письмово і зробіть це самостійно. Попросіть їх спочатку, але продовжуйте, якщо вони не відповідають, або якщо ви запитаєте один чи два рази, а потім відчуєте, що вони все одно не зроблять цього.
• Зосередьтеся на тому, щоб зробити щось, чим ви пишаєтесь. Навіть якщо це відхиляється від завдання. Навіть якщо вам доведеться скоротити великі функції на користь того, щоб зробити те, що у вас є більш гладким. Кожна ітерація думає «Чи я цим пишаюся?», А в наступній ітерації спробуйте виправити ці речі.

У мене був проект, який останнім часом жахливо провалився; Ви можете прочитати мої думки про те, чому це не вдалося, якщо ви хочете, але це підсумовує, як я зробив би щось подібне, якби у мене був інший шанс.

Відповідь Джаррода Кропиви хороша. Я додам це:

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

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

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

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

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

Таким чином, якщо певна робота не виконується, ви можете взяти її на себе, щоб розділити роботу між людьми, які насправді прагнуть працювати над нею. Таким чином, ви не зможете в кінцевому підсумку закінчитися невдалим проектом, і у вас будуть записи про спробу повідомити дати, час та всю відповідну інформацію, яку ви зможете показати в кінці, якщо все піде не так. АЛЕ речі, які тримають вас у праві, якщо деякі люди не набирають ваги.

З точки зору порад:

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

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

Сподіваюся, це допомогло комусь, є так багато аспектів провідного проекту, над яким ми могли б продовжуватись назавжди, але це залежить лише від багатьох речей. Принаймні, це крихітний шматочок на допомогу.