Proaktywność w sprincie/zespole/pracy

3

Tak z ciekawości zakładam wątek, żeby dowiedzieć się jakie u Was jest ciśnienie na "proaktywność".

Co jakiś czas podczas daily/retro ktoś rzuca tekstem, że ludzie są za mało "proaktywni" z różnych powodów. A u mnie z tym jest mega ciężko z racji na mój charakter (introwertyk i to mocny, nie lubię się dużo wypowiadać i wychodzić przed szereg), przez co mam wrażenie, że irytuję kilku ludzi^^

Jak jest daily w sprincie, to w sumie każdy członek zespołu raz na jakiś czas prowadzi je, udostępnia ekran z taskami i jedzie kolejno pytając się jak idzie praca. Na początku zwykle jest pytanie "kto chce prowadzić" i znajduje się chętny. Ja się póki co od tego wymiguję, ale zakładam, że może to być źle postrzegane powoli.

Gdy jest jakieś retro, to wrzucamy własne karteczki z opisem co było dobrze/źle/co przestać robić w sprincie, itp. Ja zwykle tego nie robię, bo po prostu nie mam pomysłów. A potem każdy kolejno to czyta. I jak jest moja kolej na podsumowanie sprintu z mojej perspektywy, to zwykle mówię jedno zdanie, że jest ok. I tyle. Wolę się skupić na programowaniu a nie innych rzeczach, które mnie w sumie niezbyt interesują.

Ludzie wychodzą często z własnymi propozycjami jakichś rzeczy/usprawnień. Np. kolega z teamu wyszedł z propozycją spotkań stricte dla zespołu backendowego by rozmawiać o taskach. Póki miał czas, to spotkania się odbywały. Ale nikt inny prócz niego nie chciał się tym zajmować, więc zdechło, co się koledze niezbyt podobało, że inni to olewają.

Często jak jest rozmowa o jakimś procesie (np. jego usprawnieniu), to nie mam swojego zdania i mówię, że się dostosuję. Bo nawet nie mam pojęcia co miałbym powiedzieć (baa, nawet nie mam pojęcia o czym gadają xD).

Plus masa innych sytuacji, gdzie zwykle jestem jedynym, który nie bierze aktywnego udziału w dyskusji.

Ja tam zawsze wolałem się skupić na swoich taskach, a inne rzeczy mnie zwykle mało obchodzą. A nawet stresują. I chyba jestem złym człowiekiem :P Najchętniej bym po prostu kodził, robił swoje i tyle.

Dodatkowo zdarza się, że spotkania zajmują 1/3 tygodnia, ja bym najchętniej wywalił je w cholerę, albo nie chodził na nie wcale.

55

Miałem takie cyrki w poprzednim projekcie i szybko z niego zrezygnowałem. U mnie pojawiło się jeszcze pojęcie "dojrzałości korporacyjnej" pod płaszczykiem proaktywności :D Owszem, trzeba się komunikować w projekcie bo bez tego nie da się efektywnie rozwijać projektu. Jednak jak dla sm'a czy innego dziwaka włączają się jakieś odklejki to zapala mi się czerwona lampka. Dla mnie praca to 8h - Mam wykonać swoją robotę i elo, pora na cs'a. Jak komuś mało proaktywności i obowiązków to niech sobie po godzinach dłubie a nie przekłada swoje fiksacje na innych.

0
ledi12 napisał(a):

Miałem takie cyrki w poprzednim projekcie i szybko z niego zrezygnowałem. U mnie pojawiło się jeszcze pojęcie "dojrzałości korporacyjnej" pod płaszczykiem proaktywności :D Owszem, trzeba się komunikować w projekcie bo bez tego nie da się efektywnie rozwijać projektu. Jednak jak dla sm'a czy innego dziwaka włączają się jakieś odklejki to zapala mi się czerwona lampka. Dla mnie praca to 8h - Mam wykonać swoją robotę i elo, pora na cs'a. Jak komuś mało proaktywności i obowiązków to niech sobie po godzinach dłubie a nie przekłada swoje fiksacje na innych.

Nie no, projekt jest spoko, ludzie też. Dużo można się nauczyć, sporo nowych rzeczy. A praktycznie wszyscy mają większą wiedzę i zawsze skorzy do pomocy. Więc nic tylko korzystać.

