Wpis z mikrobloga

Generalnie nigdy nie byłem jakis wielkim krytykantem całego Agile, Scrum etc.
Uważałem to za „zlo konieczne”

Do czasu aż zobaczyłem jak pracuje jedna z firm z branży IT.
Naprawdę jestem w szoku do jakiego stopnia to wszystko ma żółwie tempo.
Daily 2h dziennie.
Do tego w piątki podsumowanie całego sprintu, mówienie co nam się podobało a co nie etc.

A kodowanie? Jak już kodujemy to 3 osoby robią to samo xD
Jeden koduje a trzech się patrzy.
Ja rozumiem ze pairing programming jest fajne w celach nauki etc.
No ale cholera… nie jak trwa codziennie po 4 godziny.

I wiecie co jest najgorsze?
Oni nie wiedza dlaczego to wszystko tak się wydłuża.

#programowanie #it #scrum #agile
  • 12
  • Odpowiedz
Do tego w piątki podsumowanie całego sprintu, mówienie co nam się podobało a co nie etc.


@michal_szn: akurat retro jest bardzo dobrym pomysłem i jest to czas kiedy powinieneś powytykać te wszystkie rzeczy, które wypisałeś. Gorszym pomysłem są tygodniowe sprinty, bo ile realistycznie jesteś w stanie dowieźć w tydzień? a to tylko niepotrzebnie skraca czas na kodzenie, zwiększając liczbę spotkań ¯\(ツ)/¯
  • Odpowiedz
@michal_szn tak ale gadanie może być wszędzie. To ze janusze wzięli scrum i robią 2 godzinne daily to nie znaczy ze scrum jest #!$%@? tylko janusze wycierają sobie nim mordę tłumacząc zasadność tych spotkań. O dziwo jak raz pracowałem z „prawdziwym” scrum masterem to mega pilnował żeby daily było krótkie itd.
  • Odpowiedz
@jurek-gagarin to jest częściowo prawda bo w scrumie nie ma podziału na role tylko są członkowie zespołu, ale w praktyce to bez sensu bo jak np PO ma cos zakodzic. Inaczej jak jesteś backendowcem a masz do zrobienia jedna linijkę na froncie
  • Odpowiedz
@michal_szn: klasycznie, są dwie opcje, choć warto dodać że w obu winna sytuacji jest organizacja:

1) organizacja wie co czyni, ale OP nie wie w czym bierze udział - widzimy tu jakieś elementy Scruma, XP, tylko że OP ich nie rozpoznaje

2) organizacja nie wie co czyni więc i... OP nie wie w czym bierze udział, bo... widzimy tu jakieś elementy Scruma, XP ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@michal_szn: Znają narzędzia, ale źle ich używają. Jak we wszystkim potrzebny jest balans.

Daily (czyli planowanie jednego dnia) powinno trwać 15 minut. Pair programming też jest forma nauki, ale moim zdaniem to głównie sposób zwiększania jakości i rodzaj synchronicznego code review. Dobrze działa w połączeniu z TDD, ale te niepiszące osoby muszą myśleć, bo inaczej to też strata czasu. Dodatkowo trzeba pamiętać, że nie do każdego typu zadania pasuje, nie każdy
  • Odpowiedz
@Zavis: Najlepiej jest bez tych durnych sprintów. :) Kiedyś na retro w moim zespole postanowiliśmy zrobić eksperyment i zrezygnowaliśmy ze sprintów, ze story pointów. Już wtedy braliśmy małe zadania (max kilka dni pracy), więc postanowiliśmy co dwa dni na daily zastanowić się co następne dorzucić do listy następnych rzeczy do zrobienia (bo już nie sprintu). Obecnie jeżeli zajdzie taka potrzeba, gdy wiemy, że jakieś zadanie się skończy, zastanawiamy się co następne,
  • Odpowiedz
  • 0
@bb89: znam ludzi z backendu ktorzy nie pojda nawet jednej linijki kody zrobic przy frontendzie, bo mowia "placa mi za bycie backendowcem a nie full stackiem" i maja po czesci racje... Tak jak ktos pisal, zawsze liczy sie jakis balans jednak..
  • Odpowiedz
@michal_szn: spoko ale niezrobienie najprostszej rzeczy poza swoim stanowiskiem jest slabe dla mnie. Rozumiem jakby backendowiec nagle dostawal 50/50 taski z frontu i backiem, ale karta "nie placa mi za to" jest slaba. Wlasnie o to chodzi miedzy innymi w scrumie zeby dowozic jako zespol czyli masz moce przerobowe to pomagasz gdzie mozesz, od tego jest code review zeby to sprawdzic. A jakby szanownego backendowcowi powiedziec zeby napisal pare testow e2e
  • Odpowiedz