HTML

ÉnKép - takacsot

Friss topikok

  • Karbonade: Az első résszel egyáltalán nem értek egyet, Európában az Operának egyelőre jóval nagyobb részesedé... (2009.04.02. 14:07) My browser war
  • takacsot: @Bővíz László: Természetesen lehet. Javasolni tudom a könyvesboltok polcain az önfejlesztés részl... (2009.01.01. 12:30) Az IQ-m
  • natalie: szerintem nagyon jo könyv. ajánlom midenkinek! (2007.09.12. 01:21) Stephen King: A mobil
  • Ismeretlen_28084: zseniális könyv tényleg (2007.04.10. 15:24) Matt Beaumont: E-sztori
  • Ismeretlen_29217: Pontosan az gond, hogy a teszt kódrészletet nem tudják értelmezni. Konkrétan a paraméterátadási m... (2006.10.18. 08:02) Internyúzás

Kai Gilb: evo és Niels Malotaux: Evolutionary Project Management Methods

2005.08.18. 18:01 takacsot

Aki ismer annál köztudott, hogy nem véletlenül kezdtem el a PSZF-et. Kifejezett célom, hogy ilyne-olyan mendzseri pozícióba kerüljek. Ehhez ugyebár tapasztalat, elhivatottság és némely esetben jó rokonság kell. Jó rokonságom az pedig nincs. Marad a többi.

Mostani lelkesülésem áldozatai ezek az az irományok. Mindkettő csak elektronikusan látezik. Asszem laza guglizással meg is találja bárki. Mindkettő ugyanarról szól. Evolúciós alapú projektmendzsmentről. De ez az amiről nem mondok semmit, mert elég hozzá elolvasni ezeket a cuccokat. Bárki elérheti.

Airől viszont beszélni fokok az egy töredéke ennek a módszernek. Ez pedig a feladat meghatározás. ebbe most a Task és Feature jellegű dolgokait beleértem, hiszen ezek hasonló dolgok. Mindegyiknek van meghatározása, vége, fejlesztési ideje. Persze a különbségek is láteznek, hiszen a feature adja a szoftver értékét, az ami a felhasználóban/ügyfélben elégedettséget vált ki. A task az egy alacsonyabb részletezettségi fokon álló valami. Szóval az alábbiak mindkettőre igazak elsznek, de saját magamon csak a feladatokat tudtam kipróbálni.

Miről van szó? A feladatot álltalában meg kell határozni, szép szóval definiálni. A legtöbbször tartalmazza a a feladat nevét vagy rövid leírását, egy részletes leírást és MD-t (man day). A fenti irományok viszont rávilágítottak néhány egyébb jellemzőre, amivel sok probléma elkerülhető.

Az egyik, monjuk ez az, amire magamtól már korábban rájöttem, hogy teljesen más eredmények jöhetnek ki, ha napokban vagy ÓRÁKBAN adod meg a fejlesztési időt. Ha napokban adod, az egy elég dúrva becslés. Tényleg az, hogy hány nap alatt tudod megcsinélni. ebben persze benne van minden járulékos dolog is. Megbeszélések, meetingek, pisi, kaki, ebéd, uzsonna, tízórai és az irodai/otthoni szex is. Ha viszont órákban adod meg akkor a ténylegesen ráfordított időt becsülöd meg. És így van! Lehet valami köze a pszichológiához, de szerintem csak a nagyságrend meghatározása részletesebb gondolkodásra, előtervezésre sarkall. Persze ebben az esetben nem lehet 40 órás héttel számolni, hiszen ha a tiszta munkát becsültük meg, mikor megyünk el szarni a reggeli kávé után?

Másik dolog a feladat definiálása. Pontosabban annak egy fontos rész: a készfeltételek. Illetve ez elég szerencsétlenül hangzik, de arról van szó, hogy az adott feladat akkor van definiálva, ha meghatározzuk, hogy MIT IS JELENT az, hogy KÉSZ. Nap mint nap találkozok és szerintem mindenki találkozik olyan feladat meghatározással, hogy pl el kell készíteni ez meg ezt a workflow-t, azt a varázsló alapú rögzítési felületet, ennek meg annak az eljárásnak az implementációját. De azokban a leírásokban ritkán (szinte soha) nem szerepel, hogy mikor is van kész adott feladat. Mikor mondhatot azt, hogy TÖBBÉ NEM KELL HOZZÁNYULNI? (persze ezt, egy adott releas kiadására vonatkoztatva, mert ugyebár egy szoftverrendszer folyaamtosan változik).

Szóval ez roppant mód megtetszett és nekiálltam a saját feladataimat ilyen mód definiálni (a feladatokkal legalább nincs baj, mert csak feature szinten van kiadva meló, amit leghet taskokra bontani)!

Huh! Nehéz! Sokkal nehezebb, mint gondolná az ember! Legalábbis az első néhány tucat. De utánna kialakul egy rutin, amikor már le tudod írni, hogy mikor tekinthető valami késznek. Gyakorlatilag elengedheetettlen valami checklistet készíteni, amit ki lehet pipálni minden feladatnál. Lefordul? Pipa. Unit test hibátlan? Pipa. Új funkciókhoz van unit teszt? Pipa. A feature-höz van teszt terv? Pipa. API doc? Pipa.... és így tovább. Persze nem az ellenörző lista szabja meg, hogy mikor van kész. Csak az mondja meg, hogy mikor NINCS kész biztosan. Némi rutin után sokat könnyít a munkán ez a technika, hiszen ha egy feladatot befejeztél, akkor TÉNYLEG befejezted. Nem kell visszanézned, hogy Jaj visszamegyek, mert ez meg azt kihagytam! Persze felmerülhet teljesen jogosan, hogy egy adott dolgot újra elő kell venni, fejleszteni kell rajta. De ez akkor már egy MÁSIK feladat.

Próbáljátok ki egy hétig. Az első pár nap kinszenvedés lessz a végkritérium meghatározása miatt. De meg lehet találni. Saját magaddal könnyű dolgod lessz. De gondolj bele: mások munkáját így meghatározva sokkal könnyebben tudod nyomon követni a haladást és szerencsétlen munkatársnak is sokkal nagyobb sikerélmény lészen, mert tudja úgy zárni a napo/hetet, hogy ezt meg azt teljesen megcsinálta.

Szólj hozzá!

A bejegyzés trackback címe:

https://takacsot.blog.hu/api/trackback/id/tr43775611

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása