Jak zachęcić do przyjęcia kontroli wersji

Niedawno zacząłem pracować w zespole, w którym nie ma kontroli wersji. Większość członków zespołu nie jest przyzwyczajona do kontroli wersji. Używam mercurial prywatnie do śledzenia mojej pracy. Chciałbym zachęcić innych do przyjęcia go, a przynajmniej zacząć aktualizować swój kod w miarę rozwoju zmian. Czy ktoś może mi doradzić, w jaki sposób mogę zachęcić do stosowania rozproszonej kontroli wersji, takiej jak mercurial. Wszelkie porady dotyczące pozyskiwania ludzi, w tym menedżerów do DVCS, byłyby bardzo mile widziane.

Musisz uzasadnić użycie kontroli wersji i najpierw spróbować sprzedać ją współpracownikom, a jeśli to się nie powiedzie, przejdź do łańcucha kierowniczego projektu i wyżej.

Dla innych inżynierów oprogramowania, twoja sprawa powinna skupić się na tym, jak oszczędza czas i bóle głowy na dłuższą metę. Znajdź czasy z własnej przeszłości lub opublikowane historie (blogi, artykuły w czasopismach, oficjalne dokumenty) o tym, jak korzystanie z kontroli wersji ułatwia Ci życie. Jeśli zostałeś spalony przez brak kontroli wersji, zrób to osobiście. Jeśli inni programiści byli w tej samej sytuacji, powinni zobaczyć światło i to, w jaki sposób te narzędzia mogą im pomóc.

To jest twój najlepszy zakład. Chociaż nie mogę teraz znaleźć źródła (źródeł), przeczytałem (w kilku miejscach), że najskuteczniejsze zmiany w procesie pochodzą od programistów, którzy muszą sobie z nimi poradzić. Jeśli uda Ci się zaangażować programistów, osiągniesz dwie rzeczy. Po pierwsze, masz już wpisowe od osób, na które zmiana procesu będzie miała wpływ. Po drugie, jest grupa ludzi, którzy przekonają kierownictwo, że jest to wartościowy wysiłek i poprawi produkt i projekt.

Jeśli jednak nie możesz uzyskać wsparcia zespołu programistów i nadal czujesz się niesamowicie silnie związany z wdrażaniem kontroli wersji, możesz przejść do zarządzania. Ale staje się bardziej ryzykowne, jeśli idziesz w pojedynkę, ponieważ nie tylko musisz się martwić o sprzedaż ulepszenia, ale także radzić sobie z reakcją ze strony kolegów.

Aby zarządzać projektami, programami i organizacją, należy zastanowić się, w jaki sposób wdrożenie kontroli wersji może zaoszczędzić czas i pieniądze organizacji. Ludzie na tym poziomie dbają o to, ile pieniędzy kosztuje projekt, gdzie jest ono w porównaniu do szacunków i tak dalej. Poszukaj białych ksiąg, książek, artykułów oraz innych profesjonalnych dokumentów i publikacji, które wyjaśniają, w jaki sposób wdrożenie kontroli wersji pozwoliło zaoszczędzić czas i pieniądze innych organizacji na dłuższą metę. Tutaj możesz również wprowadzić perspektywę jakości, jeśli Twoja organizacja jest zainteresowana jakością oprogramowania.

W szczególności wspomniałeś, że chcesz korzystać z rozproszonego systemu kontroli wersji. Nie zmuszaj tego do gardła zespołu lub organizacji. Przedstaw je do kontroli wersji i ich opcji. Chociaż osobiście wolisz używać DVCS (jak Mercurial), może nie być najlepszym rozwiązaniem dla Twojego zespołu i organizacji. Użycie narzędzia, które jest niewłaściwie dopasowane, pogorszy sytuację tylko poprzez rzucanie.

Pamiętaj również o ryzyku późnego wprowadzenia procesu . Chociaż stosowanie kontroli wersji jest powszechnie akceptowaną najlepszą praktyką, może być za późno, aby skutecznie wprowadzić ją w bieżącym projekcie bez ogromnego ryzyka zakończenia projektu. Zamiast tego zaleciłbym skoncentrowanie się na poprawie status quo dla przyszłych projektów i zespołów.

Jest to również ogólne podejście, które można zastosować w celu wprowadzenia usprawnień procesów lub technologii.

Pierwsze pytanie brzmi: co oni obecnie robią? Z pewnością każdy programista nie ma kodu źródłowego na swoim własnym pudełku, który zmienia do woli. Po zakończeniu procesu, w którym aktualnie postępują, możesz zasugerować narzędzia usprawniające ten proces - zwykle SCM jest idealny, aby im w tym pomóc, a nie zmuszać ich do wykonania innego procesu.

Najważniejsze jest to, że jeśli mają pseudo-SCM, może przechowywać gdzieś aktualną wersję na serwerze, to musisz ustalić, czy DVCS lub CVS jest bardziej odpowiednie, nie próbuj sprzedawać ich Mercurial jeśli SVN jest lepszym rozwiązaniem.

Najszybszym sposobem jest przekonanie kierownictwa, że ​​jest to potrzebne.

Wykonaj obliczenia:

Koszt oprogramowania do kontroli wersji - bezpłatnie.
Koszt sprzętu do obsługi repozytorium - jeden serwer.
Koszt wdrożenia oprogramowania - kilka osobodni dla małego zespołu, rosnących dla większych zespołów.

Koszt niewdrożenia kontroli wersji:

Najlepszy przypadek - dni stracone z powodu brakujących edycji, wzajemnego nadpisywania zmian itp., Powtarzających się błędów i tak dalej.
Najgorszy przypadek - jak wiele ludzkich lat pracy Twój zespół do tej pory poświęcił.

Ta ostatnia liczba jest najgorszym scenariuszem utraty pracy z powodu awarii serwera itp., Ale nawet scenariusze „najlepszego przypadku” powinny uświadomić im, dlaczego jest to potrzebne. Koszt powtarzających się błędów może być większy, ponieważ może prowadzić do utraty klientów.

Zespół programistów powinien również zrozumieć te koszty i biorąc pod uwagę, że większość (jeśli nie wszystkie) oprogramowanie do kontroli wersji bezproblemowo integruje się z IDE w dzisiejszych czasach, nawet nie zauważą, że jest tam przez większość czasu.

Zarządzanie zazwyczaj dba o oszczędność pieniędzy. Podkreśl, w jaki sposób kontrola wersji może przynieść korzyści zespołowi finansowemu, a od razu zwrócisz na to uwagę!

Jest jeden aspekt, którego inni ludzie tutaj nie poruszali, a myślę, że masz w swoim kącie - mówisz o rozproszonej kontroli wersji - z samej swojej natury, możesz wkraść się w faktyczną praktykę, jeden programista na czas. Dzięki bardziej skomplikowanej kontroli wersji, takiej jak ta, której używamy w moim biurze (MS Visual SourceSafe), ciężko byłoby ci podejść do faceta w sześcianie naprzeciwko mojego i sprzedać go, jeden na jednego na podstawie zalet kontrola wersji. Jednak w przypadku (dowolnego) DVCS możesz po prostu powiedzieć „hej, spróbuj tego i zobacz, czy ci się podoba. Pokażę ci liny i chętnie odpowiem na wszelkie pytania, przeprowadzę cię, bla bla bla ”. W ten sposób nie potrzebujesz „procesu” z góry na dół, możesz zbudować oddolny mandat, jedna osoba na raz.

Opierając się na odpowiedzi gbjbaanb.

Kluczową kwestią jest to, że powinieneś dostosować proces kontroli wersji do istniejącego procesu i pokazać, jak oszczędza on resztę wysiłku zespołu.

Ja też osobiście faworyzuję Mercurial, ale niekoniecznie chciałbym narzucić go osobom nieprzyzwyczajonym do kontroli wersji, ponieważ jest to trochę trudniejsze do zrozumienia niż staroświecki system kontroli wersji oparty na serwerze. To powiedziawszy, jeśli jest to prawdziwa strona greenfields, najlepiej byłoby przejść całą wieprza, pominąć lata 80. i 90. i wybrać Mercurial. Chciałbym również spojrzeć na niektóre elementy cyklu życia oprogramowania innych firm zbudowane wokół Mercurial - jestem pewien, że istnieje jedno, ale jego nazwa ucieka mi;)

Zgaduję, że pracujesz dla małej firmy i jesteś stosunkowo nowy w zespole, więc może to być trudna sprzedaż - szczególnie jeśli reszta zespołu jest zakorzeniona i ma zaufanie do kierownictwa. Może najlepiej pozwolić im źle coś załatwić, a potem przyjść im na ratunek. To nie oznacza sabotażu, tylko poczekaj na nieuniknione.