Wyciśnijmy z programistów za pomocą SCRUM'a

1

Zacznę od tego, że nie mam nic do metodyki SCRUM, jednak ostatnio zauważyłem, że "biznes" w Polskich korporacjach sprytnie wykorzystuje tą metodykę do wyciskania z programistów jak z cytryn. Coś na zasadzie - jeżeli koszt zwykłego pracownika to 10k, a programisty 30k, to może zróbmy tak, aby robił za 3 osoby albo i więcej - i udało się, a przynajmniej w 3 korporacjach w których pracowałem.

Pewnego dnia...
Zorganizowano nam spotkanie z dyrektorem IT, który rzekł: nie chcemy więcej słyszeć, że zespół scrumowy nie osiągnął celu sprintu w postaci funkcjonalności np. w aplikacji mobilnej i nikogo nie interesują tłumaczenia typu: nie mieliśmy dostarczonych grafik, backendu(nawet w postaci kontraktów), dokumentacji, braku scrum mastera bo siedzi 7 miesiąc na L4, lub dostępności 1 testera na 20 zespołów programistycznych, (który w dodatku nie mówi po polsku ani po angielsku).
Twierdził, że od strony biznesu, to cały zespół scrumowy gdzie nie liczą się pojedyncze umiejętności tylko zespół jako całość i jeżeli nie ma testerów to testują inni itp.

Problem polega na tym, że programista(przynajmniej ten przeciętny) jest w stanie napisać dokumentację czy zrobić analizę (analityk), przetestować (tester), zrobić grafikę (ui), komunikować się z biznesem (po) i pełnić wszystkie obowiązku Scrum mastera, ale w drugą stronę to już nie działa :) (nie wymieniłem wszystkich obowiązków, wiem że macie ich więcej :) )
Tak się składa, że obowiązków programisty nikt zastąpić już nie może. (Oczywiście zależnie od poziomu programisty inne obowiązki będą zrealizowane na różnym poziomie, jednak obowiązki programisty przez innych nie będą zrobione w żadnym stopniu).

Gdy programista zrobi już wszystko, to w nagrodę jest zmuszony przez PO do prezentowania wyników sprintu co 2 tygodnie przed publicznością (bo przecież wybrał zawód siedzenia przed komputerem to musi by ekstrawertykiem) i zebrania pretensji od interesariuszy dlaczego tak mało i co z bugami z produkcji, bo przecież można je było jeszcze wcisnąć między zadania, podczas gdy PO sam jest zdziwiony co powstało przez ostatnie 2 tygodnie w jego aplikacji.

Rynek w teorii weryfikuje i jeżeli programiści by tego robić nie chcieli to by tego nie wymagali, ale prawda jest taka, że aktualnie jest zbyt dużo chętnych na stanowisko programistów (wbrew temu co mówią firmy wciskające szkolenia programistyczne i mówiące o niedoborze 40mln programistów w 38mln kraju) i ludzie godzą się na wszystko.

Nie wydaje wam się, że od programisty aktualnie wymaga się zbyt dużo ?
Zapraszam do dyskusji.

8

Nie ludzie godą się na wszystko tylko wannable juniorzy albo jacyś desperaci.

Zorganizowano nam spotkanie z dyrektorem IT, który rzekł: nie chcemy więcej słyszeć, że zespół scrumowy nie osiągnął celu sprintu w postaci funkcjonalności np. w aplikacji mobilnej i nikogo nie interesują tłumaczenia typu: nie mieliśmy dostarczonych grafik, backendu(nawet w postaci kontraktów), dokumentacji, braku scrum mastera bo siedzi 7 miesiąc na L4, lub dostępności 1 testera na 20 zespołów programistycznych, (który w dodatku nie mówi po polsku ani po angielsku).
Twierdził, że od strony biznesu, to cały zespół scrumowy gdzie nie liczą się pojedyncze umiejętności tylko zespół jako całość i jeżeli nie ma testerów to testują inni itp.

Scrum jest słaby i generalnie ma tyle wspólnego z byciem agile co świnika morska z pływaniem, ale Ty przede wszystkim pracujesz u Janusza.

2

