STORY POINT „ mennyit ér egy agilis történet?”

„… miért kell más eszközt keresnünk, mint a korábban alkalmazott óra alapú becslések?...” „… hogyan lehet kézzelfoghatóvá tenni a Story Point tartalmát?...” „… ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni?...” „… Hogyan történik a viszonyszámok meghatározása?...” „… van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között?...”

A beszélgetőpartnerek: Vida Tibor, az evosoft Hungary Kft. Orvostechnikai ágazatának technikai ágazatvezetője Gönye Zoltán, szoftver-minőségbiztosítás © 2008. Minden jog fenntartva!

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Elsőként nézzük meg, hogy miért kell más eszközt keresnünk, mint a korábban alkalmazott óra alapú becslések? Tapasztalatunk szerint az óra alapú becsléssel az a legnagyobb probléma, hogy elhitetjük a megrendelővel, és magunkkal is, hogy pontos becslést adtunk. Valójában azonban ez csak egy körülbelüli érték, hiszen szinte mindig új- és-új feladatot kell megoldani, nem jellemző, hogy kétszer ugyanazt végezzük el. A gyakorlatban a szoftver megírásához szükséges időt az előző tapasztalataink alapján becsüljük, a korábban kifejlesztett szoftverekhez viszonyítva. Ha viszont így van miért ne használhatnánk az összehasonlításokhoz egy mértékegység nélküli viszonyítási számot? Ez lenne tehát a Story Point? Így van. Hogyan lehet kézzelfoghatóvá tenni a Story Point tartalmát? Nehéz pontos definíciót adni, nem az a tipikus, mérnöki gondolkodásmódban megszokott mértékegység. Azt próbálja meg kifejezni, hogy az adott feladat elkészítése mekkora munkát jelent, milyen nehéz is. Ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Elsőként nézzük meg, hogy miért kell más eszközt keresnünk, mint a korábban alkalmazott óra alapú becslések? Tapasztalatunk szerint az óra alapú becsléssel az a legnagyobb probléma, hogy elhitetjük a megrendelővel, és magunkkal is, hogy pontos becslést adtunk. Valójában azonban ez csak egy körülbelüli érték, hiszen szinte mindig új- és-új feladatot kell megoldani, nem jellemző, hogy kétszer ugyanazt végezzük el. A gyakorlatban a szoftver megírásához szükséges időt az előző tapasztalataink alapján becsüljük, a korábban kifejlesztett szoftverekhez viszonyítva. Ha viszont így van miért ne használhatnánk az összehasonlításokhoz egy mértékegység nélküli viszonyítási számot? Ez lenne tehát a Story Point? Így van. Hogyan lehet kézzelfoghatóvá tenni a Story Point tartalmát? Nehéz pontos definíciót adni, nem az a tipikus, mérnöki gondolkodásmódban megszokott mértékegység. Azt próbálja meg kifejezni, hogy az adott feladat elkészítése mekkora munkát jelent, milyen nehéz is. Ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Elsőként nézzük meg, hogy miért kell más eszközt keresnünk, mint a korábban alkalmazott óra alapú becslések? Tapasztalatunk szerint az óra alapú becsléssel az a legnagyobb probléma, hogy elhitetjük a megrendelővel, és magunkkal is, hogy pontos becslést adtunk. Valójában azonban ez csak egy körülbelüli érték, hiszen szinte mindig új- és-új feladatot kell megoldani, nem jellemző, hogy kétszer ugyanazt végezzük el. A gyakorlatban a szoftver megírásához szükséges időt az előző tapasztalataink alapján becsüljük, a korábban kifejlesztett szoftverekhez viszonyítva. Ha viszont így van miért ne használhatnánk az összehasonlításokhoz egy mértékegység nélküli viszonyítási számot? Ez lenne tehát a Story Point? Így van. Hogyan lehet kézzelfoghatóvá tenni a Story Point tartalmát? Nehéz pontos definíciót adni, nem az a tipikus, mérnöki gondolkodásmódban megszokott mértékegység. Azt próbálja meg kifejezni, hogy az adott feladat elkészítése mekkora munkát jelent, milyen nehéz is. Ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. hogy pontos becslést adtunk. Valójában azonban ez csak egy körülbelüli érték, hiszen szinte mindig új- és-új feladatot kell megoldani, nem jellemző, hogy kétszer ugyanazt végezzük el. A gyakorlatban a szoftver megírásához szükséges időt az előző tapasztalataink alapján becsüljük, a korábban kifejlesztett szoftverekhez viszonyítva. Ha viszont így van miért ne használhatnánk az összehasonlításokhoz egy mértékegység nélküli viszonyítási számot? Ez lenne tehát a Story Point? Így van. Hogyan lehet kézzelfoghatóvá tenni a Story Point tartalmát? Nehéz pontos definíciót adni, nem az a tipikus, mérnöki gondolkodásmódban megszokott mértékegység. Azt próbálja meg kifejezni, hogy az adott feladat elkészítése mekkora munkát jelent, milyen nehéz is. Ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. megoldani, nem jellemző, hogy kétszer ugyanazt végezzük el. A gyakorlatban a szoftver megírásához szükséges időt az előző tapasztalataink alapján becsüljük, a korábban kifejlesztett szoftverekhez viszonyítva. Ha viszont így van miért ne használhatnánk az összehasonlításokhoz egy mértékegység nélküli viszonyítási számot? Ez lenne tehát a Story Point? Így van. Hogyan lehet kézzelfoghatóvá tenni a Story Point tartalmát? Nehéz pontos definíciót adni, nem az a tipikus, mérnöki gondolkodásmódban megszokott mértékegység. Azt próbálja meg kifejezni, hogy az adott feladat elkészítése mekkora munkát jelent, milyen nehéz is. Ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. szoftverekhez viszonyítva. Ha viszont így van miért ne használhatnánk az összehasonlításokhoz egy mértékegység nélküli viszonyítási számot? Ez lenne tehát a Story Point? Így van. Hogyan lehet kézzelfoghatóvá tenni a Story Point tartalmát? Nehéz pontos definíciót adni, nem az a tipikus, mérnöki gondolkodásmódban megszokott mértékegység. Azt próbálja meg kifejezni, hogy az adott feladat elkészítése mekkora munkát jelent, milyen nehéz is. Ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Ez lenne tehát a Story Point? Így van. Hogyan lehet kézzelfoghatóvá tenni a Story Point tartalmát? Nehéz pontos definíciót adni, nem az a tipikus, mérnöki gondolkodásmódban megszokott mértékegység. Azt próbálja meg kifejezni, hogy az adott feladat elkészítése mekkora munkát jelent, milyen nehéz is. Ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Hogyan lehet kézzelfoghatóvá tenni a Story Point tartalmát? Nehéz pontos definíciót adni, nem az a tipikus, mérnöki gondolkodásmódban megszokott mértékegység. Azt próbálja meg kifejezni, hogy az adott feladat elkészítése mekkora munkát jelent, milyen nehéz is. Ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. munkát jelent, milyen nehéz is. Ez eddig rendben van, de miért nem lehet ezt óra alapon kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. kifejezni? A óra alapú becslésekre vannak ugyan viszonylag pontos módszerek, mint például az FPA, de ezek gyakran nem elég gyorsak, és nem ritkán igen költséges az alkalmazásuk. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Nézzük az alapproblémát: Gyakori, hogy a feladat nehézségéből nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. nem következik egyértelműen, hogy azt mennyi idő alatt, azaz mekkora ráfordítással lehet azt elvégezni. Egy nagyon leegyszerűsített, de talán érthető példa: Ha pl. egy web oldalt kell kifejleszteni, amihez egy két fős csapatunk van, mondjuk egy designer és egy fejlesztő, akkor: Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Nyilvánvalóan a fejlesztő a szoftveres részeket tudja hatékonyan megírni, míg a designer a kinézettel fog hamarabb végezni. Fordítva ugyanez a nehézségű feladat várhatóan sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. sokkal nagyon ráfordítással készülhet el. Rendben, fogadjuk ezt így el. Hogyan történik a viszonyszámok meghatározása? Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Sokféle módszer van, az egyik legelterjedtebb a Fibonacci számok használata. A legegyszerűbb feladat 1 Story Point ér, a többit ehhez viszonyítjuk. Nagyon fontos azonban, hogy a konkrét viszonyszámokat a csapat mindig egyetértésben határozza meg. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Térjünk vissza egy pillanatra az óra alapú becsléshez. Van-e kapcsolat az óra alapú ráfordításbecslés és a Story Point alapú megközelítés között? Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Természetesen van, egy nehezebb feladatot hosszabb idő alatt lehet megoldani. Azonban a Story Point, mint egy durva becslés eredménye nem konvertálható egyértelműen órává. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Ha egy sprintben (azaz egy fejlesztési szakaszban) a csapat 900 órát fordított a fejlesztésre, és közben 52 Story point értékben teljesített, akkor ebből természetesen kalkulálható, hogy 1-1 story point-nyi feladat megoldása mekkora munkát jelentett. Ez az adott csapatra nézve már azt jelenti, hogy a következő sprintben már lehet vele tervezni. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

Beszélgetés a Story Point-ról, az agilis szoftverfejlesztés módszerek egyik eleméről. Hosszabb távon természetesen az a cél, hogy egy-egy fejlesztési ciklus azaz sprint alatt egyre több és több Story Point-ot tudjunk szállítani.

A beszélgetőpartnerek: Vida Tibor, az evosoft Hungary Kft. Orvostechnikai ágazatának technikai ágazatvezetője Gönye Zoltán, szoftver-minőségbiztosítás © 2008. Minden jog fenntartva!