Zwinny zespół projektowy

Zwinny zespół projektowy

Wprowadzenie

 

W literaturze dominują dwa nurty zarządzania projektami. Pierwszy sposób – tradycyjny – opiera się na liniowym podejściu do zarządzania. Kierunek ten jest dobrze opisany w publikacjach, posiada dobre praktyki oraz jest w pełni przewidywalny, jeśli chodzi o liczbę i jakość realizowanych przedsięwzięć. Przedsiębiorstwa stosują wtedy proces o strukturze kaskadowej, w którym każda faza łączy się z następną w ramach prostej sekwencji działań: opracowanie koncepcji i specyfikacji produktu, projektowanie, testowanie oraz wdrożenie. Nie jest to sposób, który zwiększa innowacyjność zespołów projektowych. Drugi kierunek, pochodzi z branży IT i polega na tzw. zwinnym projektowaniu, który nie jest jeszcze do końca ukształtowany, ogranicza się do podstawowych wskazań, dotyczących zbioru zasad i reguł. Szczególnie sprawdza się on w procesie zarządzania innowacją. Metodyki zwinne dotyczą nie tylko projektowania nowych produktów lub usług, ale także sposobów zarządzania zespołami, odpowiedzialnymi za tworzenie i upowszechnianie innowacji.

 

Agile wywodzi się z „Manifestu zwinności” (Agile Manifesto, 2001) – jest to deklaracja wytwarzania oprogramowania IT. Przedstawia ona wartości, które zostały określone przez jej autorów jako najważniejsze przy rozwoju i tworzeniu projektów informatycznych. Pod Manifestem, który był odpowiedzią na niską efektywność klasycznego podejścia, podpisało się 17 osób. Zgodnie z tą metodą, zespoły projektowe (dostawcy) dostarczają co kilka tygodni (4-6 tyg.) aktualną wersję produktu lub usługi, co pozwala reagować na opinie odbiorców oraz na ewentualne zmiany w ofercie konkurentów.

 

Zwinny zespół projektowy - zasady i wartości

 

Nie ma jednego przepisu, aby otrzymać produkt lub usługę innowacyjną. Zespoły, które stosują podejście zwinne zdają sobie z tego sprawę. Dlatego posługują się zasadami, które pomagają im dokonywać właściwych wyborów i unikać problemów (Stellman, Green, 2015, s. 58-85):

 

Zasada nr 1. Zwinny zespół projektowy jest klientocentryczny. Z tego powodu metodyki zwinne zwykle są oparte na iteracjach. Zespoły stosujące to podejście w ramach planowania iteracji wybierają wymagania, które zapewnią im największą wartość. Jedyny sposób na ustalenie tych funkcji polega na współpracy z klientem i uwzględnianiu informacji zwrotnych uzyskanych w poprzednich „przyrostach”.

 

Zasada nr 2. Zespół jest otwarty na zmiany. Nikt w zespole nie robi problemów, gdy potrzebna jest zmiana. Każdy członek zespołu jest odpowiedzialny za wprowadzanie modyfikacji. Ponadto zespół nie odwleka zmian, nie są one traktowane jako błędy.

 

Zasada nr 3. Zwinny zespół projektowy dostarcza funkcjonujące produkty lub usługi. Łatwiej jest to robić, gdy zespół pracuje w ramach krótkich iteracji prowadzących do dostarczenia działającej innowacji. W ten sposób każdy członek zespołu ma konkretne cele i dużo lepiej wie, co ma robić. Ponadto każda osoba ma poczucie, że odpowiada nie tylko za własne zadania, ale też za to, co cały zespół dostarczy na koniec „przyrostu”.

 

Zasada nr 4. Zespół komunikuje się. Bezpośrednia rozmowa to lepsze od dokumentacji narzędzie wymiany informacji w zespole projektowym. Każdy wie, że osobiste omówienie problemu to najskuteczniejszy sposób na zrozumienie nowego zagadnienia. To dlatego w podejściu zwinnym tak ważna jest komunikacja między poszczególnymi osobami.

 

Zasada nr 5. Zwinny zespół projektowy zespół projektowy współpracuje z pracownikami biznesowymi. Zespół dążą do jak najczęstszych kontaktów z pracownikami biznesowymi. Projektanci poznają problemy biznesowe, które mają zostać rozwiązane. Robią to przez rozmowy z użytkownikami, towarzyszenie im przy pracy i obserwowanie efektów.

 

Zasada nr 6. Zwinny zespół projektowy jest zmotywowany do pracy w projekcie. Projekty innowacyjne przebiegają najlepiej, gdy wszyscy w firmie uważają, że zespół rozwija wartościowe produkty lub usługi, a także gdy wszystkie osoby (włącznie z właścicielem produktu) rozumieją, co sprawia, że oprogramowanie jest cenne dla organizacji.

 

Zasada nr 7. Zespół osiąga postępy. Dobry zespół pracuje tak, aby każdy (członkowie zespołu, menedżerowie, interesariusze i klienci) zawsze dobrze znał aktualny stan projektu.

 