Również nigdy czegoś podobnego nie doświadczyłem. Co do nadmiaru juniorów to może i faktycznie, ale prawdziwych fachowców to nadal mamy niedobór. Zamiast więc siedzieć po 12h po prostu robisz uczciwie ile się da a na retro podnosisz sprawę że za dużo bierzecie na sprint i się nie wyrabiacie. A jak nie ma retro, to ergo i nie ma SCRUMa (aka SCUMA) i gadki szmatki o celach i wyzwaniach możesz spokojnie olać...

Jak ktoś mądry kiedyś powiedział projekt to maraton a nie sprintowanie w kółko. Współczesny agile mówi wprost o sustainable pace czyli o takim doborze tempa żeby dało się w ten sposób pracować przez miesiąc, rok i 10 lat. Inaczej ryzykujesz wypaleniem i utratą zdrowia.

8

Twierdził, że od strony biznesu, to cały zespół scrumowy gdzie nie liczą się pojedyncze umiejętności tylko zespół jako całość i jeżeli nie ma testerów to testują inni itp.

To jest dzbanem i nie wie o czym mówi. Tak, liczy sie caly zespół i odpowiadacie za dowożenie ficzerów kolektywnie jako cały zespół. Ale idea jest taka że skład zespołu umożliwia wykonywanie dowolnego taska, a nie że jak nie ma grafika to developer klika sobie w painta.

zmuszony przez PO do prezentowania wyników sprintu co 2 tygodnie przed publicznością

To akurat dość normalne bo kto ma prezentować jak nie autor ficzera? Przecież reszta zespołu może nie wiedzieć w ogóle o co chodzi, gdzie kliknąć, co ma się stać etc. To nie jest występ przed publicznością, bo focus jest na tym CO prezentujesz a nie tym kto prezentuje.

Nie wydaje wam się, że od programisty aktualnie wymaga się zbyt dużo ?

Wydaje mi się że jak jesteś dorosły to jesteś kowalem swojego losu. Jakby mi ktoś powiedział że mam siedzieć i robić grafiki w paincie to zabiłbym go śmiechem, a jakby dalej nalegał to rzuciłbym papierami i tyle.

2

@Shalom: co do review, dodam, że była rezerwowana sala, programista miał stać na środku sali i opowiadać o biznesowych aspektach danej funkcjonalności na tle około 50 osób, tylko o biznesowych aspektach. Np. jak wygląda proces rezerwacji usługi czy sprzedaży jakiegoś produktu.
Moim zdaniem, o biznesowych aspektach powinien opowiadać ktoś kto się na tym zna, natomiast o technicznych rzeczach programista. Ale może jestem w błędzie. Scrum chyba nie wspomina, kto powinien robić takie przedstawienie.

5

Nie do końca rozumiem co masz na myśli. Demo po sprincie polega na tym że prezentujesz działanie ficzera i tyle. Trwa to pewnie ze 2 minuty. Rzucasz np. aplikacje na rzutniku, pokazujesz ze user ma teraz w profilu pole numer buta, pokazujesz ze wartość się zapisuje i potem wyświetlają sie reklamy zgodne z tym numerem buta a jak ktoś wpisze 69 to wyświetla sie popup nice i tyle.
Wiadomo ze nie opowiadasz tam o tym że ten numer buta to zapisujesz w Cassandrze z replikacją na 13 nodów i kworum po 3 odpowiedziach, bo demo jest dla klientów a nie dla inżynierów. Masz pokazać klientowi że coś zrobiliście w ciągu sprintu. Cel dema jest taki, że klient może zobaczyć praktycznie od razu jak wygląda ficzer i dać szybki feedback że to np. nie to o co mu chodziło.
Jeszcze raz: wszyscy na demo maja w dupie kto prezentuje. Pewnie jak ich 5 minut później zapytasz w kuchni to nie będą nawet pamiętać, bo wszyscy są skupieni na tym co jest prezentowane.
Nie wiem kto wg ciebie miałby prezentować dany ficzer, skoro nikt oprócz osoby/osób które go zrobiły pewnie nie wie jak go użyć.

1
TwojStaryWSwoichWspomnieniac napisał(a):

Problem polega na tym, że programista(przynajmniej ten przeciętny) jest w stanie [...]

zrobić grafikę (ui),

O Boże! Lepiej niech nie robi.

komunikować się z biznesem (po)

