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.
@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.
@WhiskyRomeo: żadna. R&D w żadnym wypadku nie powinno być wrzucane w ramy scrumowe. a jak ktoś zatrudnia do działu R&D i oferuje prace w scrumie to mogę go jedynie wyśmiać...
"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
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 managerzy i seniorzy głównie. Designy, diagramy, dokumenty - jest całkiem dobrze. Brakuje gwarancji przydzielania zasobów, nie brakuje chęci do pracy. Główna robota ma priorytet i nie wiadomo kto i na ile zacznie pracować.
To bardzo ciekawa inicjatywa - często pomysły dają zwykli programiści ale nie mają doświadczenia jak to popchnąć dalej, zorganizować, zwiększyć widoczność w śród innych zespołów. Jako senior chce osadzić takiego pomysłodawcę w roli leadera - niech się realizuje.
@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
Typek z kanału "Sprawdzam jak" wyjaśniony przez widza za wrzucanie klik-bajtowych miniaturek na swoim live prezentujących zalane miasto (foto w komentarzu) #powodz #sprawdzamjak #wroclaw
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
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.
"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
Trochę kontekstu: Stories są dość dobrze opisane. Pracują nad tym managerzy i seniorzy głównie. Designy, diagramy, dokumenty - jest całkiem dobrze. Brakuje gwarancji przydzielania zasobów, nie brakuje chęci do pracy. Główna robota ma priorytet i nie wiadomo kto i na ile zacznie pracować.
To bardzo ciekawa inicjatywa - często pomysły dają zwykli programiści ale nie mają doświadczenia jak to popchnąć dalej, zorganizować, zwiększyć widoczność w śród innych zespołów. Jako senior chce osadzić takiego pomysłodawcę w roli leadera - niech się realizuje.
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