Jak przekonać moich towarzyszy do przestrzegania podstawowych zasad

28

Mam problem z kolegami z drużyny. Krótko mówiąc: Jesteśmy trzema studentami pracującymi nad projektem na konkurs. Projekt składa się z 2 oddzielnych aplikacji: jednej dla systemu Windows (którą opracowuję) i jednej dla systemu Android (moi koledzy są odpowiedzialni za jego opracowanie). Nasze bazy kodu nigdy się nie przecinają, aplikacje komunikują się za pośrednictwem narzędzi stron trzecich.

Problem jest następujący: mam doświadczenie w pracy w zespołach, ponieważ w zeszłym roku odbyłem staż w dużej firmie i staram się egzekwować pewne standardy kodowania dla naszego kodu. Skonfigurowałem również oprogramowanie repozytorium git / wiki / współpracy, którego możemy używać do wypychania kodu / pisania pomysłów, protokołów dokumentów i tak dalej, ale wygląda na to, że tylko ja używam tych narzędzi.

Próbowałem im powiedzieć, że pisanie wysokiej jakości kodu i dokumentowanie każdego kroku przyniesie nam korzyści na dłuższą metę, ale wydaje się, że nie widzą w tym korzyści. Zastanawiałem się również nad dodaniem testów integracyjnych, ale z tego, co widzę, dopóki nie używają aktualnych narzędzi, aby ułatwić im życie, nie sądzę, żebym ich przekonał o przydatności testów integracyjnych.

Większość kodu równorzędnego znajduje się na ich komputerach, nie dzielą wspólnej bazy kodu i, jak się dowiedziałem, zintegrowali swoje elementy, spotykając i udostępniając kod za pomocą pamięci USB.

Moje pytanie brzmi: czy jestem zbyt surowy w tej sprawie? Czy egzekwuję jakieś absurdalne zasady? Pamiętaj, że jest to mały projekt, wymagania są bardzo jasne (stworzyłem dokumenty określające, co powinny robić aplikacje), trzech wykwalifikowanych programistów może to zrobić w ciągu 3-4 dni, więc mogą nie zauważyć dodatkowej złożoności jakości pisania kod tak długo, jak działa ich bieżąca metoda.

Czy jest jakiś sposób, aby pokazać im zalety dokumentowania kodu, używania git i tak dalej?

razvanp
źródło
37
Może uważają to za przesadę w przypadku „aplikacji na tydzień”? Być może to przez „jak” próbujesz ich przekonać? Jaka jest ich strona tej historii? Ich opinia nawet nie pojawiła się w twoim poście, ale słuchanie i rozumienie jest IMHO ważniejsze niż używanie tego czy innego narzędzia. ... a może po prostu nie dbają o zakres projektu? Wprowadzanie zmian wymaga komunikacji, umiejętności i cierpliwości.
Dagnelies
2
Po to są menedżerowie projektów. Musi być jakiś autorytet do podjęcia decyzji. „Próbowanie przekonać” może trwać wiecznie.
SChepurin,
@arnaud Rozmawiałem z nimi na ten temat, ale po prostu ich to nie obchodzi. Napisali trochę dokumentacji, ale większość z nich jest zrobiona przeze mnie. Również jeden z nich wprowadził pewne zmiany do naszego repozytorium git po tym, jak poprosiłem o sprawdzenie kodu, ale od tego czasu minął tydzień.
razvanp
7
Wprowadzenie nowych praktyk i nowych narzędzi opóźnia rozpoczęcie pracy, a później poprawia prędkość. Jaki jest harmonogram zawodów?
MarkJ
1
Czy przedstawiłeś je wszystkim opisywanym pojedynczo, czy zrobiłeś infodump? Jeśli jest to ten drugi problem, istnieje potencjalny problem - być może go przytłoczyłeś. Jest to klasyczny błąd neofita: Państwo poznać zalety, ale nie można zakładać, będą one natychmiast zrealizować te zalety. Musisz zacząć powoli, najpierw najbardziej użyteczną rzeczą.
mikołak

Odpowiedzi:

43

Moje pytanie brzmi: czy jestem zbyt surowy w tej sprawie?

Możesz doprowadzić konia do wody, ale nie możesz zmusić go do picia.

Trudno powiedzieć, czy jesteś „zbyt surowy”, ale może być nierealne oczekiwanie, że członkowie twojej drużyny wykorzystają całą infrastrukturę, na którą liczysz. I naprawdę, jeśli zespół dobrze współpracuje, użycie wiki do komunikacji między trzema osobami jest prawdopodobnie przesadą.

Zmniejsz swoje oczekiwania i poszukaj sposobów na osiągnięcie niektórych celów bez konieczności korzystania z narzędzi, których nie znają. Jeśli nie wiedzą, jak korzystać z git, prawdopodobnie i tak nie skorzystają z tego. Jednak nadal chcesz się upewnić, że utworzono kopię zapasową całego kodu w przypadku awarii dysku twardego lub innej katastrofy, więc poproś o okresowe kopiowanie folderu projektu na Dysk Google, Dropbox lub podobną usługę udostępniania plików online. Upewnij się, że robisz to samo.

