Scrum, sprint, jak pogodzić implementacje i testy

1

Wiem, że wiele osób tutaj nie popiera Scruma, Agile i innych podobnych wynalazków. Sam nie jestem ich zwolennikiem, no ale przyszło mi z nimi pracować, a czego nie lubie jeszcze bardziej to siedzieć dupogodziny, stąd ten temat.

Mamy projekt rozwijany od kilku miesięcy w typowym Scrumie. Początki były dość ciężkie, dowoziliśmy po dosłownie kilka % zaplanowanych story pointsów, z powodu wielu różnych zewnetrznych czynników, z którymi musieliśmy się uporać, jednak obecnie większość problemów jest już za nami, a MVP dla family & friends jest już na produkcji. Poza tym, wstępna implementacja obejmowała stworzenie kilku dość generycznych i konfigurowalnych komponentów, które teraz po prostu musimy reużyć by zaimplementować kolejne wymagania. Oznacza to, że pierwszy taki komponent implementowaliśmy przykładowo 5 dni i na jego dokładne przetestowanie (przez manualnych testerów) schodziły 3 dni. Teraz, gdy mamy już gotowy szkielet, implementacja nowego komponentu to 2 dni + 2 dni na testy

Prowadzi to do następującej sytuacji:

  • zaczynamy sprint, wszyscy mają co robić bo testerzy muszą dokładnie rozpisać wszelkie przypadki testowe, a developerzy zaczynają implementacje
  • po mniej więcej dwóch dniach kończymy implementacje pierwszych story i oddajemy je na testy
  • w międzyczasie poprawiamy ewentualne błędy z oddanych tasków i oddajemy kolejne zadania
  • mija +/- 75% sprintu, zaczynają się kończyć zadania developerskie, teoretycznie jedyne co mamy do zrobienia to poprawa ewentualnych błędów

No i co wtedy?

  • jeżeli weźmiemy całe story z backlogu, to go nie dowieziemy, braknie czasu na implementacje + przetestowanie.
  • jeżeli weźmieny tylko implementacje, a testy przełożymy na kolejny sprint, to znowu na początku przyszłego sprintu będzie problem, developrzy będą oddawać kolejne taski, a testerzy będą sprawdzać i ewentualnie zgłaszać bugi ze sprintu poprzedniego
  • jeżeli nie zrobimy nic, testerzy pracują do końca sprintu, a my mamy wolne. W teorii super, w praktyce, osobiście wole mieć coś do robienia niż udawać, że pracuje

Zdaje sobie sprawę z najprostszej możliwej odpoowiedzi - "wywalić Scruma", aczkolwiek niestety nie wchodzi to w grę :/

7

Pomijająć oczywistą odpowiedź, która nie działa, bo partia komunistyczna zabroniła wywalać Scruma (mimo, że jak soft jest na produkcji to trzymanie się Scruma jest debilne średnie.)

jeżeli weźmiemy całe story z backlogu, to go nie dowieziemy, braknie czasu na implementacje + przetestowanie.
No i co się wtedy stanie? będzie pluton egzekucyjny?
Czy może spadnie wam velocity, bo paradoksalnie !!! więcej zrobicie (tylko nie domkniecie).
Czy też jak spadnie velocity to przyjdzie policja scrumowa i będzie pluton egzekucyjny?

2
AngryProgrammer napisał(a):

No i co wtedy?

  • jeżeli nie zrobimy nic, testerzy pracują do końca sprintu, a my mamy wolne. W teorii super, w praktyce, osobiście wole mieć coś do robienia niż udawać, że pracuje

Czemu od razu udawać że się pracuje? Można się doszkalać i oglądać filmiki na YT z konferencji np

Swoją drogą JDG wygląda tu jak skrzyżowanie czarnego papieża i ostatniego władcy ognia

6

Bierzesz dalszy task z backloga i tyle, co za problem? o_O Ten task wejdzie do nowego sprintu a ty będziesz miał head-start. Nie bardzo rozumiem gdzie coś nie działa.

Niemniej dla mnie cały ten wasz setup jest zrypany, bo macie krzywe definition of done. Task jest done jak masz automatyczne testy e2e działające na CI. Dopóki tego nie ma, to task nie jest "dowieziony". Mam nadzieje zresztą że to właśnie robią ci wasi testerzy -> piszą te testy e2e. Więc nie ma takiej sytuacji że zaczyna sie nowy sprint a testerzy zaczynają zgłaszać bugi do ficzerów które niby są "dowiezione". Bo skoro były dowiezione, to już powinny wszystkie przechodzić testy na zielono.

0
AngryProgrammer napisał(a):

Zdaje sobie sprawę z najprostszej możliwej odpoowiedzi - "wywalić Scruma", aczkolwiek niestety nie wchodzi to w grę :/

A jak wywalisz scruma, to będziesz automagicznie wiedział czy to, co dowiozłeś jest dobre, czy niedobre bo testerzy doklikają się do bugów? No nie będziesz wiedział

A sami testerzy testują tylko nowe rzeczy, czy sprawdzają też czy nie popsuliście starych? Jak nie sprawdzają, to skąd wiesz czy w międzyczasie czegoś nie od-wieźliście? :)

A jak żmudnie testują coraz więcej scenariuszy, to nie sparaliżuje wam to po pewnym czasie pracy - albo przez to, że testerów przerośnie kolejka rzeczy do sprawdzania, albo przez to że po jednym sprincie lista rzeczy od-wiezionych będzie dłuższa, niż dowiezionych?

5
Shalom napisał(a):

Bierzesz dalszy task z backloga i tyle, co za problem? o_O Ten task wejdzie do nowego sprintu a ty będziesz miał head-start. Nie bardzo rozumiem gdzie coś nie działa.