SMa nie ma. Był przez jakiś czas, ale klient z niego zrezygnował, więc sami prowadzimy sobie scruma.

Część teamu, która jest bezpośrednio od klienta jest mocno wygadana (Holendrzy, itp.), a część teamu z mojej firmy jest mniej wygadana, zwłaszcza ja.

Jak mam coś do zakomunikowania, to to komunikuję. Chociaż nie zdarza się to często. A zwykle mam wrażenie, że jakbym się skupił na taskach zamiast brać udział w dyskusjach jak co usprawnić, to dużo lepiej by to wyszło.

9

Dla mnie to jest naturalne by dawać swoje propozycje. Lubię mieć jak największy wpływ na wszystko i usprawniać procesy by wszystko szło lepiej.

2

Jeśli ktoś pyta jak idzie praca to to już sugeruje status, a nie daily i to jest sprzeczne ze scrumem. Na daily tylko mówicie co będziecie robić w okresie do kolejnego daily i wyłapujecie zależności, jak zależność jest - dogadujecie się do szczegółów PO daily.
Jeśli omawiacie "jak idzie praca" na daily (które dosłownie kilka minut trwać powinno) to znaczy to tyle, że nie będziecie mieli co omawiać na kolejnych spotkania (czy to review i czy retro), więc nic dziwnego, że potem na retro siedzisz cicho. No bo co masz powiedzieć jak już wszystko jest powiedziane?

2

Też tak miałem na początku przygody z programowaniem. Po prostu byłem zbyt mało doświadczony by dostrzegać to co można zrobić lepiej. Z czasem przegiąłem w drugą stronę: narzekałem na zbyt wiele rzeczy i zbyt wiele propozycji rzucałem.
Uważam, że jak ktoś nie ma żadnych uwag na retro to:

  • projekt jest prowadzony lepiej niż jego doświadczenie (rzemieślnik nie będzie pouczał mistrza)
  • ma wszystko w d.
ToTomki napisał(a):

Jeśli ktoś pyta jak idzie praca to to już sugeruje status, a nie daily i to jest sprzeczne ze scrumem.

hm, wg mojego rozumowania scruma na daily każdy mówi 3 rzeczy:

  • co robił wczoraj
  • z czym ma problemy
  • co będzie robił dzisiaj
2

@serek:
No widzisz, więc ludzie mówią o tym, że się nic nie dzieje nowego. Albo taski sobie przerzucacie razem na boardzie. Przecież to absurd. Boarda to powinniście updatować jak jest okazja to updatowania (czyt. wykonasz zadanie), a nie czekać na jakieś dziwne spotkanie. Bardzo pragmatycznie tam macie. Potem jest

@LitwinWileński:
No to się statusujecie. Ja nie mówię, że to źle, bo to zależy od projektu. Po prostu to nie jest scrumowe. W scrumie zakłada się samoorganizację zespołu i rozłożenie odpowiedzialności za zadania na zespół, a nie na jakieś dziwne procesy, w tym przypadku poranny rytuał. Kiedy masz coś zrobić - robisz. Spotkania mają tylko naprowadzić na wychwytywanie zależności między osobami, czy to chodzi o dokonane w ramach sprintu zmiany, czy problemy, ale nie kontrolować ich na każdym etapie, bo to nie jest scrum tylko zespołowa inwigilacja jednych członków zespołu przez pozostałych na jakimś okrągłym stole.

Ja sam jakimś super zwolennikiem scruma nie jestem, ale jak ja widzę takie opisy spotkań to ja się nie dziwię, że ludzie hejtują scruma, bo jak się pracuje w jakiejś jego karykaturze to można mieć odruch wymiotny na samą myśl o danej organizacji pracy. Sam miałem kilku scrum masterów. W więcej niż jednym zespole scrum mastera odsunęliśmy, bo pracę sabotował. Nawet SM często nie znają Scruma, więc easy, zrozumiałe.

0

Mój guru od zdrowego programowania mówi tak (od 3:45 do 4:00):

więc albo Ty się mylisz @ToTomki albo on

7
serek napisał(a):

Tak z ciekawości zakładam wątek, żeby dowiedzieć się jakie u Was jest ciśnienie na "proaktywność".

Co jakiś czas podczas daily/retro ktoś rzuca tekstem, że ludzie są za mało "proaktywni" z różnych powodów. A u mnie z tym jest mega ciężko z racji na mój charakter (introwertyk i to mocny, nie lubię się dużo wypowiadać i wychodzić przed szereg), przez co mam wrażenie, że irytuję kilku ludzi^^

