Procesy, Manifest Agile, doskonalenie … Ale o co chodzi?

Procesy, Manifest Agile, doskonalenie … Ale o co chodzi?

W trakcie swojej drogi zawodowej zauważyłam, że pomimo, iż Agile jest powszechnie stosowany jako standard pracy w branży IT, nie do końca osoby, które powinny wiedzieć coś więcej o tej metodologii – faktycznie wiedzą. „Zwinne” realizowanie projektów informatycznych jest oczywiście jak najbardziej zalecane i nie zamierzam podważać zasadności Agile oraz pracy w zespołach scrum’owych, wręcz przeciwnie.

Jakie są korzenie Agile’a, dalej Scrum’a ? 

Czy Scrum Master ma świadomość, że zarządza procesem?

Jakiego znaczenia w związku z tym nabierają słowa z Manifestu Agile? Czy bezrefleksyjne, bezkrytyczne stosowanie manifestu faktycznie przysparza wartości i zawsze się sprawdza? Jaką role ma do odegrania kierownictwo?

Osobiście uważam, że każda metodologia jaką dany zespół czy organizacja zadecyduje stosować jako standard powinna pasować do jej własnych potrzeb tzn.: odpowiadać na potrzeby jej klientów oraz wspierać jej pracowników w dostarczaniu tych potrzeb. Skopiowana metoda i zestaw narzędzi w jednej organizacji sprawdzi się doskonale, w innej wylejemy „dziecko z kąpielą”. Dlaczego, ponieważ należy zaprojektować proces w którym chcemy wykorzystać dany zestaw narzędzi doskonalących, można powiedzieć skroić go na potrzeby tego zespołu, tej organizacji a nie wszystkich dookoła. Jest to określona praca do wykonania związana z poznaniem metodologii, etapem nauki, zrozumienia przez wszystkich członków zespołu lub też organizacji, opracowaniem standardu postępowania - a jednak.

Wyjdę od Manifestu Agile - Manifesto for Agile Software Development (z ang. Manifest zwinnego tworzenia oprogramowania – 2001 r.), a mianowicie rozumiem, że wytwarzanie oprogramowania w modelu kaskadowym nie sprawdziło się i mówiąc w dużym uproszczeniu sformułowano zasady agile. Historycznie nawet wcześniej - ale fakty historyczne poruszę w odrębnym materiale.

  

" Manifest programowania zwinnego: 

Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. 

W wyniki naszej pracy, zaczęliśmy bardziej cenić:

Ludzi i interakcje od procesów i narzędzi 

Działające oprogramowanie od szczegółowej dokumentacji 

Współpracę z klientem od negocjacji umów 

Reagowanie na zmiany od realizacji założonego planu.

Oznacza to, że elementy wypisane po prawej stronie są wartościowe,

ale większą wartość mają dla nas te, które wypisano po lewej. "  

[źródło: http://agilemanifesto.org/iso/pl/]

Założenia manifestu są zgodne z systemem produkcyjnym Toyoty (TPS), gdzie już w latach 50-tych XX wieku wprowadzano i można powiedzieć potwierdzano ich skuteczność na żywym organizmie jakim była TOYOTA.

A dokładniej:

• obserwowanie produkcji, reagowanie na błędy i wprowadzanie poprawek już w trakcie produkcji, poprzez wykorzystanie cyklu Deminga – PDCA (Plan, Do, Check, Act), nic innego jak planowanie sprintu, development, prezentacja wyników, retrospektywa; 

• TPS - Toyota Production System = Thinking People System – Ludzie, ich pomysły, chęć pracy, zachęcanie pracowników do kreatywności,

• systemowe podejście do doskonałości procesów i ludzi! Poprzez pozwalanie na kreatywność pracowników, doskonalono procesy a dzięki temu można powiedzieć TWORZONO wybitnych ludzi.

Zwracam uwagę jak ważną role miało do spełnienia kierownictwo. Rozwijanie umiejętności pracowników a nie niszczenie pomysłów w zarodku!

W tym miejscu STOP:

Stwierdzenia zawartego w manifeście:

„Ludzie i interakcje przed procesami i narzędziami” w mojej ocenie, nie należy rozumieć, że manifest zachęca do ignorowania procesów.

Byłoby to nielogiczne, bo procesy są wszędzie, nawet tworzenie tegoż manifestu było procesem. Doskonalenie ludzi i doskonalenie procesów jest ze sobą nierozerwalne. To ludzie i ich otwarte umysły tworzą procesy, ale to procesy pokazują jak wykonywana jest praca, gdzie dochodzi do zakłóceń i dają feedback co trzeba zmienić, udoskonalić i znowu myśl ludzka szuka rozwiązań. Jak w kole Deminga!

Kilka przykładów na doskonalenie procesów, które wykorzystywane są w Agile:

„Just-in-time” – szczupła produkcja, ograniczanie marnotrawstwa, braku zapasów. Czy podczas tworzenia oprogramowania nie występuje marnotrawstwo? Nawet w zespołach Srum’owych? A oczekiwanie na …. decyzje, informacje, wsad do kolejnego kroku, nieprzemyślane działania, nadmiarowa praca niekoniecznie potrzebna ;). Jaka jest rola szefostwa w tym aspekcie, na ile budują samodzielne zespoły i pozwalają na tę samodzielność? 

