Crystal Light 1. Geneza metodyki

Crystal Light jest nie jedną, ale grupą metodyk zaproponowanych przez Alistaira Cockburna. Urodził się on w 1953 r., 22 lata później uzyskał magistra w zakresie nauk in-formatycznych na Uniwersytecie w Cleveland. W 2003 r. otrzymał tytuł doktora na Uni-wersytecie w Oslo. Swoją karierę w branży ICT rozpoczynał w drugiej połowie lat 80.

XX w. w koncernie IBM. Jest jednym z aktywnych członków ruchu zwinnego wytwarza-nia oprogramowawytwarza-nia oraz współautorem Manifestu zwinności, jak również PM Declara-tion of Independence.

Podobnie jak światło, przechodząc przez pryzmat, rozszczepia się na paletę kolorów, tak i rodzina Crystal Light składa się z całej gamy metodyk oznaczanych różnymi kolora-mi. Ich dostępność ma umożliwić zarządzającym dobór rozwiązania najlepiej oddającego specyfikę realizowanego projektu. Autor uzależnił powyższy wybór od czterech parame-trów opisujących potencjalne skutki porażki projektu lub budowanego systemu. Są to:

utrata komfortu (ang. comfort – C), strata bieżących środków pieniężnych (ang. discretiona-ry money – D), utrata aktywów (ang. essential moneys – E) oraz utrata życia (ang. life – L)¹²⁶. Stopień intensywności koloru odpowiada „ciężkości” metodyki. W palecie metodyk Crystal Light znaleźć można wersje metodyki takie jak: Clear, Yellow, Orange oraz Red¹²⁷. Ich liczba odpowiadała zamierzeniom zbudowania szerszego systemu, jednak w prak-tyce Cockburn przedstawił w szczegółach jedynie Crystal Clear, zaś Crystal Orange do-czekało się jedynie zgrubnego opisu. Informacje dotyczące pierwszej z nich autor zawarł w książce swojego autorstwa pt. Crystal Clear. A Human-Powered Methodology For Small Teams wydanej w 2004 r. przez wydawnictwo Addison-Wesley, zaś druga opisana została w jednym z rozdziałów jego książki pt. Surviving Object-Oriented Projects opublikowanej siedem lat wczesniej. Wśród innych źródeł wiedzy o metodyce warto wskazać stronę in-ternetową autora (http://alistair.cockburn.us/Crystal+light+methods).

126 A. Cockburn: Crystal Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley, London 2004, s. 240.

127 W niektórych źródłach spotkać można także warianty takie jak: Crystal Orange We, Crystal Maroon, Crystal Dia-mond, Crystal Sapphire, Crystal Blue, por. http://www.scrumstudy.com/blog/what-is-crystal/ (dostęp: 24.11.2021).

Rysunek 17. Dobór metodyk z rodziny CL względem typu projektu

L6 L20 L40 L80

E6 E20 E40 E80

D6 D20 D40 D80

C6 C20 C40 C80

Czysta Żółty Pomarańczowy Czerwony

Poziom krytyczności systemu

Rozmiar projektu

Źródło: A. Cockburn: Crystal Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley, London 2004, s. 240.

2.4.2.

Założenia metodyki

W intencji autora metodyka Crystal Clear (CC) jest metodyką lekką, opracowaną na potrzeby małych liczących od 6 do 8 osób, zlokalizowanych w jednym miejscu zespo-łów pracujących nad systemami, których ewentualne błędy nie zagrażają ludzkiemu życiu.

Zespołów, które „dokonują priorytetyzacji dla bezpieczeństwa dostarczenia satysfakcjo-nującego rezultatu, wydajności w budowaniu rozwiązania oraz dogodności konwencji pracy”¹²⁸. W przeciwieństwie do innych metodyk zwinnych (jak np. Extreme Program-ming) metodyka CC koncentruje się przede wszystkim na ludziach i zespole, a nie dyscy-plinie w praktykach i procesach realizacji projektu. Sam autor, podsumowując założenia swojej metody opisał ją słowami:

Projektant wiodący, wraz z dwoma – ośmioma programistami, w dużym pokoju lub w przylegających do siebie pokojach, stosując tablice, ekrany i arkusze papierów

mając łatwy dostęp do ekspertów, nie będąc narażonym na zakłócenia pracy,

regularnie, co miesiąc lub dwa (najpóźniej co kwartał)

dostarczają użytkownikom działający, przetestowany, użyteczny kod,

okresowo dokonując oceny i refleksji oraz modyfikując swoje praktyki pracy¹²⁹.

128 A. Cockburn, Crystal Clear…, s. 312.

129 Ibid.

Metodyka CC koncentruje się na elementach takich jak: stosowanie przyrostowych, iteracyjnych modeli cyklu życia, komunikacja i współpraca między członkami zespołu, swoboda w zakresie przyjmowanych przez zespół praktyk realizacji projektu. W przeci-wieństwie do metodyki XP, Crystal Clear sukces projektu opiera nie na przestrzeganiu praktyk, ale na maksymalizacji indywidualnego potencjału członków zespołu.

2.4.3.

Struktura metodyki

Podstawowe zalecenia metodyki Crystal Clear opierają się na opracowanej przez au-tora liście siedmiu wymaganych priorytetów. Pierwsze trzy mają charakter obligatoryjny, kolejne wspierają poziom bezpieczeństwa zespołu. Są to:

1) częste dostawy (ang. frequent delivery),