wtedy weź spytaj tego gościa co ma na myśli, i dalej drąż temat aż mu się odechce rzucać takich tekstów a Ty się wykażesz proaktyrnością

4

Wszystko jest umowne. Istnieje negatywna jak i pozytywna proaktywność. Negatywna to taka, która szkodzi zamiast pomagać np. ktoś chce być "fajny" i wymyśla rzeczy z d**y, żeby wyglądało to tak, że coś robi. Pozytywna to oczywiście taka, która daje wartość dodaną np. jak pracujesz nad jakimś taskiem i w czasie pisania ogarnąłeś, że coś da się zrobić inaczej przez co oszczędzisz czas albo zrobisz coś lepiej niż jest teraz

serek napisał(a):

Ludzie wychodzą często z własnymi propozycjami jakichś rzeczy/usprawnień. Np. kolega z teamu wyszedł z propozycją spotkań stricte dla zespołu backendowego by rozmawiać o taskach. Póki miał czas, to spotkania się odbywały. Ale nikt inny prócz niego nie chciał się tym zajmować, więc zdechło, co się koledze niezbyt podobało, że inni to olewają.

Jak nikt się nie przekonał to raczej mamy przykład słabej proaktywności, niektórzy coś przeczytają w internecie i próbują to wdrożyć nawet jak dla większości brzmi to jak bezsens

3

Ja nie wychodzę z jakimiś inicjatywami, totalnie nic. Robię tylko taski i nic więcej ponieważ jestem szeregowym programistą, dowożę wszystko na czas więc nie ma problemów. Jeżeli mam wychodzić z własnymi inicjatywami i tymi podobnymi rzeczami to wtedy podniósłbym głos aby mnie awansowali na Leada czy coś takiego i podnieśli stawkę.

2

@crx: nigdy nie zostaniesz leadem odwalając tylko swoją robotę i się nie udzielając, powiem więcej odwalając tylko to co ci każą i się nie udzielając to z mida będzie ci ciężko wyjść.

4
ehhhhh napisał(a):

powiem więcej odwalając tylko to co ci każą i się nie udzielając to z mida będzie ci ciężko wyjść.

Przesada. Zawsze można się od razu zatrudnić na seniora :D

Być proaktywnym i wychodzic ze swoimy pomysłałi. No fajnie, ale jak jestem zawalony robotą to myślę tylko o tym jak się ze spintem wyrobić. Jak ktoś ma czas być proaktywnym to pewnie za mało tasków dostał do sprintu do zrobienia :P

0

@KamilAdam: jak jest spotkanie na temat dalszych prac, podejścia do architektury konkretnego modułu lub jak rozwiązać konkretny problem i siedzisz tam cicho bo nie masz żadnych pomysłów to kiepski z Ciebie senior.

10

Słowo "proaktywność", rzucane przez Scrum Mastera w korpo, to w 99% korpo-bzdura. Wywieranie presji na ludziach, żeby na siłę wymyślali jakieś problemy i gadali o nich na retro, to absurd, często pozwalający przykryć prawdziwe problemy, których nie ma co zgłaszać, bo wszyscy o nich wiedzą, a nikt nie wie jak rozwiązać. W rezultacie np. nie da się załatwić licencji na potrzebne narzędzie, czy dostępu do jakiejś usługi potrzebnej w projekcie, to zamiast tego ktoś forsuje pomysł, żeby w trakcie retro pisać do na zielonych karteczkach, a don't na czerwonych, powstaje action item, żeby te karteczki załatwić i po długich bojach z zaopatrzeniem. zatwierdzaczami itp. na następnym retro można pisać te wnioski na kolorowych karteczkach i odnotować "sukces". Jak taki rak się rozrośnie, to ludzie czują się przymuszeni do wymyślania jakichś głupot, żeby być "proaktywnymi", co skutkuje, że wymyślane są coraz większe głupoty, byle tylko sprostać wymaganiu "proaktywności". Jako, że pierdoły typu kolor karteczki nie mają żadnego znaczenia, to dyskusje nad tym trwają wieczność, bo każdy chce się wykazać "proaktywnością", a bike shredding jest okazją pozbawioną ryzyka.

3

