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ó - 3. rész: De...hogyan?


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

Most már mindent elolvastál arról, hogy miért van szükséged a specifikációra, és mi is az a specifikáció, beszéljünk arról, kinek is kell ezt írnia.

Ki írja a specifikációt?

Engedd meg, hogy megosszak most itt veled egy kis Microsoft-os történetet. Amikor a Microsoft elkezdte a nagy sorozatát az 1980-as években, mindenki elolvasta a The Mythical Man-Month c. könyvet, a szoftver management egyik klasszikusát. (Ha még nem olvastad, komolyan ajánlom.) A legfontosabb pontja ennek a könyvnek, hogy ha több programozót adsz a késésben lévő fejlesztéshez, akkor még inkább késni fog. Ez azért van, mert ha van n programozód a projektben, a kommunikácós utak száma n(n-1)/2, ami ugye O(n2) (a kommunikációs utak száma a programozók számának négyzetével arányos) .

Így a programozók a Microsoftnál, akik azon aggódtak, hogyan írjanak nagyobb és nagyobb programokat, általában elfogadták azt a nézetet, hogy a programozók hozzáadása a dolgokat csak rosszabbá teszi.

A Mincrosoft régi vezető tervezője, Simonyi Károly (Charles Simonyi) javasolta a mester programozók koncepcióját. Az ötlet lényege, hogy egy mester programozó felelős az összes kód írásáért, de neki ezt egy junior programozócsapatra kell bíznia, a „kód rabszolgákra”. Ahelyett, hogy a mester programozó debuggolná végig az összes függvényt, valójában csak a függvények prototípusait kellene megadnia, létrehozni a csupasz körvonalakat, majd hozzávágni valamelyik junior programozóhoz a megvalósítást. (Természetesen Simonyi lett volna a mester mester programozó.) A kifejezés, hogy "Mester Programozó" túl középkori, így a Microsoft helyette a "Programfelelős"-t (program manager) választotta.

Elméletileg ez az, ami megoldja a Mythical Man-Month problémát, mivel senki sem beszél senki mással – minden junior programozó egy programfelelőssel beszél, és így a kommunikáció O(n) (A kommunikációs utak száma a programozók számával arányos) az O(n2) helyett.

Nos, Simonyi talán ismerte a Hungarian Notation-t, de nem ismerte a Peopleware-t. Senki sem akar kódrabszolga lenni. Ez a rendszer egyszerűen nem tud működni. Végül a Microsoft felismerte az állitólagos Mythical Man Month dacára, hogy nyugodtan hozzáadhat néhány embert a csapathoz, és nagyobb teljesítményt kap, bár a hatékonyság csökken. Az Excel csapat 50 programozóból állt, amikor én ott voltam, és többet termelt, mintha csak 25 emberből állt volna -- de nem kétszer annyit.

A mester/szolga programozás ötlete elvesztette a hitelét, de a Microsoft ezeket a programfelelősöknek hívott embereket nyugodtan körbeugrálta. Egy Jabe Blumenthal nevű ügyes ember újrafeltalálta a programfelelős pozíciót. Mostantól kezdve a programfelelős a tervezésért és a specifikációért felelt.

Azóta aztán a programfelelős gyüjti össze a követelményeket, kitalálja, hogy a kódnak mit kellene csinálnia, és írja a specifikációt. Általában minden programfelelősre jut 5 programozó, ezek a programozók felelősek a programfelelős által létrehozott specifikáció kódolásáért. A programfelelős kell, hogy összehangolja a marketinget, a dokumentációt, a tesztelést, a lokalizációt, és minden más bosszantó részletet, így a programozó nem veszít időt ezzel. Végül, a Microsoftnál a programfelelős van arra kitalálva, hogy legyen egy vázlatos kép a fejében a cégről, ezzel a programozók valóban fel vannak szabadítva és csak arra kell koncentrálniuk, hogy kóddarabjaik igazán jók legyenek.

A programfelelős felbecsülhetetlen értékű. Ha mindig arra panaszkodsz, hogyan tudnának a programozók a inkább a technikai részletekre koncentrálni mint az üzletiekre, akkor programfelelősre van szükséged. Ha állandóan arra panaszkodsz, hogy lehet az, hogy azok az emberek, akik jó kódot írnak, nem tudnak egy rendes szöveget megírni emberi nyelven, akkor programfelelősre van szükséged. Ha folyamatosan az a bajod, hogy a terméked sodródni látszik tiszta irányelvek nélkül, akkor programfelelősre van szükséged.

