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.

Cele metodyki Crystal

Rodzina Crystal dąży do osiągnięcia trzech priorytetów. Są nimi (K. Kaczor 2014 s. 90):

• Bezpieczeństwo projektu (ang. project safety) - projekt powinien dostarczyć zasadny wynik biznesowy, ze względu na ustalone priorytety i ograniczone zasoby.
• Efektywność rozwoju (ang. development efficiency) - oczekuje się aby praktyki deweloperskie były efektywne z ekonomicznego puntu widzenia.
• Przyjęcie przez zespół narzuconych reguł (ang. habitability of the resulting conventions) - akceptacja reguł i praktyk przez zespół jest niezwykle istotna, ponieważ członkowie zespołów omijają je traktując konkretne techniki jako niedogodności wydłużające pracę i stanowiące obciążenie.

7 zasad metodyki Crystal

A. Cockburn wymienił zasady realizacji projektów realizowanych zgodnie z metodyką Crystal - pierwsze trzy są wymagane, a kolejne cztery przenoszą zespół w strefę bezpieczeństwa, w której członkowie czują się swobodnie i pracują wydajnie i efektywnie (P. Mangudo 2012 s. 10-11):

Częste dostarczanie użytecznego kodu (oprogramowania) (ang. Frequent delivery) Najważniejszą zasadą 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 to, ż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 (ang. Easy access to expert users) 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. Ambassador users 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. Metodyka crystal podkreśla siłę i autonomię zespołu i na te właśnie aspekty kładzie silny 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:

• Małe zespoły, 1 – 6 uczestników projektu
• Najlepiej sprawdza się w małych projektach
• 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,
• Wymagane jest, 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

Role w metodyce Crystal

A. Cocburn wyróżnił w metodyce Crystal następujące role w zespole (A. Cockburn, 2004, s. 155 - 157):

• Executive Sponsor - Odpowiada za finansowanie projektu i dysponuje zasobami, definiuje cały projekt oraz pomaga zespołowi w podejmowaniu kluczowych decyzji biznesowych.
• Ambassador User - Użytkownik, który testuje finalny produkt, zna on procedury operacyjne i ma pełną wiedzę o tworzonym produkcie.
• Lead Designer - Osoba odpowiedzialna za cały nadzór techniczny, aby projekt przebiegał zgodnie z planem. Jego funkcja sprowadza się zarówno do projektowania produktu (oprogramowania), jak i do samego programowania. Musi być to osoba wszechstronna i doświadczona, która poradzi sobie z najtrudniejszymi zadaniami programistycznymi.
• Designer - Programmer - Współpracuje z Lead Designerem przy projektowaniu i programowaniu produktu.
• Coordinator - Odpowiada za zapewnienie sponsorom projektu wglądu w strukturę i status projektu. W zespole pełni rolę mediatora, ułatwia dyskusję i ogranicza konflikty.
• Business Expert - Osoba posiadająca wiedzę w zakresie tego jak działa firma, jaką ma strategię. W zespole odpowiada na pytania deweloperów. Zdarza się, że w niektórych zespołach Ambassador User jest również Business Expertem.
• Writer - Odpowiada za pisanie kodu zgodnie z planem projektu.
• Tester - Odpowiada za testowanie oprogramowania, zgłaszanie istniejących błędów i podjęcie próby ich naprawienia (jeśli to możliwe).

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ń

Bibliografia

• Cockburn, A. (2004). "Crystal clear: A human-powered methodology for small teams: A human-powered methodology for small teams. Pearson Education."
• Mangudo, P., Arroqui, M., Marcos, C., & Machado, C. F. (2012)."Rescue of a whole-farm system: crystal clear in action. International Journal of Agile and Extreme Software Development", 1(1), 6-22.
• Kaczor, K. (2014). "SCRUM i nie tylko. Teoria i praktyka w metodach Agile", PWN, Warszawa