Jidoka – rozwiązywanie problemów u źródeł i  w momencie ich wystąpienia, czyli prawo do powiedzenia stop gdy widzę, że jest problem, który trzeba rozwiązać tu i teraz a nie na koniec produkcji.

Kanban – powszechnie stosowane narzędzie w tworzeniu oprogramowania, są aplikacje posiadające gotowe rozwiązania dla zespołów Scrum’owych jak chociażby Jira – osobiście uwielbiam! Tablice Kanban mogą być w wersjach elektronicznych (Jira) czy też fizycznie wisieć na ścianie jeśli to sprawdza się lepiej w danym zespole. Przy czym Jira daje mnóstwo możliwości i danych do analizy, dla mnie osobiście (bez reklamy) doskonałe narzędzie pod każdym względem. Notabene ciekawa jestem ile zespołów scrumowych wykorzystuje pełen komplet możliwości tej aplikacji. (takie moje rozważania)

I inne... 

Tutaj branża IT ameryki nie odkryła – to wszystko wywodzi się wprost z TPS TOYOTY i jej ogromnych osiągnięć w drodze do doskonałości.

„Szczupła i zwinna” produkcja to nic innego jak Lean.

Dlaczego o tym piszę? Ponieważ zanim przejdę do mówienia o tworzeniu procesów, ich analizie i dalej, to zależy mi na wyjaśnieniu wszystkich niejasności z jakimi się spotykam i ewidentnie wynikają one z braku wiedzy i rozumienia istoty sprawy czyli PROCESÓW.  

Czy tego chcemy, czy nie, każdy sprint to proces do którego wchodzą określone dane, wewnątrz dochodzi do wytworzenia określonej wartości, spożytkowania zasobów przeznaczonych na pracę; nawet koncepcyjną; dochodzi do interakcji pomiędzy ludźmi, a w konsekwencji otrzymujemy dane wyjściowe. W przypadku złożonych procesów w danym sprincie dochodzi do powiązań międzyprocesowych – ponieważ komunikacja to także proces i może najważniejszy ze wszystkich. Jej brak powoduje niezrozumienie, niespełnienie oczekiwań, utratę czasu, irytację w zespole, konflikty międzyludzkie. Proszę zobaczyć ile zakłóceń można zidentyfikować tylko z poziomu high level patrząc na sprint a ja jeszcze go nie zaczęłam analizować.

Ktoś powie:

- No dobra, w motoryzacji dużo łatwiej mierzyć, liczyć to co wchodzi, ustalać czasy, początek cyklu, koniec, liczyć straty bo jest magazyn, są rzeczywiste fizyczne podzespoły, …. W informatyce jest koncepcja, my tworzy. 

Czy to oznacza, że nasz klient będzie czekał w nieskończoność aż coś wytworzymy ? NO nie. Zgodzę się, że tworzenie aplikacji, szczególnie zupełnie czegoś nowego to bardziej abstrakcyjny proces, jednak jego także można policzyć, zmierzyć i udoskonalać a narzędzia do tego daje nam metodologia Lean i narzędzia Six Sigma. Tak Six Sigma!

Sayings Taiichi Ohno (http://www.leanvlog.com)

Ponieważ podobno piszę zbyt długie artykuły :), na dziś zakończę moje rozważania, jednak ciąg dalszy nastąpi. 

Urszula Sotowicz

Inżynier zarządzania procesowego, 

audytor systemów bezpieczeństwa informacji, 

trener, 

pasjonatka rozwoju i ciągłego doskonalenia.