Przeciętny, typowy programista i rozwinięte zdolności komunikacji? Weź nie żartuj.

Więc problemy nie polegają na tym co wyżej.

1
0xmarcin napisał(a):

Jak ktoś mądry kiedyś powiedział projekt to maraton a nie sprintowanie w kółko.

Nie wiem, czy to takie mądre. Projekty mają horyzont czasowy maratonu, fakt, ale człowiek nie będzie pracował efektywnie w takim horyzoncie czasowym. Przede wszystkim wymagałoby to zaplanowania całego projektu od początku do końca i trzymania się go, a wiadomo że po 2 tygodniach takim planem można już sobie buty wytrzeć, bo pojawiły się nowe dane, ktoś miał zachciankę, ktoś przejrzał na oczy, ktoś odkrył jakiś problem, itp. Po drugie, z psychologicznego punktu widzenia - łatwiej jest przejść 20 razy po 50 schodów niż raz 1000. Łatwiej wtedy ocenić postęp i uzyskać satysfakcję z kawałka pracy, który się wykonało. Idąc 1000 schodów naraz, przy 232 już nie pamiętasz ile przeszedłeś, nie wiesz ile ci jeszcze zostało, nie wiesz czy przy 900 ktoś cię nie zawróci do początku bo okaże się, że pomylono klatki schodowe.

0
Shalom napisał(a):

Nie do końca rozumiem co masz na myśli. Demo po sprincie polega na tym że prezentujesz działanie ficzera i tyle. Trwa to pewnie ze 2 minuty. Rzucasz np. aplikacje na rzutniku, pokazujesz ze user ma teraz w profilu pole numer buta, pokazujesz ze wartość się zapisuje i potem wyświetlają sie reklamy zgodne z tym numerem buta a jak ktoś wpisze 69 to wyświetla sie popup nice i tyle.

@Shalom: według mnie autor ma na myśli to, że przychodzi Ci na takie spotkanie 50 menadżerów, którzy nawet nie są zainteresowani tym konkretnym ficzerem. Ich interesuje tylko to, że projekt który współtworzysz został hucznie przedstawiony zanim powstał i wiążą z nim nadzieje. Ponieważ projekt jest spory, a mijają kolejne tygodnie, to dobrze byłoby pokazać efekty. Problem w tym, że jest to jakiś mało znaczący ficzer dla zarządu. To że możesz wpisać numer buta i dostać dopasowane reklamy ich nie interesuje. Ich interesuje kompletny internetowy sklep z setką ficzerów i profilowaniem klientów. A najważniejsze jest to, że sklep przynosi zyski. Ponieważ w zespole jest trzech programistów, którzy jeszcze mają podążać za procesem i produkować w międzyczasie masę raportów, ogarniać, frontend i UX to idzie to po prostu wolno. Kierownictwo ciśnie, a Ty masz to ładnie sprzedać, pomimo że nie bardzo masz co i nie jest to w ogóle Twoja rola.

1

Zorganizowano nam spotkanie z dyrektorem IT, który rzekł: nie chcemy więcej słyszeć, że zespół scrumowy nie osiągnął celu sprintu w postaci funkcjonalności np. w aplikacji mobilnej i nikogo nie interesują tłumaczenia typu: nie mieliśmy dostarczonych grafik, backendu(nawet w postaci kontraktów), dokumentacji, braku scrum mastera bo siedzi 7 miesiąc na L4, lub dostępności 1 testera na 20 zespołów programistycznych, (który w dodatku nie mówi po polsku ani po angielsku).
Twierdził, że od strony biznesu, to cały zespół scrumowy gdzie nie liczą się pojedyncze umiejętności tylko zespół jako całość i jeżeli nie ma testerów to testują inni itp.

Uwielbiam takie januszostwo. Czytaj: nie zrobię nic żeby polepszyć pracę zespołu, nie zadbam o jakość pracy pracowników i ich stosowną ilość, nie kiwnę palcem by zbadać sytuacje a jedynie krzykiem i rozkazami powiem, że teraz ma być dobrze i tak ma być, bo ja jestem dyrektorem. Po czym opuszcza spotkanie z poczuciem spełnionego obowiązku...

1

