@Marcys32 Mam podobną sytuację, którą opisałem tutaj: Kiedy zespoły zaczynają się kanibalizować Widziałem nawet, że się wypowiedziałeś w moim wątku. Postaram się zrobić mały update tego co udało mi się od tamtego czasu poprawić i co mi w tym pomogło.
Szanuję @jarekr000000 za dzielenie się techniczną wiedzą, natomiast osobiście uważam to co pisze na temat agile'a za szkodliwe. Z tego co pamiętam, kiedyś w jednym wątku napisał, że jednym z jego sukcesów na retrospektywach było zlikwidowanie retrospektyw. Z mojego doświadczenia retrospektywy są właśnie narzędziem walki z patologiami. Przez ponad pół roku zgłaszałem swoje uwagi opisane w poprzednim temacie, między innymi to, że część zespołu pracuje w weekendy i kluczowe zmiany kodu są przepychane w bardzo słabej jakości bez żadnego review w weekendy, ale też kilka innych rzeczy. Kiedy miarka się przebrała, porozmawiałem z kilkoma osobami z którymi przez cały ten okres omawiałem te rzeczy. Następnie opisałem konkretne przypadki i zaraportowałem to do szefa osoby, która wpływała tak patologicznie na część zespołu. Szefowie tamtej osoby czytali nasze retrospektywy i przyznali mi rację. Tamta osoba została persona non grata w naszym zespole, a ja tylko umocniłem swoją pozycję.
W moim wątku większość osób mówiło, że jedynym rozwiązaniem jest zmiana pracy. Wydaje mi się, że wiele osób celowo odwraca głowę w takich sytuacjach bo boi się konfrontacji. W rzeczywistości rozsądnej firmie zależy na tym, żeby miała dobrą opinię i nie będzie tolerowała patologii. Są też firmy, które nastawione są tylko i wyłącznie na zysk i tam nikt nie liczy się z tym czy opinia firmy jest dobra bo jeżeli wypłyną brudy to firma krzak się po prostu zwinie. Ja swoją obronę przygotowywałem przez prawie rok i wyciągnąłem swoje działa w odpowiednim momencie po odpowiednim rozeznaniu. Twoja sytuacja może być inna, ale obrona zawsze jest podobna. Musisz najpierw przygotować sobie grunt, tzn. zacząć rozmawiać o konkretnych problemach.
Wszyscy będą zadowoleni: programiści dostają bonusy, menadżerowie dostają bonusy (bo zepoły dostarczyły więcej sp). Win/win.
@jarekr000000 Raczej lose/lose i niezrozumienie tego do czego służą estymaty. Estymaty nie są dla programistów tylko dla managerów. Jedyne co powinien robić programista to estymować zadania zgodnie z prawdą, obowiązującą skalą i metodologią. Jeden zespół zrobi 200 sp w sprincie, drugi 20. To nie znaczy, że ten co robi 200 jest lepszy. Każdy zespół ustala własną skalę według której szacuje zadania. Te szacunki są właśnie po to, żeby product owner w trakcie sezonu urlopowego był w stanie oszacować ile zespół jest w stanie dostarczyć i żeby później product owner mógł powiedzieć, że zostało dowiezione wszystko co zostało zadeklarowane. To jest właśnie zarządzanie. Jeżeli product owner wymusza na zespole zrobienie większej ilości story pointów niż wynika to z prędkości zespołu to po prostu zespół tego fizycznie nie jest w stanie dowieźć bez nadgodzin. Nadgodziny są dodatkowym kosztem w budżecie projektu i ktoś odpowie za ten koszt. Jeżeli programiści robią bezpłatne nadgodziny, że dostarczyć wymuszone przez product ownera zadania to znaczy, że ktoś tutaj nie umie zarządzać.