Blog

Projektmenedzsment szakmai cikkek

Havi mustra - A jósok vitájáról

2017. március 02.

Aktuális havi mustránkban a tervező projektmenedzser szemszögéből vizsgáljuk a becslés örökzöld témáját.

Köszöntöm a bejegyzés Olvasóit!

Egy éve írtam a lehetetlennek látszó projekthatáridők kezeléséről (Parkinson és a projektek tervezése), ahol fontos kérdés volt a projekttevékenységek erőforrás- és időigényének valamilyen értelemben vett „kis hibával” történő becslése. Ez alkalommal a tervező projektmenedzser szemszögéből vizsgálom a becslés örökzöld témáját.

A projektek egyedi, egyszeri feladatok, de egyediségükben nagyon is eltérnek. Wsyocky méltán számos kiadást megért művében [1] a projektek életciklusát [2] négy osztályba sorolja aszerint, hogy a projekt célja egyértelmű vagy nem az, illetve a projekt megvalósításának mikéntje (a cél elérésének módja) jól meghatározott vagy homályos. Az olyan projektek esetében, ahol a projekt célja és annak elérése is egyértelmű, Wysocky szerint a tradicionális, részletes szakaszokra bontott életciklust érdemes használni. Ilyen az esetben a tevékenységek adatai „jól” becsülhetők, többek között azért, mert rendelkezésre állnak korábbi hasonló adatok. Ha pedig vannak korábbi adatok, akkor elvben lehetséges normákat is meghatározni (normára példa az időegység alatt egy szakember által leburkolt felület mérete). A (tevékenység-specifikus) normák segítségével a projekt során elkészítendő, számszerűen jellemzett eredménytermékeket előállító tevékenységek időigénye jól becsülhető. Egy norma felhasználásának persze lehetnek feltételei, amelyek ha nem teljesülnek egy projektben, úgy az arra a normára alapozott becslés hibája nagy is lehet.

A normán alapuló becslési módszerek szakterület- és tevékenység-specifikusak. Ebben a posztban egy olyan becslési módszerrel foglalkozom, amelyben a szakterület lényegtelen, legalábbis a projektmenedzser számára.A szoftverfejlesztési projektek esetében gyakran előfordul, hogy a végfelhasználó bizonyos munkavégzési feladatait kellene támogatni, de a támogatás pontos módját sem a felhasználók, sem fejlesztők nem látják át kezdetben. Wysocky fenti tipizálásában ez az az eset, amikor a cél jól ismert, viszont elérésének mikéntje homályos. Ilyen esetekre a szerző az agilis életciklus-modell használatát javasolja, ami nála iterációkra épül, azaz a projektben gyakran kell újratervezni és így becsülni is.

A szoftverfejlesztési projektek esetében a fejlesztési technológia (pl. Java) rendszerint jól ismert, azaz amennyiben egy elvégzendő feladat nagysága (nehézsége) jól felmérhető, akkor az elvégzésének időigénye is jól becsülhető. Ilyen esetekben egy tevékenység időigényének becslése visszavezethető a feladat méretének a becslésére.

Az agilis (szoftverfejlesztési) projektekben egy adott feladat nehézségének, összetettségének becslésére gyakran használják az ún. „planning poker” (kb. „tervezési póker”) technikát [3]. Egy feladat nehézségi szintjét rendszerint a Fibonacci-sorozat (1, 1, 2, 3, 5, 8 stb.) valamelyik számával jellemzik (a Fibonacci-sorozatban egy elem értéke mindig az azt közvetlenül megelőző két elem összege). Az értékelendő feladat ismertetése és némi gondolkodási idő után a becslésben (avagy játékban) részt vevő tapasztalt fejlesztők (a szakértők avagy jósok) egy-egy kártya felmutatásával egyszerre bemondják, hogy az adott feladat véleményük szerint mennyire nehéz a Fibonacci-skálán. Ezután a két leginkább eltérő becslést adó szakértő szóban kifejtheti a többieknek, hogy miért pont akkora nehézségűre becsülte a feladatot. Ezután egész addig következnek újabb licitálási és érvelési fordulók (menetek), amíg a szakértők konszenzusra nem jutnak (a folyamatról lásd például Cohn könyvét [4] )

