Metodyka Crystal: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
Nie podano opisu zmian |
mNie podano opisu zmian |
||
| (Nie pokazano 65 wersji utworzonych przez 3 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''Metodyka Crystal''', której twórcą jest Alistar Cockburn jest jedną z metodyk zaliczanych do | '''Metodyka Crystal''', której twórcą jest Alistar Cockburn jest jedną z [[metodyka|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 poziomy metodyki Crystal jest liczba osób, które są zaangażowane w realizację [[projekt|projektu]]. | ||
== | ==TL;DR== | ||
Metodyka Crystal to adaptacyjne zarządzanie projektami w obszarze tworzenia oprogramowania. Ma siedem poziomów złożoności, zależnych od liczby osób zaangażowanych w projekt. Jej priorytety to bezpieczeństwo projektu, efektywność rozwoju i akceptacja przez zespół narzuconych reguł. Metodyka opiera się na 7 zasadach, takich jak częste dostarczanie użytecznego kodu i osobiste bezpieczeństwo. Wyróżnia się 7 poziomów metodyki Crystal, od małych zespołów do bardzo dużych. W metodyce występują różne role, takie jak Executive Sponsor, Ambassador User czy Lead Designer. Zaletami metodyki są częste dostawy, bliska komunikacja i adaptacyjność, ale ma także wady, takie jak niejasne zasady w zależności od wielkości projektu czy trudności w przypadku zespołów rozproszonych. | |||
== | ==Rys historyczny== | ||
Rodzina Crystal dąży do osiągnięcia trzech priorytetów. Są nimi (K. Kaczor 2014 s. 90): | W 1991 roku Alistair Cockburn pracował w IBM i otrzymał zadanie opracowania najbardziej efektywnej [[metodyka|metodyki]] tworzenia oprogramowania. W związku z tym musiał przeprowadzić [[wywiad|wywiady]] i przestudiować wiele [[zespół projektowy|zespołów projektowych]]. Cockburn podkreślił znaczenie [[komunikacja|komunikacji]] i rozmowy: "Skoncentrowanie się na umiejętnościach, [[komunikacja|komunikacji]] i społeczności pozwala zwiększyć [[efektywność]] projektu i jego adaptację do zmian bardziej niż skupianie się na [[proces|procesach]] i [[plan|planach]]" (Highsmith 2002, s. 261). Odkrył również, że należy wybrać i dostosować [[strategia|strategię]] do grupy uczestników projektu i zadań przez nich wykonywanych (N. Abbas, A. M. Gravell, G. B. Wills, 2008, s. 7). | ||
*'''Bezpieczeństwo projektu''' (ang. | |||
*'''Efektywność rozwoju''' (ang. | ==Priorytety metodyki Crystal== | ||
*'''Przyjęcie przez zespół narzuconych reguł''' (ang. | Rodzina Crystal dąży do osiągnięcia trzech [[priorytet|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 [[priorytet|priorytety]] i ograniczone [[zasób|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 [[metoda|techniki]] jako niedogodności wydłużające pracę i stanowiące obciążenie. | |||
<google>n</google> | |||
==7 zasad metodyki Crystal== | ==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): | A. Cockburn wymienił zasady realizacji projektów realizowanych zgodnie z metodyką Crystal - pierwsze trzy są wymagane, a kolejne cztery przenoszą [[zespół projektowy]] 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. | '''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. | '''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 [[produkt|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. | '''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 | '''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 [[kierownik|przełożonych]]. Mając swobodę mówienia, zespół może odkryć i naprawić swoje słabości. Otwarta [[komunikacja|komunikacja]] oznacza też [[zaufanie]], ponieważ zgadzamy się na to, iż każdy może zaprezentować swoje zdanie na forum [[zespół projektowy|zespołu projektowego]]. | ||
''' | '''Skupienie ''' (ang. Focus) - kierownictwo i liderzy muszą ustalić [[priorytet|priorytety]] projektu, [[Wymagania i cele projektu|wymagania]], [[cel|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 [[informacja zwrotna|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 [[środowisko realizacji projektu|ś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 [[autonomia|autonomię]] zespołu i na te właśnie aspekty kładzie silny nacisk". (J. Wośko 2016, s. 103) | |||
Wszystkie | |||
==Poziomy metodyki Crystal== | |||
Wszystkie podejścia w ramach rodziny metodologii Crystal koncentrują się na ludziach i [[komunikacja|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 [[priorytet|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 (A. Cockburn 2006, s. 167-173): | |||
'''Crystal Clear:''' | '''Crystal Clear:''' | ||
*Małe zespoły, 1 | * Małe zespoły, od 1 do 6 uczestników projektu, | ||
*Najlepiej sprawdza się w małych projektach | * Najlepiej sprawdza się w małych projektach, | ||
*Jest zorientowany na ludzi i nie koncentruje się na procesach | * Jest zorientowany na ludzi i nie koncentruje się na procesach, | ||
* Jest skoncentrowany na bezpieczeństwie projektu. | |||
*Jest skoncentrowany na bezpieczeństwie projektu | |||
'''Crystal Yellow:''' | '''Crystal Yellow:''' | ||
*Małe i średnie zespoły o liczności od 7 do 20 uczestników, | * 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, | * 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 | * 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, | * 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. | * 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:''' | '''Crystal Orange:''' | ||
*Średnie zespoły o liczności od 21 do 40 uczestników, | * Ś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, | ||
* Czas trwania projektu to około 1 do 2 lat, | |||
*Używany w projektach, które mają stale rozwijającą się bazę kodu, | * 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 | * Wymagane jest, aby każda kolejna wersja była wydawana średnio co 3-4 miesiące. | ||
'''Crystal Red:''' | '''Crystal Red:''' | ||
*Średnie i duże zespoły składające się od 40 do 80 osób, | * Ś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) | * Zespoły są dzielone zgodnie z wymaganiami pracy (według umiejętności), | ||
*Występuje tradycyjny model tworzenia oprogramowania | * Występuje tradycyjny model tworzenia oprogramowania. | ||
'''Crystal Maroon:''' | '''Crystal Maroon:''' | ||
*Duże zespoły składające się od 80 do 200 osób, | * Duże zespoły składające się od 80 do 200 osób, | ||
*Średni czas trwania projektu ponad 2 lata | * Średni czas trwania projektu ponad 2 lata. | ||
'''Crystal Diamond & Sapphire''' | '''Crystal Diamond & Sapphire''' | ||
* Bardzo duże zespoły, ponad 200 osób biorących udział w tworzeniu projektu, | |||
Podział został przedstawiony w poniższej tabeli: | * Najwyższy stopień zaawansowania w realizacji projektu. | ||
Podział rodziny Crystal został przedstawiony w poniższej tabeli (K. Kaczor 2014, s. 89): | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! Czynnik !! Crystal Clear !! Crystal Yellow !! Crystal Orange !! Crystal Red !! Crystal Maroon !! Crystal Diamond & Sapphire | ! 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 | 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ą: | Czynnikami pionowymi na powyższej tabeli są (H. Altarawneh, S. Alamaro, A. El Sheikh 2012, s. 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 [[zasób|zasobami]], definiuje cały projekt oraz pomaga zespołowi w podejmowaniu kluczowych [[decyzja|decyzji]] biznesowych. | |||
* ''Ambassador User'' - Użytkownik, który [[testowanie w projekcie|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 [[projektowanie|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 [[projektowanie|projektowaniu]] i [[programowanie|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 [[konflikt|konflikty]]. | |||
* ''Business Expert'' - Osoba posiadająca wiedzę w zakresie tego jak działa firma, jaką ma [[strategia|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, s. 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ć [[proces|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ń. | |||
== | {{infobox5|list1={{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Metodyka Extreme Programming]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[Metodyka MSF]]}} — {{i5link|a=[[Kanban (agile)]]}} — {{i5link|a=[[Kształtowanie zespołu]]}} — {{i5link|a=[[Nexus]]}} — {{i5link|a=[[Tradycyjne zarządzanie projektem]]}} — {{i5link|a=[[Facylitacja]]}} }} | ||
==Bibliografia== | ==Bibliografia== | ||
* | <noautolinks> | ||
*Mangudo | * Abbas N., Gravell A., Wills G. (2008), ''Historical Roots of Agile Methods: Where did: Agile Thinking Come from?'', School of Electronics and Computer Science, University of Southampton | ||
* | * Alzoabi Z. (2012), ''Agile software: Body of knowledge. In Business Intelligence and Agile Methodologies for Knowledge-Based Organizations: Cross-Disciplinary Applications'', IGI Global | ||
* Anwer F., Aftab S., Waheed U., Muhammad S. (2017), ''[https://www.ijmse.org/Volume8/Issue2/paper1.pdf Agile Software Development Models TDD, FDD, DSDM, and Crystal Methods: A Survey]'', International Journal Of Multidisciplinary Sciences and Engineering, vol . 8, nr. 2, Virtual University of Pakistan | |||
* Cockburn A. (2004), ''Crystal clear: A human-powered methodology for small teams'', Addison-Wesley Professional | |||
* Cockburn A. (2006), ''Agile software development: the cooperative game'', Highsmith Series | |||
* Hanser E. (2010), ''Agile Prozesse: Von XP über Scrum bis MAP'', Springer-Verlag. Lorrach | |||
* Highsmith J. (2002), ''Agile software development ecosystems'', Addison-Wesley Professional, London | |||
* Kaczor K. (2018), ''Scrum i nie tylko. Teoria i praktyka w metodach Agile'', Wydawnictwo naukowe PWN, Warszawa | |||
* Mangudo P., Arroqui M., Marcos C., Machado C. (2012), ''Rescue of a whole-farm system: crystal clear in action'', International Journal of Agile and Extreme Software Development, 1(1) | |||
* Wośko J. (2016), ''[https://pjmbook.files.wordpress.com/2016/10/zarzc485dzanie-projektami-v1-0.pdf Zarządzanie projektami, Podręcznik]'', WSB | |||
</noautolinks> | |||
{{a|Michał Wajda}} | |||
[[Kategoria:Metodyki zarządzania projektami]] | |||
{{#metamaster:description|Metodyka Crystal to adaptacyjne zarządzanie projektami w tworzeniu oprogramowania. Poznaj tę skuteczną metodykę.}} | |||
Aktualna wersja na dzień 09:45, 19 sty 2024
Metodyka Crystal, której twórcą jest Alistar Cockburn jest jedną z metodyk zaliczanych do 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 poziomy metodyki Crystal jest liczba osób, które są zaangażowane w realizację projektu.
TL;DR
Metodyka Crystal to adaptacyjne zarządzanie projektami w obszarze tworzenia oprogramowania. Ma siedem poziomów złożoności, zależnych od liczby osób zaangażowanych w projekt. Jej priorytety to bezpieczeństwo projektu, efektywność rozwoju i akceptacja przez zespół narzuconych reguł. Metodyka opiera się na 7 zasadach, takich jak częste dostarczanie użytecznego kodu i osobiste bezpieczeństwo. Wyróżnia się 7 poziomów metodyki Crystal, od małych zespołów do bardzo dużych. W metodyce występują różne role, takie jak Executive Sponsor, Ambassador User czy Lead Designer. Zaletami metodyki są częste dostawy, bliska komunikacja i adaptacyjność, ale ma także wady, takie jak niejasne zasady w zależności od wielkości projektu czy trudności w przypadku zespołów rozproszonych.
Rys historyczny
W 1991 roku Alistair Cockburn pracował w IBM i otrzymał zadanie opracowania najbardziej efektywnej metodyki 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 zwiększyć efektywność projektu i jego adaptację do zmian bardziej niż skupianie się na procesach i planach" (Highsmith 2002, s. 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ół projektowy 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, s. 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.
W związku z powyższym wyróżnia się 7 poziomów, poniżej przedstawiono ich charakterystyki (A. Cockburn 2006, s. 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, s. 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, s. 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ń.
| Metodyka Crystal — artykuły polecane |
| Feature-Driven Development — Metodyka Extreme Programming — Backlog produktu — Metodyka MSF — Kanban (agile) — Kształtowanie zespołu — Nexus — Tradycyjne zarządzanie projektem — Facylitacja |
Bibliografia
- Abbas N., Gravell A., Wills G. (2008), Historical Roots of Agile Methods: Where did: Agile Thinking Come from?, School of Electronics and Computer Science, University of Southampton
- Alzoabi Z. (2012), Agile software: Body of knowledge. In Business Intelligence and Agile Methodologies for Knowledge-Based Organizations: Cross-Disciplinary Applications, IGI Global
- Anwer F., Aftab S., Waheed U., Muhammad S. (2017), Agile Software Development Models TDD, FDD, DSDM, and Crystal Methods: A Survey, International Journal Of Multidisciplinary Sciences and Engineering, vol . 8, nr. 2, Virtual University of Pakistan
- Cockburn A. (2004), Crystal clear: A human-powered methodology for small teams, Addison-Wesley Professional
- Cockburn A. (2006), Agile software development: the cooperative game, Highsmith Series
- Hanser E. (2010), Agile Prozesse: Von XP über Scrum bis MAP, Springer-Verlag. Lorrach
- Highsmith J. (2002), Agile software development ecosystems, Addison-Wesley Professional, London
- Kaczor K. (2018), Scrum i nie tylko. Teoria i praktyka w metodach Agile, Wydawnictwo naukowe PWN, Warszawa
- Mangudo P., Arroqui M., Marcos C., Machado C. (2012), Rescue of a whole-farm system: crystal clear in action, International Journal of Agile and Extreme Software Development, 1(1)
- Wośko J. (2016), Zarządzanie projektami, Podręcznik, WSB
Autor: Michał Wajda