Na poprzednim projekcie miałem takiego kolegę, który był taki proaktywny że jak miał blocker w swoim zadaniu (musiał czekać na odpowiedź od kogoś) to dobierał się do czyjegoś innego zadania bez pytania czy ktoś nad tym pracuje czy nie i je kończył równolegle a niekiedy przed daną osobą wyrzucając taką osobę z tego zadania. Wtedy ta osoba nie miała co robić więc brała jego zadanie. W momencie jak przyszła odpowiedź na jego pytanie to był koniec sprintu, zadanie przepisane na osobę która miała inne zadanie prawie zrobione, taka sytuacja.
Więc tamta osoba nie dowiozła a on dowoził, w oczach ProductOwnera i ScrumMastera złoto nie programista.
Zresztą pomimo scrum mastera w zespole i pod jego obecność często i tak prowadził standup.

3

Ogólnie te całe proaktywności w korpo w otoczce Sprintów, Scruma, gadanie o efektywności, estymatach, zwiększaniu wydajności to tylko dokręcanie śruby Developerom.

Jednak stara się z tego wszystkiego zrobić w pewnym sensie religie ze względu że jak Dev zacznie w to brnąć to nawet sobie sprawy nie zda że to tylko służy do jak największej jego eskploatacji.

Czym to się wszystko różni od brania taska z backlogu i na kiedy się zrobi to się zrobi i da się do review tak jak było to dawniej?

W środowisku branżowym na zachodzie coraz bardziej widzę że ludzie otwierają oczy i widzą że Scrum to narzędzie służące do jak największego zniewolenia programisty.

2
crx napisał(a):

Czym to się wszystko różni od brania taska z backlogu i na kiedy się zrobi to się zrobi i da się do review tak jak było to dawniej?

Pobawię się w adwokata diabła i zapytam w jaki sposób przedstawić klientowi estymację kosztową i czasową dostarczenia produktu jeżeli podejście ludzi do zadań jest "na kiedy się zrobi to się zrobi"?

Wyobrażasz sobie chłopa który przychodzi zrobić remont łazienki i na pytanie na kiedy będzie gotowe to odpowie "Na kiedy się zrobi to się zrobi. Może za dwa tygodnie, a może za trzy miesiące. Work life balance mordo!" :P I proszę bez odpowiedzi w stylu "nie porównuj remontu łazienki do tworzenia softu bo to inny rodzaj pracy".

5

Jesteś mi w stanie powiedzieć jak długo Ci zajmie napisanie wiersza po niemiecku?

Niestety sporo zadań w IT to są tego typu zadania tylko przełożone na inną płaszczyznę.

Bo z tego co ja widzę że właśnie za pomocą Scruma w IT stara się upchać tego typu zadania w 2 tygodniowych iteracjach. Tylko problemem jest to że potem Devowie robią nadgodziny, mają problemy zawodowe jak wypalenie i tym podobne. Do tego jeszcze dojdzie osoba jak Scrum Master która Ci będzie dawała rady "jak pracować efektywniej".

2

Czy jestem proaktywny? To zależy.
Otóż gdy jest do zrobienia coś, co mnie technicznie rozwinie i naucze sie przy tym coś nowego, wytężę mózg na jakiejś ciekawej rozkminie lub uwazam ze wplynie to na mnie pozytywnie w jakimkolwiek stopniu, to jak najbardziej.
Natomiast nie zgłaszam się nigdy po zadanie, które absolutnie nic nie wniesie w mój rozwoj gdy jest to np doslownie wyklepanie wg schematu tego co sie juz robilo 100x i nic tam odkrywczego sie nie moze zdarzyc.
Nie zgłaszam sie rowniez gdy robienie zadania bedzie wymagalo duzo synchronizacji i wyjasnien/ustalem z osobami slabymi lub nietechnicznymi. Przewaznie w takiej sytuacji nie wiadomo do konca co klient/business stakeholder chce i taka sytuacja zmieni sie w serie głupich calli, ustalen, denerwowania i potem do konca zycia tej funkcjonalnosci jest sie za nia odpowiedzialnym, wciaganym na głupie calle itd na wlasne zyczenie.

4
crx napisał(a):

Jesteś mi w stanie powiedzieć jak długo Ci zajmie napisanie wiersza po niemiecku?