Caleb
źródło
3
Dobra odpowiedź; zaczynając od czegoś łatwego w użyciu i tego, co prawdopodobnie już wiedzą, będzie znacznie łatwiejsze niż zmuszanie ich do czytania dokumentacji. Poza tym Dropbox działa cuda na każdym, kto nie zna wersji.
DistantEcho,
2
Z sukcesem używam github w dwuosobowym projekcie. Nie używamy wiki, ponieważ nie musimy jeszcze tego robić , ale używamy problemów i innej boskości github.
caarlos0
22

Podejrzewam, że jeśli nauczysz się robić te rzeczy w małych projektach, będziesz przygotowany na pojawienie się dużych projektów.

Jeśli zastosują się do dobrych praktyk rozwojowych w tym projekcie, będą mieli kod do zaprezentowania przyszłym pracodawcom i będą mieli doświadczenie, które uczyni ich cennymi jako pracowników.

Jeśli potrzebujesz więcej materiałów do ich przekonania, odsyłam do Pragmatic Programmer lub Code Complete .

Z drugiej strony rozważ rozluźnienie ich. Jeśli projekt jest dowodem koncepcji, który jest zbijany tuż po konkursie, powinieneś rozważyć pozwolenie mu na wykonanie tego, co im się podoba. Być może starają się napisać kod w pierwszej kolejności, bez mentalnych kosztów dobrych praktyk.

Gustav Bertram
źródło
8
Pomogłoby to PO, jeśli zostawiłbyś komentarz wyjaśniający, dlaczego przegłosowałeś.
Gustav Bertram
10

Obawiam się, że opisane zasady nie są wcale podstawowe.

Najłatwiejszym zadaniem IMO jest przekonanie członków twojej drużyny do korzystania z niektórych standardów kodowania. A prostym sposobem na osiągnięcie tego jest pokazanie im tego samego fragmentu kodu, który był kiedyś dobrze sformatowany, a następnie źle sformułowany, poprosił o przeczytanie kodu, zrozumienie jego działania i pozwolenie, by sami się ocenili.

Korzystanie z repozytorium git może być uciążliwe dla nowicjuszy. Kiedy pracowałem w 3-osobowym zespole nad projektem Androida, początkowo mieliśmy wiele problemów z naszym systemem kontroli wersji. Spodziewam się, że twoi koledzy z drużyny również będą mieli problem.

Wspomniałeś, że ukończenie projektu przez doświadczonego programistę zajmie 3-4 dni (zakładam, że zajęłoby to Twojemu zespołowi 2-3 razy dłużej). Jest to bardzo krótki okres czasu, więc argument, że korzystanie z nowych narzędzi pomoże na dłuższą metę, po prostu nie zadziała.

Możesz zrobić krótkie i proste dema, aby pokazać, jak te narzędzia są używane. Najpierw obejmij najbardziej podstawowe funkcje, usiądź obok nich i pomóż im korzystać z narzędzi. Przygotuj się do wykonywania wszystkich zadań, takich jak konfigurowanie gita, tworzenie struktury strony wiki itp.

Edycja : W odpowiedzi na komentarz, myślę, że ustalenie jasnych zadań, szacunków i terminów oraz śledzenie czasu spędzonego jest ważniejsze niż używanie git lub podobnych narzędzi. Jeśli planujesz później pracować nad aplikacją, bardzo ważne jest, aby śledzić, co już zostało zrobione i jak długo trwała każda funkcja. Proponuję więc zacząć od zarządzania zadaniami, a następnie przejść do narzędzi, których chcesz użyć.

superM
źródło
Tak, doświadczeni programiści zajęliby 3-4 dni, aby ukończyć projekt, jeśli pracują w pełnym wymiarze godzin, ale mamy zadania domowe, kursy, na które musimy przejść, dni, kiedy nie mamy ochoty na kodowanie - więc określiłem termin około . jeden miesiąc. Niestety nie zadbałem o skonfigurowanie niektórych narzędzi do śledzenia całkowitego czasu pracy nad konkretną funkcją, więc nie mogę w wiarygodny sposób określić łącznej liczby godzin pracy. Pamiętaj również, że planujemy kontynuować pracę nad aplikacją po zakończeniu konkursów.
razvanp
Proszę zobaczyć moją edycję.
superM
9

Właściwie podobają mi się myśli Joela Spolsky'ego na ten temat, które przedstawił w „ Making Things Done When You're Only a Grunt” . Podsumowując:

  1. Po prostu zrób to - pisz makefile, stwórz codzienny serwer kompilacji itp.
  2. Nikt nie korzysta z kontroli źródła lub baz danych błędów? Zacznij korzystać z nich sam. Jeśli ktoś zgłosi błąd dotyczący Twojej pracy, poproś go uprzejmie o skorzystanie z bazy danych błędów, aby zgłosić ci błędy, abyś mógł je śledzić; w przeciwnym razie nie będziesz w stanie utrzymać ich prosto w głowie i naprawić. W każdym nietrywialnym projekcie pojawi się sytuacja, którą można rozwiązać tylko za pomocą kontroli źródła: użyj kontroli źródła dla kodu samodzielnie i wkrocz heroicznie, aby uratować dzień, w którym taka sytuacja wystąpi. Gdy zdarzy się to kilka razy, przekonają się
  3. Stwórz kieszeń doskonałości - rób odpowiednie rzeczy dla siebie: spekulacje, planowanie itp. Ponieważ nie wydaje się to pracą, nie wydaje się, że możesz skorzystać z tych rad przez cały czas, ponieważ nie możesz zatrudnić nowi członkowie zespołu, którzy wierzą w twoją wiadomość
  4. Zostań bezcenny - udowodnij , że jesteś świetnym współpracownikiem, który umocni twój wpływ w zespole. W przeciwnym razie istnieje ryzyko, że staniesz się znany jako osoba, która ceni proces i narzędzia nad wynikami
Sójka
źródło
Bezcenna odpowiedź!
Vorac,
4

Dokumentacja, Wiki, oprogramowanie do kontroli wersji, metodologie itp. To doświadczenia i wnioski zdobyte w miarę upływu czasu; praca nad kilkoma projektami i prawdopodobnie przez kilka zespołów. I zwykle przylega do tych, którzy są już zatrudnieni lub poważnie podchodzą do swojej branży. Są studentami, więc ich zainteresowania prawdopodobnie nie są ograniczone tym, co dzieje się w przyszłości. :)

Ale spróbuj odpowiedzieć na twoje pytanie:

Jeśli jesteś z nimi w zespole, musisz zastosować to, co uważasz za ważne w sposób korzystny dla ich zainteresowań. Jako przykład: czy powinni narzekać na to, że ich kod bardzo często psuje się, gdy udostępniają go USB? Następnie może daj im prosty (nieskomplikowany) sposób używania SVN (zamiast git) jako narzędzia do kontroli wersji.

Zgadzam się również z komentarzem arnaud.

Widziałeś zalety wszystkich tych narzędzi podczas pracy z nimi i tak widziałeś w nich wartość i dlaczego rozumiesz ich użycie. Jeśli twoi koledzy z zespołu nie widzą wartości dodanej w tym, co robią obecnie, nie zastosują jej. Smutne jest to, że liczy się to nawet dla drużyn złożonych z ludzi o dowolnym poziomie doświadczenia.

David „łysy imbir”
źródło
Nie jestem przekonany, że SVN jest znacznie łatwiejszy w użyciu niż git. W systemie Windows zalecałbym Mercurial / TortoiseHG.
pingwin
Prawdziwe. Z mojego doświadczenia z SVN i GIT odkryłem, że SVN jest łatwiejszy do wyjaśnienia tym, którzy są nowi w koncepcji wersjonowania.
David „łysy imbir”
2

Podejście to ma problemy:

  1. Twoje podejście nie jest symetryczne. Inni członkowie zespołu muszą się zmienić, ale nie uczysz się ich dobrych praktyk. Egzekwowanie zasad w takich sytuacjach jest trudne. Lepszym podejściem byłoby zebranie dobrych zasad i praktyk od wszystkich członków zespołu, a następnie wszyscy po prostu czytają wynikowy dokument.

  2. Uczenie się jest trudne. Reguły innych ludzi po prostu nie mają sensu, ponieważ reguły te nie mają logicznej struktury, jakiej oczekują programiści. Egzekwowanie reguł, które nie mają sensu, nie jest pożytecznym działaniem.

  3. Wszyscy nauczyli się różnych rzeczy. To naturalne, że programiści pochodzący z różnych środowisk nauczyli się różnych rzeczy. Ich mocne strony są różne, a style pisania innego kodu. Narzędzia, których używają, są różne. Egzekwowanie jednego zestawu zasad / narzędzi / stylów będzie koszmarem, ponieważ ograniczenia tracą siłę, którą programiści spędzili lata na nauce.
  4. Zmiana wymaga czasu. Osoba, która wymyśliła reguły, które egzekwujesz, ma dość czasu na przestrzeganie zasad, wszyscy cierpią i spędzają czas na nauce nowych zasad. To jeden z powodów, dla których wszyscy członkowie zespołu powinni mieć możliwość zmiany zasad.
  5. Wybór narzędzi / konwencji lub stylów kodowania dla całego zespołu jest trudnym zadaniem . Z czasem można to zrobić powoli, sprawdzając, co działa, a co nie. Danie zespołowi 2 tygodni na rozpoczęcie przestrzegania 50 zasad nie zadziała.
tp1
źródło
-1

Znalazłem ten bardzo problem na uniwersytecie. Wiele osób po prostu nie chce nauczyć się innego (i być może bardziej profesjonalnego) sposobu pracy.

Jeśli jednak masz systemy i wyjaśnisz, jak z nich korzystać, wiele osób chętnie spróbuje. Myślę też, że repozytoria są bardzo słabo wykorzystywane i ludzie zwykle używają czegoś takiego jak dropbox.

Callum Bonnyman
źródło