Jak przekonać moich towarzyszy do przestrzegania podstawowych zasad

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?

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.

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.

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ć.

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

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.

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.

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.