A tervezési póker a múlt század ötvenes éveiből származó Delfi-módszer alkalmazása a becslés elvégzésére (Delfi vagy Delphoi a görögök legkedveltebb és legismertebb jóshelye volt). A Delfi-módszert stratégiai döntések előkészítésére és meghozatalára találták ki, lényege az adott terület elismert szakértőitől kapott eltérő vélemények ütköztetése mindaddig, amíg nincs konszenzus. A Delfi-módszer alkalmazásának nyilvánvaló feltétele, hogy legyenek olyan szakértők, akik kompromisszum képesek.

Ha valaki első pillantásra úgy vélné, hogy a Delfi-módszer triviális, mindig alkalmazható és eredményes, akkor olvasson bele Linston és Thuroff több, mint ötszáz oldalas klasszikus művébe [5] , és látni fogja, hogy bőven vannak ebben buktatók.

A projekttevékenységek mérete becslése esetében a Delfi-módszer alkalmazásának zsenialitása abban áll, hogy ellentétben az analitikus, részekre bontó megközelítésekkel, mint például a funkcióelemzés, a hangsúlyt a szakértők vitájára helyezi. (A funkciópont-elemzés [6] a szoftverfejlesztésben használt szabványos becslési módszer, ahol az adott funkció bemeneti és kimeneti adatainak bonyolultságát, illetve az elvégzendő feldolgozási tevékenység komplexitását számszerűsítik, majd ezen értékekből kalibrált együtthatókat tartalmazó képlettel számítják ki a funkció nagyságát jellemző számértéket.) A Delfi-módszer alkalmazása során a projektmenedzsernek nem kell megértenie, hogy miként jött ki egy konkrét érték, az ő szempontjából ez pusztán egy megbízható jóslat. A hangsúly itt a „megbízható” minősítésen van.

A Delfi-módszer agilis szoftverfejlesztési projektekben történő használatának az az előnye is megvan, hogy egyrészt aki becsül, annak gyakran kell ezt megtennie, azaz előbb-utóbb rendelkezni fog a megfelelő becslési tapasztalatokkal; másrészt várhatóan magának kell a becslése következményeivel szembesülnie. Mindkét mozzanatot érdemes átvenni, ha valaki a Delfi-módszert akarja használni a saját projektje tevékenységei időigényének becslése során.

Rovatvezető: Klimkó Gábor, Elnökhelyettes, PMSZ


1. Wysocki, R. K. (2011). Effective project management: traditional, agile, extreme. John Wiley & Sons.
2. Wsyocky „projekt életciklus” fogalmi értelmezése kicsit eltér a PMBOK-ban
3. Moløkken-Østvold, K., Haugen, N.C. és Benestad, H.C. (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), pp. 2106-2117.
4. Cohn, M. (2005). Agile estimating and planning. Pearson Education.
5. Linstone, H.A. és Turoff, M. (Eds.). (1975). The Delphi method: Techniques and applications. (Vol. 29). Reading, MA: Addison-Wesley.
6. Symons, C. R. (1991). Software sizing and estimating: Mk II FPA (function point analysis). Wiley
 

