Joel on Software

Joel on Software   Joel, szoftverekről

 

További "Joel on Software" cikkek magyar nyelven

További "Joel on Software" cikkek angol nyelven

E-mail a szerzőnek (angol nyelven)

 

Fájdalommentes funkcionális specifikáció - 2. rész: Mi is ez a specifikáció?


Szerző: Joel Spolsky
Fordította: Plesz Gábor
2000. oktober 03.

(Elolvastad már az első részt? Ha nem, akkor olvasd el.)

 

Ez a cikksorozat a funkcionális specifikációról szól, nem a technikai specifikációról. Ezeket keverni szokták. Én nem tudom, hogy vajon létezik-e  hivatalos terminológia, de azt elmondom, hogy én mit gondolok, amikor ezeket a fogalmakat használom.

 

1. A funkcionális specifikáció leírja a termék működését teljesen a felhasználó szemszögéből. Egyáltalán nem foglalkozik azzal, hogyan lesz ez megoldva. A tulajdonságokról beszél. Menüket, képernyőket, dialógusablakokat határoz meg.

2. A technikai specifikáció leírja a program belső megvalósítását. Adatstruktúrákról beszél, relációs adatbázis modellekről, a programnyelvek és eszközök és algoritmusok között választ.

 

 

 

Ha terméket tervezel kívülről és belülről, a legfontosabb, hogy a felhasználói tapasztalatokba dugd az orrod. Mik legyenek a képernyők, hogyan kell működniük, mit kell csinálniuk. Később ügyelj arra, hogyan tudsz eljutni innen oda. Itt ne okoskodj arról, hogy melyik programnyelvet kell használni, mielőtt arról döntesz, hogy egyáltalán a program mit csináljon. Én csak a funkcionális specifikációról beszélek.

 

Írtam egy rövid példát, ami remélem megmutatja, hogyan kell kinéznie egy jó funkcionális specifikációnak. Mielőtt továbbmegyünk, kérlek, olvasd el ezt a példát.

 

Elolvastad?

 

Nem olvastad el. Menj és most olvasd el, és aztán gyere vissza, így tovább tudunk arról beszélgetni, hogy mi kell és mi nem a jó specifikációba. Itt várlak. Köszönöm.

 

(Várakozás türelemmel...)

 

[Image]

Jól van. Visszajöttél.

 

 

Itt van néhány dolog, amit minden specifikációba beleírok.

 

A cáfolatok. Tisztán önvédelem. Ha beírsz egy bekezdést, valami olyasmit, hogy „Ez a specifikáció még nincs lezárva”, nem akarják majd az emberek betörni a fejed. Ahogy az idő telik, lassan a specifikáció elkészül, ki tudod cserélni "ez a specifikáció le van zárva a legjobb tudásom szerint, de ha valamit elfelejtettem, kérlek jelezd." Ahogy emlékszel, minden specifikáció a következőkből áll:

 

A szerző. Egy szerző. Néhányan azt gondolják, hogy a specifikációt csapatoknak kell írniuk. Ha valaha már próbáltad a csapatos írást, akkor tudod, hogy minél nincs rosszabb tortúra. Hagyd meg a csapatos írást a management tanácsadó cégeknek a Harvardon frissen végzettek hadseregével, akiknek szükségük van a nehéz és fontos munka látszatára, amivel a saját magas díjukat tudják igazolni. A te specifikációdat kezelni és írni egy embernek kell. Ha nagy terméked van, akkor vágd szét területekre, és minden területet adj oda egy embernek független specifikációra. Más cégek azt gondolják, hogy ez egoizmus, és nem „jó csapatmunka”, ha egy ember „viszi el a jogot” azzal, ha az ő nevét nyomják a specifikációra. Értelmetlenség. Az emberneknek felelősségel kell birtokolniuk a dolgokat, amit specifikálnak. Ha valami baj van a specifikációval, a specifikáció tulajdonosa a felelős érte, az ő nevével van a specifikáció éppen ezért kinyomtatva, mert ő a felelős a megoldásért is.

Forgatókönyvek. Ha egy terméket tervezel, akkor valódi élő forgatókönyveket kell elképzelned, hogy milyen emberek fogják használni. Különben a végén még tervezel egy olyan terméket, ami nem felel meg semmilyen valódi használatra (ld. Cue?Cat - angolul). Szúrd ki a termék célközönségét, és képzelj el fiktív, teljesen a képzelet szülte, de tipikus felhasználókat minden célközönségből, akik teljesen tipikus módon használják majd a terméket. A felhasználói felület tervezéséről szóló könyvem 9. fejezetében (az egész ingyenesen letölthető - egyelőre angolul) fiktív felhasználók és forgatókönyvek létrehozásáról írok. Na most itt van, ahova beteheted őket. Jobb munka az élénk és realista forgatókönyvvel a valódi és elképzelt felhasználókhoz tervezni a terméket, pontosan ez az amiért azt mondom, hogy egy kicsit merülj el a kitalált részletekbe.

.

Nem célok. Ha egy csapattal készítesz egy terméket, mindenki a saját favoritját segíti, elképzelt vagy valódi kedvenc tulajdonságait, ami nékül nem tud élni. Ha hagyod, akkor ez el fog vinni végtelen időt és egy csomó pénzt. El kell kezdened a tulajdonságokat cenzúrázni, és erre a legjobb módszer a „Nem célok” fejezete a specifikációnak. Dolgok, amiket nem fogunk megcsinálni. A nem célok lehetnek tulajdonságok, amiket nem akarsz („ne legyen telepatikus felhasználói felület!”) vagy lehet ennél általánosabb is („Nem akarunk foglalkozni a teljesítménnyel. A termék olyan lassú lehet, amilyen csak akar amíg működik. Ha a 2. verzióban lesz időnk, akkor optimalizálni fogjuk a lassú biteket.”) Ezek a nem célok olyanok, amik vitákat okoznak, de pontosan ezért nagyon fontos olyan hamar kidobni őket az ablakon, ahogy csak lehetséges. "Még csak meg se próbáld." ahogy Sir Gerge mondaná.