Od razu widać, że nie pracowałeś w scrumie. :P
Nie można brać oficjalnie tasków z przyszłości, bo po pierwsze nie można rozszerzać zakresu sprintu, a po drugie burndown chart ma zejść do zera. Efektem pracy programisty w scrumie nie jest działający kod czy inne takie nikomu niepotrzebne pierdoły tylko burndown chart.

superdurszlak napisał(a):

A jak wywalisz scruma, to będziesz automagicznie wiedział czy to, co dowiozłeś jest dobre, czy niedobre bo testerzy doklikają się do bugów? No nie będziesz wiedział

Jak wywali scruma, to nie będzie musiał dowozić w ramach sprintu, a po zakończeniu taska będzie mógł swobodnie brać następny.

@AngryProgrammer: nie udawaj, że pracujesz, po prostu nie pracuj. Po pierwsze ze scrumem nie wygrasz, a po drugie pracę trzeba szanować.

0

W ex firmie wyglądało to tak:

a) programiści oddają kod do testów
b) wykonywanie testów przez testerów (2 - 7 dni w zależności od wielkości tematu)
c) w czasie b) kod powinien być zamrożony, a programiści tylko naprawiać zgłoszone bugi, uzupełniać dokumentację, wspomagać testy pod kątem inżynierskim (dopisanie kroków w automatach, jakiś poprawki w środowisku testowym itd.) - w praktyce byli programiści, którzy potrafili przez cały dzień nic nie zrobić i się kręcić między kawą i papierochem przez 8h i fajrant.

Jeżeli nie ma żadnych pierdółek do zrobienia podczas etapu zamrożenia kodu, typu właśnie dokumentacje, środowiska, pomoc dla testerów, to wypadałoby zgłosić kierownikowi projektu, liderowi itd., bo to oni dają tu d**y, że pracownicy nie mają co robić. To jest głupie zarządzanie i marnowanie czasu. A z mojego nikłego doświadczenia już wiem, że takie udawanie, że coś się robi potrafi bardziej zmęczyć niż pracowanie.

2

Dlatego ja zawsze wolałem podejście Kanban Board + tory per feature. Wtedy nie ma sprintu per se, tylko każdy feature zmierza od fazy analizy do wdrożenia/DoD (definition of done). Planowanie w takim wypadku nie wymaga zaangażowania całego zespołu tylko podzbioru osób które nad danym feature'em będą pracować. Gdy dana funkcjonalność przejdzie w fazę testów (a zakładam że i tak programiści napiszą unit testy i testy integracyjne), a programista nie ma co robić to może rozpocząć pracę nad kolejną funkcjonalnością.
PS: Żeby to dobrze działało musi być położony duży nacisk na kończenie już zaczętej roboty zanim zacznie się robić nowe rzeczy. Działa dobrze jak masz seniorski zespół.

W Scumie zazwyczaj pracowałem w takim trybie że programiści testowali ile się da i nie czekali na zielone światło od QA, a zespół testerów działał niezależnie i bugi zgłaszał asynchronicznie. Założenie było takie że zgłoszone problemy to raczej proste sprawy typu NullPointer a nie że trzeba przemodelować logikę lub że brakuje połowy funkcjonalności.

1

Nie bardzo widzę z czym masz problem : P Tak jak napisał @somekind, nie dokładasz nowych rzeczy z backlogu, jeżeli nie zostały one zatwierdzone na sprint planningu, bo inaczej nigdy nie dowieziecie sprintu do końca. I też to o czym pisze @Shalom, jakie jest wasze definition of done? Jaki macie cel na dany sprint? Skoro go wykonaliście to tylko się cieszyć.

Jeżeli rzeczywiście zostaje wam wolny czas w sprincie, to albo na sprint review ustalcie, że możecie wziąć więcej tasków na kolejny sprint, albo doszkalaj się w wolnym czasie, albo (tak jak u nas), przeglądaj istniejący kod w celu refaktoringu na przyszłość. Nie koniecznie musisz go refaktoryzować teraz, ale możesz wrzucić zadania do backlogu, które zrobisz później. Minimum te 20% czasu, każdego sprintu czy co drugiego, warto poświęcić nie na nowe rzeczy, a wlaśnie na refaktoring.

1

Jak ci Scrum (czy cokolwiek) narzuca robienie czegoś głupiego, to olej to (Scruma, czy co tam). Wiem, że najczęściej najmniej zwinnym członkiem zespołu jest Scrum Master / Mistress, ale trzeba ich sobie wychować.

Robicie swój plan, zostało ci trochę czasu w sprincie, to bierzesz się za:

  • dług technologiczny - unit testy, ostrzeżenia z Sonara, refaktory, poprawki i usprawnienia w pajplajnach, wszystko co przeszkadza w bieżącej pracy i może cię kopnąć w przyszłości
  • douczasz się
  • robisz jakieś story z następnego sprintu, nie wciągając go do sprintu
    Jak SM ma z tym jakiś problem, to spuszczasz go na drzewo bo wszystko co to może zaburzyć, to "velocity" w krótkim czasie, później się wyrówna. Warunek: trzeba popracować nad podzieleniem historyjek na drobne fragmenty. Im drobniej tym lepiej. Spodziewasz się, ze wpadnie scrumowa inkwizycja i zrobi ci kuku, bo przez 3 dni coś zrobiłeś, zamiast się opierdalać?

Trzymanie manualnych testerów w 2021 roku jest już mocno vintage. W tym przypadku jest też głównym powodem występowania problemu.

1 użytkowników online, w tym zalogowanych: 0, gości: 1