W zeszłym roku Ela Zielińska zaprosiła mnie do napisania serii artykułów o Agile dla portalu Asystentka Leve Master by przybliżyć Wirtualnym Asystentkom i Wirtualnym PM zwinne metodyki zarządzania projektami. Pod jednym z nich ostatnio pojawił się komentarz, wobec którego nie można przejść obojętnie.
Udało mi się skontaktować z Darkiem, jego autorem, który zgodził się na to, żebym opublikowała komentarz również na stronie narudo.pl. Darek doskonale wie o czym pisze, posiada bardzo duże doświadczenie w wielu obszarach projektów IT. Chociaż bardzo ceni anonimowość, przedstawił się dla nas w kilku słowach. Darku, dziękujemy!
Brałem udział w ponad 40 projektach informatycznych, w różnej roli, przeważnie Analityka Biznesowego, Analityka Systemowego. Mam ponad 20 lat doświadczenia w różnego rodzaju Analizach.Byłem IT Managerem, pomagałem również w organizacji procesów produkcji oprogramowania w firmach, w tym przy okazji organizacji firmy PPUC (Poczta Polska Usługi Cyfrowe), właściciela platformy Envelo, oraz realizacji jej Produktów. Pracowałem tam, jako Analityk IT, potem Analityk Biznesowy w Biurze Rozwoju Produktów. Interesuję się Inżynierią Oprogramowania, metodami szacowania wymiaru oprogramowania, metodykami realizacji projektów. Interesuje mnie również Inżynieria Systemów, jako nauka o organizacji dużych, kompleksowych systemów, nie tylko informatycznych
Czytajmy komentarze 🙂
Poniżej, za zgodą autora, zamieszczam cały komentarz. Oryginalny komentarz jest TUTAJ. Niech ten wpis będzie początkiem dyskusji o doborze metodyk do projektów i procesach w organizacjach.
Dziękuję za ten tekst, prawdę powiedziawszy przyda mi się takie zestawienie przy rozmowach na temat Scruma z „Talibami” znającymi tylko Scruma i ślepymi na jego wady 🙂 To by po Hitchcock’owsku mocno uderzyć na początku i by potem napięcie mogło tylko rosnąć 😉
Główną wadą „czystego” Scruma jest to, że jest to Produkt sam w sobie, nastawiony na dobrą sprzedaż, z bardzo dobrym marketingiem, który niestety zepsuł „rynek” – dzisiaj praktycznie zanikła dyskusja i argumentacja, jak w tym artykule, że metodykę dobiera się do pracy do wykonania, a nie jak z taśmą Aleksandra Forda: „Dostarczymy ci Forda T w każdym kolorze, pod warunkiem, że będzie to kolor czarny”. Znaczy „Metodyka? Tak – może być każda, byle zwinna, byle był to Scrum”!
Nie tędy droga. Oglądałem kiedyś film dokumentalny o projekcie i budowie najwyższego mostu na świecie, na którejś z francuskich przełęczy. Problemem były najwyższe zbudowane do tej pory przęsła i sposób ich podniesienia. Francuski inżynier opowiadający o tym stwierdził coś, co jest kluczowe DLA KAŻDEGO PROJEKTU, W KAŻDEJ BRANŻY: „- Dobry inżynier budowlaniec powinien mieć ‚z tyłu głowy’ wszystkie techniki i narzędzia, które pojawiły się w budownictwie na przestrzeni ostatnich 4 tysięcy lat tak, by móc dobrać te, które najlepiej odpowiadają potrzebom w danym projekcie”. Do przetransportowania na miejsce budowy, podniesienia i ustawienia na miejscu przęseł zastosowano te same techniki, które zastosowali budowniczowie piramid Egipskich, kilka tysięcy lat wcześniej…
Informatyka nie liczy sobie kilku tysięcy lat, ale techniki zarządzania projektami są starsze, niż informatyka. Podobnie jak Autorka tego tekstu, nie wyobrażam sobie stawiania mostu przez Wisłę „Agilowo” i z zastosowaniem zwykłego Scruma 😉 Jest taka dziedzina informatyki, którą nazywa się Inżynierią Oprogramowania, która ma znaczenie, a o której w takich dyskusjach kompletnie się zapomina, jakby myśląc, że Scrum załatwi wszystko. Zdarzało mi się już ratować projekty „załatwione” w ten sposób przez Scruma, chociaż sam jestem zwolennikiem zwinnego dostarczania Produktu, ale „z głową”!
Tak naprawdę Scruma wymyślono po to, by ograniczyć problem w projektach, jaki pojawił się na rynku – brak dobrych Analityków i „Procesu Analitycznego”, tj. usystematyzowania tego, co ma być produktem ich pracy, jak ma ona wyglądać, czemu służy. Od jakichś 10 lat obserwuję odchodzenie od pewnych ról w projekcie (przy czym nie udaje się to nie bez powodu), tj. Analityka (w znacznie mniejszym stopniu), czy też Projektanta (tutaj ta rola praktycznie zanikła), przy pojawieniu się Developera, tj. roli zawierającej w sobie kompetencje Programisty, Projektanta, częściowo Architekta i Analityka.
Z punktu widzenia zakresu projektu i pracy, która musi być wykonana, nie ma cudów – ktoś musi zanalizować zakres projektu
(Wymagania) określony czy to funkcjonalnością (Przypadkiem Użycia), „historyjką użytkownika”, czy też zadaniem. Jeśli w projekcie brakuje dobrego Analityka, to ta praca rozkłada się gdzieś pomiędzy Scrum Mastera i Developera, bo sama historyjka odpowiada na pytanie „co”, a specyfikacja musi odpowiedzieć również na pytanie „jak”. Zwykle Analityk odpowiada na wszystkie pytania zarówno „co”, jak i „jak” ma być wytworzone, z jaką jakością, z jakim zakresem informacyjnym itp. Po prostu jest to ktoś, kto koordynuje projekt w warstwie pomiędzy Product Ownerem, który koncentruje się na wartości dla Klienta a Developerem. Jest to zwykle Analityk – właściciel Wizji Rozwiązania.
Problemem nadal jest niestety zanik roli Projektanta. Spotkałem się już w praktyce zawodowej z przypadkiem powierzchownego wdrażania Scruma w projekcie kompletnie do tego nie przystosowanym (kilkadziesiąt milionów złotych, dobrze określony zakres, 60 „Developerów”, gdzie Scrum Master bezmyślnie próbował wymusić zastosowanie prostego Scruma bez przygotowania zespołu). Prezentując zakres projektu zespołowi Developerów, spotkałem się z pytaniami w rodzaju: „- No dobrze, wiemy co mamy zrobić (historyjki), ale jak mamy to zrobić?!”, albo „- OK, ale kto nam zaprojektuje bazę danych?”. To było wprost wypunktowanie braków Scruma (i przy okazji braku kompetencji konkretnego Scrum Mastera – patrz wdrożenie Zespołu do takiego a nie innego wykonania pracy, która jest do zrealizowania)!
No właśnie, to jest praca do wykonania – „jak” i koordynacja Wizji Rozwiązania, skoncentrowania jej w jednej „głowie”, dlatego najbliżej z tych metodyk zwinnych jest mi do Agile PM. Zgadzam się tam niemal z wszystkim, zwłaszcza z tym „Buduj przyrostowo od solidnych podstaw”, bo solidny model na początku projektu to podstawa! Każdy projekt przypomina raczej strukturę hierarchiczną, wtedy jest sprawnie zarządzany, natomiast Scrum wprowadza pewną anarchię i brak odpowiedzi na pytanie, kto odpowiada za realizację Wizji Rozwiązania? Kto jest właścicielem tej wizji? Na poziomie Produktu – Product Owner, ale na poziomie Wizji Rozwiązania? Architekt? Nie – powinien za to odpowiadać Analityk! Ta odpowiedzialność w Scrumie jest rozproszona, co generuje w projekcie ryzyka.
W Agile PM brakuje mi jednego pryncypium: „Konsekwentnie zarządzaj zmianą”, co jest nieco w sprzeczności i neguje „dostarczaj na czas” rozumiane jako bezwzględne trzymanie się ustalonego terminu. Bo kto go ustala? I czy to uwzględnia zarządzanie zmianą? Bo każda zmiana może podważyć ustalone terminy wynikające z pracochłonności i efektywności zespołu! Ja znam swoją efektywność, bo gromadziłem statystyki w projektach, w których brałem udział (zawsze musiałem określić czas realizacji Analizy, zawsze musiałem znać jej zakres – to było zawsze moje założenie przy szacowaniu czasu realizacji). W dużych, trwających długo projektach, zmian może pojawić się w trakcie bardzo wiele, w szczególności jedna kluczowa – podważenie zasadności biznesowej projektu. I co wtedy? Trzymamy się terminów?
Jest ponadto jeszcze jedno kryterium w dobieraniu metodyki do projektu, poniekąd wynikające z tego, co napisałem, tj. kompetencje zespołu projektowego. Otóż, jeśli są one za słabe a projekt duży, kluczową rolę pełnią Analityk, Projektant, Architekt w projekcie. Po prostu – wszelkie zwinne metodyki kładą nacisk na wysokie kompetencje Developerów i pewną uniwersalność tej roli, przy bardzo dobrych umiejętnościach interpersonalnych, w komunikacji w zespole. Programista i „dobra komunikacja”, to często nie idzie ze sobą w parze (przy całym szacunku dla Programistów!).
Po prostu, Programista musi być poniekąd introwertykiem/perfekcjonistą, koncentrować się na szczegółach, dbać o detale, pracując na poziomie niemal atomowym – kodu, a to zazwyczaj nie idzie w parze z dobrą komunikacją na poziomach bardziej abstrakcyjnych, tykających Wizji Rozwiązania – generuje to problemy ze spójnością tej wizji. Lepiej powierzyć część kompetencji związanych z Wizją Rozwiązania dedykowanym, wyspecjalizowanym rolom (Analityk, Architekt, Projektant), zamiast liczyć na to, że zajmą się tym „wszyscy”, co zwykle znaczy – nikt! Taki zespół jest tak słaby, jak najsłabsze jego ogniwo, czy to jeśli chodzi o personę, rolę, czy też pracę do wykonania w WBSie projektu, a bywa, że tym słabym ogniwem jest Wizja Rozwiązania, często eklektyczna, niespójna, niepełna, niekonsekwentna, niejednoznaczna, nadmiernie skomplikowana! To dlatego właśnie nie buduje się mostów „Agilowo” – nie przeżyłby pewnie żaden Architekt (ten od architektury mostów, czy domów). Oni tradycyjnie stoją pod mostem w trakcie prób obciążeniowych, gwarantując swoim życiem, że opracowali Wizję Rozwiązania z należytą starannością 😉
Jest jeszcze jedno zagadnienie, które wpływa na wybór metodyki, ale poniekąd poruszone w tekście – produkt i jego czas życia, sposób obsługi, przeznaczenie, umocowanie zespołu. Jeśli Produkt ma posłużyć organizacji na potrzeby wewnętrzne, budżet nie jest sztywny i bardziej przypomina projekty utrzymaniowe/usługę, gdzie wiadomo, że Produkt będzie żył „na bieżąco”, to wybrałbym metodyki bardziej zwinne. Jeśli produkt ma być produktem rynkowym, to ZAWSZE, PRĘDZEJ CZY PÓŹNIEJ POJAWIĄ SIĘ ZAGADNIENIA ZWIĄZANE Z UTRZYMANIEM, tj. zgłoszenia Klientów, które musi przyjąć I Linia Wsparcia i poddać Analizie Analityk Service Desk w II Linii Wsparcia, który analizuje wpływ i zakres potencjalnej zmiany na projekt, po czym przekazuje do III Linii Wsparcia – Developerom/Programistom (A powinien Projektantowi/Architektowi, ale patrz wyżej).
Poważnym problemem na tym etapie jest brak Dokumentacji Analitycznej Produktu, której zwykle nie ma w projektach Scrumowych, bo nikt nie sięga aż po utrzymanie, koncentrując się na wytworzeniu! Każdy proces można ująć w skali CMMI (Capability Maturity Model Integration – model dojrzałości organizacyjnej), która definiuje dojrzałość procesową organizacji. Można nią określić również dojrzałość procesu produkcyjnego. Scrum na tej skali wypada blado…
Pierwszy poziom – procesy realizujemy ad hoc, nie ma ustalonej metodyki ich realizacji, po zrealizowaniu zapominamy i rozchodzimy się do siebie.
Drugi poziom – procesy realizujemy powtarzalnie, ale metodykę „mamy w głowie”, tj. odchodzi ktoś z zespołu, tracimy wiedzę o tym, „jak” realizować konkretne zadanie, nowa osoba przynosi swoje pomysły na to, „jak” – tracimy czas (i co z terminami – patrz wyżej). Na tym mniej więcej poziomie, jeśli chodzi o realizację „jak”, czyli na poziomie Wizji Rozwiązania, umieścić można Scruma.
Trzeci poziom – udokumentowany, to pierwszy poziom bezpieczny. W odniesieniu do dokumentacji projektowej, dotyczyć to może w szczególności dokumentacji Analitycznej. Jeśli ją mamy, mamy dobrze wyspecyfikowaną Wizję Rozwiązania, nie boimy się zmian w zespole – wystarczy, że Developer będzie miał wymagane do realizacji kompetencje techniczne, nie musi domyślać się jak zrealizowano zadania, albo jak ma je zrealizować – ma to w dokumentacji!
Czwarty poziom, to poziom mierzalny. Dokumentacja Analityczna daje tutaj podstawy do szacowania wymiaru funkcjonalnego, choćby metodami punktów funkcyjnych, czy wręcz wymiarowania oprogramowania wspomnianymi metodami. Trudno to przecenić, bo to dokładna odpowiedź na pytanie – ile będzie trwało dane zadanie, przy założonych kompetencjach zespołu i jego składzie, mając obliczony wymiar funkcjonalności oprogramowania (poniekąd determinujący pracochłonność), przy określonej efektywności pracy zespołu. Nadal te metody wymiarowania nie są powszechnie stosowane (wymiarowanie metodą punktów funkcyjnych), bo zgadza się – są pracochłonne. Tym niemniej brak Analizy kosztuje – zwykle dużo więcej, ale na etapie funkcjonowania Produktu na rynku, czy też już przed końcem projektu, gdy przed uruchomieniem rynkowym Produktu pojawia się coś takiego, jak np. „crunch” u twórców gier, czyli praca ponad ustalone godziny. Jest to właśnie wynik nieprzemyślenia do końca tego „jak” Produkt ma być wytworzony, niedostatecznej koordynacji prac, bo nie ma jednego, ustalonego właściciela Wizji Rozwiązania, oraz braku formalnej dokumentacji tej wizji. Praca Scrumowa ma właśnie taki trochę anarchistyczny charakter i wynikające z tej anarchii problemy.
Dopowiem o skali CMMI – piąty poziom, to poziom organizacji uczącej się, która modyfikuje swoje procesy, np. Proces Produkcyjny, czy Proces Analityczny (mało która go ma – nie spotkałem się z taką, która by w ogóle wiedziała, że go potrzebuje). Po każdym projekcie mamy „Lessons Learnt”, który to etap powinien nam odpowiedzieć na pytania – co zrobić mogliśmy lepiej i dlaczego, jak zmodyfikować nasze procesy, biorąc pod uwagę zebrane wskaźniki (poziom 4 CMMI).
W swojej praktyce zawodowej, w różnej skali projektach, spotykałem się często z metodykami zwinnymi, sam je stosując, np. elementy Scrum’a, ale prawie nigdy nie był to czysty Scrum, bo po prostu metodykę narzucono, bo modna, bo ktoś zasłyszał, że tak będzie lepiej, nie przemyślawszy, czy jest dostosowana do projektu. Parę takich projektów udało mi się uratować, np. niwelując w ciągu 3 miesięcy (wraz z Kolegami Analitykami, którzy zastosowali zaproponowaną metodę i pojawili się razem ze mną w projekcie w roli „Strażaka” do ugaszenia pożaru) „dług technologiczny” – 18 miesięcy pracy bez rezultatów. Musieliśmy praktycznie zaczynać projekt od początku, od jego organizacji, ale dzięki zasadom Inżynierii Oprogramowania i Dobrym Praktykom, dobrej pracy Analityków w zespole, „zasypaliśmy” Developerów specyfikacją funkcjonalności niwelując ten wspomniany wyżej „dług” do zera!
Ważne, by metodykę dostosować do potrzeb w konkretnym Projekcie i ograniczeń, wynikających również z kompetencji Zespołu. Każde niedostosowanie metod do wymagań odnośnie pracy do wykonania (kluczowe jest jej zidentyfikowanie w Projekcie), skutkuje „rolowaniem” długu, który kiedyś komuś przychodzi spłacić – Developerowi pod koniec projektu, albo członkom zespołu Service Desk na Etapie Utrzymania i Rozwoju. W przyrodzie żadna praca nie ginie, parafrazując znane powiedzenie, co najwyżej nie ma dobrze określonego właściciela…
Jestem Magda, ta z narudo.pl – entuzjastka technologii, project manager i analityk
IT. Wspieram przedsiębiorców i twórców internetowych w skutecznym wykorzystywaniu narzędzi online i sztucznej inteligencji oraz organizacji i planowaniu. Wierzę w optymalizację pracy i efektywne zarządzanie, jestem gotowa podzielić się swoim doświadczeniem i wiedzą abyśmy mogli pracować mądrzej, nie ciężej.
