Wpis z mikrobloga

Cześć ludzie.
Mam w robocie kilka pobocznych projektów, które nie są głównym priorytetem. Każdy z tych projektów nie jest ze sobą powiązany i uczestniczy w nich kilku programistów z różnych zespołów. Celem tych projektów jest głównie research, PoC, samorealizacja, budowanie tooli do automatyzacji głównej pracy, albo wypełnienie nudy.
Nie ma oficjalnie przydzielonych zasobów na spędzanie czasu nad pracą w tych projektach więc nie można wymagać od programistów niczego oprócz dobrej woli.

Pytanie: Jaka metodologia pracy najbardziej się do tego nadaje?

Planuje zrobić sprinty w jirze ze zmiennym czasem trwania - czyli realizuje wszystko w sprincie i go zamykamy, niezależnie od czasu. Tracimy informacje o velocity, co i tak jest bez sensu bo zespół ciągle się zmienia i robią to ludzie z doskoku.

Co polecacie w takim przypadku?
Chce móc planować ficzery i je estymować. O koszcie sprintu informuje managera, aby wiedział ile zasobów na to pójdzie.

Dajcie jakieś rady, bo może istnieją znacznie lepsze i prostsze rozwiązania.

#programowanie #scrum
  • 7
Próbowaliście po prostu pracować?


@ToksycznySocjopata: Sam zauważyłeś, że wszystko jest losowe. Bez organizacji ludzie nawet nie wiedzą o tych projektach. Bez wyceny i namaszczenia menagera, nie mogą poświęcać zbyt dużo czasu nad tymi projektami.
To duża firma.
@ToksycznySocjopata: jaki nick taki troll

"Po prostu pracować", to sobie można jak ktoś już zorganizuje tą pracę, co OP właśnie stara się zrobić.

@WhiskyRomeo: Scrum to bardziej tworzenie produktu, a rodzaj prac na pierwszy rzut oka wygląda bardziej przypomina klasyczny maintenance, którego zwykle pakuje się w Kanbana. Ale jeśli i tak macie jakieś odcinki czasu i estymaty (bo przecież potrzeba zaplanować jakiś budżet w jakimś czasie), to ani Kanban ani
Scrum to bardziej tworzenie produktu, a rodzaj prac na pierwszy rzut oka wygląda bardziej przypomina klasyczny maintenance, którego zwykle pakuje się w Kanbana. Ale jeśli i tak macie jakieś odcinki czasu i estymaty (bo przecież potrzeba zaplanować jakiś budżet w jakimś czasie), to ani Kanban ani nawet Scrumban też nie podpasują bo tam z założenia nie ma estymat ani terminu "końca sprintu".


Trochę kontekstu: Stories są dość dobrze opisane. Pracują nad tym
via Wykop Mobilny (Android)
  • 1
@WhiskyRomeo: Kanban. Scrum w założeniach ma zaangażowanie i służy pracy w niesprecyzowanych ściśle ramach produktu, a tu macie czysto dobrą wolę co do czasu.

Robicie Kanban boarda, wszystkie dobrze opisane stories w "to do", oznaczyć zależności i niech ludzie ściągają wedle czasu i możliwości. Plus limit, niech jedna osoba nie ma zbyt wiele na "doing", np 1 story per głowa w danym punkcie w czasie. Ile głów, tyle max stories w