Miért fontos, hogy a fejlesztési projekt megfelelő specifikációval legyen ellátva? Körülbelül olyan kérdés ez, minthogy: kell-e egy nyolcemeletes lakóparkhoz részletes építkezési terv? Fontos, hogy lehetőleg minden részletre kiterjedjen? Igen, kell! Igen, fontos!

 

Töltsd le a specifikációs sablont

 

Minden fejlesztési procedúra fázisokból áll, amelyek bizonyos sorrendben követik egymást. Vizsgáljuk meg ezeket és helyezzük kontextusba magát a specifikációt.

A fejlesztési projekt folyamata

1. Definíciós fázis

  • Megbeszélés az ügyféllel, a megoldandó probléma felvázolása
  • Specifikálás megkezdése
  • Folyamattervezés
  • Wireframe-ek (drótvázak) elkészítése
  • Folyamatos egyeztetés és iterálás

2. Tervezési fázis

  • UI elemek (képernyőképek) elkészítése
  • Specifikáció véglegesítése

3. Fejlesztési fázis

  • A specifikációnak megfelelő rendszer elkészítése
  • Felmerülő módosítási igények leegyeztetése, lehetőség szerint iterálása

4. Tesztelési fázis

  • Tesztelés és hibajavítás
  • Ennek lezárultával élesítés, átadás

5. Támogatás

  • A későbbiekben felmerülő bug-ok reportolása és beütemezése javításra
  • Hibajavítás
  • Frissítések kiadása

Ezen blogposzt nem foglalkozik a fejlesztési procedúra többi részével, hanem a funkcionális specifikációt kiemelve a tervezésre fókuszál. Láthatjuk, hogy a tervezés a folyamat elején foglal helyet értelemszerűen és itt kell lefektetni az alapokat. Tehát az első kettő fázisban érdekelt a specifikáció és a második végére kell, hogy elkészüljön. Sajnálatos módon a tapasztalat azt mutatja, hogy a specifikálás a projekt azon része, amelyet általános tendencia szerint legtöbbször elhanyagolnak, idő pénz vagy egyéb indokok által vezérelve. De reálisan azért, mert nem látják azt a hasznosságot, amit nyújtani tud, rövid de még inkább hosszú távon. Éppen ezért nálunk ez kiemelt fontosságú és ennek megvannak a maga okai, hiszen a projekt összes többi, ráépülő fázisát befolyásolja. Most, hogy definiáltuk a megfelelő kontextust, vizsgáljuk meg mit is jelent a specifikálás, mit várhatunk el ettől?

Specifikáció

Ez maga a terv. The MasterPlan! Az első fázisban még szárnyalhat a képzelete a projektmenedzsernek és jöhetnek az ötletek és utána konkretizálódik, hogy mi is kerül bele a tervbe. Kifejezetten a definíciós fázisban repüljön a fantázia és egy nagy képből faragjunk, pontosítsunk, mint fordítva. Utólag beépíteni egy funkciót egy nem arra felkészített alapra jelentheti a problémákat. Szóval, ha kitaláltuk mit is szeretnénk, utána kerülnek lefektetésre, meghatározásra a  fejlesztés egységei, amit végeredményben elvárhatunk az elkészítésre váró projekttől.

Cél, hogy minél részletesebben meghatározzuk mit szeretnénk látni a projekt végén és ezt le is kell írni. Nyílván nem feltétlenül lehet minden egyes részét maximális részletekbe menően definiálni, de erre törekedni lehet. És itt ez a kulcs. Minél jobban meg tudjuk határozni mit szeretnék, annál inkább tudjuk csökkenteni a projekt rizikófaktorait. pl:

  • Nem tudjuk mit szeretnénk… Mindenkinek az érdeke, hogy tudjuk mit szeretnénk létrehozni. Így növelhetjük a projekt sikerességének és az felek elégedettségének esélyét.
  • Félreértések a kivitelezővel, mit vártunk el, mit kaptunk meg? Ha tudjuk mit várhat el az ügyfél, akkor tudja, mit kérhet és mit nem kérhet számon.
  • Fejlesztési nézeteltérések. Például, ha nem tervezünk megfelelően, akkor a későbbiek folyamán lehetséges, hogy az az alap amit leraktunk, nem tudja megfelelően támogatni azt, amit 2-3 verzióval később szeretnénk látni. Így megvan az esélye, hogy újra kell valamit írni nulláról.
  • Mit tudunk és mit nem tudunk integrálni? Például harmadik fél megoldásokat, amelyekben lehet, hogy a funkció nagy része megvan, de testreszabni többe kerül, mint megírni tisztán elölről.
  • Ha nézeteltérések vannak, akkor az plusz időt és főleg plusz erőforrást fog magával vonni emberi és anyagi oldalon egyaránt.

Most, hogy elhelyeztük és definiáltuk a specifikáció szerepét és célját, nézzük meg milyen részekből épül fel.

A specifikáció részei

Sokféle módszer van arra, hogy meghatározzuk mit is szeretnénk csinálni fejlesztés címszó alatt. Úgy döntöttünk, hogy kidolgozunk egy saját specifikáció sablont. Sokéves tapasztalatunkat öntöttük bele egy olyan dokumentumba, amelyet szinte bármilyen fejlesztési projekt kapcsán tudunk alkalmazni (maximum kis módosítással). Természetesen szem előtt tartjuk, hogy a fejlesztések jó része termék fókuszú, így az agilis fejlesztési módszertannal is kompatibilis. Ezzel csak azt szeretnénk jelezni, hogy nem életszerű minden egyes aspektust 100%-ban definiálni, rugalmasságnak is muszáj maradnia. Az általunk készített sablon az alábbi részekből áll:

  1. Bevezetés
    1. Általános leírás a projektről, miről szól
    2. Kik szerepelnek benne kapcsolattartóként
    3. Kód verzió követése, file megosztás
    4. Milyen csatornán keresztül kommunikálnak a résztvevők
    5. Milyen operációs rendszereken fog futni
    6. Milyen eszközökön fog futni
    7. Hogyan lesz tesztelve
    8. Milyen adatkommunikációt alkalmaz
    9. Milyen fejlesztői környezetben készül
  2. Ha kikerül valamilyen store frontra a szoftver, akkor ott milyen információkat kell megadni
  3. Időzítés – a projekt milyen fázisokra van osztva és hogyan van ütemezve
  4. Navigáció – honnan hova lehet eljutni a szoftverben, milyen folyamatok, milyen képernyők vannak
  5. Funkciók
    1. Áttekintő lista a funkciókról
    2. Funkciók egyesével történő definiálása
      1. Leírás, hogy pontosan mit várunk el
      2. Ha van benne tartalom, akkor a tartalmi elvárások
      3. Screenshotok
      4. Adatkommunikáció

Összefoglalva: ne engedjük meg magunknak azt a luxust, hogy nem fektetjük le az alapjait a projektünknek és nem teszünk mellé egy végiggondolt tervet. Rövid és hosszútávon egyaránt érezhető lesz ennek a megtérülése időben, pénzben, energiában és idegsejtek számában is! Ha esetleg nincs megfelelő dokumentum erre a célra, akkor az általunk kialakított sablont az alábbi linken lehet megnézni, sőt akár le is tölteni!

https://canecom.com/specification/

@Andris