Zarządzanie zmianą w projekcie informatycznym

Zarządzanie zmianą w projekcie informatycznym Flavio Takemoto / stock.xchng

System Kontroli Wersji jest rodzajem zapisu dotychczasowych danych. Gdy chcemy powrócić do poprzedniej wersji programu, SKW nam to ułatwi.

Artykuł zawiera krótkie wprowadzenie do tematu zarządzania zmianami w projekcie informatycznym. Na zarządzanie zmianą składają się dwa elementy: kontrola wersji kodu oraz śledzenie błędów i zmian. W artykule zajmiemy się oboma tymi zagadnieniami, szczegółowo potraktujemy zwłaszcza problem wersjonowania kodu, który jest jednym z najważniejszych czynników zapewniających jakość wytwarzanego oprogramowania i sprawną pracę w ramach zespołu.

Omówione zostaną powszechnie stosowane procedury i narzędzia pozwalające efektywnie zarządzać zmianami w projekcie. Artykuł jest przeznaczony dla osób zarządzających projektami oraz dla programistów, którzy chcą dowiedzieć się czym jest kontrola wersji i śledzenie błędów.

Artykuł jest poświęcony zarządzaniu zmianami w projekcie informatycznym. Jest to niezwykle ważny element projektu informatycznego, który w dużym stopniu ułatwia i usprawnia pracę całego zespołu, pozwala tworzyć oprogramowanie lepszej jakości.

Rozpoczniemy od ogólnego wprowadzenia do tej tematyki, które pokazuje wagę omawianych kwestii, a także charakterystyczne cechy, jakie powinny mieć narzędzia wspomagające zarządzanie zmianami. Następnie przejdziemy do bardziej szczegółowych rozważań oraz konkretnych i praktycznych przykładów.

Zarządzanie zmianą składa się z dwóch podstawowych elementów:

    • kontroli wersji,
    • śledzenia błędów i zmian.

Zajmiemy się najpierw wersjonowaniem kodu.

Projekty informatyczne stają się coraz bardziej skomplikowane, trwają coraz dłużej, wymagają efektywnej i dobrze skoordynowanej współpracy zespołu specjalistów.

Jednym z najbardziej podstawowych sposobów na usprawnienie komunikacji w zespole jest użycie narzędzi do wersjonowania kodu źródłowego programów, dokumentacji oraz wszelkich innych plików powstających przy wytwarzaniu produktu (np. grafika, podręcznik użytkownika, itp.).

Kontrola wersji pozwala na śledzenie zmian wnoszonych przez poszczególnych członków zespołu, umożliwia, w razie potrzeby, przywrócenie poprzednich wersji oprogramowania, pozwala zablokować dostęp do wybranych zasobów tak, aby dwie lub więcej osób nie modyfikowały jednocześnie tego samego pliku, co może mieć niepożądane konsekwencje.

Potrzeba użycia systemu kontroli wersji znalazła się na pierwszym miejscu wśród czynników poprawiających sprawność zespołu programistów w opinii znanego programisty i publicysty Joela Spolskyego: Test Joela: 12 kroków ku lepszym programom.

Wykorzystanie narzędzi do zarządzania zmianą w kontekście wprowadzania w firmie systemów jakości jest opisane w artykule Zarządzanie zmianą: podstawa Modelu Dojrzałości Organizacyjnej (CMM/CMMI).

Kolejnym sposobem usprawnienia pracy zespołu jest wykorzystanie narzędzie do śledzenia błędów i zmian w projekcie. Jest rzeczą oczywistą, że oprogramowanie w czasie swojego cyklu życia, począwszy od wczesnej fazy projektowania systemu, poprzez etap budowania systemu, aż do wdrożenia kolejnych wersji u klienta będzie się zmieniało.

Zmiany te mogą wynikać pojawiających się nowych wymagań lub modyfikacji tych, które były już uwzględnione albo być wymuszone przez wykrycie błędów.

Kluczową sprawą jest takie zarządzanie cyklem życia aplikacji, które gwarantuje, że zgłoszony błąd, czy zgłoszone nowe wymaganie, nie zostanie "zgubione". Powinno ono być przydzielone odpowiednim osobom, które albo zajmą się poprawieniem błędów, albo, zanim problem zostanie przekazany programistą, ocenią jak bardzo kosztowne będzie wprowadzenie żądanych zmian.