Tak jak myślałem. Sprowadzanie roboty programisty do pracy artysty. Dla mnie to zwykła robota, nie mająca nic wspólnego z artyzmem. Już nie róbmy z siebie nie wiadomo kogo. Byli programiści jako inżynierowie, potem rzemieślnicy, teraz artyści.

Poza tym nie chcę cię zmartwić ale artyści też mają swoje kontrakty w których zobowiązują się do wydania albumu/singla/napisania książki, cokolwiek i jeżeli nie spełnią tego warunku to w najlepszym wypadku płacą karę a w najgorszym zrywany jest kontrakt z wydawcą/wytwórnią, co też może przełożyć się na karę pieniężną. Dlatego często albumy zawierają dwa trzy hity a reszta to wypełniacze żeby dopchać płytę na czas.

Poza tym nie odpowiedziałeś mi na pytanie:

w jaki sposób przedstawić klientowi estymację kosztową i czasową dostarczenia produktu jeżeli podejście ludzi do zadań jest "na kiedy się zrobi to się zrobi"?

Co do reszty twojego posta to problemem nie jest scrum sam w sobie, tylko sposób w jaki jest on implementowany.

3
crx napisał(a):

Jesteś mi w stanie powiedzieć jak długo Ci zajmie napisanie wiersza po niemiecku?

Przecież artystów w IT to zaledwie kilka % całości (a w Polsce na oko to będzie z 53 osoby), w dodatku często po godzinach pracy. Mało kto robi artystyczne rzeczy, wymyśla algorytmy czy robi technologię, programuje libki, udziela się w open source. IT to prawie w całości (w polsce w szczególności) to składanie gotowych klocków. Składanie klocków zgodnie z instrukcją w sposób, w jakie już wcześniej były ułożone identycznie przez 1000 osób.
Moja praca to siedzenie na dupie i udawania, że interesują mnie te spotkania. Po spotkaniach biorę dokumentacją/tutorial i zmieniam val orderId = orderService.getOrder().getId() na val reservation = reservationRepository.getReservation(userId). I taka prawda, wymyślenie algorytmu jest raz na kilka lat, przejście po grafie to wyjątek, a nie regularny dzień.
Mało kiedy jesteś artystą i wymyślasz coś na nowo, coś oryginalnego. Przez większość życia robisz coś co zostało już zrobione, tylko co najwyżej inaczej to nazywasz. Odnosząc się do Twojej analogi - ściągasz wiersz z neta i zmieniasz kilka słów.

Programiści mogą być artystami po pracy, jak robisz coś swojego albo bawisz się w open source. Inna sprawa, że pracodawcy chcą magików od JVMa do robienia crudów (i co dziwne czasami za takich płacą).

1
markone_dev napisał(a):

Pobawię się w adwokata diabła i zapytam w jaki sposób przedstawić klientowi estymację kosztową i czasową dostarczenia produktu jeżeli podejście ludzi do zadań jest "na kiedy się zrobi to się zrobi"?

Pracując w agile "nie da się". Agile nie wychodzi z założenia poza koniec sprintu. Jak masz duży projekt to wszsytko co jesteś w stanie dostarczyć to jakieś SWAGi oparte na własnych doświadczeniach i robieniu prostytutki z matematyki. Jeżeli ktoś szacuje pracochłonność/czasochłonność projektu z budżetem kilku baniek na podstawie SP dostarczonych przez zespół, to prosi się o kłopoty, bo właściwie z góry wiadomo, że w idealnych warunkach i przy masie pracy poświęconej na szacowanie błąd będzie +-50% Podejście ludzi nie ma moim zdaniem znaczenia, bo nie da się "spieszyć" pisząc oprogramowanie.Możesz co najwyżej nie marnować czasu. Jak wyznaczysz czajnikowi o określonej mocy deadline na zagotowanie wody, to nie będzie to miało żadnego wpływu na jego pracę. Chcesz coś zmienić, to albo musisz mieć czajnik (zespół) o większej mocy, albo zweryfikować cele i zamiast litra wlać 3/4.

0
piotrpo napisał(a):
markone_dev napisał(a):

Pobawię się w adwokata diabła i zapytam w jaki sposób przedstawić klientowi estymację kosztową i czasową dostarczenia produktu jeżeli podejście ludzi do zadań jest "na kiedy się zrobi to się zrobi"?