Zasada nr 8. Zwinny zespół projektowydba o utrzymanie właściwego tempa projektu. W praktyce zespoły, w których liczba nadgodzin jest skrajnie duża, w dłuższym okresie robią mniej niż grupy pracujące w normalnych godzinach, a ponadto zwykle tworzą rozwiązania niższej jakości. To dlatego w zespołach stosujących podejście zwinne liczy się możliwe do utrzymania tempo pracy.

 

Zasada nr 9. Zwinny zespół projektowy troszczy się o projekt. W dłuższej perspektywie znacznie szybsze jest unikanie usterek niż naprawianie ich później. Jedną z najbardziej podstawowych zasad projektowych – i to nie tylko w dziedzinie oprogramowania, ale w całej inżynierii – jest reguła KISS (ang. keep it simple, stupid). Zespoły zwinne stosują się do niej w obszarze planowania projektu, budowania oprogramowania i funkcjonowania grupy.

 

Zasada nr 10. Zespół tworzy proste rozwiązania. Najskuteczniejszym sposobem na uzyskanie tego efektu jest współpraca z klientami i interesariuszami oraz budowanie tylko najbardziej przydatnego i wartościowego produktu lub usługi. Jeśli dana funkcja nie jest wartościowa dla firmy w dłuższej perspektywie często taniej jest w ogóle jej nie rozwijać.

 

Zasada nr 11. Zespół samoorganizuje się. Zespół samoorganizujący się nie stosuje wydzielonego etapu tworzenia wymagań lub projektu. Cały taki zespół współpracuje przy planowaniu projektu (zamiast polegać na jednej osobie, która jest właścicielem planu) i modyfikowaniu planów. Zespół działający w ten sposób zwykle rozbija projekt na historie użytkowników i inne niewielkie porcje oraz zaczyna pracę od tych zagadnień, które zapewniają firmie największą wartość. Dopiero potem zaczyna zastanawiać się nad szczegółowymi wymaganiami, projektem i architekturą.

 

Zasada nr 12. Zwinny zespół projektowy zwiększa efektywność. Zespół nie jest zwinny, jeśli nie dba o stałe usprawnianie procesów tworzenia (rozwijania) nowego produktu lub usługi. Zespoły zwinne badają sytuację i adaptują się do niej. Analizują przebieg wcześniejszych projektów i wykorzystują zdobytą wiedzę do późniejszego wprowadzania usprawnień. Robią to nie tylko po zakończeniu projektu. Każdego dnia w trakcie spotkań szukają możliwych modyfikacji i jeśli jest to uzasadnione, wprowadzają zmiany. Jest to ważne zwłaszcza w zespołach, które dopiero uczą się podejścia zwinnego. Jedyny sposób na poprawę funkcjonowania zespołu to ciągłe analizowanie dotychczasowych dokonań, aby ocenić jakość współpracy i opracować plan poprawy

 

Poziomy kierowania w Agile

 

Podejście zwinne jest różne od innych metodyk, ponieważ punktem wyjścia są tu wartości i zasady. Zespół korzystający z tego podejścia musi uczciwie przyjrzeć się nie tylko sposobom projektowania, ale też interakcjom między jego członkami i z innymi osobami z firmy. Zespół zwinny dzięki temu, że najpierw poznaje zasady, a dopiero potem stosuje metodykę (wiedząc, że będzie to wymagać dużo pracy, analiz i poprawek) może realistycznie liczyć na znalezienie lepszych sposobów prowadzenia projektów. Zapewnia to drogę do większej zwinności oraz pozwala rozwijać
i dostarczać lepsze produkty i usługi.

 

Hierarchia w Agile może powstawać na wiele sposobów. Zespół zwinny (Zespół Deweloperski) powinien umieć funkcjonować w ramach dowolnej struktury. Jednak zespoły zwinne zwykle lepiej radzą sobie z samodzielnym rozwiązywaniem konfliktów, ponieważ koncentrują się na wzajemnej komunikacji i zależy im na tych samych celach w większym stopniu niż w przypadku innych zespołów. Na pytanie o to, kto decyduje, które funkcje znajdą się w projekcie i jak zostaną zbudowane, to zazwyczaj odpowiadają osoby odgrywające określone role w zespole zwinnym. W zespole stosującym podejście Scrum to właściciel produktu ustala, które funkcje należy dodać. Zespół powinien przy tym zaakceptować tylko te funkcje, które można wykonać w ramach danej iteracji. Plan należy jednak do wszystkich, ponieważ tak działają zespoły samoorganizujące się. Ale samo to, że właścicielem planu jest cały zespół, nie oznacza jeszcze, że nikt nie jest szefem. Oczywiście, że jest przełożony. Różnica polega na tym, że szef na tyle wierzy w podejście zwinne, że pozwala zespołowi podejmować decyzje związane z projektem i je popiera – nie podważa ich ani nie kontroluje grupy na nadmiernie szczegółowym poziomie. Jest to jedyne nastawienie sprawdzające się w praktyce.

 

Zwinny zespół projektowy – przykład

 