2) refleksyjne usprawnienia (ang. reflective improvement), 3) osmotyczna komunikacja (ang. osmotic communication), 4) bezpieczeństwo osobiste (ang. personal safety),

5) skupienie (ang. focus),

6) wczesny dostęp do ekspertów użytkownika,

7) środowisko techniczne z zautomatyzowanymi testami, zarządzaniem konfiguracją i częstą integracją.

Zespoły posługujące się metodyką CC mają swobodę określenia praktyk, którymi będą się posługiwać. CC nie wymaga stosowania żadnej techniki lub narzędzi, jednakże dla wsparcia zespołów rozpoczynających swoją pracę autor przytacza w podręczniku ze-staw pięciu strategii oraz dziewięciu technik. Mimo deklaracji nienarzucaniu ich stoso-wania, są one w praktyce ważnym elementem CC. Są to:¹³⁰

Strategie

1) Rozpoznanie 360 stopni – wraz z rozpoczęciem projektu zespół powinien komplek-sowo rozpoznać elementy takie jak: wartość biznesowa, wymagania, model dome-nowy, plany technologii, plan projektu, tworzenie zespołu, proces realizacji projektu.

2) Wczesne zwycięstwa – poszukiwanie możliwości szybkiego dostarczenia wartości użytkownikom, budujące siłę, pewność i poczucie wartości zespołu.

3) Chodzący szkielet (ang. walking skeleton) – małe wdrożenie systemu wykonujące niewielki, ale w całości opracowany zakres funkcji, obrazujące główne elementy ar-chitektury.

130 Ibid., s. 63–129.

4) Przyrostowa reakchitektura – modyfikowanie przez zespół infrastruktury lub archi-tektury systemu wraz z jego rozbudową o nowe funkcjonalności.

5) Tablice informacyjne – dobrze widoczne i czytelne plansze lub ekrany obrazujące postęp projektu i jego najważniejsze parametry; tablice informacyjne powinny być aktualne.

Techniki

1) Kształtowanie metodyki – gromadzenie informacji o wcześniejszych doświadcze-niach oraz kształtowanie procesu i praktyk realizacji projektu (wywiady i warsztat metodyczny).

2) Warsztaty refleksyjne – warsztat organizowany po każdej dostawie, wpierający prio-rytet „refleksyjne usprawnienia”; jego celem jest zidentyfikowanie przez zespół pro-blemów, jak również praktyk, które powinny zostać zachowane oraz wprowadzone jako nowe do pracy zespołu.

3) Błyskawiczne planowanie (ang. blitz planning) – technika dla stworzenia planu roz-woju projektu składająca się z dziesięciu kroków postępowania, tj.: zgromadzenia uczestników (sponsor, przedstawiciel użytkownika, programiści), burzy mózgów na temat zadań, strukturalizacji zadań, przeglądu zadań, szacowania zadań, ustalenia kolejności zadań, wskazania chodzącego szkieletu, identyfikacji kolejnych wydań, optymalizacji planu, dokumentacji planu.

4) Szacowanie delfickie z rankingami ekspertów – technika szacowania czasu i nakła-dów pracy zalecana podczas planowania projektu.

5) Codzienne spotkania „na stojąco” – krótkie spotkania robocze projektu.

6) Projektowanie kluczowych interakcji (ang. essential interaction design) – technika warsztatowa pozwalająca w szybki sposób odkryć wymagania poprzez identyfikację ról użytkowników, ich celów oraz wzajemnych interakcji zachodzących w systemie.

7) Miniatura procesu (ang. process miniature) – szybkie przeszkolenie pracowników w za-kresie procesów poprzez warsztaty mające na celu przyśpieszoną symulację procesu (prześledzenie przebiegu, uczestniczenie w nim, odegranie kroków postępowania).

