@GutekSan: zarzucasz mi nieprawdę, ale w sumie nie wiem w czym, bo gdzieś musiałbym skłamać, a nie widzę gdzie w Twoim poście.
W pierwszej wersji chciałem Ci zarzucić nie "nieprawdę" a po prostu "bzdury", z tym że nie chciałem zaogniać tej dyskusji i zastąpiłem to słowo pierwszym lepszym eufemizmem, który mi przyszedł do głowy. Faktycznie, trudno przypisać obiektywną prawdę czy nieprawdę stwierdzeniom: scrum to defokusacja od biznesu albo wyciąganie ludzi z zespołów jest pożądane, natomiast bliżej im po prostu do zwykłych bzdur. Nie uznaję tych bzdur jednak jako przejaw głupoty, bardziej chęci pokazania zabawnej i prowokacyjnej kontrowersyjności.
Co do ZUSu, na UOP opłaca go za mnie pracodawca, z tym że nie wiem co to ma do dyskusji o retro.
Z czego ten ZUS pracodawca płaci? Z restrospektywy się magicznie kasa generuje?
Trochę tak. Tyle, że tyle w tym magii ile w pętli sprzężenia zwrotnego w układach elektronicznych, albo filtrze Kalmana. Retrospektywa to nie jest zebranie, tylko spojrzenie wstecz na proces i decyzje z odpowiedniego dystansu, znając już przynajmniej częściowo konsekwencje podjętych działań. Pozwala wprowadzić korekty do procesu, który samoistnie dryfuje od wyznaczonego celu. A szybsze czy pewniejsze osiągnięcie tego celu, to zazwyczaj w biznesie oznacza więcej kasy.
Dla mnie ważnym elementem satysfakcji z pracy jest poczucie, że:
- zarabiam odpowiednio dużo pieniędzy
- nadal opłacam się pracodawcy
Tyle, że te rzeczy zapewniasz sobie przez odpowiednią negocjację na wejściu i rzetelną pracę, na co dzień nie musisz się tym martwić. Za to istnieje szereg czynników, które mają wpływ na satysfakcję z pracy, a które trzeba cały czas kontrolować:
- poczucie sensu wykonywanej pracy
- relacje z kolegami
- styl zarządzania (np. micromanagement)
- brak przeszkód i różnego typu dystraktorów
- tematyka zgodna z wewnętrznymi zainteresowaniami
- możliwość rozwoju
Jeśli ich nie ma lub są słabe, satysfakcja leży i kwiczy, choćby się zarabiało gar złota. A do kontrolowania tych czynników służy właśnie retro.
Właściwie czyj punkt widzenia reprezentujesz w tej dyskusji? Pracownika czy pracodawcy? Mam wrażenie, że tego drugiego. Bo zatrudnianie ludzi to nie jest problem pracownika.
Jestem pracownikiem, ale zajmuje się czasem zatrudnianiem ludzi. To chyba normalne. To jest mój problem, jak nie zatrudnię dobrych ludzi to będę musiał pracować z pierdołami.
Nie zajmujesz się zatrudnianiem, co najwyżej rekrutowaniem. A jeśli Cię to boli to dopisz to sobie do mojej listy powyżej, i masz kolejny argument by zachować retro. I pamiętaj też, że nie chodzi tylko o to by zatrudniać dobrych, ale i o to by dobrych nie stracić, a brak satysfakcji do tego prowadzi.
W żadnej z nich przestój na 2 -3 tygodnie tylko dlatego że jakiś zespół ma cele sprintu, to raczej nie jest normalna sprawa. W biznesie 3 tygodnie to czasem bardzo długo. Przeważnie nie, ale bywają 3-4 akcje w roku, że jednak.
Ale o czym w ogóle mówimy? O wprowadzania nowego produktu na rynek czy o utrzymaniu istniejącego? Bo przy wprowadzaniu 2-3 tygodnie to jest nic. Zwłaszcza, że te 2-3 tygodnie to najgorszy scenariusz (zmiana pojawia się zaraz po zaplanowaniu, a to stosunkowo łatwo naprawić). W praktyce średnio taki przestój wynosiłby tydzień.
Ale oczywiście, bywa że trzeba zrobić coś na już, bo nie działa. Tyle, że z faktu że trzeba to zrobić, nie wynika np. kto ma to zrobić. Np. zamiast odrywać od zadań kogoś czyje cele są naprawdę ważne, można kazać gasić pożary komuś, kto się akurat nudzi.
IMO Waterfall został wymyślony przez Scumowców, aby zdefiniować jakiegoś wroga. Tak jak bolszewicy wymyślili kułaków, chociaż ich prawie w Rosji nie było.
Waterfall był, tylko pewnie nie aż tak wypaczony, jak to Agile prezentuje. Objawem Waterfalla jest np. rozdzielenie na dział developmentu i dział testów. Ja pracowałem w takim systemie.
Mieliśmy różne procesy iteracyjne (spiralny) z cyklami - miesiąc, 2 miesiące (wzorowane na bieda RUP, który też był mitycznym procesem), różniły się tym od Scrumu, że nie było tyle straty czasu na spotkania :-)
Ale w mojej opinii Scrum nie oznacza spotkań. Spotkania są tam, gdzie organizacja jest wewnętrznie zbiurokratyzowana i się w nich lubuje. Jakbyś zlikwidował Scrum i wprowadził dowolną inną metodykę, spotkania i tak tam pozostaną. Ot, taka mentalność. U mnie bywało różnie, obecnie nie mam prawie wcale spotkań wynikających ze Scrumu (poza 5-10 minut daily, sprint planningiem i godzinnym retro raz na miesiąc).
I nieważne jakie były te cykle i plany to nagłe wrzutki i tak były i były normalne. Zmienialliśmy kilka razy plany prawie z dnia na dzień, pracując dla całkiem konserwatywnych banków (jeden miał nawet zawsze plan 10-letni (!)).
No więc i tak pracowaliście w Agile'u, tyle że nie nazwanym. Przecież to jest właśnie esencja Agile'u - szybka reakcja na zmiany. Cała reszta (Scrumy, Kanbany, itp) to po prostu pewne standardy łączenia możliwości szybkiego reagowania z realizacją długotrwałych celów.
Dodam jeszcze, że to że wrzutki są, nie oznacza, że są normalne. Generalnie dużo rzeczy da się przewidzieć, i wystarczy niewiele by zła wrzutka stała się dobrym elementem backlogu. A nawet jeśli nie da się ich uniknąć, można poprawić sposób w jaki są zarządzane.
Sytuacja A: Masz zadanie, które zajmuje trochę czasu - miesiąc, może 2. Zdążyłeś się wgryźć, przychodzi kierownik i mówi: rzuć to i leć gaś pożar gdzie indziej. Wracasz, musisz się na nowo wgryzać, w międzyczasie coś się pozmieniało. A potem Cię pytają: czemu Twoje zadanie idzie opieszale
Takie akcje to dla mnie normalka, tylko, że żaden kierownik nie pyta mnie czemu idzie opieszale, bo jak przyszedł powiedzieć rzuć i leć gaś pożar to powiedziałem, że tak będzie. Btw. miałem dokładnie taką rozmowę w tym tygodniu we wtorek.
Bywa, że kto inny mówi: 'rzuć to i leć gaś pożar', a kto inny mówi: 'rób swoje zadanie'.
Pisałem już kiedyś, że jak zespół jest dobry to i scrum mu nie przeszkodzi. To dotyczy prawie dowolnej metodyki. Również chyba tej na żywioł.
To są mrzonki. W praktyce nie spotkałem się z taką sytuacją. Nawet jak masz zespół samych gwiazd to jakiś standard pracy jest potrzebny, może zwłaszcza tam.
Agile poznałem w 2007 i stracznie się zajarałem.
A ja przeciwnie. Najpierw myślałem: "czego oni oczekują? że będziemy znać się na wszystkim? Do pewnych branż Scrum po prostu nie pasuje". Z czasem zobaczyłem, że dzięki temu lepiej rozumiem nad czym pracuję, bo nie jestem zamknięty w swojej bańce, a wszystko szło efektywniej.
Tyle, że przez wiele lat trafiałem na firmy gdzie ten agile było wypaczany (korpo agile/korpo scrum, błedy i wypaczenia). Moja wiara, jakkolwiek, pozostała silna. System dobry, tylko ludzie nie dorośli. I dopiero w Szwajcarii (dla mnie niedawno) trafiłem do zespołu, który robił praktycznie scrum by the book. Dopiero wtedy zrozumiałem, że to naprawdę wielka strata czasu.
Tyle, że wg mnie właściwy scrum to właśnie ten "wypaczony" scrum, a właściwie nie "wypaczony" tylko "przycięty do potrzeb". Scrum "by the book" jest dla nowicjuszy, którzy pierwszy raz o nim słyszą, więc się im pokazuje wszystko co mają do dyspozycji. Ale z czasem każda organizacja czy nawet zespół go dostosowuje pod siebie. Im dłużej pracuję w Scrumie, tym jest mniej nacisku na scrumowe obrzędy, za to pozostaje filozofia Agile i podstawowe narzędzia do kontroli postępu prac. U mnie nie ma sprint goali, velocity, pokera, regularnych demo. W innych zespołach wciąż widzę niektóre z tych elementów, ale może im to pasuje.
Scrum "by the book" jest jak Kata w sztukach walki. Ćwiczy się to, ale jeśli ktoś będzie chciał to zastosować na ulicy przeciw 3 zakapiorom, to jest debilem. Scrum "by the book" jest jak danie żołnierzowi pełnej zbroi, miecza, topora, szabli, mizerykordii, rapiera, pistoletu, kałasznikowa, M40, M134, granatnika i łuku, i wrzucenie na pole walki. W 10 minut załamie się pod ciężarem tego wszystkiego, ale jak sobie wybierze co mu odpowiada, będzie efektywny.