Programozóként egyszerre csak egy, vagy több projekten is dolgoztok?

#20

Szerintem semmit. Jó, ez gonosz volt.

A legtöbb "probléma" általában abból adódik, hogy sokan nem ismerik ezeket a fogalmakat, hogy mi mivel jár stb, ezért sokszor csinál olyat a scrum master, ami nem a feladata és így vegyülnek a role-ok.

Két alkalom van, amikor a scrum master-nek több dolga lehet. Amikor először bevezetik az agile módszertant, illetve innovation sprint alatt.

Ahhoz pedig hogy tisztában legyen a fogalmakkal, módszerekkel, mi hogy működik, tényleg jó lehet 1-2 training. Én pl. fejlesztő vagyok, de nekem is van SAFe certificate-em, mert az egyik training-jüket megcsináltam (részben mert a cég fizette).

Visszatérve az eredeti kérdésre, ha csak scrum master-i feladatokat látnak el, és nem több, nagy csapattal foglalkoznak, akkor elég valószínűletlen, hogy teljes állású scrum master-ek kellenek, de egyébként fel tud halmozódni sok minden, ha sok csapat van. (A konkrét feladatokat a fentebbi linken láthatod.)

Nem tudom milyen méretű csapatokról van szó nálatok, viszont az elmondottak alapján én egy olyan változtatást eszközölnék, hogy a teljes állású scrum master-eket kitenném, max egyet hagynék mondjuk valami guide-nak vagy hogy ő vezesse az ART-ot. A scrum master-eket csapatokból választanám ki, és helyette PO-kat vennék fel.

#22

Attól függ miről kell PPT-t készíteni. Mondjuk minden csapatnál velocity-t számolni és ezeket bemutatni Inspect&adapt meeting-en lehet scrum master feladata. Az I&A meeting-et az RTE vezeti, aki hasonló szerepet tölt be, mitn a scrum master-ek, csak eggyel "magasabb" szinten, szóval ez a role annyira nem áll a scrum master-ektől messze.

[link]

De igen, a szerepkörök vegyítésével elérhető, hogy teljes állású scrum master-ek legyenek, ami egyébként nem baj, tényleg sok szerep van, ami elfér egymás mellett és időben külön-külön nem lenne teljes állás.

Arra érdemes figyelni, hogy ne kerüljenek össze egyébként egymásnak ellentmondó szerepek, pl. PO és valamilyen fejlesztő (vagy scrum master).

A PO-nak azért elég alap szinten kell csak megértenie, hogy mi kell. A PO-nak nem kell érteni, hogy hogyan működik a program, csak annyit - új item szempontjából -, hogy mi lenne az elérendő cél. Ez pedig kb. az, amit a customer mond.

Tehát kb. annyira kell megértenie, hogy ilyen template-eket ki tudjon tölteni:

[link]

Ezután kapja meg egy architect (vagy team, mert csapat is kidolgozhatja igazából), aki a teljes item-et kisebb részekre bontja, kidolgozza, hogy melyik item-mel mit kellene csinálni, és ezeket kapják meg a team-ek.

A team meg megbecsüli.

A leírásod alapján te inkább az architect szerepkört élvezed, mintsem a PO feladatot. Hogy egyszerűen bemutassam a különbséget. A PO a "what" kérdésre ad választ, míg az architect a "how"-ra.

A különbség, ami miatt pedig nem ajánlott, hogy a PO-nak business szempontokat kell szemelőtt tartania, míg egy fejlesztőnek szakmai szempontokat. A kettő pedig ütközhet. Ha egy személy tölti be ezt a két szerepet, akkor problémás lehet ilyen esetekben, hogy a legjobb döntés szülessen.

[link]

[link]

A customer mondja meg, hogy mit kell csinálj és nem a PO. A PO közvetíti ezt, de neked a feladatod ezt követni. Azt, hogy hogy csináld, te találod ki (csapat vagy achitect).

Mivel lefelé nem szokás váltani, ezért két út áll előtted:

1) fizetésemelést kérsz.

2) munkahelyet váltasz.

#3 érdekes hogy nem tudtál rá jobb kifejezést, miközben rögtön utána le is írtad:

"egyszerre csak egy dologban tudok elmélyülni"