Programowanie z grupą ludzi, których nigdy nie spotkałem

Przydzielono mi projekt grupowy z mojej klasy informatyki AP i muszę pracować z trzema innymi osobami. Nigdy z nimi nie rozmawiałem, nie mam pojęcia o ich umiejętnościach, a wszystko, co mam, to adres e-mail. Podsumowując, zadanie to:

„Jako zespół ukończysz co najmniej trzy moduły do ​​klasy ...”

Zamierzam zostać „kapitanem drużyny”, ponieważ żaden z nich nie próbował się ze sobą skontaktować, ale jestem ciekawy: jak to zrobić? Wysłałem im e-mailem i zapytałem, czy są jakieś metody komunikacji, które wolą od siebie nawzajem, ale kiedy faktycznie zaczniemy projekt, będę musiał dowiedzieć się, kto co robi.

Co powinienem zrobić? Jak „przejąć kontrolę” i prowadzić trzy osoby, których nigdy nie spotkałem?

Oto fragment faktycznego zadania:

Dlatego musisz omówić różne role, które każdy członek zespołu podejmie w tym projekcie na początku tygodnia. Możesz komunikować się przez Pronto (lub Blackboard IM), e-mail, wiki, grupę google, blog lub dowolną inną metodę, którą uznasz za stosowną. Jeśli członek grupy nie zaangażuje się w grupę do końca tygodnia, poinformuj o tym instruktora, który zapewni dodatkowe wskazówki.
...
Pod koniec projektu odbędzie się również ocena zespołu, w której ocenisz wkład każdego członka zespołu w zakończenie tego projektu wraz z sugerowaną oceną.

Edycja: Wiele osób sugerowało, że spotkam się w kawiarni lub coś w tym rodzaju. Jedynym problemem jest to, że wszyscy jesteśmy w różnych stanach. Doszedłem również do wniosku, że jeden z nich nie może korzystać z Facebooka / Skype / Twittera, więc muszę uciekać się do wysyłania wiadomości przez komunikator Yahoo i e-maile.

Liderem tego projektu będzie osoba, która podejmie działania i przejmie kontrolę na początku.

Dotyczy to większości rzeczy w życiu - nie tylko tworzenia oprogramowania. Kiedy wszyscy biegają jak kurczaki bez głów, osoba, która wszystko przemyśla, robi krok do przodu i mówi: „ Tak właśnie zrobimy i jak to zrobimy ”. jest zwykle osobą, która wyglądała na lidera reszty projektu. Pamiętaj, że robiąc to, bierzesz odpowiedzialność za ostateczny sukces lub porażkę projektu.

Chcesz poprowadzić ten projekt? Oto kilka rzeczy, które możesz od razu zacząć robić, aby wywrzeć duży wpływ.

1. Skorzystaj z narzędzia do zarządzania projektami, takiego jak Trello, wysyłaj zaproszenia do wszystkich i zacznij przypisywać części projektu do ludzi.
2. Wygeneruj bazę danych błędów i zacznij dodawać zadania i błędy - ponownie, po prostu zacznij przypisywać.
3. Skonfiguruj repozytorium kontroli wersji i sprawdź dobry początkowy fragment kodu, z którego każdy może pracować. Nie odmawiaj żadnej innej kontroli kodu.
4. Zaoferuj ludziom pomoc w rozpoczęciu programowania, pokazując im, jak korzystać z systemu kontroli wersji i bazy danych błędów.
5. Wysyłaj cotygodniowe wiadomości e-mail zawierające szczegółowe informacje o stanie projektu i postępach z poprzedniego tygodnia.

Żaden z tych kroków nie jest szczególnie trudny ani czasochłonny, ale w przyszłości znacznie zaoszczędzą czas . Co więcej, sprawi, że Twój zespół zacznie ze sobą rozmawiać i przyzwyczai się do patrzenia na ciebie.

Odpowiedź Jarroda Nettlesa w dużym stopniu podsumowuje to, co chciałem zasugerować, dlatego w podobnej sytuacji przedstawię niektóre z moich ostatnich doświadczeń.