“Elgondolkodtató egy szakmai baklövésről, vívódásról hallani, amit egy gyakorlott projektvezető követ el. Nem, nem a kárörvendés végett. Az ügy tanulsága miatt. Engem az is energiával tölt fel, ha meghallgatok pár történetet, kézzelfogható dolgot a projektmenedzsment világából. Legyen az bármilyen apró. A történeteknek ereje van. Ami miatt még szeretem őket, hogy emberközeliek, emlékezetesek és rólunk szólnak. Néha édes, de keserű. Mint a Tonik!
A PMSZ Tonik sorozat egy két hetente megjelenő írás, ami röviden, töményen fogalmaz meg eseteket a projektek világából. A középpontban az ember, a csapat és a projektvezetés áll. Nem a kemény módszertanokról szól. A való világot mutatja. Néhány perc alatt elolvasható történetek ezek, melyek frissítően hatnak a napi „robotban” és bízom benne, hogy tanulsággal is szolgálnak. Fogadjátok szeretettel írásaimat!”

Havi mustra - A jósok vitájáról

2017. március 02.

Aktuális havi mustránkban a tervező projektmenedzser szemszögéből vizsgáljuk a becslés örökzöld témáját.

Köszöntöm a bejegyzés Olvasóit!

Egy éve írtam a lehetetlennek látszó projekthatáridők kezeléséről (Parkinson és a projektek tervezése), ahol fontos kérdés volt a projekttevékenységek erőforrás- és időigényének valamilyen értelemben vett „kis hibával” történő becslése. Ez alkalommal a tervező projektmenedzser szemszögéből vizsgálom a becslés örökzöld témáját.

A projektek egyedi, egyszeri feladatok, de egyediségükben nagyon is eltérnek. Wsyocky méltán számos kiadást megért művében [1] a projektek életciklusát [2] négy osztályba sorolja aszerint, hogy a projekt célja egyértelmű vagy nem az, illetve a projekt megvalósításának mikéntje (a cél elérésének módja) jól meghatározott vagy homályos. Az olyan projektek esetében, ahol a projekt célja és annak elérése is egyértelmű, Wysocky szerint a tradicionális, részletes szakaszokra bontott életciklust érdemes használni. Ilyen az esetben a tevékenységek adatai „jól” becsülhetők, többek között azért, mert rendelkezésre állnak korábbi hasonló adatok. Ha pedig vannak korábbi adatok, akkor elvben lehetséges normákat is meghatározni (normára példa az időegység alatt egy szakember által leburkolt felület mérete). A (tevékenység-specifikus) normák segítségével a projekt során elkészítendő, számszerűen jellemzett eredménytermékeket előállító tevékenységek időigénye jól becsülhető. Egy norma felhasználásának persze lehetnek feltételei, amelyek ha nem teljesülnek egy projektben, úgy az arra a normára alapozott becslés hibája nagy is lehet.

A normán alapuló becslési módszerek szakterület- és tevékenység-specifikusak. Ebben a posztban egy olyan becslési módszerrel foglalkozom, amelyben a szakterület lényegtelen, legalábbis a projektmenedzser számára.A szoftverfejlesztési projektek esetében gyakran előfordul, hogy a végfelhasználó bizonyos munkavégzési feladatait kellene támogatni, de a támogatás pontos módját sem a felhasználók, sem fejlesztők nem látják át kezdetben. Wysocky fenti tipizálásában ez az az eset, amikor a cél jól ismert, viszont elérésének mikéntje homályos. Ilyen esetekre a szerző az agilis életciklus-modell használatát javasolja, ami nála iterációkra épül, azaz a projektben gyakran kell újratervezni és így becsülni is.

A szoftverfejlesztési projektek esetében a fejlesztési technológia (pl. Java) rendszerint jól ismert, azaz amennyiben egy elvégzendő feladat nagysága (nehézsége) jól felmérhető, akkor az elvégzésének időigénye is jól becsülhető. Ilyen esetekben egy tevékenység időigényének becslése visszavezethető a feladat méretének a becslésére.