Takie określenie trybu postępowania ze zgłoszonymi wymaganiami nazywa się często zdefiniowaniem reguł przebiegu pracy (ang. workflows).

Wprowadzenie procedur zarządzania zmianami w projekcie owocuje wzrostem produktywności zespołu. Każdy wie, czym powinien się zająć, co więcej, można rozłożyć równomiernie obciążenie pracą, gdyż wiadomo kto ma ile przydzielonych zadań. Ponadto użycie odpowiednich narzędzi powoduje, że tworzenie wszelkich raportów, podsumowań staje się bardzo proste - można je wygenerować jednym przyciśnięciem klawisza.

Z drugiej strony także klient jest zadowolony, ponieważ istnieje jasny tryb zgłaszania błędów bądź próśb o uzupełnienie produktu o nową funkcjonalność. Wiadomo, kto na danym etapie prac zajmuje się określonym zgłoszeniem, kto powinien poinformować klienta o tym, że prace zostały ukończone i jest dostępna nowa, poprawiona wersja produktu.

Oczywiście w idealnej sytuacji narzędzie do śledzenia błędów i zmian jest zintegrowane z narzędziem kontroli wersji - pozwala to połączyć występujący błąd lub prośbę o dodanie funkcjonalności z kolejnymi wersjami konkretnych plików (np. kodu źródłowego), pozwala to tworzyć wersje produktu, które są zdefiniowane przez określoną funkcjonalność.

Warto zwrócić uwagę, że wersjonowania czy śledzenia błędów opłaca się używać nie tylko w przypadku dużych projektów, w których bierze udział kilkadziesiąt-kilkaset osób. Efektywne zarządzanie zmianą przynosi naprawdę znaczące korzyści również w przypadku niezbyt dużego projektu, w który zaangażowanych jest trzech czy czterech programistów. Zajmijmy się teraz dokładniej kontrolą wersji.

Po co nam kontrola wersji kodu źródłowego?

Według różnych źródeł około 70% firm tworzących oprogramowanie nie używa żadnego systemu kontroli wersji. Część osób czytających być może zada sobie pytanie "Czego nie używa?". Poniżej postaram się przybliżyć problematykę kontroli wersji tym, którzy nie wiedzą, na czym ona dokładnie polega lub wahają się, czy może być dla nich użyteczna.

Zacznijmy od początku. Na większości uczelni student informatyki dowie się czym jest klasa, jak napisać metodę i które języki programowania są według jego wykładowców najlepsze. Prawdopodobnie zdobędzie wiedzę w abstrakcyjnych dziedzinach informatyki, zgłębi meandry matematyki, ale nikt mu nie powie o kontroli wersji kodu źródłowego.

Bo właściwie po co? Projekty na zaliczenia rzadko będą rozbudowane. Czas ich życia wyznacza zbliżająca się sesja. Student opuszcza uczelnię przekonany, że teraz przed nim świetlista kariera w informatyce, że wie już wszystko.

Pierwszej pracy nie szuka się teraz po studiach ale w ich trakcie. Zgodnie z pierwszym akapitem tego paragrafu szanse na trafienie do firmy, w której używa się systemu kontroli wersji (SKW) są mniej więcej jak 1:2. Pierwsze zetknięcie się z takim systemem jest zazwyczaj naznaczone wzajemną nieufnością: programista nie ufa SKW, a SKW nie ufa programiście. Porozumienie zdobywa się w "boju".

Gdy raz pozna się pożytki płynące z użycia narzędzi do kontroli wersji, trudno sobie wyobrazić bez nich pracę.

Gdy trafiłem po raz pierwszy do dużej firmy tworzącej oprogramowanie na zamówienie, od razu dostałem polecenie zainstalowania systemu kontroli wersji. "Co za strata czasu" - pomyślałem. Po instalacji i krótkim instruktażu pobrałem kod, nad którym miałem pracować i zacząłem coś w nim zmieniać. Najpierw wszystkie pliki były tylko do odczytu, a jak zdjąłem ten atrybut to serwer nie chciał ich przyjąć. Chwilę potrwało zanim ja przyzwyczaiłem się do systemu wersjonowania a on do mnie. Na szczęście pod czujnym okiem starszych kolegów nic nie zepsułem.