Proponuję znaleźć sposób na rozmowę z nimi na głos, a nie przez e-mail. Jeśli nie jesteś w tym samym obszarze, zdobądź je wszystkie na Skype. Jeśli jesteś w okolicy, spotkaj ich w kawiarni lub coś takiego. Wystąpienie osobiście na początkowych spotkaniach doprowadzi cię do podjęcia decyzji i wykonania pracy tam i teraz; wątki e-mailowe pozwalają tym, którzy są nieśmiali lub często nie mają przy komputerze, aby wstrzymali ten proces - wszyscy wiemy, jak leniwi mogą być uczniowie!

Na twoim pierwszym spotkaniu chciałbym poznać twoją grupę, starając się kontynuować projekt - ale nie ignoruj ​​projektu! 10 lub 20 minut spędzonych na łamaniu lodu jest prawdopodobnie wystarczające wśród 4 osób.

Jeśli chodzi o rozmowę o projekcie, proponuję przejrzeć to , co według ciebie obejmuje projekt. Myślę, że ważne jest, abyś wyjaśnił, że to jest twoje zrozumienie, a nie przypadek, gdy mówisz im dokładnie, co mają robić. Każdy powinien mieć możliwość przekazania swoich myśli i pomysłów na ring, jeśli takie mają, i powinieneś odejść od tego początkowego spotkania z wystarczającym zrozumieniem tego, co, jako grupa, czujesz, pociąga za sobą projekt.

Podczas przyszłych (regularnych) spotkań możesz bardziej szczegółowo przyjrzeć się różnym częściom projektu; sprawdź, co dokładnie trzeba zrobić, jakie zasoby i ile czasu będzie potrzeba i kto może to zrobić. W razie potrzeby podziel kawałek dalej. Być może spróbuj ustalić jakieś miękkie terminy?

Czy któryś z was ma doświadczenie w pracy z grupą ludzi, których nigdy nie spotkał online, i nie spotkasz ich osobiście, ale musisz wspólnie ukończyć projekt?

Dodaj niedostateczne budżetowanie, niedorzeczne terminy i sprzedaj się w dół rzeki przez marketing, a to brzmi jak około 65% projektów rozwoju oprogramowania w prawdziwym świecie.

Najprawdopodobniej najlepiej by ci było, gdyby ludzie woleli ochotników na części, którymi byliby zainteresowani, zamiast zajmować się jednostronnie i przydzielać zadania. Wszyscy prawdopodobnie siedzą tam i myślą o tym, jak powinni przejąć dowodzenie. Albo jak zdobyć biednego drania, który za bardzo dba o całą pracę w grupie, żeby mogli jeździć na jego poziomie.

Pierwszą rzeczą do zrobienia w takich przypadkach jest ustanowienie narzędzia do śledzenia problemów i nauczenie się, jak z niego korzystać.

Aby uzyskać bardziej podstawowe wprowadzenie do obsługi programowania, tak jak to opisałeś, moje ulubione odniesienie znajduje się w artykule Martina Fowlera Korzystanie z procesu zwinnego oprogramowania z programowaniem na morzu . W tym artykule omówiono podstawy i zaawansowane koncepcje konfiguracji rozproszonej komunikacji zespołowej:

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

W swoim projekcie na pewno nie będziesz w stanie postępować zgodnie ze wszystkimi wskazówkami i sztuczkami wymienionymi tam (np. Prawdopodobnie nie będzie dla Ciebie Ambasadorów ani wizyt kontaktowych :), ale i tak warto się uczyć.

• Dla wielu drużyn posiadanie powyższego byłoby z pewnością przesadą. Mimo to uważam, że bardzo pomocna jest taka kompleksowa lista kontrolna - aby sprawdzane były nawet pomijane elementy i miały jasno udokumentowane powody odrzucenia - aby upewnić się, że nic ważnego nie zostało pominięte.

Nie powiedziałeś nam, ile masz na to czasu ani języka, w którym pracujesz (powiedziałbym, że jedna klasa jest bardzo mała, ale być może w twoim języku jest o wiele więcej).