Roześmiałbym się głośno a tuż po tym zapytał pana dyrektora czy zamierza się zwolnić jeśli rzeczywiście nie chce o tym więcej słyszeć a o zwiększeniu zasobów (albo redukcji obciążenia) nawet nie próbował myśleć. Chyba że sami bierzecie na siebie o wiele za dużo roboty chcąc zadowolić każdego - wtedy macie problem.

Co do prezentacji to normalne. Jeżeli narzekają że mało i nie jest to waszą winą to nikt nie każe ci siedzieć cicho i nie reagować. Jeśli dajecie sobą pomiatać to będziecie pomiatani.

5

To wina PO

4

Do prezentacji radziłbym się przekonać, bo takie prezentacje mogą być też motywujące (w zależności od odbiorcy).
Nawet jeśli nie dostaniesz pozytywnego feedbacku, to dowiesz się co jest dla odbiorców przydatne a co nie.
Co z tego że zrobisz kod zgodnie ze sztuką, z superwydajnymi algorytmami, w topowym języku jeśli nie będzie robił tego co klient sobie wymyślił (ale np. nie zakomunikował). Najważniejsze są cele biznesowe, czasem je się realizuje za pomocą kartki i długopisu, czasem przy pomocy Excela, a czasem przy pomocy customowej implementacji (w jakiejś np. Dżawie Skryptowej).

0

@vpiotr: Zgadzam się, bez biznesu nie będzie przecież pieniędzy na programistów. Tym bardziej jeżeli idziemy do biznesowej firmy. Aplikacja ma przynieść korzyści firmie, a nie być zabawką dla programistów... jednak
problem niestety polega na tym, że na rozmowie o prace i w ogłoszeniu, nigdy nie ma informacji o tym, że 10% Twojej pracy będzie tylko związania z Twoją specjalnością i będziesz chodził na spotkania biznesowe i wyciągał z ludzi informacji. Jak dobrze pójdzie to będziesz programował 1 dzień w tygodniu w Javie 1.6, a w ogłoszeniu był Kotlin. Zawsze na rozmowie, jest tylko zachwalanie jakich to technologii i ile to programowania to nie będzie, nikt nie wspomina o pozostałych aspektach.

Ja już się przyzwyczaiłem, jestem tylko ciekaw czy w innych firmach jest to samo i widzę, że zdania są podzielone.

0

@TwojStaryWSwoichWspomnieniac: Ja całkiem niedawno byłem w takim krótko-terminowym projekcie (3 miesiące).
Rozpoznanie potrzeb. Dokumentowanie wymagań. Ustawianie równo wierszy w Excelu. 50% czasu to spotkania.
Inżyniera (mnie) potrzebowali tylko po to żeby mądrze pokiwał głową (przez Teamsy ciężko).
Wnioski wyciągnąłem. Ale każdy może mieć inne.
Teraz mam tylko spotkania opcjonalne lub KT.

0

Ciekawe czy w tej firmie funkcjonuje koncepcja iteracyjnego podejścia do budowy produktu i eksperymentów, które z definicji mogą zakończyć się negatywnie. Z mojego doświadczenia, Jeśli tego nie ma, to można sobie odpuścić jakiekolwiek podejście zwinne i wrócić do jaskini, czyli release raz na kwartał i z góry narzucony zakres oraz deadline (na 1.X mamy wdrożyć „aplikacje”).

0
Charles_Ray napisał(a):

Ciekawe czy w tej firmie funkcjonuje koncepcja iteracyjnego podejścia do budowy produktu i eksperymentów, które z definicji mogą zakończyć się negatywnie. Z mojego doświadczenia, Jeśli tego nie ma, to można sobie odpuścić jakiekolwiek podejście zwinne i wrócić do jaskini, czyli release raz na kwartał i z góry narzucony zakres oraz deadline (na 1.X mamy wdrożyć „aplikacje”).

Od eksperymentów jest PO a nie programiści. Programiści co najwyżej moga cos zasugerować. I jak wzięli na spring jakies zadanie ktore sami zestymowali to powinni je dowieść albo mieć jasne wyjaśnienie dlaczego się ni udalo.

3
TwojStaryWSwoichWspomnieniac napisał(a):

Twierdził, że od strony biznesu, to cały zespół scrumowy gdzie nie liczą się pojedyncze umiejętności tylko zespół jako całość

