Metodyka Crystal

Metodyka Crystal, której twórcą jest Alistar Cockburn jest jedną z metodyk zaliczanych do zwinnego zarządzania projektami w obszarze tworzenia oprogramowania komputerowego. Metodyka Crystal, ma siedem poziomów złożoności, które opierają się o wspólną podstawę tzw. „kod genetyczny”, a głównym kryterium, które odróżnia kolejne typy metodyki Crystal jest liczba osób, które są zaangażowane w realizację projektu.

Rys Historyczny

W 1991 roku Alistair Cockburn pracował w IBM i otrzymał zadanie opracowania najbardziej efektywnej metodologii tworzenia oprogramowania. W związku z tym musiał przeprowadzić wywiady i przestudiować wiele zespołów projektowych. Cockburn podkreślił znaczenie komunikacji i rozmowy: „Skoncentrowanie się na umiejętnościach, komunikacji i społeczności pozwala projektowi być bardziej efektywnym i zwinnym niż skupianie się na procesach i planach” (Highsmith 2002, str. 261). Odkrył również, że należy wybrać i dostosować strategię do grupy uczestników projektu i zadań przez nich wykonywanych.

7 zasad metodyki Crystal

A. Cockburn wymienił również cechy udanych projektów realizowanych zgodnie z Crystal - pierwsze trzy są wymagane, a kolejne cztery przenoszą zespół w strefę bezpieczeństwa, w której członkowie czują się najwygodniej i pracują najlepiej:

Częste dostarczanie użytecznego kodu (oprogramowania) (ang. Frequent delivery) Najważniejszą właściwością każdego projektu jest częste dostarczanie działającego, przetestowanego kodu do rzeczywistych użytkowników. W przypadku nie stosowania się do tej zasady istnieje wysokie ryzyko, że produkt w postaci oprogramowania może być całkowicie bezużyteczny.

Refleksyjne podkreślanie jakości procesu (ang. Reflective improvement) Cykliczne spotkania zespołu i dyskusja członków nad poprawkami i zmianami oraz wyciąganie wniosków podnosi jakość opracowywanego produktu.

Komunikacja osmotyczna (ang. Osmotic communication) Dotyczy to podkreślenia znaczenia komunikacji miedzy wszystkimi członkami zespołu znajdującymi się w jednym pomieszczeniu. Istotą nie jest wyłącznie czynny udział w dyskusji, ale także słuchanie dyskusji odbywającej się w tle, które niekoniecznie stanowi pierwszy plan danego członka zespołu, ale pozostaje w pewnej części świadome.

Osobiste bezpieczeństwo (ang. Personal safety) Poczucie bezpieczeństwa osobistego jest kluczową cechą, którą należy osiągnąć w zespole. Jest to zasada związana ze swobodą wyrażania własnego zdania na temat realizowanego projektu, nie obawiając się jakichkolwiek negatywnych konsekwencji ze strony przełożonych. Mając swobodę mówienia, zespół może odkryć i naprawić swoje słabości. Otwarta komunikacja oznacza też zaufanie, ponieważ zgadzamy się na to, iż każdy może zaprezentować swoje zdanie na forum zespołu projektowego.

Skupienie (ang. Focus) Kierownictwo i liderzy muszą ustalić priorytety projektu, wymagania, cele i jasno przekazać je zespołowi. Oznacza, że każdy w zespole wie czym będzie się zajmować, ma przeznaczoną na to odpowiednią ilość czasu, jest w stanie się skupić na swoich zadaniach. Zespoły powinny określić dwie godziny każdego dnia roboczego w którym nie są dozwolone żadne przerwy, w tym spotkania, rozmowy telefoniczne i pokazy.

Ciągły dostęp zespołu do użytkowników ekspertów Ciągły dostęp do użytkowników z wiedzą ekspercką pozwala uzyskanie szybkiej odpowiedzi w postaci informacji zwrotnej dotyczącej jakości produktu i zauważonych błędów. Użytkownicy eksperci pełnią rolę testerów, którzy dostarczają wyniki z poszczególnych iteracji. Programiści powinni często udostępniać swoje oprogramowanie, aby wykorzystać otrzymane informacje zwrotne do ulepszania swoich produktów.

Środowisko techniczne (ang. Technical environment) Projekt powinien być realizowany w odpowiednim środowisku, z przeprowadzaniem automatycznych testów, częstą integracją i efektywnym zarządzaniem konfiguracją. Wiele zespołów programistycznych będzie integrować system kilka razy dziennie lub przynajmniej raz dziennie. Zespoły, które wykonują „ciągłą integrację z testami”, będą w stanie wykryć błędy na poziomie integracji w krótkim czasie