W miarę jak poznawałem zalety systemów kontroli wersji coraz bardziej przekonywałem się do korzystania z nich. Teraz nawet w projektach, które robię sam używam systemu kontroli wersji.

Podobne artykuły:

Czym jest kontrola wersji?

Kiedy tworzymy program koncentrujemy się przede wszystkim na tym, żeby uzyskać żądaną funkcjonalność z możliwie najmniejszą liczbą błędów. Ale w trakcie pracy poprawiając jedne błędy często tworzymy inne.

Pisząc tekst korzystamy z funkcji "Cofnij" edytora automatycznie, kiedy tylko jest nam potrzebna - nikt nie powie że funkcja "Cofnij" jest niepotrzebna. Ale gdy zamkniemy program to tracimy całą informację o zmianach w naszej pracy. Przez to "Cofnij" nie działa następnego dnia rano, gdy przyjdziemy do pracy. Zmian, które zrobiliśmy kilka dni wcześniej, już nie cofniemy. Brakuje nam historii zmian w plikach.

Kontrola wersji zapełnia tę lukę dodając taką historię. Historia zaś daje możliwość powrotu do dowolnego punktu w czasie tworzenia systemu. Kontrola wersji działa jak przycisk "Cofnij" w skali makro.

Powyższe porównanie odnosi się jednak do pojedynczego stanowiska pracy. Gdy nad projektem pracuje wiele osób to wtedy magiczny przycisk "Cofnij" nie istnieje. Jednak błędy popełniamy nadal. Tak naprawdę przy pracy zespołowej potrzebujemy czegoś z pogranicza magii i technologii - "magicznej" kontrola wersji, która da możliwość cofania zmian niezależnie od tego, kto je popełnił.

Żaden członek zespołu nie musi się martwić, że zmiana, którą wprowadził popsuje kod innych, ponieważ w każdej chwili można wrócić do poprzedniej wersji. Pozwala to zespołowi budować pewność siebie niezbędną do odważnych zmian i rewolucyjnych pomysłów. W projekcie lepiej widać, że kontrola wersji to nie tylko prowadzenie historii plików - to również sposób komunikacji między członkami zespołu.

Za każdym razem gdy w systemie kontroli wersji pojawia się nowa wersja pliku musi ona mieć opis zmian. Dzięki temu każdy członek zespołu może sprawdzić co się w określonym pliku zmieniło i nie potrzebuje w tym celu szukać autora zmian.

Jak działają systemy kontroli wersji?

W systemach kontroli wersji używa się kilku magicznych zwrotów. W zasadzie są one wspólne dla większości systemów. Ponieważ SKW są najczęściej w języku angielskim to prezentowane będą nazwy angielskie z polskim objaśnieniem.

    • Repository (repozytorium) - miejsce przechowywania plików w systemie kontroli wersji, niekoniecznie baza danych, często pewna specyficzna struktura katalogów z opisami.
    • Katalog roboczy - miejsce w którym znajdują się kopie lokalne plików nad którymi pracujemy. Najczęściej katalog na naszym komputerze.
    • Get (pobranie) - pobranie plików z repozytorium np.: z serwera.
    • Check-in (wstawienie) - gdy skończymy zmieniać pliki to wstawiamy je na serwer, tak aby każdy mógł je pobrać w najnowszej wersji.
    • Check-out (wybranie) - pobranie plików z serwera z zamiarem zmiany. Może być związane z jednoczesną blokadą.
    • Lock (blokada) - zablokowanie innym użytkownikom możliwości wybrania.
    • Label (etykieta) - oznaczenie nazwą grupy plików w celu łatwej ich identyfikacji.
    • Branch (gałąź) - stworzenie alternatywnej linii wersjonowania. Pozwala to na rozwój tego samego pliku w różnych kierunkach, np.: wprowadzanie poprawek do starej wersji i dodawanie funkcji do nowej wersji.
    • Merge (połączenie) - łączenie dwóch kopii pliku w jeden. Może się odnosić do dwóch sytuacji: łączenia gałęzi i rozwiązywania konfliktów.

