On Monday, December 31, 2018 at 11:24:46 AM UTC+1, Mateusz Bogusz wrote:
> U mnie, "sprinty" są tygodniowe. W poniedziałki i środy punktujemy
> zadania w "backlogu" (wszyscy, czyt. 20 programistów, punktacja: 1, 3,
> 5, 8, 13, 20).

Zespół scrumowy ma 20 programistów?

> W czwartki układamy kolejnego "sprinta", gdzie zawsze coś zostaje na
> koniec tygodnia i w poniedziałek rano jest przerzucane z
> poprzedniego do kontynuacji.

Ile czasu wam to wszystko około-sprintowe zajmuje? Z tego co piszesz
macie w 5-dniowym sprincie trzy dni z planowaniem -- to wygląda na
potężny narzut czasowy. (Nie mówiąc, że spotkania zwykle rozwalają
cały dzień.)

> Ogólna zasada głosi, że jak oddajesz
> zadanie do testów, to zanim weźmiesz kolejne to przetestuj chociaż jedno
> inne oddane do testów - średnio to działa, bo znalezienie błędu powoduje
> cofnięcie zadania do zrobienia, którym jego autor zajmie się po
> skończeniu aktualnego zadania więc coś co było oddane do sprinta, często
> jest "wykonane w miarę działające" trzy tygodnie później.

Przecież w ten sposób sami strzelacie sobie w głowę. :)
Priorytetem powinno być zadanie rozpoczęte wcześniej.

BTW testujecie ręcznie?

w.

do góry

>> U mnie, "sprinty" są tygodniowe. W poniedziałki i środy punktujemy
>> zadania w "backlogu" (wszyscy, czyt. 20 programistów, punktacja: 1, 3,
>> 5, 8, 13, 20).
> Zespół scrumowy ma 20 programistów?

Nikt nie używa terminu scrum, tylko że pracujemy "zwinnie". Projekt ma
oczywiście pod projekty, ale założenie jest takie żeby każdy "umoczył
palec wszędzie" (technologicznie realne, najwyżej się "douczy, to będzie
na plus w razie urlopów") z czego ma wynikać "ogólne zrozumienie
projektu i potrzeb kolegów w zespole". Także na spotkaniu część jest
biznesem dla innych, potem w innym obszarze na odwrót...

>> W czwartki układamy kolejnego "sprinta", gdzie zawsze coś zostaje na
>> koniec tygodnia i w poniedziałek rano jest przerzucane z
>> poprzedniego do kontynuacji.
> Ile czasu wam to wszystko około-sprintowe zajmuje? Z tego co piszesz
> macie w 5-dniowym sprincie trzy dni z planowaniem -- to wygląda na
> potężny narzut czasowy. (Nie mówiąc, że spotkania zwykle rozwalają
> cały dzień.)

Za dużo jak dla mnie.

>> Ogólna zasada głosi, że jak oddajesz
>> zadanie do testów, to zanim weźmiesz kolejne to przetestuj chociaż jedno
>> inne oddane do testów - średnio to działa, bo znalezienie błędu powoduje
>> cofnięcie zadania do zrobienia, którym jego autor zajmie się po
>> skończeniu aktualnego zadania więc coś co było oddane do sprinta, często
>> jest "wykonane w miarę działające" trzy tygodnie później.
> Przecież w ten sposób sami strzelacie sobie w głowę.:)
> Priorytetem powinno być zadanie rozpoczęte wcześniej.

Masz na myśli, że jak tylko zrobione wcześniej zadanie zostanie
"odbite", to traktować to tak samo jak wysypany build w CI?

> BTW testujecie ręcznie?

Jest ciągła integrację i deployment. Kilkadziesiąt jednostkowych i kilka
integracyjnych, ale wiadomo że to kropla do potrzeb.

Po nich i tak jest etap testu funkcjonalnego przez kolegę, który nie
pisał tego zadania + etap code review (przez osobę trzecią) = można
zintegrować kod na gałąź stabilną. Największy problem jest z "ciągłym
dostarczaniem".

--
Pozdrawiam,
Mateusz Bogusz

do góry