Przede wszystkim mieć działający produkt za wszelką cenę.

Jeśli projekt trwa dwa tygodnie lub krócej, załóż, że będziesz jedyną osobą, która coś zrobi i będziesz bardzo szczęśliwy z otrzymanej pomocy. Staraj się planować dla wszystkich, ale upewnij się, że jeśli nikt nic nie zrobi, nadal będziesz mieć działający produkt. Nawet jeśli ktoś coś zrobi, nie polegaj na nim: bądź przygotowany na to, że ktokolwiek zrezygnuje w dowolnym momencie.

Jeśli masz więcej niż tydzień, rozważ zaplanowanie dnia tygodnia, w którym produkt powinien zostać oznaczony jako kamień milowy, i trzymaj się tego w jak największym stopniu. Upewnij się, że masz coś, co możesz wykopać i sprawdź niedociągnięcia: jeśli najgorsze dojdzie do najgorszego, to będzie to, co dostarczysz. Każde utworzone, zobaczysz, jak wiele możesz poprawić, co zmotywuje cię do pójścia na. Nie planuj zbyt daleko naprzód: na pewno musisz mieć pojęcie o tym, co skończysz, ale zachowaj swoje najbardziej szczegółowe plany na krótki czas.

Zauważ, że te dwa elementy się częściowo pokrywają: jest to celowe, ponieważ moim zdaniem dwa tygodnie to trochę szara strefa, w której wykonanie dwóch iteracji jest trudne, ale praca tylko w jednej iteracji jest ryzykowna.

Zakładam najgorszy przypadek, w którym będziesz pracować z ludźmi, którzy są nowicjuszami w programowaniu. Moja ogólna rada to:

• Zrób listę funkcji, które chcesz wkrótce wdrożyć i kto będzie nad nimi pracował. Jarrod zasugerował Trello, a ja całkowicie popieram to: jeśli twoi koledzy z drużyny nie są zbyt doświadczeni, to bardzo pomoże. Możesz też spróbować zatrzymać tam błędy.
• W czteroosobowym zespole potrzebujesz kontroli wersji. Może sprawić, że inni będą bardziej niechętni, jeśli nie wiedzą, jak to zrobić, ale warto.
• Wszelkie zewnętrzne zależności mogą odstraszyć początkujących. Jeśli piszesz testy jednostkowe, powiedz ludziom, że nie powinni się martwić o ich zerwanie. Powiedz ludziom, że nie powinni martwić się zerwaniem kompilacji, zwłaszcza na początku. Znacznie trudniej jest poprawić osoby, które nie popełniają żadnego kodu, niż te, które popełniają błędny kod.
• Sprawdź, czy rzeczy zaproponowane tutaj naprawdę Cię dotyczą. „Ciągła integracja” to wymyślny termin - w przypadku małego programu może to oznaczać „ten program działa i można korzystać ze wszystkich funkcji”. Czy w ogóle masz strony? Czy podział na zespoły pomaga ci?
• YAGNI, sto razy. Jeśli naprawdę musisz, napisz rzeczy z wyprzedzeniem dotyczące funkcji, które sam stworzysz. Spraw, by działało, a następnie refaktoryzuj, w przeciwnym razie nie będziesz w stanie sprawić, by działało.
• Refaktor. Gdy już zadziała, poświęć trochę czasu na naprawę. Nie zapominaj, że twoi koledzy z drużyny również będą musieli przeczytać Twój kod: dzień spędzony na naprawie brzydkich elementów i zamianie prostych rozwiązań na bardziej wydajne nie jest dniem straconym.
• Miej oko na wszystkie części. Przeglądanie dzienników zmian i od czasu do czasu czytanie kodu innej osoby pomaga upewnić się, że wszystko odpowiada standardom jakości, które według ciebie powinieneś egzekwować, i upewnia się, że nie jest tak trudno nurkować, jeśli dana osoba odpadnie.
• Nie wahaj się pracować nad najważniejszą rzeczą, w przeciwieństwie do wyznaczonej rzeczy. Jeśli ktoś nie dotrzymuje terminu, zanotuj gdzieś pisemną notatkę i zrób to sam. Zapytaj ich najpierw, ale śmiało, jeśli nie odpowiedzą lub jeśli zapytasz raz lub dwa, a potem poczujesz, że nadal tego nie zrobią.
• Skoncentruj się na robieniu czegoś, z czego jesteś dumny. Nawet jeśli odbiega od zadania. Nawet jeśli musisz wyciąć duże funkcje, aby wygładzić to, co masz. Każda iteracja myśli „Czy jestem z tego dumny?”, Aw następnej iteracji spróbuj naprawić te rzeczy.