Scrum Master – jego zadania polegają na pomocy zespołowi w planowaniu i likwidowaniu przeszkód w projekcie.

Product Owner – poznaje potrzeby firmy i przekazuje je zespołowi. W tej sytuacji zarządza rejestrem zadań, decyduje, które funkcje należy dodać
w poszczególnych iteracjach, a także odpowiada na szczegółowe pytania zespołu, tak żeby zachować właściwy kierunek prac i zbudować odpowiednie oprogramowanie.

Zespół deweloperski – to specjaliści, którzy odpowiadają za rozwój poszczególnych elementów (części) projektu.

Kierownik projektu – prawdopodobnie nie znajdzie się w zespole zwinnym. Zamiast tego, wyznaczona osoba będzie promotorem podejścia zwinnego, zachęcającym zespół oraz menedżerów do stosowania praktyk zwinnych i przestrzegania wartości związanych z tym podejściem.

 

Korzyści i wyzwania Agile

 

Impulsem do stosowania metodyk zwinnych może być zarówno potrzeba rozwiązania problemów, jak również dostrzeganie korzyści tworzących
lub rozwijających potencjał organizacji. To istotny element w zrozumieniu uwarunkowań zastosowania metodyk zwinnych w szczególności przy prawidłowości oceny funkcjonowania przyjętych założeń. Wśród kluczowych korzyści wspomnieć należy możliwość skutecznego zarządzania w otoczeniu zmiennych priorytetów (88%), zwiększenie produktywności zespołów (83%) oraz przejrzystość projektów pod kątem zasobów, zakresu, czasu, kosztów, ryzyka i wpływu poszczególnych czynników na projekt (83%) (Wirkus, Zejer, 2017, s. 562-582).

 

W obszarze kluczowych wyzwań wymienić należy kulturę organizacyjną, brak doświadczeń z praktykami stosowanymi w metodykach zwinnych
i w dalszych etapach naginanie ich do własnych potrzeb, opór organizacji i osób zarządzających przed zmianami oraz brak ich wsparcia dla całego procesu. W literaturze wyrażany jest pogląd, że sposób myślenia jest ważniejszy, niż sama metodyka. Znajduje on potwierdzenie
u twórców Scruma. Jako wyzwania należy również wskazać takie czynniki, jak ugruntowana pozycja metodyk tradycyjnych w organizacji oraz trudności z doborem praktyk do obszarów, rozmiarów projektów i organizacji oraz reorganizacja ról i zespołów (Wirkus, Zejer, 2017, s. 562-582).

 

Bibliografia

 

Appelo, J., (2016). Zarządzanie 3.0. Kierowanie zespołami z wykorzystaniem metodyk Agile. Gliwice: Wyd. Helion. ISBN: 978-83-283-1801-4.

Cockburna, A., (2006). Agile Software Development: The Cooperative Game. 2nd Edition. Wyd. Addison-Wesley.

Ćwiklicki, M., Jabłoński, M., Włodarek, T., (2010), Samoorganizacja w zarządzaniu projektami metodą SCRUM. Kraków: Wyd. Mfiles.pl.

Kelley, T., Littman, J., (2009). Sztuka innowacji. Warszawa: Wyd. MT Biznes Sp. z o.o. ISBN: 978-83-61040.

Manifesto for Agile Software Development. (2001). Dostęp: 28.01.2019. https://agilemanifesto.org/iso/pl/manifesto.html

MARUTA, Kancelaria Radców Prawnych., (2017). Dobre praktyki w zakresie stosowania metodyk agile w projektach informatycznych (z przykładami klauzul).Dostęp: 28.01.2019. https://www.gov.pl/web/cyfryzacja/metodyki-agile-w-projektach-informatycznych

Rubin, S. K., (2014), SCRUM. Praktyczny przewodnik po najpopularniejszej metodyce Agile. Gliwice: Wyd. Helion. ISBN: 978-83-246-8073-3.

Schweber, K, Sutherland, J., (2017). Przewodnik po Scrumie: Reguły gry.ScrumGuides.org. Dostęp: 29.01.2019. https://www.Scrumguides.org/download.html

Stellman, A., Green J., (2015). Agile. Przewodnik po zwinnych metodykach programowania. Poznaj nowoczesne podejście do wytwarzania oprogramowania. Gliwice: Wyd. Helion. ISBN: 978-83-283-0940-1.

Wirkus, M., Zejer, P., (2017). Uwarunkowania zastosowania metodyk zwinnych w przedsiębiorstwie. Zeszyty Naukowe Politechniki Śląskiej, Seria: Organizacja i Zarządzanie z. 114.

Szkolenia Design Thinking dla firm

HOME

Doradztwo i szkolenia - yellowinn.pl

REGON: 122847555

e-mail: kontakt@yellowinn.pl

tel.: 735-602-780

 

Copyright 2019 yellowinn.pl | Yn wykorzystuje do analizy danych Google Analytics

Projekt strony przygotowano według metodyki IBM Design Thinking

Szkolenia Design Thinking dla firm
Design Thinking in Poland at Linkedin
Szkolenia zamknięte Design Thinking dla firm