8) Programowanie „ramię w ramię” – modyfikacja techniki programowania w parach, polegająca na pracy dwóch programistów obok siebie, przy osobnych stanowiskach, ale wspólnie doglądających swojej pracy.

9) Wykresy spalania – sposób ilustracji postępów projektu oraz tempa pracy; wykres, gdzie na osi odciętych mierzony jest czas iteracji, zaś na osi rzędnych – zakres prac do wykonania; informacje na wykresach mogą obrazować planowane postępy pracy oraz faktycznie osiągane, a także ułatwiają prognozowanie przy ekstrapolacji trendów historycznej wydajności zespołów.

Cykl życia projektu

Cykl życia projektu rekomendowany w CC opiera się de facto na kilku poziomach hierarchii. Pierwszy poziom to poziom projektu. Projekt rozpoczyna się od ustanowienia projektu (ang. charter), poprzez dwa lub więcej cykle wytwórcze, aż do jego zakończenia (ang. wrapup). Schematyczny układ cyklu życia projektu w CC przedstawiono na poniż-szym schemacie:

Rysunek 18. Schemat cyklu życia projektu w metodyce CC

Epizod Epizod Integracja

Epizod Dzień

Epizod Integracja Iteracja

Epizod Epizod Integracja

Epizod Epizod Integracja Iteracja

Dostawa Dostawa

… … … … … Projekt

Dzień Dzień

Dzień Dzień Dzień Dzień Dzień

Źródło: ibid.

Ustanawiając projekt należy zbudować zespół projektu, wykonać rozpoznanie 360 stopni, dopasować metodykę oraz opracować wstępny plan projektu.

W skład poszczególnych cykli wytwórczych wchodzą zadania takie jak: rekalibra-cja planu wydań, seria iteracji dostarczających działający i przetestowany kod, przekaza-nie rezultatu użytkownikom oraz podsumowaprzekaza-nie cyklu z refleksją odnośprzekaza-nie do efektów i sposobu pracy.

W ramach poszczególnych iteracji zespoły powinny wykonać przewidziane prace programistyczne wraz z integracją oraz podsumować iterację poprzez warsztat refleksyj-ny oraz celebrację.

Najniższym poziomem modelu są poszczególne tygodnie oraz dni robocze. W ciągu dnia członkowie zespołu spotykają się na „na stojąco”, by następnie przejść do pracy przy tzw. epizodach, czyli podstawowych jednostkach pracy programistycznej wg CC.

Role

Ostatnim elementem rekomendacji metodyki Crystal Clear są role przypisane po-szczególnym członkom zespołu. Alister Cockburn zdefiniował ich osiem. Są to:

1) sponsor wykonawczy (ang. executive sponsor) – odpowiedzialny za stronę biznesową przedsięwzięcia, zapewnienie zasobów do jego realizacji, podejmowanie strategicz-nych decyzji dotyczących relacji wymienstrategicz-nych miedzy parametrami projektu,

2) ambasador użytkownika (ang. ambassador user) – osoba reprezentująca grono inte-resariuszy po stronie klienta/użytkowników budowanego systemu; ma za zadanie przekazywać zespołowi informacje dotyczące ich wymagań, priorytetów, sposobu korzystania z systemu itp.; jest to osoba doskonale orientująca się w oczekiwaniach grupy użytkowników i występująca w ich imieniu,

3) projektant wiodący (ang. lead designer) – doświadczony ekspert od strony technicznej budowanego rozwiązania odgrywający kluczową rolę podczas określania metodyki pracy zespołu oraz projektowania i programowania rozwiązania,

4) projektant-programista (ang. designer-programmer) – członkowie zespołu zajmujący się projektowaniem i programowaniem budowanego rozwiązania,

5) ekspert biznesowy (ang. business expert) – osoba dysponująca wiedzą i doświadcze-niem odnośnie do sposobu funkcjonowania budowanego rozwiązania; wspierająca pozostałe role w zespole,

6) koordynator (ang. coordinator) – odpowiednik kierownika projektu, osoba dokumen-tująca plany projektu, rejestrująca jego postępy i koordynująca pracę; często wspie-rająca sponsora i wiodącego projektanta,

7) tester i pisarz (ang. writer) – często role rotacyjne i tymczasowe służące zapewnieniu adekwatnego poziomu testowania i dokumentowania budowanego systemu.

W dokumencie Zwinność : od zwinnych zespołów do zwinnego zarządzania (Stron 72-77)