Jakość w zwinnych metodykach zarządzania projektami

Oczekiwania w zakresie przyspieszenia oraz uelastycznienia metod prowadzenia projektów doprowadziły do opracowania metodyk zwinnych. Główną ich zaletą jest możliwość szybszego dostarczenia produktu w wersji nieposiadającej wszystkich funkcji, a także modyfikacji planu projektu, jak i samego produktu w trakcie realizacji.

Metodyki te znalazły swoje zastosowanie głównie w projektach informatycznych, jakkolwiek możliwe jest ich zmodyfikowanie dla potrzeb innych dziedzin projektowania. Do najbardziej rozpowszechnionych metodyk tego typu można zaliczyć: Scrum, Extreme Programming oraz Lean Software Development.

Za moment powstania Agile Software Development uznaje się publikację The Agile Manifesto w 2001 r., który określił 12 zasad zwinnego projektowania. Należy podkreślić, że metodyki takie jak: Scrum, Extreme Programming, Crystal Clear czy Feature Driven Development zostały opracowane kilka lat wcześniej. Jednak publikacja manifestu pozwoliła na określenie dla nich wspólnego mianownika. Dlatego przyjęto je nazywać zwinnymi (ang. agile) metodykami. Pośród zasad prezentowanych w manifeście zwraca uwagę nacisk na: orientację na klienta, bliską współpracę i dobrą komunikację z nim, a także adaptację do jego zmieniających się wymagań [Principles… 2001]. Są to założenia dotyczące zarządzania jakością w projekcie. Jednocześnie należy podkreślić rozumienie jakości jako procesu dochodzenia do dobrego produktu, co jest zbieżne z koncepcją szkoły ciągłego doskonalenia reprezentowanej m.in. przez podejście japońskie [L. Wasilewski 1998, s. 2, D. Kroslid 1999].

Scrum

W metodyce Scrum cele projektu są realizowane w ramach przebiegów (ang. sprint), które prowadzą do opracowania działającej wersji produktu. Za każdym przebiegiem do produktu dodawane są nowe funkcje. Przed rozpoczęciem przebiegu określany jest rejestr wymagań. Następnie w ramach sprintu są one realizowane równolegle z przygotowaniem testów sprawdzających ich wypełnienie oraz kompatybilność z rezultatami wcześniejszych iteracji. Kontrola jakości nie opiera się zatem na dokumentacji produktu, lecz na wymaganiach klienta. Wymaga to świadomości wymagań zarówno wśród członków zespołu odpowiedzialnych za opracowanie produktu, jak i za jego kontrolę, a także intensywnej komunikacji. Służą temu codzienne spotkania zespołu [K. Schwaber, J. Sutherland 2013]. Schemat działania w metodyce Scrum prezentuje rys. 1.

Działania na rzecz jakości są zatem zintegrowane z metodyką i nie ma możliwości wskazania oddzielnych procesów. Podczas planowania przebiegu określane są wymagania dotyczące jakości. Codzienne spotkania pozwalają zidentyfikować błędy, niezgodności i wyeliminować marnotrawstwo. Przeglądy przebiegów dostarczają informacji o stopniu spełnienia wymagań. Natomiast podsumowania służą identyfikacji metod dalszego usprawnienia procesu projektowania.

Współcześnie metodyka Scrum uzupełniana jest o elementy systemu Kanban co pozwala na uelastycznienie sprintów. W miejsce stałego czasu trwania proponowane jest zwalnianie zasobów po wykonaniu zadania. Wolni pracownicy mogą natychmiast podjąć się rozwiązywania kolejnych problemów.

Extreme Programming

Metodyka Extreme Programming (XP) opiera się podobnie jak Scrum na idei iteracji. Podstawowymi etapami każdej iteracji są: programowanie, testowanie, pozyskiwanie ocen klienta oraz projektowanie rozwiązań.  Metodyka wprowadza jednak dodatkowe narzędzia wspierające osiąganie wysokiej jakości produktu. Należą do nich przede wszystkim [M.C. Paulk 2001]:

• programowanie parami – wspólne tworzenie kodu pozwala na natychmiastową weryfikację jego poprawności oraz wskazanie potencjalnie lepszych rozwiązań,
• programowanie bazujące na testach – opracowanie scenariuszy testów sprawdzających spełnienie wymagań poprzedza programowanie, co pozwala na szybsze eliminowanie zbędnego kodu,
• bliskość klienta – docelowy użytkownik tworzonego produktu powinien być dostępny na każdym etapie tworzenia oprogramowania, co przyczynia się do lepszego spełniania wymagań, ale jednocześnie jest uciążliwe dla klienta,
• ciągła integracja – poszczególne elementy produktu są integrowane wiele razy dziennie w celu wczesnego wykrycia niekompatybilności,
• refaktoryzacja – wprowadzanie zmian doskonalących w produkcie, które nie przekładają się na wprowadzanie nowych funkcji, ale pozwalają na uzyskanie większej spójności,
• dążenie do prostoty – proste rozwiązania są łatwe do monitorowania, a także charakteryzują się wyższą odpornością na błędy,
• równomierne tempo pracy – tydzień pracy nie powinien przekraczać 40 godzin, aby zapewnić pracownikom właściwy odpoczynek i zmniejszyć ryzyko popełniania błędów.

Extreme programming wymaga wysokich kompetencji i zaangażowania zespołu oraz jego niezmienności przez cały okres projektu. Silne zaangażowanie klienta ułatwia pracę programistów, ale jednocześnie jest znaczącym obciążeniem czasowym dla zamawiającego. Dlatego metodyka ta najlepiej sprawdza się w sytuacji, gdy zamawiający i zespół projektowy są członkami tej samej organizacji (np. start-up).

Lean Software Development

Metodyka Lean Software Development (LSD) powstała z połączenia koncepcji zwinnego zarządzania projektami z odchudzonym zarządzaniem. Zaadaptowała ona koncepcję minimalizacji strat, do których w przypadku realizacji projektów zalicza się:

• częściowo wykonaną pracę,
• dodatkowe procesy,
• dodatkowe funkcje,
• przełączanie pomiędzy zadaniami,
• oczekiwanie,
• zbędny ruch,
• braki.

Ponadto do zasad LSD zaliczyć należy  [S. Wawak 2016]:

• intensyfikację uczenia się – komunikowanie, informacyjne sprzężenia zwrotne, synchronizację pracy,
• opóźnianie ostatecznych decyzji – pozostawianie opcji decyzyjnych tak długo jak to możliwe ze względu na cele projektu,
• szybkie dostarczanie produktu – stosowanie systemu pull poprzez określenie zadań i terminów, ale pozostawienie wykonawcom sposobów ich realizacji,
• uprawomocnienie zespołu – budowę przywództwa, motywację, tworzenie standardów opartych na wiedzy eksperckiej pracowników,
• integralność produktu – orientację na wartości ważne dla klienta, kompatybilność, doskonalenie produktu i testy,
• podejście systemowe – monitorowanie realizacji całego projektu oraz funkcjonowania poszczególnych procesów w celu dalszej optymalizacji.

Dla każdej z tych zasad określono narzędzia. Inaczej niż wcześniej omawiane metodyki, LSD nie jest zorientowane na produkt, lecz na proces. Kluczowe jest tu opanowanie procesu w sposób, który każdorazowo doprowadzi do uzyskania dobrego produktu. Metodykę tę charakteryzuje zatem w pełni zintegrowane podejście ciągłego doskonalenia wszystkich aspektów wykonywanej pracy. Omawiana metodyka ma potencjalnie najszersze zastosowanie poza sferą programowania.

Tekst jest fragmentem rozdziału Zarządzanie jakością w metodykach zarządzanai projektami, opublikowanego w: Jakość w społeczeństwie sieciowym, pod red. E. Skrzypek, UMCS, Lublin 2016, s. 145-154, ISBN 978-83-62785-16-2

Bibliografia

• Kroslid D., Searching for Total Quality Management – Rethinking and Reinterpreting, Linköping Institute of Technology, Linköping 1999
• Principles behind the Agile Manifesto, www.agilemanifesto.org/principles.html, 2001
• Schwaber K., Sutherland J., The Scrum Guide, Scrum.Org, 2013
• Wasilewski L., W pułapkach definicji, „Problemy Jakości” 1998, nr 1
• Wawak S., Lean Software Development, Ceopedia.org, 2016, https://ceopedia.org/index.php/ Lean_software_development
• Wawak S., Zarządzanie jakością w metodykach zarządzanai projektami, [w:] Jakość w społeczeństwie sieciowym, pod red. E. Skrzypek, UMCS, Lublin 2016, s. 145-154, ISBN 978-83-62785-16-2

Zdjęcie: Vegansoldier, Flickr.com, CC