1) MVP = čo to má robiť + čo to nesmie porušiť

MVP nie je len zoznam funkcií.

Je to:

• čo má aplikácia robiť (služby systému),

• a aké pravidlá musí dodržať (obmedzenia / constraints).

Dôležité: píš ČO to má robiť, nie AKO to naprogramuješ (WHAT, nie HOW).

2) Požiadavky nerobíš raz. Robíš ich stále dokola.

Ak to spravíš len raz na začiatku, skoro určite sa trafíš vedľa.

Správny postup vyzerá takto (a opakuje sa):

zistiť → vybrať najdôležitejšie → spísať → skontrolovať → zlepšovať

(discovery → prioritizácia → špecifikácia → verifikácia & validácia → management & evolúcia)

Ako to zistiť v praxi:

• Zistiť (1–2 týždne): porozprávaj sa s ľuďmi, sprav workshop, pozeraj ako to robia dnes (interviews, workshops, ethnography).

• Vybrať: rozdeľ veci na:

  • musí byť / malo by byť / môže byť / nemá byť

    (MoSCoW: Must/Should/Could/Won’t).

• Skontrolovať text požiadaviek: musia byť jasné, úplné, reálne a dajú sa otestovať

  (complete, consistent, precise, verifiable, realistic).

• Overiť s realitou: či ľudia fakt chcú presne toto (ukáž prototyp, sprav review, testuj)

  (validation: prototyping, reviews, A/B tests).

Tvrdý fakt: keď zle pochopíš požiadavky a zistíš to až po dodaní, môže to stáť až 100× viac, než keď to opravíš hneď.

3) “Neviditeľné” požiadavky rieš hneď (nie až keď horí)

Niektoré veci nie sú funkcie typu “tlačidlo” alebo “checkout”. Sú to pravidlá kvality:

• rýchlosť (performance),

• bezpečnosť (security),

• spoľahlivosť (reliability),

• pravidlá/štandardy,

• platforma (iOS/Android/web),

• časové limity (timing constraints).

Tieto veci vedia úplne zmeniť, ako bude aplikácia postavená (architecture). Keď ich ignoruješ, neskôr sa to prerába draho.

4) Urob jednoduché obrázky/modely, aby všetci videli to isté

Ľudia si pod textom predstavujú každí niečo iné. Preto rob modely.

Najjednoduchšie, čo stačí:

• kto čo robí v appke (use case),

• z čoho sa appka skladá (components / classes),

• ako to ide krok po kroku (sequence / activity),

• aké stavy to môže mať (state).

Tip poradia (zdravý rozum):

1. čo to má robiť (requirements)

2. ako to celé funguje (analysis)

3. ako to postavíš (design)

5) Architektúra = vyrieš najdrahšie rozhodnutia skôr

Architektúra je “kostra” aplikácie.

Ak ju pokašleš, všetko ďalšie je drahé.

Minimálne si rozhodni:

• na aké časti to rozdelíš (modules),

• aký štýl bude mať systém (architectural style),

• kto koho riadi (control strategy),

• kde čo beží (server, mobil, cloud) (distribution/deployment),

• ako to zapíšeš (dokumentácia),

• ako skontroluješ, že je to dobré (architecture evaluation).

6) Rob to v krátkych kolách, nie “3 mesiace ticho”

Najlepšie funguje:

• spraviť malý kus,

• ukázať,

• získať feedback,

• upraviť.

To je agile (iterations, stakeholder communication, quality, regular delivery).

Scrum minimum:

• sprinty 1–4 týždne,

• plánovanie, krátke denné checky, ukážka, zhodnotenie,

• zoznam práce (backlog),

• malé úlohy napísané normálne:

  “Ako používateľ chcem…, aby som…” (user story).

Pozor: keď nemáš jasný cieľ, agile sa zmení na chaos. A ľudia radi odsúvajú dokumentáciu.

7) Dáta: uprac si databázu, inak sa zasekneš na bordeli

Keď máš v dátach chaos, MVP sa začne kaziť.

Urob:

• čo sú hlavné veci (entity),

• ako spolu súvisia (vzťahy),

• čo o nich ukladáš (atribúty)

  (ERD – entity relationship diagram).

A nastav to tak, aby si nemal zbytočne duplicitné údaje (normalization).

8) Implementácia: malé kroky + kontrola, aby sa to nerozbíjalo

Najlepšie funguje:

• robiť po malých častiach (incremental),

• testovať priebežne (continuous testing),

• priebežne spájať zmeny do jedného kódu (continuous integration),

• mať poriadok vo verziách (configuration management),

• upratovať kód a zlepšovať ho (refactoring, design patterns).

Bonus: TDD znamená: najprv napíšeš test, potom kód (test-driven development). Pomáha stabilite, ale nie vždy je nutné všade.

9) Testovanie a kvalita: meraj, čo chceš zlepšiť

Kvalita znamená: produkt spĺňa požiadavky (ISO view).

Najdôležitejšie vlastnosti:

• aby sa dal ľahko upravovať (maintainability),

• bol rýchly (performance),

• nesekal (reliability),

• dal sa testovať (testability),

• zvládol rast (scalability),

• bezpečnosť a použiteľnosť (security, usability).

Testovanie ide typicky:

požiadavky → unit testy → integrácia → systém → akceptácia → výkon/bezpečnosť/použiteľnosť.

3–6 mesačný plán (jednoducho)

Mesiac 1: Správny problém + správny scope

• zistiť požiadavky (WHAT, nie HOW)

• vyrezať MVP cez MoSCoW

• skontrolovať a overiť požiadavky

• definovať aj “neviditeľné” požiadavky (rýchlosť, bezpečnosť…)

Mesiac 2: Modely + architektúra + prototyp

• základné modely (use-case, flowy)

• rozhodnúť architektúru (kostru)

• urobiť ERD (dáta)

• klikateľný prototyp + test s ľuďmi

Mesiac 3–6: Iterácie, build, test, release

• sprinty + backlog + pravidelné ukážky

• vývoj po malých častiach + CI + priebežné testy

• funkčné aj nefunkčné testy (výkon/bezpečnosť/použiteľnosť)

• zmeny požiadaviek riešiť “procesom”, nie panikou (každú zmenu analyzovať)