Metodyka Crystal

Z Encyklopedia Zarządzania

Metodyka Crystal, której twórcą jest Alistar Cockburn jest jedną z metodyk zaliczanych do [[adaptacyjne zarządzanie projektami [adaptacyjnego 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. (N. Abbas, A. M. Gravell, G. B. Wills, 2008, s. 7)

Priorytety 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

Jak podaje J. Wośko "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." (J. Wośko 2016, str.103)

Poziomy 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 (D. Cohen, s. 16)

W związku z powyższym wyróżnia się 7 poziomów, poniżej przedstawiono ich charakterystyki (A. Cockburn 2006, str. 167- 173):

Crystal Clear:

  • Małe zespoły, od 1 do 6 uczestników projektu,
  • Najlepiej sprawdza się w małych projektach,
  • Jest zorientowany na ludzi i nie koncentruje się na procesach,
  • 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,
  • Przeznaczony do projektów średniej wielkości,
  • Czas trwania projektu to około 1 do 2 lat,
  • 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

  • Bardzo duże zespoły, ponad 200 osób biorących udział w tworzeniu projektu,
  • Najwyższy stopień zaawansowania w realizacji projektu.

Podział rodziny Crystal został przedstawiony w poniższej tabeli (K. Kaczor 2014, s. 89):

Czynnik Crystal Clear Crystal Yellow Crystal Orange Crystal Red Crystal Maroon Crystal Diamond & Sapphire
(L) L6 L20 L40 L80 L200 L>200
(E) E6 E20 E40 E80 E200 E>200
(D) D6 D20 D40 D80 D200 D>200
(C) C6 C20 C40 C80 C200 C>200

Oprócz czynnika poziomego, który odnosi się do liczby osób zaangażowanych w projekt, wyróżnia się czynniki pionowe składające się na „krytyczność”, czyli poziom potencjalnych szkód, jakie system może spowodować, jeśli nie będzie działał zgodnie z projektem. Czynnikami pionowymi na powyższej tabeli są (H. Altarawneh, S. Alamaro, A. El Sheikh 2012, str. 325):

  • L - Życie (ang. Life Critical),
  • E - Znaczne pieniądze (ang. Essential Money),
  • D - Uznaniowe pieniądze (ang. Discretionary Money),
  • C - Komfort (ang. Comfort).

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 i wady metodyki Crystal

Do zalet można zaliczyć (F. Anwer, S. Aftab, U. Waheed, S. S. Muhammad 2017, str. 7):

  • 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.

Wadami tej metodyki są:

  • 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

Źródło: „https://mfiles.pl/pl/index.php?title=Metodyka_Crystal&oldid=119727”