Hogyan alkalmazz programfelelőst?

A legtöbb cégnek soha nem volt programfelelős koncepciója. Ez szerintem nagyon rossz. Az én időmben a Microsoftnál azok a csoportok, ahol erős programfelelős volt, sikeres termékeket készítettek: az Excel, Windows 95 és Access mind ismertek. De a többi csoport (mint az MSN 1.0 és a Windows NT 1.0) amiket a programozók csináltak általában figyelmen kívül hagyva a programfelelőst (akik sehogy sem lehettek nagyon jók, és valószínüleg okkal hagyták őket figyelmen kívül), az ő termékeik nem voltak olyan sikeresek.

A következő három hibát kerüld el.

1. Ne nevezz ki programozót programfelelősnek. A jó programfelelős ismeretei (tiszta fogalmazás, diplomáciai képesség, piaci szemlélet, felhasználói nézőpont, és jó felhasználói felület tervezés) nagyon ritka a jó programozónál. Biztos, hogy van olyan ember, aki mindkettőt tudja, de nagyon ritka. Az eredményes programozót kinevezni egy másik pozícióba, ahol írásban kell magát jól kifejeznie nem C++-ban, tipikus esete a Peter elvnek: az embereket kinevezni egészen a saját hozzá nem értésükig.

2. Soha ne legyen marketinges a programfelelős. Senkit nem akarok megbántani, de gondolom az olvasóim elfogadják, hogy egy jó marketinges nagyon ritkán van tisztában a technikai részlettekel.

Általában a programfelelős egy önálló karrier. Minden programfelelősnek nagyon kell értenie a technikai részletekhez, de nem kell jól kódolniuk. A programfelelősnek felhasználói felületet kell tanulni, találkozni a vevőkkel, és specifikációt írnia. Nagyon sokféle emberrel kell együttműködnie – az idióta vevőktől kezdve a bosszantó és remete programozókig, akik Star Trek uniformisban jönnek dolgozni, a nagyképű 2000$-os öltönyben járó értékesítőkig. Ilyen esetben a programfelelős a szoftver csapat összetaró ereje. A karizma döntő fontosságú.

3. A fejlesztők soha se legyenek beosztottjai a programfelelősnek. Ez egy árnyalt félreértés. Mint programfelelős a Microsoftnál én terveztem a Visual Basic (VBA) stratégiát az Excelhez, én specifikáltam egészen a legkisebb részletekig, hogyan kell létrehozni a VBA-t az Excelben. A specifikációm mérete meghaladta az 500 oldalt. Az Excel fejlesztésének a tetejéről azt saccolom, hogy minden reggel 250 ember jött munkába és alapjában véve úgy dolgozott, ahogy az óriási dokumentációban én leírtam. Fogalmam sem volt, hogy ezek az emberek hol vannak, de egy csomó ember a Visual Basic csapatból ehhez írt dokumentációt (nem említve a csapatot,akik Excel oldalról írtak dokumentációt, vagy azokat, akik teljes munkaidejükben a Help állomány hiperlinkjeiért feleltek.) Hátborzongató lett volna, ha én vagyok a hivatali beosztás-fán a teteje ennek. Így is van. SENKI sem volt beosztva hozzám. Ha szerettem volna, hogy valaki megtegyen valamit, meg kellett győznöm, hogy amit akarok az jó. Ha Ben Waldman, a vezető fejlesztő, valamit nem akart csinálni, kivettem a specifikációból, mert úgysem csinálta meg. Ha a teszterek észrevettek valamit, amit nem tudtak letesztelni, egyszerűsítenem kellett. Ha ezek közül az emberek közül bárki is a beosztottam lett volna, akkor a termék nem sikerült volna ilyen jól. Néhányan azt gondolták volna, hogy csak a feljebbvaló másodhegedűsei, máskor meg a sarkamra álltam volna, és utasítottam volna őket az én megoldásomra a saját önhittségem és rövidlátásom miatt. Ami a lényeg, nem volt választásom, megállapodásra kellett jutnom. Döntéshozatalnak ez a formája a legjobb út az igazán jó gondolatokhoz.

Az utolsó cikk ebből a sorozatból ami a specifikációról szól elmondja, hogyan kell olyan specifikációt írni, amit az emberek el akarnak olvasni.



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

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