Bardzo fajny tekst nt scruma. Jak słusznie zauważył autor, to nie metodyka jest problemem ale jej błędna implementacja.
Z jednej strony chcą być zwinni ale z drugiej chcą pracować jak dotychczas. To się niestety często nie udaje. Jeżeli taki PO nie ma wpływu na produkt i jest tylko dziewczynką do odbierania zamówień to z czym do ludzi?
Podobnie jest z developerami, którzy mają często z góry nałożone to z czego trzeba korzystać...Dostają też dedline ustalony przez osoby biznesowe, które nie mają o tym żadnego pojęcia.
Pytanie tylko czy inna metodyka rozwiąże problem? No moim zdaniem nie, bo i ona zostanie zgłwałcona i używana niezgodnie ze swoim przeznaczeniem.
https://bulldogjob.pl/news/1674-czy-to-juz-rzeczywiscie-koniec-scruma
Sprawdź, dlaczego Scrum staje się coraz mniej popularny wśród specjalistów, a nawet całych organizacji.
https://bulldogjob.pl/news/1674-czy-to-juz-rzeczywiscie-koniec-scrumahttps://www.scrumguides.org/scrum-guide.html
Nowe wytyczne dla scruma xD W tym perełki:
Scrum Masters are true leaders
#scrum
@Afish jeżeli mam zespół X pracowników pracujących wyłącznie nad zadaniem Y, to szansa na zakończenie zadania do dnia Z wynosi P%", a nie jakieś opowieści, że coś zajmie "X godzin".
jaka różnica? tu i tu się strzela że coś się uda zawsze mnie bawi, jak programiści uznają swoją pracę za tak niepowtarzalną, że aż nie da się oszacować skali trudności.
to że od strony technicznej taski są banalne / robione nty raz wcale nie oznacza że od np. zdobycia know how biznesowego nie było to czasochłonne. Usłyszysz zadanko przepchać dane z systemu A do B i pomyślisz 5h roboty + na oglądanie kotów w necie starczy, a miesiąc później dalej nie skończone :D
@WeiXiao: jaka różnica? tu i tu się strzela że coś się uda
Jeżeli patrzysz z perspektywy osoby technicznej, to nie ma różnicy, ale osoby nietechniczne słysząc "to zajmie X godzin" traktują to jako pewnik. Tak samo jak programista słyszy "czy da się to zrobić do X", to w głowie szuka argumentów na udowodnienie "niemożliwe jest zrobienie tego do X", więc nawet jak szansa jest mała, to potwierdzi, pewnie czymś w rodzaju "no tak, da się, jeżeli będziemy mieli wymagania itp itd", a druga strona wtedy słyszy "do X będzie zrobione". To jest tylko przykład mechanizmu, żeby mi tu ktoś nie wrzucał zaraz argumentów "a ja wcale tak nie słyszę", jedynie pokazuję różnicę w komunikacji przez zastosowanie ekstremum. Ale jeżeli przedstawisz wycenę jako "mając X ludzi pracujących tylko i wyłącznie nad Y, to szanse na zrobienie do Z wynoszą P", to wtedy przekaz ten jest o wiele bardziej klarowny (szczególnie, jeżeli P jest rzędu dziesięciu procent).
Usłyszysz zadanko przepchać dane z systemu A do B i pomyślisz 5h roboty
- tu świetnie widać, że mówimy o różnych rzeczach. Masz oszacować skalę trudności, a nie liczbę godzin. Skala trudności siłą rzeczy wymaga punktów odniesienia, więc musisz umieć uargumentować, że najprostsze było zadanko A polegające na czymś tam, najtrudniejsze było zadanko Z polegające na czymś innym, a to obecne zadanko to umlaut. To jest zgodne z wiedzą tłumu (bo w ogólności ludzie w zespole prawdopodobnie zgadzają się co do stopnia skomplikowania) i to spokojnie można oceniać grupowo. Teraz jeżeli chcesz przetłumaczyć poziom trudności na liczbę godzin, to musisz mieć przeliczniki uwzględniające skomplikowanie systemów A i B, umiejętności inżyniera pracującego nad zadaniem, liczbę okolicznych świąt, okres wakacyjny i masę innych rzeczy. Jeżeli zadanka A i Z dotyczą tych samych systemów, to przelicznik będzie dokładniejszy (i można tam dodać jakiś dodatkowy mnożnik odpowiadający za "bo system A to dinozaur i używa jakiejś pogańskiej corby"), dodatkowo dodajesz próg niepewności ("bo system B może używać jakiegoś własnego szyfrowania i nagle się okaże, że trzeba to dekompilować") i wreszcie przekazujesz biznesowi informację "jak będę pracował tylko nad tym, to na P procent zajmie to T tygodni". Co więcej, prostsze zadanie może zająć więcej czasu, przykładowo "poprawienie dokumentacji" jest zapewne mało złożone, ale bardzo czasochłonne.
No i na samym końcu wracamy do faktu, że to tylko szacunki. To nigdy nie będzie precyzyjne (a szacowanie przez eksperta jest w praktyce często chybione), są inne metody na planowanie projektów (chociażby Monte Carlo i szukanie ścieżek krytycznych), ale ciągle da się to robić i można na tym opierać plan pracy. Tylko trzeba to robić sensownie, a nie estymować w godzinach zadanie bez wymagań, a potem dziwić się, że zamiast pięciu godzin było pięćdziesiąt.
Dlaczego mam płacić za Scrum Mastera
Kiedy do akcji powinien wkroczyć Scrum Master i dlaczego Product Owner nie może go zastąpić
#blog #IT #technicalblog #programowanie #scrum
Niby scrum master OK, ale gdy pojawiają się w teamie problemy to ani scrum master ani kierownik nie pomoże, tylko zamiatanie pod dywan, bo nikt nie chce problemów widzieć, a jak ty widzisz problem, to podejście, że to ty masz problem. Szkoda gadać, można wydać fulll kasy na scrum masterów, konsultacje z agile itp itd a ludzi zostawić samych z ich problemami. Taka patologia, gdzie liczą się pozory a nie realne działania i zdrowy rozsądek.
Najlepiej zatrudnić dwóch i patrzeć jak się zabijają próbując pokazać którego scrum jest bardziej scrumowy i który jest bardziej agile
wrzuciłem to do komentarza pod wpisem na mikroblogu, ale wrzucam tu jeszcze, by nie umknęło.
Napisałem wpis o tym dlaczego Scrum i cały Agile zaczęły zniechęcać i przeszkadzać osobom, którym miał pomagać
Moje przemyślenia znajdziecie o tu: https://developer20.com/why-do-many-people-say-that-scrum-is-a-bullshit/
#developer2.0 #scrum #agile
Dokształcanie się jest bardzo ważne w każdej pracy. W obszarze IT jest to jednak szczególnie istotne. Ciągle pojawiają się bowiem nowe rozwiązania i trendy, w których należy się orientować, aby być cenionym specjalistą w swojej dziedzinie. Wszelkiego rodzaju dodatkowe certyfikaty i szkolenia są zatem mile widziane przez pracodawców.
Będąc cenionym pracownikiem uważam,że warto zagłębić się w metodologię scrum,bo daje ogromne możliwości. Pozdrawiam i zachęcam doo zapoznania się z artykułem na ten temat tutaj -> http://www.ekoodnawialni.pl/b[...]zkolenia-z-metodologii-scrum
@kevin_sam_w_domu: wiem wiem, spędziłem trochę ponad rok w takich klimatach ;) Aczkolwiek taki "reset" warto byłoby zrobić - nawet nie z przeświadczeniem jakiejkolwiek misji, ot po prostu celem szerzenia wiedzy innej niż ta "ludowa".