Az agilis (szoftverfejlesztési) projektekben egy adott feladat nehézségének, összetettségének becslésére gyakran használják az ún. „planning poker” (kb. „tervezési póker”) technikát [3]. Egy feladat nehézségi szintjét rendszerint a Fibonacci-sorozat (1, 1, 2, 3, 5, 8 stb.) valamelyik számával jellemzik (a Fibonacci-sorozatban egy elem értéke mindig az azt közvetlenül megelőző két elem összege). Az értékelendő feladat ismertetése és némi gondolkodási idő után a becslésben (avagy játékban) részt vevő tapasztalt fejlesztők (a szakértők avagy jósok) egy-egy kártya felmutatásával egyszerre bemondják, hogy az adott feladat véleményük szerint mennyire nehéz a Fibonacci-skálán. Ezután a két leginkább eltérő becslést adó szakértő szóban kifejtheti a többieknek, hogy miért pont akkora nehézségűre becsülte a feladatot. Ezután egész addig következnek újabb licitálási és érvelési fordulók (menetek), amíg a szakértők konszenzusra nem jutnak (a folyamatról lásd például Cohn könyvét [4] )

A tervezési póker a múlt század ötvenes éveiből származó Delfi-módszer alkalmazása a becslés elvégzésére (Delfi vagy Delphoi a görögök legkedveltebb és legismertebb jóshelye volt). A Delfi-módszert stratégiai döntések előkészítésére és meghozatalára találták ki, lényege az adott terület elismert szakértőitől kapott eltérő vélemények ütköztetése mindaddig, amíg nincs konszenzus. A Delfi-módszer alkalmazásának nyilvánvaló feltétele, hogy legyenek olyan szakértők, akik kompromisszum képesek.

Ha valaki első pillantásra úgy vélné, hogy a Delfi-módszer triviális, mindig alkalmazható és eredményes, akkor olvasson bele Linston és Thuroff több, mint ötszáz oldalas klasszikus művébe [5] , és látni fogja, hogy bőven vannak ebben buktatók.

A projekttevékenységek mérete becslése esetében a Delfi-módszer alkalmazásának zsenialitása abban áll, hogy ellentétben az analitikus, részekre bontó megközelítésekkel, mint például a funkcióelemzés, a hangsúlyt a szakértők vitájára helyezi. (A funkciópont-elemzés [6] a szoftverfejlesztésben használt szabványos becslési módszer, ahol az adott funkció bemeneti és kimeneti adatainak bonyolultságát, illetve az elvégzendő feldolgozási tevékenység komplexitását számszerűsítik, majd ezen értékekből kalibrált együtthatókat tartalmazó képlettel számítják ki a funkció nagyságát jellemző számértéket.) A Delfi-módszer alkalmazása során a projektmenedzsernek nem kell megértenie, hogy miként jött ki egy konkrét érték, az ő szempontjából ez pusztán egy megbízható jóslat. A hangsúly itt a „megbízható” minősítésen van.

A Delfi-módszer agilis szoftverfejlesztési projektekben történő használatának az az előnye is megvan, hogy egyrészt aki becsül, annak gyakran kell ezt megtennie, azaz előbb-utóbb rendelkezni fog a megfelelő becslési tapasztalatokkal; másrészt várhatóan magának kell a becslése következményeivel szembesülnie. Mindkét mozzanatot érdemes átvenni, ha valaki a Delfi-módszert akarja használni a saját projektje tevékenységei időigényének becslése során.

Rovatvezető: Klimkó Gábor, Elnökhelyettes, PMSZ


1. Wysocki, R. K. (2011). Effective project management: traditional, agile, extreme. John Wiley & Sons.
2. Wsyocky „projekt életciklus” fogalmi értelmezése kicsit eltér a PMBOK-ban
3. Moløkken-Østvold, K., Haugen, N.C. és Benestad, H.C. (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), pp. 2106-2117.
4. Cohn, M. (2005). Agile estimating and planning. Pearson Education.
5. Linstone, H.A. és Turoff, M. (Eds.). (1975). The Delphi method: Techniques and applications. (Vol. 29). Reading, MA: Addison-Wesley.
6. Symons, C. R. (1991). Software sizing and estimating: Mk II FPA (function point analysis). Wiley