Az áttekintés. Ez olyan, mint egy tartalomjegyzék a specifikációdhoz. Lehet egy egyszerű folyamatábra, vagy lehet egy kiterjedt szerkezeti tárgyalás. Mindenki el fogja olvasni, hogy legyen egy áttekintő képe az egészről, aztán a részleteket sokkal jobban fogja érteni.

 

Részletek, részletek, részletek. Végül menj bele a részletekbe. A legtöbb ember addig fog ebben lefúrni, amíg szüksége van az aprólékos részletekre. Ha web típusú szolgáltatást tervezel, jól teszed, ha minden lehetséges képernyőnek egyedi nevet adsz, és a fejezetleírásban mindegyiket agyzsibbasztó részletességgel leírsz.

 

A részletek a legfontosabb részei a specifikációnak. Emlékezz, a példában milyen vérlázító részletességgel írtam le minden hibalehetőséget a login oldalon. Mi van, ha az e-mail cím nem érvényes? Mi van, ha a jelszó rossz? Minden ilyen esethez valódi kód tartozik, amit aztán majd meg is kell írni, de sokkal fontosabb, hogy ezekhez az esethez döntések tartoznak, amiket valakinek meg kell hoznia. Valakinek döntenie kell, hogy mi legyen akkor, ha elfelejtették a jelszót. A specifikóció kell, hogy a döntést dokumentálja.

Nyitott problémák. Az rendben van, ha a specifikáció első változatában nyitott problémák maradnak. Amikor én az első vázlatot írom, egy csomó nyitott problémám van, de megjelölöm őket (speciális stílust használok, így tudok rájuk keresni) és, ha lehetőségem van, megtárgyalom az alternatívákat. Amikorra a programozók elkezdenek dolgozni, minden ilyet el kell tiporni. (Talán azt gondolod, hogy nyugodtan kezdjenek a programozók dolgozni a könnyebb részeken, és majd közben megoldod a nyitott problémáka. Rossz ötlet. Éppen elég problémád lesz az új problémák megoldásakor, amik akkor jönnek elő, amikor a programozók nekiállnak megírni a kódot, anélkül is, ha nincsenek régi nyitott problémáid. Gondolj a jövőre, és oldd meg őket. Ezen kívül a a nem triviális problémák megoldásának módja hatással lesz arra is, hogyan kell a kódot megírni.)

Széljegyzetek. Amig a specifikációt írod, emlékezz a különböző olvasóidra: programozók, teszterek, szakírók, stb. Írás közben eszedbe juthatnak olyan dolgok, amik csak az egyik csoportot érdekli. Például és a programozóknak szóló üzeneteimet, ami valamennyire technikai megvalósítási részletekről szól „Technikai megjegyzés” jellel látom el. A marketingesek figyelmen kívül tudják ezeket hagyni. A programozók falják őket. A specifikációim dugig vannak a következőkkel: "Megjegyzés a teszteléshez," "Marketing megjegyzés," és "Dokumentációs megjegyzés."

 

A specifikációnak életben kell maradnia. Néhány programozócsapat a "vízesés" mentalitást alkalmazza. Mi egyszer megtervezzük a programot, megírjuk a specifikációt, kinyomtatjuk, körberakjuk vele a programozót, és megyünk haza. Minderre azt mondom én: "Ha ha ha ha ha ha ha ha ha!"

Ez az ok, amiért a specifikációnak rossz a híre. Egy csomó ember mondja nekem, "a specifikációk használhatatlanok, mivel senki sem követi őket, ezért állandóan idejétmúltak, és soha sem tükrözik a terméket."

Bocsánat. Talán a te specifikációd idejétmúlt, és nem tükrözi a terméket. Az én specifikációm folyamatosan frissítve van. A változtatások folyamatosak, ahogy a fejlesztés folyik, és új döntések születnek. A specifikáció mindig tükrözi a csapat egyetértését, ahogy a termék fejlesztése folyik. A specifikáció akkor fagy be, amikor a kódot lezárjuk. (Ez akkor van, ha kész az összes tulajdonság, de a hibakeresés és tesztelés ennek ellenére folyik)

Hogy az emberek életét megkönnyítsem, nem frissítem és adom ki a specifikációt naponta. Folyamatosan a legfrissebb változat van egy szerveren, ahol a csapat referenciaként használhatja. Az alkalmankénti mérföldköveknél kinyomtatom, megjelölöm a változtatásokat, így nem kell az embereknek állandóan az egészet újra elolvasniuk - elég csak a megjelölt változtatásokat megnézni.

 

Ki írja a specifikációt? Olvass erről el mindent a 3. részben

 

 

 



A fordítás alapjául szolgáló angol cikk címe: Painless Software Specifications Part 2  

Joel Spolsky a Fog Creek Software alapítója. A Fog Creek egy apró szoftvercég, székhelye New York City. Joel a Yale egyetemen végzett, majd programozóként és menedzserként dolgozott a Microsoftnál, a Viacomnál és a Junonál.


Az itt olvasható oldalak egyetlen személy véleményét tükrözik.
Minden itt megjelenő tartalom ©1999-2005 Joel Spolsky. Minden jog fenntartva.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky