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.
Odpowiedzi:
Czego się nauczyłem. (Próbowałem innego rozkazu. Myliłem się. To jest kolejność, w której sprawy stają się istotne.)
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.
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.
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.
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.
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.
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.
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.
źródło
Narzędzia i metodologia
Co jest potrzebne do udanej współpracy i produktywności?
Zarządzanie / praca zespołowa
... lub cokolwiek innego na poziomie interpersonalnym
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:
Ż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ą.
źródło
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!
źródło
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ć)
źródło
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:
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ć :-)
źródło
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!
źródło
Technologia
Jeśli sprowadzasz kogoś innego jako programistę, są trzy kluczowe rzeczy, które zaleciłbym mieć przed uruchomieniem.
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.
źródło
Te punkty są najważniejsze według mnie:
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.
źródło