Oldalak

szombat

módszertanok.....

Ellentmondásnak tűnhet, hogy folyton hangsúlyozom a dokumentáció fontosságát, közben pedig lazán félmondatba odavetem, hogy az Agile a kedvenc módszertanom....
Mégsincs kettős mérce.

Összegyüjtöttem az érveimet....


1. Bármilyen módszertannal dolgozunk is, azt hiszem, hogy egy pontos igényfelmérő dokumentum létfontosságú. Ennek elkészítése alatt megismerhetjük az ügyfelet, belelátunk a kívánalmakba, eldönthetjük, hogy melyik módszertan illik a feladathoz. Simán lehet, hogy a beszélgetések alatt derül ki egy "mission critical" pontja a tervezett szoftvernek -- tehát az agile alapból kilőve. De kiderülhet, hogy van egy fantasztikus, dedikált összekötő emberünk, aki nagyon ért hozzá az Ő oldaláról, rugalmas és gyors gondolkodású. Rögtön felcsillan a remény :)

2. Még egy érv a dokumentáció mellett - még ha profikkal dolgozunk is együtt, akkor is kell lennie egy alap dokumentum készletnek amihez visoznyítnai tudunk, amire építhetünk. Az igaz, hogy ha agile módszertannal dolgozunk akkor a fókuszpont nem a rendszerterven lesz, hanem az egyes részfeladatok ledokumentálásán (akár utólagos, vagy csak tesztre alkalmas dokumentáció formájában).

3. Ma már nem hagyjató ki dokumentáció. A projektben egymásra épülhetnek a sokumentumok: Igényspec -- Kövspec/Rendszerterv -- Teszt forgatókönyvek -- Súgó/Tutorial/Handbook, csak, hogy a gerincet emeljem ki.
Pm módszertan választásakor már előre tudnunk kell, hogy pl. minden dokumentáció szükséges-e? Előfordulhat olyan eset, hogy nem kell majd súgó jellegű dokumentum. De olyan nem valószínű, hogy ne kelljen majd tesztforgatókönyv....
Tehát ha nem lineáris módszertant választunk akkor viszont nagyon tudatában kell lennünk annak a "veszélynek", hogy a dokumentumok előállítása akár több idő is lehet, illetve más típusú erőforrásra lehet hozzá szükségünk.  Ideális esetben van külön, erre allokált ember, de valljuk be: ez ritka, mint a fehér holló.
Bármilyen profi csapatnál, akár utólag, de le kell dokumentálni a fejlesztett modult, mind technikai, mind működési szempontból. Mivel ilyenkor már általában nem az ügyfélnek, hanem egyfajta belső használatra megy a dolog, a nyelvezete lehet technikaibb. Ha ez nincs, a teszt forgatókönyvek előállítása sokkal nehezebb lesz.
Viszont az nem szabad elfelejteni, hogy így elveszítjük azt az előnyt, hogy a fejlesztéssel párhuzamosan már készülhetnek a teszt forgatókönyvek. Ez egyedi mérlegelés kell legyen minden  projektben.

4. Bármilyen nem lineáris módszertan akkor tud jól működni, ha van egy szűk funkcionalitású keretrendszer amihez moduláris rendszerben csatlakoznak a funkciók.

5. Kiemelten fontos, hogy csak profi programozókkal lehet egy ilyen, kvázi a káoszt magában hordozó módszertant működtetni. Bármilyen penge is egy kezdő, nem lesz meg a kellő önbizalma (nem a nagyképűségére gondolok, azzal nem lesz baj :)) és főleg a kellő tapasztalata, hogy átlássa, hogy ha most valamit X módon csinál az később hol, milyen hatásokat generálhat. Egy gyakorlott PM ezen segíthet, de az ilyen típusú módszertanok egyik előnye a gyorsaság -- egy kezdő betanítása ebbe a rendszerbe pedig időt növelő tényező.

5/b :) Viszont ha az ügyfél és project is olyan, hogy van egy kicsit több időnk, akkor igenis érdemes a profik mellé 1, max 2 ígéretes kezdőt bevenni. Egyrészről mert jó tanulási, fejlődési lehetőség nekik, másrészről, mert megláthatnak olyat amit mi nem, illetve később ez a tapasztalat még jól jöhet. Inkább egy "laza" projekten próbáljuk ki és tanítsuk be az újoncokat, mint egy éles, durva határidőkkel rendelkező projektben.....

6. Nagyon sok cég belesik abba a hibába, hogy megpróbálja konformizálni a módszertanát és ha elkészült a process, akkor ahhoz szilárdan ragaszkodik. Eddig egyetlen cégnél sikerült elérnem, hogy legyen többféle projekt módszertan testre szabva, és legyen a projekt elején egyfajta szempontrendszer szerinti választási lehetőség. A diverzifikációtól valami miatt a nagyon 0ákban és 1esekben gondolkodó mérnökök félni szoktak :)
Tény, hogy ehhez egy érett szervezet és jó cégkultúra szükségeltetik. De ha nincs ism eg, ez jó alap lehet a kialakításához. :)

Nincsenek megjegyzések:

Megjegyzés küldése