Powyższe funkcje opisują podstawową funkcjonalność SKW.

Łatwo zauważyć, że opis funkcji Get i Check-out jest bardzo podobny. Zasadniczą różnicą jest to, że wykonanie funkcji Check-out zakłada chęć zmieniania plików.

Różnica ta zaczyna być istotna gdy chcemy korzystać z blokady. Blokada jest sposobem na uniknięcie sytuacji, w której dwie osoby zmieniają ten sam plik. Jeżeli operacja Check-out zakłada blokadę na zmianę pliku to nikt inny nie może go wybrać ani wstawić (Check-in). Funkcjonalność taka jest niezbędna, gdy edytujemy pliki binarne przechowywane w SKW.

Gdy edytujemy tekstowe pliki kodu źródłowego to blokada zazwyczaj nie jest konieczna. Jeżeli dwie osoby zmienią ten sam kod to później muszą połączyć swoje zmiany do nowej wersji. Korzystając z powyższej terminologii pracę z systemem kontroli wersji możemy opisać przez taki ciąg działań:

  1. Tworzymy repozytorium.
  2. Dodajemy do niego pliki projektu.
  3. Pobieramy (Get) pliki z repozytorium do katalogu roboczego.
  4. Wybieramy (Check-out) pliki do edycji.
  5. Zmieniamy to, co potrzebujemy.
  6. Sprawdzamy, że wszystko działa.
  7. Wstawiamy (Check-in) zmienione pliki do repozytorium.
  8. Jeżeli okaże się że ktoś zmienił plik, który wstawiamy to prawdopodobnie będziemy musieli połączyć (Merge) wersje.
  9. Jeżeli jeszcze coś jest do zrobienia to wracamy do punktu 4.

Jak widać praca z SKW z punktu widzenia użytkownika na podstawowym poziomie jest bardzo prosta.

Podobne artykuły:

Przykłady stosowania systemu kontroli wersji

Zastanówmy się, co się dzieje, jeżeli ktoś potrzebuje powrócić do starszej wersji plików? W takiej sytuacji może on wybrać z repozytorium wersję (np według daty albo etykiety) i zacząć pracę nad nią.

Trochę bardziej skomplikowana sytuacja jest, jeżeli potrzebujemy jednocześnie pracować na dwóch wersjach. Będziemy wtedy musieli dokonać rozgałęzienia projektu. Powstaną dwie gałęzie (branch), w których będziemy mogli pracować bez wpływania jedna na drugą. A gdy nadejdzie czas, że będziemy chcieli połączyć te wersje to wtedy będziemy musieli wykonać funkcję Merge.

Rozważmy następujące przykłady:

Przykład A: Tworzymy program wymieniający informację przez sieć po protokole TCP/IP, który szyfruje komunikację algorytmem A. W pewnym momencie czytamy o nowym wspaniałym algorytmie B, który jest szybszy i bezpieczniejszy. Zmiana pliku z implementacją algorytmu to moment. Następnie zaznaczamy zmienione pliki etykietą (label). Program zaczyna działać na nowym algorytmie, mijają dni i tygodnie i nagle okazuje się, że jakiś genialny matematyk wynalazł metodę ataku na algorytm B, która powoduje, że można go złamać w ciągu kilku dni a nawet godzin. Chcemy natychmiast wrócić do algorytmu A. Jeżeli mamy system kontroli wersji to jest to proste: ponieważ zaznaczyliśmy w systemie kontroli wersji zmianę algorytmu, więc albo anulujemy zmiany w pliku z algorytmem, albo kopiujemy poprzedni algorytm z historycznego pliku.

Przykład B: Nasza firma rozwija się i mamy już 3 wersję naszego produktu. Starsze wersje nie są dalej rozwijane, a tu nagle pojawia się klient, który koniecznie potrzebuje poprawek do pierwszej wersji aplikacji.

