Szoftvertervezes,hogy mukodik?

3: "Úgy is fogalmazhatunk, hogy a konkurencia már a piacra viszi a terméket, mire te elkészülsz a tervezéssel."

Úgy is fogalmazhatunk, hogy ti szoptok végkimerülésig, azt sem tudjátok milyen nap van, mert az életetek nem áll másból, csak újratervezésből és gányolásból.

Amúgy meg, amit írsz, az két dolgot mutat:

1. Nem vagy képesített fejlesztő, csak egy kontár.

2. Életedben nem dolgoztál még valamirevaló munkán, csak egy-kétezer soros kis szarokon.

A tervezés fázisai ugyan cégenként eltérőek lehetnek, de kb. ezek:

- befut a megrendelés.

- Az architektek vezetője felveszi a kapcsolatot a megrendelő konzulensével. Ez utóbbi az aki tud mindent arról, hogy a cégnek mi is kellene és hogyan.

- Az architekt az infók ismeretében megkezdi a dekompozicionálást, azaz, meghatározza az applikációban használt adatszerkezeteket, tagolja a munkafázisokat. Felméri és kiszámolja az applikáció, vagy rendszer hardver-igényét. Megállapítja a szükséges redundancia fokát.

- Tovább finomít, szeparálja a program belső szerkezetét, mindezt dokumentálja is, persze. Vannak erre célszoftverek, de saját is gyakran előfordul. Akár egészen a függvények szintjéig lemehet ez, de ilyet általában csak rendelésre csinálnak, ha másvalaki lesz az implementátor.

- Ha ez megvan, akkor a feladatok kikerülnek a teamlead-ekhez, akik a csoportjuk ismeretében kiosztják a hangyáknak feladatokat.

Ha komoly, időkritikus szoftver készül, akkor a klf. rész-feladatok kapnak "processzort" és "memóriát" is, ami rendre kevés, szűkre szabott, így

ezekért késhegyig menő harcot szoktak vívni.

Hát kb úgy hogy senki se látja át a teljes szoftvert, a scrum miatt ~jó lesz majd mindig a következő pár lépést látni.

Meg elkapkodott dizájn diktálja a fő feature-ket, aminek a készítője UX-ról nem is hallott stb....

Én sokkal lényegesebbnek gondolnám a tervezést és nem arra kéne használni a scrumot hogy majd menet közben kényelmesen összetákoljuk ami igény felmerül.