W przyszłości przejście od projektu jednoosobowego do projektu zespołowego. Co powinienem teraz robić w ramach przygotowań i na co mogę czekać?

Aby to wyjaśnić, jestem zainteresowany wiedzą, co ludzie myślą, że powinieneś wdrożyć, będąc jeszcze jednoosobowym projektem (kontrola źródła zespołu, dokumentacja, kompilacje itp.) I jakich rzeczy nie trzeba robić, dopóki nie pojawi się druga osoba na projekt.

Każdy, kto ma doświadczenie w poruszaniu się w tym scenariuszu, doceni ich spostrzeżenia.

Czego się nauczyłem. (Próbowałem innego rozkazu. Myliłem się. To jest kolejność, w której sprawy stają się istotne.)

1. Umieść wszystko pod kontrolą kodu źródłowego. Użyj czegoś, do czego wszyscy mają dostęp, i zacznij już teraz . Bez wyjątków. Bez opóźnień Bez wymówek.

2. Utwórz obszar kontroli jakości / testowania, który będzie całkowicie oddzielony od osobistego środowiska „roboczego” lub „programistycznego”. Co najmniej osobny identyfikator użytkownika. Idealnie na osobnej maszynie wirtualnej.
   Całkowicie osobny. Żadne możliwe nakładanie się z obecnym środowiskiem pracy.

3. Przestań testować poza testem jednostkowym we własnym środowisku pracy. Test kodu i jednostki wykonujesz „jak ty”. Wszystkie inne testy (integracja, wydajność, cokolwiek) wykonujesz na osobnej maszynie wirtualnej. Nigdy nie testuj jak ty. Zawsze testuj jako osobny użytkownik kontroli jakości. Idealnie na osobnej maszynie wirtualnej.

   „Działa dla mnie” to zła rzecz do powiedzenia członkom zespołu. Bardzo źle. Musisz dowiedzieć się, co robią źle. Kilka razy dziennie.

4. Planuj zapisać wszystko. Użyj zwykłego narzędzia znaczników (RST, Markdown lub coś takiego), aby cała dokumentacja była w postaci zwykłego tekstu w repozytorium kontroli wersji. Narzędzie może tworzyć strony HTML (np. Docutils dla RST), pliki PDF lub cokolwiek, co wydaje się najlepsze. Nie używaj zastrzeżonych formatów dokumentów (np. MS-Word). Mogą nie działać dobrze z niektórymi systemami kontroli kodu źródłowego.

5. Pierwsze rzeczy, które musisz zapisać, to:

   • Jak stworzyć działające środowisko programistyczne. W razie wątpliwości utwórz maszynę wirtualną i wykonaj całą operację na tej maszynie wirtualnej. Upewnij się, że kroki naprawdę działają, a dokumentacja jest przejrzysta . Rzeczywiste wiersze wpisane z rzeczywistą klarownością wiersza poleceń.

   • Jak uruchomić pakiet testów jednostkowych. Jeszcze raz. Upewnij się, że instrukcje działają i nie wymagają myślenia. „Wpisz to:” „Potwierdź to:”. Członkowie zespołu nie są głupi. Chodzi o to, że nie pamiętasz, co zakładasz, chyba że wszystko zapisujesz.

   • Jak uruchomić pakiet testów integracyjnych.

   Nie marnuj dużo czasu na opisywanie architektury lub zasad projektowania. Najpierw musisz kogoś uruchomić. Możesz wyjaśnić różne rzeczy później.

6. Następną rzeczą do udokumentowania są historie użytkowników. I przypadki testowe, które wspierają te historie. A urządzenia danych wymagane dla przypadków testowych, które obsługują te historie użytkowników.

   Udostępnisz to. Podlega kontroli kodu źródłowego.

7. Ostatecznie możesz udokumentować pozostałe 4 widoki.

   • Widok logiczny jest pomocny w dokumentowaniu. Zdjęcia są tutaj dopuszczalne. Ma to tendencję do szybkiej ewolucji, więc nie marnuj czasu na przechwytywanie starszych informacji. Opracuj sposób współpracy z członkami swojego zespołu.

   • Widok procesu jest często pomocny. Zależy to od ogólnej aplikacji, jak ważne jest to.

   • Widok rozwoju - moduły, biblioteki, frameworki itp. - jest często opisywany nieformalnie. Zdjęcie może pomóc, ale notorycznie trudno jest zrobić to tak, aby ktoś mógł odebrać dokument i zrobić z niego głowy lub ogony. Nawet ugruntowane, bardzo publiczne projekty mają dokumentację biblioteczną, która jest po prostu ignorowana. (Prowadząc do wielu pytań dotyczących przepełnienia stosu).

     Poza tym, że można być nieformalnym, może się to szybko zmienić.

   • Informacje o wdrożeniu. Serwery Adresy IP. Poświadczenia bazy danych. Wszystkie te rzeczy muszą zostać zapisane. Ostatecznie.

Narzędzia i metodologia

Co jest potrzebne do udanej współpracy i produktywności?

• Zidentyfikuj części / komponenty swojego projektu: Wyraźne rozróżnienie między różnymi częściami (baza danych, warstwa dostępu do danych, strona internetowa, usługa, API, projekty testowe, skrypty kompilacji, ...) i środowiskami (deweloper, inscenizacja, produkcja) i nazwij je konsekwentnie wpływa na komunikację ustną i pisemną (dokumentacja, nazwy projektów, ...)
• Użyj systemu zarządzania kodem źródłowym (na wypadek, gdybyś jeszcze tego nie zrobił). Zastanów się, jak korzystać z rozgałęzień w projekcie i konfiguracji.
• Zautomatyzuj swoje kompilacje - maksymalnie skonfiguruj środowisko z repozytorium źródłowego.
• Projekty testowe są koniecznością w przypadku dużych projektów, przynajmniej w przypadku bardziej złożonych projektów.
• Użyj środowiska pomostowego, w którym projekt jest gotowy do użycia. Ponadto należy tworzyć i utrzymywać przykładowe dane w celu zautomatyzowanej konfiguracji przemieszczania.
• Użyj systemu śledzenia błędów, który może pomóc w ustalaniu priorytetów i planowaniu rozwoju, a także służy jako pamięć dla poprzednich błędów i sposobu ich rozwiązania.
• Dokumentuj każdą część swojego projektu, niektóre bardziej niż inne. Osobiście lubię: Przegląd - Architektura - Zależności - Konfiguracja - Typowe problemy ( stąd ). Czasami mniej znaczy więcej - aby nie dopuścić do przedawnienia dokumentacji, lepiej jest być zwięzłym i pozwolić, aby dokumentacja stała się częścią codziennej aktywności.

Zarządzanie / praca zespołowa

... lub cokolwiek innego na poziomie interpersonalnym

• Określ swoje oczekiwania wobec drugiego programisty. Bądź rozsądny, nikt nie wnosi tyle samo zaangażowania i pasji co ty - przynajmniej nie od samego początku. Przekaż, czego oczekujesz, a czego nie, zdefiniuj obowiązki swoje i innych. Nie każdy jest inżynierem, architektem, programistą, dba i sysadmin, ale jeśli tego właśnie szukasz, wybierz odpowiednią osobę, inaczej będziesz rozczarowany.
• Początkowo , określić zadania dokładnie i przegląd i omówienie wyników. Stopniowo zaczynaj coraz mniej mikro-zarządzania. Chodzi o budowanie zaufania i zwiększenie odpowiedzialności.
• Zaplanuj swój projekt , ustal cele dla swojego projektu i zespołu na następny rok. Zapisz i sprawdź później, to da perspektywę . Cele te mogą, ale nie muszą być przekazywane innym (o ile są to cele, które musisz osiągnąć, a nie inni), może to być po prostu twoja lista kontrolna.
• Poświęć dzień na przygotowanie i zaplanowanie pierwszego miesiąca (lub dwóch / trzech miesięcy) nowego programisty. Uważam to za niezwykle motywujące, gdy pracuję z dobrze przygotowanymi ludźmi. Nikt nie powinien mieć wrażenia, że ​​jego czas jest zmarnowany.
• Puścić . To twoje dziecko, powinno też stać się własnością kogoś innego. Pozwól drugiemu stać się ekspertem lepszym od ciebie, przynajmniej w niektórych częściach projektu. Oznacza to, że faktycznie Ci się udało.
• Słuchaj - jeśli ją zatrudniłeś, ma coś do powiedzenia. Przygotuj się do nauki.
• Bądź gotów podzielić się swoją wiedzą i doświadczeniem (a zatem czas - bądź cierpliwy).
• Popełniane będą błędy , liczy się sposób, w jaki są one traktowane i to, czego wszyscy się o nich dowiadują.
• Daj czas na naukę i eksperymenty

Odnośniki do książek

Wymienię niektóre z często wspominanych książek, które faktycznie przeczytałem i uważam, że warto je przeczytać, aby uzyskać bardziej szczegółowy opis lub więcej książek, możesz chcieć sprawdzić niektóre pytania dotyczące SO, dokładnie o to pytając, na przykład to lub to pytanie.

Te książki naprawdę warto przeczytać w odniesieniu do zespołów, organizacji i projektów programistycznych:

• Peopleware
• Miesiąc mitycznego człowieka
• Ocena oprogramowania, odsłaniając czarną sztukę

Żaden z nich nie jest praktycznym przewodnikiem wdrażania metodologii X (oprócz Szacowania oprogramowania, ta książka pomaga wybrać odpowiedni proces szacowania). Oczywiście, książki bardziej skoncentrowane na samym programowaniu, takie jak Code Complete, również bardzo wzbogacają.

Opowiem o tym doświadczeniu, ale pamiętaj, że każdy jest inny. Te rzeczy nie są uniwersalne.

Jedną rzeczą jest pozwolić mu odejść osobiście. Ten projekt jest czymś, z czym żyłeś i mieszkałeś przez 18 miesięcy - naturalnie chciałbyś, aby każda zmiana była taka, jak byś to zrobił. Daj bufor kolegom do popełniania błędów, do nauki. Stwórz pokój, aby były przydatne. I pamiętaj, że może się to nie zdarzyć od razu. Byłoby również wspaniale, gdyby było coś, część kodu, którą mogliby czuć, że udoskonalili lub stworzyli, co wydaje się sukcesem w krótkim czasie. Cierpliwość i tolerancja mają tutaj dobrą stopę zwrotu. Nie próbuj mikromanagować, a jeśli chcesz krytykować, powiedzieć „jesteś w błędzie”, upewnij się, że masz jakąś zasługę, możesz to udowodnić, to nie jest walka „religijna”.

Kolejną kluczową kwestią jest znalezienie odpowiedniej osoby dla Ciebie. Najlepiej byłoby znaleźć kogoś mądrzejszego od siebie. Jest to subiektywne i względne, ale jeśli czujesz, że dana osoba ma trochę wiedzy i umiejętności, których nie masz, tak jest najlepiej. Będzie to wzajemnie satysfakcjonująca współpraca.

Można to zrobić na dwa sposoby - kolega będzie miał kłopoty, a ty przerwiesz to, co on lub ona zrobi, albo umiejętności dwojga z was pomnożą się, a nie tylko zsumują, i naprawdę docenicie współpracę.

Na temat „czystego, szybkiego, wielokrotnego użytku kodu” - proponuję podczas wywiadu, poprosić o napisanie małego mikro-jądra / menedżera usług i / lub wykonawcy pracy. Zobacz, w jaki sposób komponenty wtykowe są określone i skonfigurowane. Nie trzeba kończyć, liczy się myśl. A także szybko nauczysz się ludzi, którzy dobrze wiedzą, jak to zrobić, będą chcieli porządnych pieniędzy ;-) Powodzenia!

Moje zdanie: zacznij od udokumentowania architektury wewnętrznej projektu dla kogoś ... kto nie jest tego świadomy. Spróbuj wyjaśnić, które założenia istnieją i kiedy / gdzie odszedłeś od typowych praktyk i dlaczego.

Automatyzacja kompilacji: Świetny pomysł, mogę dodać automatyzację konfiguracji dla maszyny deweloperskiej. Najłatwiej jest zbudować, tym więcej będzie (więc więcej / szybsze testowanie wdrożenia).

Kolejny pomysł (bardzo mi kiedyś pomógł): Poproś nowego programistę o wykonanie drobnych zadań czyszczenia w różnych obszarach bazy kodu, aby przyzwyczaił się do narzędzi do układania itp. Jednym dobrym pomysłem jest usunięcie niejasne obszary, które mogą później wprowadzić zamieszanie (przykład: jeśli użyłeś gdzieś emmona w Pythonie dla dwóch linii skryptu powłoki, a twój projekt jest oparty na Javie, poproś o napisanie tych dwóch linii w Javie, aby deweloper # 3 musiał wiedzieć mniej, aby pracować)

Chciałbym skupić się na zautomatyzowaniu wszystkiego, co wymaga pracy ręcznej, a tym samym może być przykręcony przez niedoświadczonego człowieka . Który, na podstawie powyższego krótkiego komentarza, obejmuje:

• zainstaluj kontrolę wersji i zastąp ręczne kopie zapasowe automatycznymi,
• skonfiguruj automatyczne wdrażanie w jak największym stopniu (przynajmniej napisz skrypt, aby wdrożyć przez FTP, zamiast robić to ręcznie.

Jeśli tego nie zrobisz, albo będziesz przykuty do wykonywania tych zadań na zawsze, albo (niektórzy) nowi faceci nieuchronnie coś spieprzą prędzej czy później.

Innym ważnym zadaniem jest, jak zauważył @dimitris, dokumentacja. @S. Lott dodał o wiele więcej szczegółów, więc po prostu +1 do niego, zamiast powtarzać :-)

Oto kilka myśli, częściowo opartych na osobistych doświadczeniach:

• Udokumentuj swój projekt. Specyfikacje konstrukcyjne, diagramy, instrukcje i komentarze pomogą nowemu pracownikowi przyspieszyć. Wyjaśnienie złożonego systemu tylko werbalnie może okazać się powolne i frustrujące. Dokumentacja jest często zaniedbywana w projektach jednoosobowych. Upewnij się, że twój jest wyjątkiem.

• Najpierw skoncentruj się na kodzie API / rdzenia, jednocześnie dając nowemu pracownikowi trochę „warstwy aplikacji” lub naprawy błędów, aby stopniowo zapoznać się z kodem. Ogólnie rzecz biorąc, zacznij od łatwiejszych , ale znaczących i satysfakcjonujących zadań .

• Komunikacja jest ważna. Odpowiadaj na pytania, komentarze i pomysły nowego pracownika. Wyjaśnij, dlaczego uważasz, że pomysł nie jest dobry, jeśli tak robisz. Świeża para oczu może zaskoczyć zaskakująco dobrze. Jeśli nowy pracownik jest przyzwoity, może przejrzeć Twój kod i ostatecznie uczestniczyć w decyzjach architektonicznych. Dyskutuj, odbijaj pomysły od siebie. To jedna z największych korzyści z posiadania współpracownika przy projekcie.

• Jasno określ obowiązki , gdy wiesz, jakie zadania wykonuje nowy członek zespołu. Ustanów praktyki dokumentacyjne i konwencje kodowania, aby zachować płynność.

• Użyj systemu kontroli wersji . Utrzymuj logiczny układ plików źródłowych i dyscyplinę kompilacji .

Jeśli chodzi o rozmowę kwalifikacyjną - nie jestem wielkim fanem testów sztucznego kodowania lub podstępnych pytań, chyba że chcesz wypróbować zdolność kandydata do wytrzymywania stresu. W tej sytuacji nawet najinteligentniejsi rozwiązujący problemy mogą się zamknąć. Cechy, których będziesz szukać, to między innymi: uczciwość , umiejętności zawodowe , wiedza / wgląd technologiczny , entuzjazm i wzajemna kompatybilność . Atmosfera pracy może mieć duże znaczenie; odradza się wybranie członka drużyny, którego nie lubisz. Zadaj właściwe pytania i przeprowadzaj nieformalną dyskusję, aby uzyskać dobre zdjęcie swojego kandydata. Powodzenia!

Technologia

Jeśli sprowadzasz kogoś innego jako programistę, są trzy kluczowe rzeczy, które zaleciłbym mieć przed uruchomieniem.

1. Kontrola źródła
2. Śledzenie problemów
3. Ciągła integracja

Jeśli te trzy rzeczy działają poprawnie, wyeliminujesz około 75% typowego problemu, który pojawia się po przyjęciu nowego członka zespołu. Istotą tych technologii jest wzięcie dużo tego, co dzieje się tylko w twojej głowie, i wydobycie go z miejsca, w którym członek zespołu może z nim współdziałać.

Kontrola źródła zapewnia, że ​​oboje pracujesz nad tym samym. Śledzenie problemów pomaga śledzić, co należy zrobić, a także ułatwia sprawdzenie, nad czym pracują i co robią. Ciągła integracja i testowanie pomogą upewnić się, że masz powtarzalny proces kompilacji i że nowe ulepszenia nie psują innych części kodu.

Pragmatic Programmer ma na ten temat kilka całkiem dobrych książek. Oto kilka polecam. Mają inne podobne tytuły w zależności od używanego języka programowania lub kontroli wersji, której chcesz użyć:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. com / titles / auto / pragmatic-project-automation

Osobisty

Często trudności, z którymi się spotkasz, są mniej związane z techniczną stroną rzeczy, a bardziej z nauką odpuszczania. Zapewnienie komuś innemu kontroli nad aspektami projektu może być trudne - szczególnie jeśli przyzwyczajasz się do robienia wszystkiego sam i podejmowania każdej decyzji. Zaoszczędzisz sobie trochę żalu, jeśli znajdziesz obszar, w którym nowa osoba może pracować z rozsądną swobodą na początku, abyś mógł zbudować fundament zaufania. Jeśli zatrudnisz dobrą osobę, najważniejszą rzeczą, której prawdopodobnie będziesz się uczyć, jest to, jak ufać drugiej osobie w wykonywaniu dobrej pracy, nawet jeśli wszystkie jej indywidualne decyzje nie są takie same, jak te, które podjąłbyś.

Chcesz dać swojemu nowemu najemcy swobodę rozwiązywania problemów w sposób, który im odpowiada, przy jednoczesnym zachowaniu zabezpieczeń, abyś mógł wcześnie wychwycić problemy.

Te punkty są najważniejsze według mnie:

1. Przeczytaj najważniejsze części kodu i upewnij się, że są łatwe do zrozumienia. Używaj komentarzy lub intuicyjnych nazw funkcji i zmiennych.
2. Ułatw nowej osobie przesyłanie kodu.
3. Jeśli nie jest to trywialne, utwórz plik README, który objaśnia wszystkie kroki niezbędne dla nowego programisty, jak skonfigurować środowisko programistyczne. Ewentualnie ściśle pomóż w skonfigurowaniu tego środowiska.
4. Daj nowemu programistowi bardzo jasno określone zadania podczas pracy nad tym nowym projektem. Moim zdaniem zadania te powinny obejmować nową, ale prostą funkcjonalność. Moim zdaniem zadania czyszczenia nie mają większego sensu, ponieważ nowy programista musi najpierw przyzwyczaić się do twojego stylu kodowania i związanych z nim nawyków, nawet jeśli są złe. Czyszczenie, a nawet refaktoryzacja to prace, które muszą wykonać osoby znające kod.
5. Wyjaśnij, na czym polega proces przesyłania kodu. (Np. Przesyłaj tylko rzeczy, które się kompilują.) Ale nie bądź zbyt surowy, na początku może to być frustrujące.
6. Przygotuj dokument z konwencjami kodowania. Zgadywanie, jakie są pozostałe konwencje kodowania, może być naprawdę frustrujące.
7. Jeśli aplikacja jest złożona, przygotuj dokumentację wyjaśniającą architekturę. Lub wyjaśnij architekturę nowej osobie za pomocą schematów blokowych lub czegoś podobnego. Nie chcesz, aby nowy programista marnował zbyt dużo czasu na przebudowę Twojego projektu.
8. Jeśli nowy programista powinien sam przeprowadzić wdrożenia, przygotuj uporządkowaną listę kontrolną wyjaśniającą wszystkie niezbędne kroki do wdrożenia.

I na koniec: uzyskaj system kontroli wersji. Subversion jest w porządku. Pamiętaj jednak, aby nie dodawać plików Eclipse (lub cokolwiek innego), które są specyficzne dla użytkownika i dlatego stale zmieniają się. Sprawiają, że marnujesz godziny. Nie wahaj się zapytać na Stackoverflow, jeśli masz z tym problemy.