Jeżeli korzystamy z systemu kontroli wersji to nasze zadanie jest bardzo proste. Odnajdujemy w repozytorium moment w historii produktu, oznaczony jako wersja 1, tworzymy rozgałęzienie, poprawiamy kod, dostarczamy gotowy produkt klientowi i oczywiście inkasujemy należność. Gdy nie używamy SKW to musimy poszukać odpowiedniej kopii zapasowej aplikacji z tego okresu (bo robiliśmy przecież kopie zapasowe każdej wersji, prawda?), następnie poprawiamy znaleziony przez klienta błąd... Jeżeli nie dysponujemy archiwalną kopią kodu, to nasze zadanie staje się niezwykle trudne.

Można sobie zadać pytanie, dlaczego by po prostu nie sprzedać klientowi nowej wersji produktu - otóż często jest to niemożliwe, na przykład ze względu na bezpieczeństwo, inne systemy informatyczne, jakimi dysponuje klient, itd.

Powyższe przykłady opisują jedynie udogodnienia oferowane przez system kontroli wersji. Znacznie poważniejsza sytuacja jest opisana w ostatnim przykładzie.

Przykład C: Nad projektem pracuje grupa programistów. Bardzo często używany jest plik z klasą obsługującą główne okno programu - MainFrm.cpp. Dwóch programistów Jan i Tomasz pracując nad swoimi częściami kodu potrzebowało zmodyfikować plik MainFrm.

Jan jako pierwszy skończył i wstawia plik do głównego repozytorium, Tomasz robi to jako drugi. Jeżeli nie mamy SKW to repozytorium najczęściej będzie wprost w systemie plików, wtedy Jan straci swoje zmiany, bo w tym przypadku, kto pierwszy ten gorszy. SKW natomiast zasygnalizuje, że istnieje zmieniona wersja i zaproponuje łączenie (Merge) zmian. Co więcej, ponieważ zmiany nie będą anonimowe, to obaj programiści będą mogli uzgodnić swoje poprawki. Niczyja praca nie będzie stracona.

System kontroli wersji broni nas również przed nami samymi. Również w sytuacji gdy Tomasz jest zmęczony i pomimo ostrzeżenia zmusi SKW do nadpisania pliku to cały czas istnieje wersja Jana jako poprzednia. W tym przykładzie system kontroli wersji broni nas również przed uzyskaniem wersji kodu, która nie będzie się kompilowała - nadpisanie czyichś zmian może właśnie doprowadzić do problemów z kompilacją.

SKW i co dalej

System kontroli wersji nie rozwiązuje jednak wszystkich problemów w zespole programistycznym. Jest tak naprawdę częścią większej całości - systemu zarządzania zmianą. System zarządzania zmianą powinien pozwolić na łączenie zmian w kodzie z żądaniami zmiany i śledzeniem błędów. Takie podejście pozwala na dokładniejsze zarządzanie projektem i pracą. Samo podejście do projektu przez pryzmat żądań zmiany (change request) i próśb o funkcjonalność (feature request) porządkuje pracę, która musi być wykonana i pozwala na jej właściwą organizację.

Podsumowanie

Przykłady przedstawione w powyżej pokazują kilka wybranych zagadnień dotyczących wykorzystania systemów kontroli wersji. Natomiast aby można było dobrze wykorzystać te wszystkie możliwości to konieczne jest przestrzeganie dwóch bardzo ważnych reguł:

  1. Często wstawiać pliki do repozytorium. Obecnie narzędzia do wersjonowania działają na poziomie pliku i tylko tam umieszczane zmiany są zauważane, dlatego częste wstawianie pozwala na dosyć dokładne określenie zmiany oraz tego czego ona dotyczy.
  2. Wstawiać do repozytorium tylko te zmiany, które nie powodują problemów z kompilacją. Przed każdym wstawieniem wstawiający zobowiązany jest sprawdzić, czy to, co wstawia jest kompilowalne. Jeżeli pracujemy na wielu plikach, przydatne może być korzystanie z prywatnych gałęzi kodu oferowanych przez niektóre narzędzia (np. Surround SCM).

Trudno w krótkim artykule umieścić wszystkie kwestie związane z wersjonowaniem, ale mam nadzieję, że ten artykuł przekona wahających się, że warto.

Podobne artykuły:


Erudis Process Management