Podczas mojej pierwszej pracy jako programista mój zespół używał metodyki agile / scrum do zarządzania przepływem pracy w projekcie i działało to całkiem nieźle. Miałem doświadczonych mentorów, którzy postawili mnie na właściwej drodze - jestem im winien wielki dług wdzięczności. Pracowałem tam przez kilka lat, a kilka miesięcy temu przeszedłem na nową okazję.
Szybko przejdź do mojej obecnej pracy. Pracuję na uniwersytecie pod kierunkiem profesora. Ponieważ jestem na uniwersytecie, prawie każdy programista jest studentem (są tanie i obfite!) Mój szef ma doświadczenie w zarządzaniu, ale nie z programowaniem, a zespół oprogramowania nie zawsze jest na pierwszym planie . Te warunki stworzyły idealne środowisko do tworzenia oprogramowania o bardzo niskiej jakości. Projekty oprogramowania wydają się być nieco nieuczciwe, nie myślą o projektowaniu i stosują naprawdę przerażające praktyki. Wiem, że może być lepiej.
Chcę wdrożyć proces programowania, aby pomóc wszystkim w śledzeniu, zwiększyć jakość kodu i wdrożyć bardziej stabilne oprogramowanie. Po prostu nie jestem pewien, od czego zacząć.
Ja nie patrząc, na powiedzieć, odpowiedzi jak „Korzystanie Scrum”, „utwórz Tablica Kanban” lub „Spójrz na Agile!” (choć pomysły są doceniane). Mówiąc dokładniej, mam nadzieję uzyskać wgląd w to, jak wdrożyć proces programowania dla tego środowiska pracy. Pracownicy zwykle pracują od 1 do 2 lat przed przejściem, są na ogół niedoświadczeni, a codzienne spotkania z udziałem wszystkich są prawie niemożliwe do zaplanowania.
Jak sprzyja się jakości, wydajności i komunikacji w takim miejscu pracy?
Aktualizacja: po przeczytaniu niektórych odpowiedzi i komentarzy pomyślałem, że przedstawię dodatkowe informacje.
Nie uważam się mistrzem w sztuce tworzenia oprogramowania, ale ja jestem na tyle doświadczony, aby rozpoznać złe programowanie, gdy widzę go. Potrafię ustalić, czy programista jest utalentowany, czy nie po spędzeniu z nim zaledwie minuty lub dwóch. Czuję się dobrze z własnymi możliwościami znalezienia sposobu na inteligentne rozwiązanie problemu , jednak obszarem, w którym naprawdę brakuje mi doświadczenia, jest zarządzanie projektami, w które zaangażowani są inni programiści (dlatego właśnie tutaj proszę wszystkich o cudowne osoby o Rada).
Wydawało mi się, że każdy uczeń wchodzący do tego biura jest kompletnym durniem. Było tu trochę złych jaj, ale większość studentów, których spotkałam, jest inteligentna, chce się uczyć i pasjonuje się pracą. Niektórzy dopiero zaczynają i nie wiedzą, czego nie wiedzą. I w porządku. Kiedy zaczynałem programować, nie było mi lepiej!
Odpowiedzi:
Usunięcie pomyłki zajmuje więcej czasu niż sprawdzenie wstępne. Jeśli masz do czynienia z programistami (prawdopodobnie) niewykwalifikowanymi lub nieświadomymi dobrych praktyk, oznacza to, że nie powinni oni być w stanie zmienić bazy (master) kodu, dopóki ich kod nie zostanie sprawdzony przez kogoś doświadczonego.
Nie chciałeś wyjaśnienia metodologii, więc pozwól mi przejrzeć tę część: użyj zwinnych zadań, aby skonfigurować różne funkcje, które można opracować niezależnie.
Zacznij korzystać z gałęzi funkcji, aby wszyscy pracowali w osobnej gałęzi. Po zakończeniu zadania programista nie może scalić swojego kodu z gałęzią master. Jeśli korzystasz z Git, nadal mogą uruchomić żądanie ściągnięcia. W przeciwnym razie użyj dowolnej metody śledzenia zakończonych zadań (/ oddziałów), która Ci się spodoba.
Następnie przechodzimy do procesu recenzji . To, co zadajesz, jest nieco niejasne, czy są też doświadczeni programiści, którym można zaufać bardziej niż ocenom studentów. Pozwólcie więc, że rozwinę te kwestie:
Jeśli są doświadczeni programiści, powierz im przegląd kodu ukończonych zadań. Jeśli jest dobry, mogą połączyć go z gałęzią master. Jeśli tak nie jest, mogą albo sfaktoryzować go samodzielnie, albo przekazać deweloperowi informacje zwrotne na temat tego, co należy poprawić.
Jeśli nie ma doświadczonych programistów, zawsze będziesz mieć problemy. Jeśli nie ma nikogo, kto zauważyłby dobry kod ze złego kodu, niemożliwe jest utrzymanie jego jakości.
Najlepsze, co możesz zrobić, to spotkania przeglądowe, podczas których programiści przedstawiają i wyjaśniają ich implementację przed innymi programistami. Chociaż nie może to zagwarantować uniknięcia każdego problemu (np. Jeśli wszyscy programiści mają takie samo błędne przekonanie na temat dobrych praktyk, nadal zapobiegnie większości problemów (np. Jeśli co najmniej jeden programista ma właściwy pomysł i może go wyrazić; lub gdy problem występuje) od programistów, którzy inaczej rozumieją problem)
źródło
Największą rzeczą w tego rodzaju środowisku, w którym ludzie są nowi i prawdopodobnie odejdą, są obowiązkowe przeglądy kodu.
Pomagają rozpowszechniać wiedzę o tym, co należy zrobić. Pomagają zapobiegać przedostawaniu się najgorszego kodu do bazy kodu. Promują spójność we wdrażaniu.
Ponieważ przy tak dużym obrocie i braku doświadczenia komunikacja jest ważniejsza niż zwykle.
źródło
Bardziej pomysł niż rozwiązanie, ale znajdź jedną krytyczną sekcję bazy kodu, która zawiera podobne funkcje i elementy do projektów, które mogą zrobić Twoi studenci, i wyczyść ją BARDZO dobrze. Jednym z dużych problemów z nowymi programistami jest to, że nie znają norm i konwencji bazy kodu i będą patrzeć na inny kod, aby dowiedzieć się, jak skonfigurować własny. Posiadanie wielu nowych programistów pracujących w nieporządnej bazie kodu oznacza, że zobaczą bałagan i będą myśleć, że jest to akceptowalny lub najlepszy sposób na zrobienie czegoś. Złe praktyki utrwalają się nawet w środowisku o wysokich obrotach.
Dysponując co najmniej jedną nieskazitelną, dobrze napisaną sekcją kodu (lub nawet tylko jednym plikiem), możesz powiedzieć programistom-uczniom, aby wykorzystali to jako przykład najlepszych praktyk. Powiedz im, że będziesz zachwycony, jeśli będą mogli napisać kod podobny do tego, a znaczna część innego kodu może nie być dobrym przykładem właściwego sposobu robienia rzeczy.
Dodanie komentarzy lub innej dokumentacji z wyjaśnieniem, dlaczego pewne czynności są wykonywane w określony sposób, pomoże również nowym programistom szybciej przyśpieszyć działanie dzięki lepszym praktykom kodu.
źródło
Ciągła integracja -
Jest to praktyczne i koncepcyjne ramy dla stopniowego i elastycznego wdrażania narzędzi, umiejętności i procesów zespołu.
CI jest ideą przepływu pracy od pisania kodu do wdrożenia. Te zadania są koncepcyjnie i faktycznie niezależne.
CI to w szczególności automatyzacja. Ma to głęboki wpływ na jakość i produktywność, poczynając od momentu wpisania kodu na ekranie.
Spodziewaj się, że będziesz pełnoetatowym agentem zmian. Zostań liderem; nie tylko menedżer, nie tylko starszy programista.
Bądź strategiczny
Bądź taktyczny
Droga do jakości
Testów jednostkowych
Kontrola wersji
Recenzje kodu
Refaktoryzacja
Uchwyć swoje środowisko
Słowo o procesie
Zwinny (i jego podgatunki, takie jak Scrum): Zapomnij. „Jesteś zwinny, nie zwinny”. Zobacz je Dave Thomas, jeden z pierwszych sygnatariuszy Agile Manifesto .
Biorąc pod uwagę małe, niedoświadczone zespoły, mój pająk traci sens, gdy widzę narzędzia do integracji zespołu, takie jak Visual Studio Team Services. Moje doświadczenie jest tu ograniczone, ale wyczuwam, że to oszałamiające, zbędne, sztywne narzucanie procesu. Wiem, że wielu używa tych rzeczy z wielkim skutkiem, ale strzeż się potencjalnie zakupu rozwiązania szukającego problemu.
Słowo o narzędziach
Tylko ja. Nie z tych „Najlepszych narzędzi programowych teraz ...” przynęt z miodem.
Jenkins
Narzędzie do integracji CI. Internetowy, szeroko stosowany. Zasadniczo za pośrednictwem internetowego interfejsu GUI konfigurujesz i automatyzujesz różne zadania i kolejność wykonywania, takie jak kompilacja, uruchamianie testów jednostkowych, aktualizacja kontroli wersji. Jest bardzo A-La Carte, więc można go dostosować do rodzącego się środowiska CI.
Kontrola wersji
Wolę Mercurial niż Git. Ten post na blogu jest powodem, dla którego pierwotnie wybrałem Mercurial: Git to MacGyver, Mercurial to James Bond
Subversion jest dobre. Mercurial & Git mają inną architekturę, która jest lepsza niż Subversion.
Zintegrowane środowisko programistyczne
Oto wielka uwaga, jeśli wszyscy używają różnych narzędzi do kodowania: Nie ma czegoś takiego jak zwykły tekst
Słowo o profesjonalnej bibliotece
Internet jest szeroki, płytki i niezorganizowany.
źródło
proponuję zastosować inną metodologię do zarządzania twoim procesem, ponieważ, jak mówisz, nie można zaplanować spotkań (co jest absolutnie ważne dla scrum!). Nadal nie ma nic złego do stworzenia dobrej koncepcji, więc wszyscy wiedzą, co się dzieje (prawdopodobnie również za pomocą prototypu vert) i używają modelu wodospadu. Tak czy inaczej komunikacja jest największą częścią pracy.
źródło
Zachęcam do korzystania z kontroli źródła, jeśli jeszcze tego nie zrobiłeś. Pozwala to zobaczyć, co zostało zameldowane przez każdego programistę i umożliwia regresowanie tam, gdzie został wprowadzony błąd.
Ustawiłbym jakiś zestaw testów. Może to być programowanie oparte na testach, w którym piszesz testy dla każdej zatwierdzanej funkcji, lub może to być zautomatyzowany sposób uruchamiania aplikacji i wysyłania wyników do pliku, który można porównać z pożądanym wynik. Jeśli jest to uruchamiane po każdym zatwierdzeniu lub uruchamiane przynajmniej raz na noc, szybko znajdziesz regresje.
Ostatnią rzeczą, którą bym zrobił, to zaimplementować 2 zasady: 1) wszystkie kompilacje muszą mieć ostrzeżenia ustawione na błędy i wszystkie błędy włączone 2) Cały kod musi przejść przez analizator statyczny bez generowania jakichkolwiek błędów lub ostrzeżeń przed zatwierdzeniem. Uczyniłbym to nawet działaniem poprzedzającym zatwierdzenie. Te 2 rzeczy zapobiegną szybkiemu zepsuciu kodu na wiele typowych sposobów. (Nie łapią wszystkiego, ale dużo łapią.)
To również przygotuje twoich uczniów do pracy w „prawdziwym świecie” i zaszczepi im w miarę dobre nawyki.
źródło