Pracując w agile "nie da się". Agile nie wychodzi z założenia poza koniec sprintu. Jak masz duży projekt to wszsytko co jesteś w stanie dostarczyć to jakieś SWAGi oparte na własnych doświadczeniach i robieniu prostytutki z matematyki. Jeżeli ktoś szacuje pracochłonność/czasochłonność projektu z budżetem kilku baniek na podstawie SP dostarczonych przez zespół, to prosi się o kłopoty, bo właściwie z góry wiadomo, że w idealnych warunkach i przy masie pracy poświęconej na szacowanie błąd będzie +-50% Podejście ludzi nie ma moim zdaniem znaczenia, bo nie da się "spieszyć" pisząc oprogramowanie.Możesz co najwyżej nie marnować czasu. Jak wyznaczysz czajnikowi o określonej mocy deadline na zagotowanie wody, to nie będzie to miało żadnego wpływu na jego pracę. Chcesz coś zmienić, to albo musisz mieć czajnik (zespół) o większej mocy, albo zweryfikować cele i zamiast litra wlać 3/4.

Zgadza się, ale ja nie pytałem w kontekście Agile, Scrum, Kanban, Waterfall, Prince2, cokolwiek.

Kolega crx napisał, że u niego pracują na zasadzie "na kiedy będzie to będzie" bez wskazywania konkretnej metodyki. Przecież nawet w Agile stosuje się szacowanie w obrębie sprintu tak jak napisałeś, ale wciąż się estymuje.

Więc podtrzymuję swoje pytanie jak przekazać klientowi informację o koszcie i czasie trwania projektu z takim podejściem ("na kiedy będzie to będzie") w dowolnej metodyce prowadzenia projektu.

0
markone_dev napisał(a):

Więc podtrzymuję swoje pytanie jak przekazać klientowi informację o koszcie i czasie trwania projektu z takim podejściem ("na kiedy będzie to będzie") w dowolnej metodyce prowadzenia projektu.

Chyba trochę mieszasz różne sprawy. Kolega pisał o jednym tasku w ramach swojego zespołu, a nie o konkretnej funkcjonalności/części programu, która może obchodzić klienta. Jeśli twoja umowa każe ci się spowiadać, na kiedy będzie przesunięty przycisk, zmiana koloru albo zrobiony refaktor jakiejś klasy, no to coś poszło nie tak z twojej strony i następnym razem lepiej skorzystać z innego prawnika

3

@tmk3: umowa? eeeee powiedzenie klientowi na kiedy dostanie takie poprawki to normalne i sam jako klient bym tego wymagał od profesjonalnej firmy.

2
markone_dev napisał(a):

Kolega crx napisał, że u niego pracują na zasadzie "na kiedy będzie to będzie" bez wskazywania konkretnej metodyki. Przecież nawet w Agile stosuje się szacowanie w obrębie sprintu tak jak napisałeś, ale wciąż się estymuje.

Mój błąd, utożsamiłem "agile" ze Scrumem. Estymujemy zadania, nawet przykładając się do tego. Główny cel to upewnienie się, ze wszyscy w zespole rozumieją co ma zostać zrobione w ramach tej jednostki wymagań, z grubsza jak. Patrząc na dłuższe zadania i historyczne tempo ich wykonywania mogę wskazać, ze "pewnie będzie za rok, może półtora". Jeżeli jakaś wymaganie jest faktycznie pilne, to informuję wszystkich, że jest pilne, mówię dlaczego jest pilne i umieszczam je na górze backlogu, żeby zostało wykonane w pierwszej kolejności, przed zadaniami, które tak pilne nie są. Klient dostaje informację, że szacujemy dostarczenie tej funkcji aplikacji na jakiś tam dzień i będziemy go informować, jeżeli ta prognoza ulegnie zmianie.
Nie stosujemy za to jakichś bieda-psychologicznych sztuczek z "commitmentem", jak zespół wiedział, że coś jest potrzebne i nie zdążył, to był jakiś powód, np. zadanie było niedoszacowane, ktoś się rozchorował, zdechł mu chomik, albo dałem d..y nie przewidując, że zadanie może być bardziej złożone niż mi się wydawało i nie ostrzegłem zespołu. Koniec końców, wolę, żeby jakieś zadanie "spadło" niż zostało zrobione źle i 3 razy wracało od klienta do poprawki (tester nie miał już czasu sprawdzić, albo ograniczono jego proaktywność podpięciem akumulatora do wrażliwych części ciała).

Pomimo, że zdarza mi się szydzić ze SCRUM'a w wersji korporacyjnej, to jestem wręcz fanatykiem agile :) Wiem też, że pracuję z dorosłymi profesjonalistami, wiedzącymi, że kasa na ich koncie pojawia się, bo klient dostaje to czego potrzebuje.

Więc podtrzymuję swoje pytanie jak przekazać klientowi informację o koszcie i czasie trwania projektu z takim podejściem ("na kiedy będzie to będzie") w dowolnej metodyce prowadzenia projektu.

Zwyczajnie, staram się być maksymalnie szczery i dosadny w komunikacji. Jeżeli nie wiem kiedy będzie, to mówię, że nie wiem kiedy będzie. Za tydzień będę miał jakieś zgrubne szacunki. Wszystko co mogę zrobić, to zagwarantować, że ważne dla niego zadanie zostanie wykonane jako pierwsze, przed mniej pilnymi.

0
tmk3 napisał(a):
markone_dev napisał(a):

Więc podtrzymuję swoje pytanie jak przekazać klientowi informację o koszcie i czasie trwania projektu z takim podejściem ("na kiedy będzie to będzie") w dowolnej metodyce prowadzenia projektu.

Chyba trochę mieszasz różne sprawy. Kolega pisał o jednym tasku w ramach swojego zespołu, a nie o konkretnej funkcjonalności/części programu, która może obchodzić klienta.

Co mieszam. Na funkcjonalność składa się wiele tasków. Więc jeżeli estymacja tych tasków jest na zasadzie "na kiedy będzie to będzie" to nie da się wyestymować funkcjonalności/estymacja będzie niedokładna.

Jeśli twoja umowa każe ci się spowiadać, na kiedy będzie przesunięty przycisk, zmiana koloru albo zrobiony refaktor jakiejś klasy, no to coś poszło nie tak z twojej strony i następnym razem lepiej skorzystać z innego prawnika

Niczego takiego nie mam w umowie, ale nigdy bym nie chciał pracować z ludźmi którzy robią zadania na zasadzie "na kiedy będzie to będzie". Jak to brzmi w ogóle z ust specjalisty IT? :D

Jak oddajesz auto do serwisu, albo kompa do naprawy to też akceptujesz podejście serwisu "na kiedy będzie to będzie"?

Wiadomo, że estymacje są z definicji niedokładne, ale dlatego są nazywane estymacjami. Nie znaczy to jednak, że nie należy estymować w ogóle. WTF, co ja w ogóle muszę tłumaczyć...

2
markone_dev napisał(a):

Jak oddajesz auto do serwisu, albo kompa do naprawy to też akceptujesz podejście serwisu "na kiedy będzie to będzie"?

Jeżeli usłyszę "nie wiem kiedy uda się to naprawić, bo nie wiem co się stało, sprawdzę to zobaczymy ile zajmie naprawa, ściągnięcie części itd." to zwykle akceptuję taką odpowiedź. Jestem w stanie zrozumieć, że ktoś czegoś w danej chwili nie wie.

Wiadomo, że estymacje są z definicji niedokładne, ale dlatego są nazywane estymacjami. Nie znaczy to jednak, że nie należy estymować w ogóle. WTF, co ja w ogóle muszę tłumaczyć...

Wytłumacz to specjalistom od SCRUM'a Którzy najpierw wycisną z ciebie podanie jakiejś wartości z d...y, a później pieprzą o commitmentach, bo im burndownchart brzydki wyjdzie.

1

@piotrpo: ojojojoj to do jakiego ty mechanika jeździsz? Mój jak nie wie to zawsze mi najpierw mówi kiedy dokładnie zadzwoni z informacją co jest i co dalej będzie robił. Więc w dniu oddania auta zawsze mam estymację ile potrwa badanie i generalnie zawsze tego samego dnia dostaję informacje co jest i ile potrwa naprawa, więc tak estymacja nawet na analizę od mechanika jest standardem i to nawet w małych warsztatach. Bo np mój obecny mechanik nie ma pracowników.

Natomiast w dużych serwisach też wiedza kiedy bo wpisują ciebie w grafik i przydzielają pewna ilośc godzin, tym samym w takim warsztacie wiesz w dniu oddania ile zapłacisz za samą diagnostykę.

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