Scrum Guide rzeczywiście nie wyznacza ról poszczególnych osób takich jak "tester" czy "programista", ale tylko dlatego że nie może czy nie chce być zbyt specyficzną instrukcją jakie w zespole powinny istnieć stanowiska. Dlatego w scrumie jest przewidziany tylko product owner, scrum master i reszta - a ta reszta powinna być wedle potrzeby i umiejętności poszczególnych osób.

Scrum nie jest ani za ani przeciw temu by wszyscy w zespole znali się na wszystkim i robili wszystko.

Również to że scrum nie przewiduje pozycji np. testera nie oznacza że testerów powinno nie być, a czasami się takie bzdury słyszy. No ale nie przewiduje też programistów PHP. Ani Java. Po prostu scrum nie jest listą potrzebnych stanowisk.
Jeśli celem sprintu jest wysłanie człowieka w kosmos to potrzebny jest wyszkolony astronauta i nie ma tłumaczenia że scrum nie przewiduje astronautów.

Do tego dochodzi kwestia umów o pracę i wpisanego tam zakresu obowiązków.

2

Według mnie to nie wina scrumu a spieprzonej firmy ;) No i druga sprawa, scrum scrumowi nie równy. W poprzedniej pracy sprint review wyglądało faktycznie jak przesłuchanie, gdzie jakiś z choinki urwany menadżer wymagał wyjaśnień czemu task A nie dojechał, a programista musiał znać wszelkie reguły biznesowe bo biznes o coś lubił zapytać. Do tego scrum master, który na spotkaniach siedziach i grał na telefonie, a jak coś trzeba było załatwić to po pół dnia dostałem od niego imię innego gościa który mi może pomóc. Nie wspomnę o wciskaniu ile się da SP na sprint, porównywaniu "bo tamten team wziął 5 SP więcej" i również wciskaniu pomiędzy taski na sprincie jakieś poboczne zadania, nie do końca programistyczne. Przykładowo, telefon od jakiegoś menadżera, że coś mu nie działa i muszę mu pomóc, ale to max 5 minut (w efekcie 2 godziny, context switching, itp, itd).

A ostatnio się przekonałem, że można inaczej. Miałem problem z dostępami, ticket zgłoszony i od 24 godzin zero akcji. Powiedziałem o tym SM i nagle lawina maili i esklacja problemu wyżej, a po godzinie problem rozwiązany. Sprint review - zupełnie inna historia, siedzą ludzie zainteresowani produktem i dają realny feedback z tego co się prezentuje, od drobnych rzeczy typu "ten przycisk mógłby być nieco większy" po grubsze fuck-upy typu "to jebnie, bo nie przewidzieliśmy tego i tego, musimy to przemyśleć".
No i jak tylko pojawi się blocker w postaci zewnętrznej zależności to zadanie co prawda nie wylatuje ze sprintu, ale jest odpowiednio oznaczone i nikt nie ma problemu, że nie udało się czegoś skończyć.

Nie zmienia to faktu, że niektóre ceremonie scrumowe są według mnie naciągane i można by je było skrócić, ale odkąd mam doświadczenie z całkiem nieźle przeprowadzonym scrumem to przestałem na niego tak narzekać.

0

Pracujemy w różnych firmach i mamy różne doświadczenia. @Shalom wspomniał o prezentacji która trwa "pewnie 2 minuty".

W poprzedniej firmie, sprint review trwało cały dzień dla biznesu, a dla developerów było to zależne od ilości zespołów.
Np. jeżeli zespołów backedowych było 5, to trwało to około 5h z przerwą.
W moim przypadku były to 4h ze względu na 4 zespoły. Po jakimś czasie, kilku miesiącach pozwolili programistom opuszczać salę, jeżeli ich zespół już zaprezentował. Co skróciło czas do 45m-1.5h.
Dzień przed takim review programiści musieli się przygotowywać, trwało to też prawie cały dzień, przygotowywać się nie tyle technicznie, co biznesowo. PO wraz z analitykiem organizowali spotkanie, na którym opowiadali programiście co tak właściwie znaczy ten ficzer dla interesariuszy. Ogólnie ludzie brali urlopy akurat na dni sprint review z wyprzedzeniem, tak jak niektórzy na początku roku biorą urlopy na długie weekendy.
W obecnej firmie jest lepiej, sprint review to 45minut jedyny problem to takim że jest pod koniec sesja pytań i dziwnym przypadkiem tu znowu wybierany jest programista osoba w którą będzie strzelane pytaniami, gdzie reszta zespołu po prostu wychodzi żeby czasami nie dostać pytania, a na planowaniu z uśmiechem na twarzy scrum master pyta jak było :)

