Metodyka Crystal: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
Nie podano opisu zmian
Nie podano opisu zmian
Linia 1: Linia 1:
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.
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.

Wersja z 23:26, 15 kwi 2021

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.