Köszönöm a kérdést! Igen, sőt. Én a csapataimmal addig bontogatom a feladatokat, amíg csak lehet. Ideális esetben max. 8 KÉ-s alfeladatok szintjére érdemes bontani. A kivitelezőkkel közösen kell gondolkodni, hogy ki az, aki esetleg meg tudja oldani 55 KÉ alatt, vagy kinek van ötlete arra, hogy 55 KÉ milyen feladatokból épül fel és csoportokra kell bontani. A másik oldalon a megbízóval érdemes egyeztetni, hogy az elvárt célt, vagy egyszerűsítse, hogy beleférjen egy adott sprintbe, vagy vállalja, hogy 2-3 sprint alatt fog elkészülni az adott kérés. Remélem tudtam segíteni :)
Kedves Kristóf! Amikor a BA hibákat észlel, vagy módosítani szeretne a DEMO (sprint végén tesztelésre átadott, ha jól értem a definíciót) funkcióin, akkor azt hogyan tervezi be a PO, hiszen közben már zajlik esetleg egy másik sprint?
Releváns kérdés, köszönöm. A DEMO az már tesztelt és működő funkcionalitások demonstrációja a megbízó, vagy termékmenedzser felé. A csapattagok ilyenkor megmutatják, hogy az általuk sprintben elvégzett feladatok milyen eredménnyel zárultak. A tesztelés tehát a sprint része, amit erre dedikált ember végez. Ha a tesztelés akkora problémát tár fel, ami megkérdőjelezi a funkcionalitást és hátráltatja a többi feladatot, akkor ez a kiértékelés és a demo tematikája lesz. Új igények és észrevételek bekerülnek a backlogba és újra keresztülmennek a becslési rituálén. Ha "bug"-ról, vagyis hibáról van szó, ami blokkol valamilyen funkcionalitást, vagy felhasználói élményt, akkor azok automatikusan a legmagasabb prioritást kapják. Ez már egyéb folyamatbeli protokollokat érint, amik a RETRÓ-k tematikájába tartoznak. Remélem tudtam segíteni.
Köszönöm Kristóf a gyors válaszod! Még egy kérdésem lenne: Az 55 KÉ értéket hogyan lehet megbecsülni? Van erre valami ököl szabály? Gondolom ez az érték nagyban függ a csapat méretétől, szakértelmük szintjétől stb. Még az is számíthat, ha valaki épp egy sprint alatt szabadságon van, beteg lesz stb. Hogy lehet ezt ügyesen modellezni? Köszönöm.
Jó a kérdés! A becslések helyessége szokott lenni az első, amit új csapattagoknál, vagy csapatoknál igyekszek optimalizálni. Ami nekem sokszor bejött az az volt, hogy a csapattal közösen felállítottunk egy szempontrendszert kb. az alábbi kérdések mentén: Csináltam már ilyet? Kell hozzá segítség? Kutatást igényel? Kísérletezgetést igényel? Ellenőriznie kell valakinek? Érint egyéb komponenst? A válaszok alapján meghatározzuk először a legegyszerűbb feladatot (1 KÉ) aztán a legnehezebbet (55 KÉ) és minden mást a kettő közé lövünk be. A szempontrendszer mindig attól függően bővül, vagy csökken, amit a kivitelezés folyamata megkíván. A csapat sebességét 3-5 sprint átlagából szoktam meghatározni. Az elején általában alulbecsülnek, aztán túl, de az 5. sprintre általában normalizálódik. A csapattagok egyéni teljesítmény statisztikái befolyásolják a sprint KÉ sebességét. Egy idő után látható lesz, hogy egy Senior Full Stack fejlesztő képes teljesíteni egyedül azt, amit két másik medior egy sprint alatt. Ha elmegy szabira, akkor az ő sebességének az átlaga esik ki. Ezért érdemes a csapatokat párosítva összeállítani. Ez a példa igaz bármilyen szerepkörre, ahol szerepet játszik a terhelhetőség, tapasztalat és gyakorlat. Az értékpontok meghatározásához értelemszerűen az üzleti életben társulnia kell munkaóráknak, mert legtöbbször az elszámolások a munkaórák alapján történnek, de most erre nem térek ki, mert ennek a kalkulációja és az értékpontok azonosítása már egy hosszabb téma. Tervben van ez is, de nagyon lassan haladok. Remélem tudtam segíteni!
Szuper videó, Köszi!!!
Ha a csapat sebessége 55, de van egy olyan feladat amit 55 fölé értékel a kivitelező,akkor azt célszerű max 55 KÉ részekre bontani?
Köszönöm a kérdést! Igen, sőt. Én a csapataimmal addig bontogatom a feladatokat, amíg csak lehet. Ideális esetben max. 8 KÉ-s alfeladatok szintjére érdemes bontani. A kivitelezőkkel közösen kell gondolkodni, hogy ki az, aki esetleg meg tudja oldani 55 KÉ alatt, vagy kinek van ötlete arra, hogy 55 KÉ milyen feladatokból épül fel és csoportokra kell bontani. A másik oldalon a megbízóval érdemes egyeztetni, hogy az elvárt célt, vagy egyszerűsítse, hogy beleférjen egy adott sprintbe, vagy vállalja, hogy 2-3 sprint alatt fog elkészülni az adott kérés. Remélem tudtam segíteni :)
Kedves Kristóf! Amikor a BA hibákat észlel, vagy módosítani szeretne a DEMO (sprint végén tesztelésre átadott, ha jól értem a definíciót) funkcióin, akkor azt hogyan tervezi be a PO, hiszen közben már zajlik esetleg egy másik sprint?
Releváns kérdés, köszönöm. A DEMO az már tesztelt és működő funkcionalitások demonstrációja a megbízó, vagy termékmenedzser felé. A csapattagok ilyenkor megmutatják, hogy az általuk sprintben elvégzett feladatok milyen eredménnyel zárultak. A tesztelés tehát a sprint része, amit erre dedikált ember végez. Ha a tesztelés akkora problémát tár fel, ami megkérdőjelezi a funkcionalitást és hátráltatja a többi feladatot, akkor ez a kiértékelés és a demo tematikája lesz. Új igények és észrevételek bekerülnek a backlogba és újra keresztülmennek a becslési rituálén. Ha "bug"-ról, vagyis hibáról van szó, ami blokkol valamilyen funkcionalitást, vagy felhasználói élményt, akkor azok automatikusan a legmagasabb prioritást kapják. Ez már egyéb folyamatbeli protokollokat érint, amik a RETRÓ-k tematikájába tartoznak. Remélem tudtam segíteni.
Köszönöm Kristóf a gyors válaszod!
Még egy kérdésem lenne: Az 55 KÉ értéket hogyan lehet megbecsülni? Van erre valami ököl szabály?
Gondolom ez az érték nagyban függ a csapat méretétől, szakértelmük szintjétől stb. Még az is számíthat, ha valaki épp egy sprint alatt szabadságon van, beteg lesz stb. Hogy lehet ezt ügyesen modellezni? Köszönöm.
Jó a kérdés! A becslések helyessége szokott lenni az első, amit új csapattagoknál, vagy csapatoknál igyekszek optimalizálni. Ami nekem sokszor bejött az az volt, hogy a csapattal közösen felállítottunk egy szempontrendszert kb. az alábbi kérdések mentén: Csináltam már ilyet? Kell hozzá segítség? Kutatást igényel? Kísérletezgetést igényel? Ellenőriznie kell valakinek? Érint egyéb komponenst? A válaszok alapján meghatározzuk először a legegyszerűbb feladatot (1 KÉ) aztán a legnehezebbet (55 KÉ) és minden mást a kettő közé lövünk be. A szempontrendszer mindig attól függően bővül, vagy csökken, amit a kivitelezés folyamata megkíván.
A csapat sebességét 3-5 sprint átlagából szoktam meghatározni. Az elején általában alulbecsülnek, aztán túl, de az 5. sprintre általában normalizálódik.
A csapattagok egyéni teljesítmény statisztikái befolyásolják a sprint KÉ sebességét. Egy idő után látható lesz, hogy egy Senior Full Stack fejlesztő képes teljesíteni egyedül azt, amit két másik medior egy sprint alatt. Ha elmegy szabira, akkor az ő sebességének az átlaga esik ki. Ezért érdemes a csapatokat párosítva összeállítani. Ez a példa igaz bármilyen szerepkörre, ahol szerepet játszik a terhelhetőség, tapasztalat és gyakorlat.
Az értékpontok meghatározásához értelemszerűen az üzleti életben társulnia kell munkaóráknak, mert legtöbbször az elszámolások a munkaórák alapján történnek, de most erre nem térek ki, mert ennek a kalkulációja és az értékpontok azonosítása már egy hosszabb téma. Tervben van ez is, de nagyon lassan haladok.
Remélem tudtam segíteni!
Eléggé parasztvakítás a SCRUM (akárcsak az agilis módszer), a Fibonacci-számokon hangosan felröhögtem. :D
Köszi a hozzászólást. Akkor ezek szerint nincsenek vele jó tapasztalataid?