To, że programista programuje daną funkcjonalność, nie znaczy że tylko on wie jak ma działać, częściej to nawet tester i analityk powinien znać lepiej cały process, nie wspominając o PO.
Tester ma napisać scenariusz testowy, analityk stworzyć dokumentację, a sam PO jest właścicielem produktu.
Więc moim zdaniem, w niektórych przypadkach programista wie najmniej, bowiem pobierze dane do procesu, wykorzysta jakiś generyczny mechanizm do stworzenia określonej ilości ekranów do tego procesu i tyle. Nie wgłębia się co tym razem tam sprzedajemy, akcje, buty czy owoce.

5

I dlatego niektórzy tak bardzo chcą wracać do biur :) Na czym upływałby im dzień pracy, gdyby nie długie i bezsensowne spotkania?

0

Moje doświadczenia są lepsze. Product owner jest na demo i jak trzeba to przejmuje dyskusje z klientami, raczej wszyscy z zespołu na tym demo są, nie ma problemu żeby ktoś inny z zespołu przejął demo danego featurea (czy to ktoś kto pisał testy czy ktoś zupełnie niezwiązany). Prezentacja to określenie co dany ficzer wnosi plus pokazanie zmian. Znaczna większość zamyka się w paru minutach (mój osobisty rekord to jakieś 15 sekund - naprawa jakiegoś buga)

Oprócz takich stricte procesowych różnic - u nas jest oczekiwanie że zanim powstanie linijka kodu to cel biznesowy będzie dobrze znany, niezależnie od roli w zespole. PO na demo zwykle odzywa się tylko wtedy kiedy są pytania o to jak dany ficzer spina się z produktami klientów albo jakimś przyszłym featurem który nie został wygroomowany. Czasami na rekrutacji w poprzedniej firmie mieliśmy śmieszne sytuacje jak kandydaci pracowali ponoć nad jakimś produktem przez 2 lata a nie wiedzą kto tego używa, ani po co, ani jak to w ogóle wpisuje się w całość firmy.

1
TwojStaryWSwoichWspomnieniac napisał(a):

Zacznę od tego, że nie mam nic do metodyki SCRUM, jednak ostatnio zauważyłem, że "biznes" w Polskich korporacjach sprytnie wykorzystuje tą metodykę do wyciskania z programistów jak z cytryn. Coś na zasadzie - jeżeli koszt zwykłego pracownika to 10k, a programisty 30k, to może zróbmy tak, aby robił za 3 osoby albo i więcej - i udało się, a przynajmniej w 3 korporacjach w których pracowałem.

Niedawno czytałem artykuł, w których autor analizuje to, jak wygląda praca/podejście w firmach z Silicon Valley i jak wygląda praca w firmach poza SV (szczególnie w Europie wg autora).

I okazuje się, że w SV programistę traktuje się faktycznie jak kogoś, kto jest po to, żeby rozwiązywać problemy (może dlatego w USA się nazywa programistów "inżynierami" niezależnie od wykształcenia?), natomiast w Europie programistów traktuje się jak zwykłych głupiutkich robotników, którzy po prostu mają zrobić swoje (naklepać przypisane do nich taski z Jira), a od rozwiązywania problemów to jest biznes, czy ludzie od produktu. A programiści tylko mają zaklepać kolorowe znaczki.

artykuł: https://blog.pragmaticengineer.com/what-silicon-valley-gets-right-on-software-engineers/
dyskusja na HN: https://news.ycombinator.com/item?id=25717390

i stąd potem popularność tych wszystkich Scrumów, Kanbanów, Jira-driven-development itp i ogólnie metod pracy rodem z jakiejś fabryki (Kanban powstał na potrzeby produkcji w fabrykach). Spychanie programisty do roli zastępowalnego trybika.

1 użytkowników online, w tym zalogowanych: 0, gości: 1