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.

6

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.

7

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 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0