Wróżka estymuszka

Są różne metody estymowania czasu, jakie zajmie zrobienie i przetestowanie featurea. Możemy bazować na doświadczeniu, poprzednich projektach, wiedzy, czasu budżetu itp. Mamy nawet Planning pokera, który często wykorzystywany jest w projektach scrumowych.

Po drugiej stronie mamy jednak managerów, dla których wszystko wyestymowane jest źle. Za drogo, za dużo czasu, za dużo ludzi jest potrzebnych. Żeby trafić z estymacją, która zostanie zaakceptowana, trzeba być albo wróżką, albo myśleć jak Manager.

Autentyczna rozmowa między kolegami estymującymi projekt:

[Adam]: Podsumowując, ile czasu Wam to zajmie?

[Marcin]: 4 tygodnie nie damy rady krócej.

[A]: Ok, dobra, to chodźmy do Jarka (Managera), tylko powiedzmy mu, że zajmie to 6 tygodni bo na pewno będzie się pytał, czy nie da się tego skrócić. Pewnie będzie chciał obciąć, więc akurat zostanie tyle ile nam trzeba.

Spotkanie u managera:

[Jarek]: I jak macie już?

[M]: Tak, myślę, że w 6 tygodni damy radę

[J]: Tak długo? Adam, nie da rady tego jakoś zoptymalizować, praca na dwie zmiany, weekend work itp.? Co o tym myślisz?

[A]: Mmm… no w sumie możemy jeszcze coś tam wywalić i jak się chłopaki sprężą to na dwie zmiany powinni dać radę w 5 tygodni.

[J]: Marcin, dacie radę w 4? Macie mocny zespół, pociśniecie i będzie dobrze.

[M]: Adaś to jest realne?

[A]: Noo ostatecznie powinniście dać radę, wpadnij to mnie to pogadamy co i jak zoptymalizować

[M]: No dobra to spróbujemy w 4…

[J]: Super! Dzięki chłopaki!

Wnioski? Wnioski wyciągnijcie sami. Po co komuś scrumy, spotkania, analitycy biznesowi, skoro i tak Manager wie lepiej.

 

Zabawny jak programista

Dzień jak co dzień. Godzina 10, obowiązkowa część każdego dnia – „Scrum”. Programiści i testerzy prześcigają się w chwaleniu czego to nie zrobili i co będą robić dzisiaj. W tym momencie do akcji wchodzi Zbyszek:

„Wczoraj robiłem testy aplikacji na Androidzie i iOSie. Dzisiaj się będę bawił w zmianę orientacji”

No i się zaczęło. Programiści obiecali pomoc w zmianie orientacji, podsyłając odpowiednie linki, teledyski i cenne uwagi dotyczące zmiany płci. Żeby tak Bugi poprawiali w takim tempie i z takim zaangażowaniem . A biedny Zbyszek no cóż…bycie testerem czasami wymaga poświęceń.

Co w LOGACH piszczy?

Posłużmy się ciocią Wikipedią: : Log (inaczej: dziennik, plik dziennika, rejestr zdarzeń) – chronologiczny zapis zawierający informację o zdarzeniach i działaniach dotyczących systemu informatycznego, systemu komputerowego czy komputera.

Innymi słowy, jest to wymysł developerów, który ma ułatwić im życie. Jednak jak wszystko, to jakie logi maja się pokazywać, również trzeba zaprogramować.

Jakież więc było moje zdziwienie, gdy jeden z błędów zgłoszonych przez testerów brzmiał mniej więcej tak:

„Inappropriate word KURWAAAAAAAA in logs”

Faktycznie, po otwarciu można było zauważyć zrzut logów, a wśród z nich linijkę, w której programista odwołuje się do Pani, uprawiającej najstarszy zawód świata. Czy to wołanie o pomoc? Czy akt desperacji? Prawdopodobnie nigdy się nie dowiemy.

Ciekawostką jest, że błąd został znaleziony przez obcokrajowca, pracującego z lokacji poza Polską. Znaczenie słowa poznał, wpisując je w Google translate…

Czy można stopniować krytyczność błędów?

Naprawdę, krew człowieka zalewa. Na środowisku produkcyjnym wychodzi krytyczny bug, trudno, zdarza się. Programiści w pocie czoła szukają rozwiązania, testerzy lecą do szafek po iPhony i zaczynają sprawdzać.

Błędy na produkcji znajdywane są zawsze w godzinach popołudniwych bądź nocnych, kiedy ani developera ani testera nie ma już w pracy. Taka złośliwość rzeczy martwych.

Informacja od klienta: „Macie 4h na poprawienie, albo revertujemy cały feature.” Brzmi groźnie. Pierwsze uruchomienie i faktycznie bug jest. Reprodukowalny 10 na 10 prób. W tym momencie tester zaczyna zadawać sobie pytanie:

Dlaczego nie wyłapałem tego podczas testów?

Ale nie o tym chciałem pisać. Developerzy szybko znaleźli przyczynę i wypuścili fixa. Sprawdzamy, działa. Robimy więc szybką regresję. Po 5 minutach znajdujemy kolejny Bug. Krytyczny. Szybkie zgłoszenie i odpowiedź:

Tego błędu nie poprawimy teraz, bo jest mniej krytyczny niż błąd kliencki.

Mniej krytyczny? Serio, będziemy stopniować krytyczność błędów? Cała teoria testowania legła w gruzach. Fix naprawia błąd na produkcji, klient jest zadowolony, a że dodatkowo mamy innego Criticala, who cares?

Ciekaw jak się stopniuje krytyczność?

Mało krytyczny – bardzo krytyczny – w ch*j krytyczny – zajebi*cie krytyczny?

Bycie developerem to musi być przygoda…