Wszystkie powyższe zasady są w mniejszym lub większym stopniu obecne w innych metodach typu zwinnego. Crystal Clear podkreśla siłę i autonomię zespołu i na te właśnie aspekty kładzie nacisk.

Typy metodyki Crystal

Wszystkie podejścia w ramach rodziny metodologii Crystal koncentrują się na ludziach i komunikacji, ale podejścia ze względu na wielkość zespołu (ilość członków przydzielonych do realizacji projektu) różnią się od siebie krytycznością i priorytetem projektu. Podstawowym założeniem jest to, że im więcej osób jest w zespole, tym bardziej złożony jest projekt i im bardziej uporządkowany jest typ tego projektu, tym bardziej ustrukturyzowane i sztywne musi być podejście do niego. Dlatego Cockburn nazwał swoje różne podejścia od kryształów geologicznych, z twardszymi kamieniami, takimi jak diamenty, reprezentującymi bardziej ustrukturyzowane podejścia. I odwrotnie, najbardziej płynne podejście zostało nazwane Crystal Clear.

W związku z powyższym wyróżnia się 7 poziomów, poniżej przedstawiono ich charakterystyki:

Crystal Clear: Najlepiej sprawdza się w małych projektach - Małe zespoły, 1 – 6 uczestników projektu - Jest zorientowany na ludzi i nie koncentruje się na procesach - Wymaga pełnej dokumentacji - Jest skoncentrowany na bezpieczeństwie projektu

Crystal Yellow: Małe i średnie zespoły o liczności od 7 do 20 uczestników, - Obszary kodu oprogramowania mają określną własność, co wskazuje na pełną odpowiedzialność twórcy w razie wprowadzania modyfikacji, - Informacja zwrotna pochodzi od realnych użytkowników oprogramowania - Bezpośrednia komunikacja, która zmniejsza potrzebę dokumentacji i jednocześnie wpływa na lepsze zrozumienie zadań wykonywanych przez deweloperów, - Przeprowadzane są testy automatyczne i ustalane są plany ulepszeń, składa się to na sporządzenie listy rzeczy do poprawienia w określonym czasie.

Crystal Orange: - średnie zespoły o liczności od 21 do 40 uczestników, - Czas trwania projektu to około 1 do 2 lat, - Przeznaczony do projektów średniej wielkości, - Używany w projektach, które mają stale rozwijającą się bazę kodu, - wymaga się, aby każda kolejna wersja była wydawana średnio co 3 – 4 miesiące.

Crystal Red: - średnie i duże zespoły składające się od 40 do 80 osób, - zespoły są dzielone zgodnie z wymaganiami pracy (według umiejętności) -występuje tradycyjny model tworzenia oprogramowania

Crystal Maroon: -duże zespoły składające się od 80 do 200 osób, - Średni czas trwania projektu ponad 2 lata;

Crystal Diamond & Sapphire Podział można przedstawić na wykresie prezentującym strukturę Crystal

Zalety metodyki Crystal

Zapewnia częste dostawy, aby móc zidentyfikować ewentualne problemy na wszystkich etapach Zawsze jest miejsce na ulepszenie charakterystyk, poświęcenie czasu na opracowanie oprogramowania i umożliwienie dyskusji o tym, jak ulepszyć procesy Umożliwia bliską komunikację i promuje interakcję i dzielenie się wiedzą między członkami zespołu Wymaga środowiska technicznego z automatycznymi testami i częstą integracją Pozwala zespołom pracować w sposób, który ich zdaniem jest najbardziej efektywny Ułatwia bezpośrednią komunikację między członkami zespołu, promuje przejrzystość i odpowiedzialność Podejście adaptacyjne pozwala zespołom dobrze reagować na potrzeby zmian.

Wady metodyki Crystal

Występowanie różnych typów Crystal w rodzinie metodyki, oznacza, że zasady mogą się również różnić w zależności od wielkości zespołu i projektu, co czyni je niejasnymi Może nie działać w przypadku zespołów rozproszonych w kilku lokalizacjach ze względu na ciągłą potrzebę komunikacji i uzgadniania Planowanie i rozwój nie są zależne od wymagań projektu Brak z góry określonych planów może prowadzić do nieporozumień Brak dokumentacji może również prowadzić do nieporozumień