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.

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ń