Wpisy z tagiem: 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".

rozumiem, dzieki

@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.

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

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