W moim obecnym projekcie nasz scrum disaster zabronił nam estymować zadania przewidziane w sprincie na więcej niż osiem stroypointów bo "źle to wygląda w cyferkach". Wszycy więc estymujemy do 5 storypointów, a jak zadanie przeciąga się to podbijamy do 8 i więcej.
W moim poprzednim projekcie w Motoroli w KRK jak przeciągałeś zadanie powyżej 2 tygodni to lądowałeś na cenzurowanym, a jak podobny motyw był w kwartale kilka razy to requestowali o nowego kontraktora no bo ten jest "kiepski".
Sam byłem świadkiem jak podmieniano kontraktorów w jednej z firm gdzie kiedyś pracowałem aniżeli np. skupić się na "podciągnięciu" go czy dano mu czasu. Niestety często jako kontraktor musisz być jak komandos i niejednokrotnie wymagania się takie że masz wiedzieć i robić wszystko "na już". Przynajmniej ja tak zaobserwowałem.
Mógłbyś rozwinąć co to znaczyć "lądować na cenzurowanym"?
może spróbujcie nie być klepaczami do wynajęcia i poszukajcie firmy produktowej - to wiele upraszcza
jarekr000000 napisał(a):
Tacy właśnie są programiści. Możesz sobie ich nazywać nieprofesjonalnymi, ale robią robotę.
Jaką niby robotę robią? Te bugi, które trzeba potem naprawiać tygodniami? To chyba krecia robota jest.
Nie wiedząc co się robi ani po co, to dobrze można zrobić chyba tylko przypadkiem. Dla mnie to mało profesjonalne podejście. I chyba nie tylko dla mnie, bo jak widzę po narzekaniach tutaj na forum, to ludzie raczej chcieliby nie mieć bugów, za to jasno sprecyzowane wymagania co do zadań, a więc nie mają ich w dupie.
piotrpo napisał(a):
@somekind: obrońcą scruma.... piekło zgasło, raj płonie, Jakrkacz idzie w pokutnej paradzie róności...
xD
Nigdzie nie bronię scruma, po prostu stawiam mu o 180 stopni odmienne zarzuty niż padają tutaj. Scrum spowalnia, a nie przyspiesza.
Robienie bezpłatnych nadgodzin to efekt bycia nieasertywną ciapą, a nie tej czy innej metodyki.
abrakadaber napisał(a):
może spróbujcie nie być klepaczami do wynajęcia i poszukajcie firmy produktowej - to wiele upraszcza
Ale wtedy nie będzie na co narzekać. A tu przecież trzeba narzekać - jest źle, bo musi być źle, tak było za dziadów i ojców, więc nam też musi być źle.
A jak jakiś somekind pisze, że można mieć z pracy frajdę, że można nie mieć bugów, że można wiedzieć, co się robi, że można mieć zaplanowaną pracę - i na ogół ten plan wykonywać, to przecież nie ma racji - bo my wiemy lepiej, jak u kogo jest w robocie. ;)
Some, ale to Ty rozpowszechniasz, że zasady obowiązujące u Ciebie w robocie (na przykład to, że bugi da się zawsze mniej więcej estymować) przekładają się na cały świat, a nie w drugą stronę. Chyba ani jedna osoba tu nie stwierdziła, że nie ma takich poszczególnych przypadków, że da się to robić. Zanim włączysz reakcję obronną to weź po prostu jeszcze raz przeczytaj co inni piszą i co sam napisałeś, bo mi się wydaje, że tutaj w większości kwestii spornych pojawił się problem z wzajemnym zrozumieniem, a nie w różnicach w poglądach :P
somekind napisał(a):
jarekr000000 napisał(a):
Tacy właśnie są programiści. Możesz sobie ich nazywać nieprofesjonalnymi, ale robią robotę.
Jaką niby robotę robią? Te bugi, które trzeba potem naprawiać tygodniami? To chyba krecia robota jest.
Nie wiedząc co się robi ani po co, to dobrze można zrobić chyba tylko przypadkiem. Dla mnie to mało profesjonalne podejście. I chyba nie tylko dla mnie, bo jak widzę po narzekaniach tutaj na forum, to ludzie raczej chcieliby nie mieć bugów, za to jasno sprecyzowane wymagania co do zadań, a więc nie mają ich w dupie.
Nie wiem skąd ty takie wnioski wyciągasz..] wchodzisz już w erystykę - czyżby jakaś reakcja obronna?
Po pierwsze to oczywiście ludzie niektórzy może i nie chcieli by mieć bugów, ale że akurat dane było mi przećwiczyć to wiem, że zarządzenia w sprawie zakazu bugów nie działają.
A krecia robota to jest nie naprawianie bugów.
Jasno sprecyzowane wymagania co do zadań też by może chcieli mieć - natomiast praktyka jest taka, że robi się zadania bez jasno sprecyzowanych wymagań - bo część pracy programisty to te wymagania odnaleźć i spisać (resztę świetnie robi chatgpt).
Jakby osoby zgłaszające wymagania potrafiły je zdefiniować bardzo dokładnie to by klepacze byli zbędni, bo klepanie to właśnie doprecyzowanie wymagań do takiego poziomu, by głupi komputer je zrozumiał :P
@oliver_ zrób quite quitting i szukaj nowej roboty. Ten SM nie gra do Waszej bramki a liże dupe biznesowi. Toksyk, szkoda czasu.
@ToTomki: Na jakimś tam poziomie abstrakcji, to co nazywamy kodowaniem, to właśnie doprecyzowanie wymagań do poziomu rozumienia ich przez komputer.
@jarekr000000: Nie widziałem na własne oczy, ale słyszałem o "zakazie bugów", popartym zakazem zatrudniania testerów, bo jak programistom zakazano tworzenia błędów, to po co sprawdzać, czy faktycznie ich brakuje.
A nawiązując do reszty, tego co piszesz, to z mojego doświadczenia, każdy jeden projekt który upadł w mojej karierze, zrobił to z tego samego powodu: kłamstwa. Że coś zostało zrobione, a nie został.o TODO w kodzie, albo zamknięty task z towarzyszącym bugiem, żeby zdążyć z deadlinem. Albo że wiemy co ma zostać napisane, a nikt nie ma zielonego pojęcia. Ogólnie sytuacji, w której ktoś zamiast rozwiązać problem, zamiatał go pod dywan. Ekstremum, to system bankowy, który został z powodzeniem napisany, poczym wrócił od klienta po jednym dniu testów, bo działał tylko z jednym użytkownikiem na raz.
ToTomki napisał(a):
Some, ale to Ty rozpowszechniasz, że zasady obowiązujące u Ciebie w robocie (na przykład to, że bugi da się zawsze mniej więcej estymować) przekładają się na cały świat, a nie w drugą stronę. Chyba ani jedna osoba tu nie stwierdziła, że nie ma takich poszczególnych przypadków, że da się to robić. Zanim włączysz reakcję obronną to weź po prostu jeszcze raz przeczytaj co inni piszą i co sam napisałeś, bo mi się wydaje, że tutaj w większości kwestii spornych pojawił się problem z wzajemnym zrozumieniem, a nie w różnicach w poglądach :P
No niewątpliwie coś jest nie tak ze zrozumieniem tutaj. Bo ja np. nigdy nie twierdziłem, że bugi da się estymować. Kilka razy nawet temu zaprzeczyłem. A mimo to, znowu ktoś mi to imputuje. :)
jarekr000000 napisał(a):
Nie wiem skąd ty takie wnioski wyciągasz..] wchodzisz już w erystykę - czyżby jakaś reakcja obronna?
Z Twoich słów - raz piszesz o bugach, które potrafią wypełnić cały sprint, a innym razem o tym, że ludzie mają gdzieś to, co robią. Dla mnie to wygląda na dość prostą przyczynowość. Byłem tego świadkiem nie raz, jakoś nigdy ludzie, którzy mieli robotę gdzieś, nie tworzyli dobrego softu.
Po pierwsze to oczywiście ludzie niektórzy może i nie chcieli by mieć bugów, ale że akurat dane było mi przećwiczyć to wiem, że zarządzenia w sprawie zakazu bugów nie działają.
Ja nie sugerowałem nigdzie zakazywania bugów. Po prostu - jeśli rozumie się to, co się robi, to błędów jest mniej.
Jasno sprecyzowane wymagania co do zadań też by może chcieli mieć - natomiast praktyka jest taka, że robi się zadania bez jasno sprecyzowanych wymagań - bo część pracy programisty to te wymagania odnaleźć i spisać
No tak by zrobili profesjonaliści, ale po co drążyć wymagania, skoro macie je gdzieś? W moim odczuciu to, co piszesz na temat swoich doświadczeń z pracy jest jakieś takie niespójne.
Być może dzielenie się swoimi spostrzeżeniami to dla niektórych erystyka, nic na to nie poradzę. Nie wiem tylko przed czym miałbym się bronić - to nie ja mam problemy z jakością ani organizacją w robocie. :)