Miałem projekt, który ostatnio strasznie się nie powiódł; możesz przeczytać moje przemyślenia na temat tego, dlaczego to się nie powiedzie, jeśli chcesz, ale to podsumowuje, jak zrobiłbym coś takiego, gdybym miał inną szansę.

Odpowiedź Jarroda Nettlesa jest dobra. Dodałbym to:

1. Spodziewaj się, że przynajmniej jedna z pozostałych trzech osób będzie całkowicie bezużyteczna.
2. Po prostu zaakceptuj, że poczujesz, że wykonujesz większość (lub całość) pracy, ale wszyscy otrzymają równe uznanie. Każda próba uczynienia rzeczy „sprawiedliwymi” spowoduje tylko niepotrzebny konflikt i spowolni cię.
3. Pozostań w kontakcie z dobrymi członkami zespołu. Tych ludzi trudno znaleźć i będziesz chciał z nimi ponownie pracować.

Kilka razy byłem w podobnej sytuacji, ponieważ jestem pewien, że mam wielu ludzi. Najważniejsze jest, aby starać się, aby wszyscy byli zadowoleni i zadowoleni, więc myślę, że dobrze jest, że chcesz podjąć się roli lidera zespołu, jednak jak ktoś wspomniany powyżej - do tego należy podejść ostrożnie, jak ktoś inny mogą czuć, że zamiast tego powinni wykonać pracę.

Wiem, że powiedziałeś, że nikt nie wziął na siebie kontaktu, ale czasami takie sytuacje mogą być trudne dla ludzi, tak jak powiedziałeś, że pracujesz z ludźmi, których nigdy nie spotkałeś, a komunikacja może być trudna itp.

Zacznę od wiadomości e-mail skierowanej do wszystkich i informującej, kim jesteś, jak czujesz, że projekt powinien zostać rozwiązany, i poinformuj, że chcesz kierować projektem, biorąc odpowiedzialność za określenie ról, celu, terminów, czasu komunikacji, spotkań ( jeśli pożądane / pożądane) i aktualizacje projektu.

Chociaż nie możesz całkowicie wpływać na innych ludzi, możesz śledzić, kto robi co, a kto nie. Delegowanie zadań umożliwia równomierne lub odpowiednie dzielenie pracy dla osób o różnych umiejętnościach lub poziomach.

W ten sposób, jeśli pewna praca nie jest wykonywana, możesz wziąć na siebie podział pracy między ludzi, którzy tak naprawdę chcą nad nią pracować. W ten sposób nie skończysz z nieudanym projektem na końcu i będziesz miał zapisy prób przekazania dat, godzin i wszystkich istotnych informacji, które możesz pokazać na końcu, jeśli coś pójdzie nie tak. Wszystkie rzeczy, które utrzymują cię w porządku, jeśli niektórzy ludzie nie ciągną za siebie.

Pod względem wskazówek:

Osobiście uwielbiam współpracujące środowisko pracy tutaj: https://docs.google.com/

Pozwala to na udostępnianie dokumentów tekstowych, arkuszy kalkulacyjnych itp. Jest to świetny sposób współpracy. Nie mogę podkreślić, jak czasami jest to przydatne. Używam go z niektórymi ludźmi, z którymi pracuję, którzy nie są obecnie w kraju.

Mam nadzieję, że to komuś pomogło, istnieje tak wiele aspektów prowadzenia projektu, że moglibyśmy kontynuować na zawsze, ale to zależy tylko od tak wielu rzeczy. Przynajmniej to trochę pomaga.