Ako správne naplánovať (väčší) projekt C Komunita

Dobrý večer komunita fóra,

Chcem to len vedieť,
aké triky a tipy používate na sledovanie ešte väčších projektov a odhadnutie, ako dlho to teraz bude trvať,
byť blízko svojho dokončenia.

Či už ide o ďalšiu skvelú hru alebo najlepší OS na svete.
Nejako to museli byť naplánované a zorganizované,
pretože nikto si len tak nesadne s nápadom a začne programovať, kým všetko nesedí.

Ako štruktúrujete plánovanie?
Ako hlboko by ste mali ísť do podrobností?

Tí, ktorí to plánujú, zjavne zarábajú najviac peňazí, pretože to nie je také ľahké. Zjednodušene povedané, začnete s hlavným problémom („operačný systém“) a rozdelíte ho na 2 alebo 3 čiastkové problémy („hardvér“ a „používateľské rozhranie“), ktoré potom rozdelíte na dva alebo tri čiastkové problémy a budete ich robiť, až kým sa nedostanete. v určitom okamihu dospel k programovým sekvenciám.

Nejako to museli byť naplánované a zorganizované,
pretože nikto si len tak nesadne s nápadom a začne programovať, kým všetko nesedí.

Mnoho projektov vychádza zhruba rovnako. To neznamená, že sa nerobí žiadny návrh softvéru. Plánovanie celého projektu vopred, vrátane časového rámca, sa však stane veľmi zriedka a potom zvyčajne nefunguje tak dobre.

ps: Založené na skutočne obrovských projektoch. Hry nie sú obrovské projekty, aspoň nie vtedy, keď staviate na hotovom engine. A „stredne veľké“ projekty sa dajú naplánovať celkom dobre, najmä ak už niekto „doménu“ pozná.

Moja predchádzajúca skúsenosť mi teda na jednej strane hovorí, že by som si to mal naplánovať presne tak, ako je to popísané vyššie, a na druhej strane, že je lepšie len napredovať a programovať, potom všetko vymazať a urobiť to znova bez všetkých chýb, pretože mi nejak chýba prax plánovať všetko od nuly.

Na druhej strane si myslím, že by som si mal veľmi dobre premyslieť, čo by program vlastne mal robiť. ak chcem postaviť auto, neposratím ho, ale premyslím si požiadavky (aký výkon, ktoré palivo, pohon predných alebo zadných kolies,.), naplánujem, spočítam a potom sa to v určitom okamihu poserie.

takže ak sa zaujímate o samotné metódy, vyhľadajte „softvérové inžinierstvo“ na Amazone alebo v miestnej univerzitnej knižnici.

Takže moja predchádzajúca skúsenosť mi na jednej strane hovorí, že by som si to mala naplánovať presne tak, ako je to popísané vyššie, a na druhej strane, že je lepšie jednoducho začať s programovaním, potom všetko vymazať a všetko zopakovať .

Klasické plánovanie zhora nadol (t. J. Od celkového nápadu po detail) môžete urobiť, iba ak máte prehľad o celom projekte a kto to robí? Preto by ste museli niečo podobné urobiť už skôr.

Ak to tak nie je, zvážte radšej plánovanie zdola nahor, najskôr navrhnite súčasti, vyvíjajte použiteľné prototypy (*) a potom príďte na to, ako to dať dohromady.

Pravdepodobne tu budete tiež potrebovať niekoľko iterácií, kým nebude všetko v poriadku, ale môžete urobiť skutočne nákladné chyby pri plánovaní (v polovici cesty, keď si chcete uvedomiť, že celkový plán nie je dobrý, alebo tráviť toľko času za posledných 10 percent ako pri prvých 90). dúfajme, že sa tomu vyhnete tak, že plánujete dom až potom, keď budete mať funkčné stavebné bloky.

(*) „Použiteľné prototypy“ znamenajú: dostatočnú funkčnosť na začiatok, nie však nevyhnutne nepriestrelné v každej situácii.

Na druhej strane si myslím, že by som si mal veľmi dobre premyslieť, čo by program vlastne mal robiť.

Čo program by mal byť schopný (a čo nie) by sa mal vopred zvážiť, je to tak. Musíte však oddeliť od čoho Ako.

ak chcem postaviť auto, neposratím ho, ale premyslím si požiadavky (aký výkon, ktoré palivo, pohon predných alebo zadných kolies,.), naplánujem, spočítam a potom sa to v určitom okamihu priskrutkuje.

Iste, robíte to, keď ste už postavili auto, alebo keď už viete, ako sa zvyčajne vyrábajú autá, pretože ostatní už vyrobili veľa automobilov.

Vo väčšine prípadov (bohužiaľ) sa najskôr požaduje niečo, potom by ste mali rýchlo ukázať masku obrazovky, potom prikývnuť a keď je obnažená kostra oblepená mäsom, vyjde každý, kto predtým iba prikývol a uvedomil si oni to vlastne chceli tak strašne inak.

Pre svoju prvú prácu som musel vytvoriť program, ktorý mal byť založený na holom povrchu systému DOS, ale s jednotlivými maskami, výberovými oknami, vyskakovacími oknami, riadkami, rámcami, pohodlnými editormi riadkov (oddelenými reťazcami integer a float) a skokmi tam a späť v rámci jednotlivé prvky.

Program teda narástol zdola nahor aj zhora nadol. Zospodu nahor najskôr definujte základné prvky a tie, ktoré na nich stavajú. Napr. Riadok a štvorec zložený zo štyroch riadkov.

Zároveň rozdeľte program zhora na jednotlivé základné prvky, napríklad Hlavný s výberom jednotlivých základných funkcií, a potom ich postupne rozdeľujte, kým sa nesplnia „hore“ a „dole“. Ak je to potrebné, naprogramujte z každej úrovne 1-2 prvky, aby ste získali prehľad o požadovanom čase, a sčítajte všetky prvky. A potom nezabudnite poskytnúť rezervu pre nepredvídané, podľa skúseností 10 - 100%.

PS: Dr. Günter Rothardt krát vydal knihu Practice of Software Development, ktorá sa témam venovala veľmi podrobne. Je však z roku 1987, a preto je ťažko dostupný. Ale možno sú ešte knižnice, ktoré si možno požičať.

Tiež si myslím, že najlepšia je kombinácia zhora nadol a zdola nahor.
Ak robíte iba zhora nadol, technické prekážky sa objavia príliš neskoro a naopak pri zdola nahor vám chýba základné pochopenie celkovej architektúry.
Špeciálne pre prototyp by ste mali vyvinúť piercing, ktorý je založený na architektúre a ktorý už obsahuje niektoré technické podrobnosti.

Plánovanie projektu však nie je len písanie kódu. Zahŕňa to všetky podpoložky zo softvérového inžinierstva (a iných netechnických nástrojov, ako je infraštruktúra, tímová komunikácia atď.).

Maska obrazovky nie je „holá kostra“, naopak, pokožka, ktorá sa na konci na ňu pretiahne. Vedúci projektu by si to nemali zamieňať a nemali by tým, ktorí rozhodujú, nechať veriť.

Subjekty s rozhodovacími právomocami, ktoré iba prikyvujú a nekladú otázky, ukazujú, že projektu nerozumeli. Skúsení projektoví manažéri to vedia a túžba spätná väzba. Ak osoby s rozhodovacími právomocami majú nielen prikývnuť, ale aj podpísať (svojím menom na kúsku papiera), potom sa zvyčajne prebudia.

Ďakujeme za množstvo veľmi užitočných odpovedí.

Najmä knižný tip, ale najskôr si pozriem, či ho v knižnici nájdem, až potom si ho kúpim. Sám o sebe sa zdá byť veľmi dobrý.

Aby som celú úvahu od čistej teórie viedol k hmatateľnému príkladu, začal som zhruba plánovať „herný engine“.

Ak s tým súvisím základný koncept, ktorý tu bol spomenutý, potom to bolo plánovanie zhora nadol.
Ďalej bude nasledovať pridanie zdola -> HORE.
Ihneď po dokončení by sa jednotlivé moduly osobitne vyvinuli a v prípade potreby by sa rozšírila celá štruktúra.

Pochopil som to správne alebo som tu urobil chybu?

Existuje krásne príslovie, ktoré znamená: „Otázka bola o nebi, odpoveďou bolo lano.“.

Viem iba, že existujú určité osvedčené a základné vybavenie.
Napr. Brožúra s protokolom s adresovaním obsahu alebo (žokejové) premiešanie podľa modelu alebo pracovného plánu podľa modelu x, y, z.
To sa dá urobiť rovnako ako neskôr, napríklad v hodnoteniach.

Namiesto (osvedčeného) teoretického modelu možno ako model v softvéri použiť iný program. Tabuľky alebo operačné systémy tiež začínali malé.

Pokiaľ ide o základné koncepty/plány, nemôžem sa zaobísť bez čmáranice papierom a ceruzkou.

V prípade programov je tu tiež nepríjemná otázka, aký je najnovší (hlavný/oficiálny) kód alebo kde som bol naposledy?
Riešením je opäť transparentnosť - ktorá sa dá prejaviť aj disciplinovanými alebo rituálnymi krokmi.

Dobrým pomocníkom pri plánovaní sú stále plagáty a poznámky A5. Plagáty možno tiež dobre prilepiť, ak potrebujete sledovanie šírky steny/veľkosti king.

Maska obrazovky nie je „holá kostra“, naopak, pokožka, ktorá sa na konci na ňu pretiahne. Vedúci projektu by si to nemali zamieňať a nemali by tým, ktorí rozhodujú, veriť.

Aby som celú úvahu od čistej teórie viedol k hmatateľnému príkladu, začal som zhruba plánovať „herný engine“.

Myslím, že to je teraz opäť niečo iné ako to, čo ste pôvodne požadovali. Požiadavky a požiadavky sú úplne odlišné. Vďaka hernému enginu sa zaoberáte čistým dizajnom softvéru. Projekt je veľmi dobre zvládnuteľný, možné požiadavky sú obmedzené a máte menej zainteresovaných strán.
Vo „veľkých“ a skutočných projektoch to zďaleka nie je len o definovaní triednych diagramov čo najčistejšie na čerstvom vzduchu. Väčšina problémov potom spočíva v tom, že musíte veľa robiť s rozvinutými štruktúrami, rozporuplnými požiadavkami, nejasnými požiadavkami, akýmikoľvek vlastnosťami, ktoré tu sú už desaťročia a ktoré zasahujú do nových požiadaviek, ktorých sa však nemôžete zbaviť bez dôležitých zákazníkov. rozrušiť atď.

Vlastne áno, ale zistil som, že „tvorcovia rozhodnutí“ zvyčajne nemôžu/nechcú myslieť ďalej ako na farebný obrázok.

Vlastne áno, ale zistil som, že „tvorcovia rozhodnutí“ zvyčajne nemôžu/nechcú myslieť ďalej ako na farebný obrázok. Najmä vo verejnej službe to ide od zamestnancov, lekárov a profesorov k zodpovedným rozhodovacím orgánom na ministerstvách.
V dobre fungujúcich spoločnostiach je to trochu inak. Ale nie vždy. Každý chce vidieť niečo farebné, pretože mu pripadá krásne alebo nie pekné.

Možno to vytvorí silné nedorozumenie. Napríklad, ak potrebujete program, ktorý hovorí, čo musí byť schopný, alebo sa môžete dohodnúť na funkciách popisným/dohodnutým spôsobom - potom sú najdôležitejšie funkcie/nástroje.
Napríklad https://www.tipp10.com/de/
Tu ide hlavne o základné funkcie (naučiť sa písať), databázu (vylepšenie alebo zaznamenávanie medzier, štatistika) alebo náklady a predovšetkým o to, či program funguje ako taký (mám program Dos-Konsoleprg, ktorý funguje podobne, ale minimálne rovnako dobrý). Raketa vzduch-zem, ktorá zasiahne určité tanky na zemi, nie je zázračná funkcia, mala by byť.

Kedy programátori systému Linux dostanú nápad, že by sa pri presúvaní okien nemali zrútiť počítače s internetovým prehliadačom založeným na oknách?
V tejto súvislosti (pod kapotou, zložitá téma) musím byť, že prehliadač Netscape mohol byť bezchybne používaný s myšou na systémoch Unix pred viac ako 20 rokmi.
(Neviem, ako je to dnes, buď v systémoch Unix chýba dôležitý ovládač, myš nefunguje, nefunguje internet (modul nebol rozpoznaný atď.)
alebo obrazovka zostane úplne čierna. Myš/Internet Nix najrozšírenejšie.)

Potom zostáva prvý dojem, že produkt je príliš komplikovaný alebo „nefunguje“ a používa ho iba neochotne.
.
Potom si vyskúšate vývojársku verziu
.
Potom prídu k stolu produktoví manažéri a konzultanti .

. A tým sa dostávame k verzii 3, uplynul rok a stále nie je k dispozícii nič vhodné pre zákazníkov. Toto je bohužiaľ normálny prípad, keď vývojári prichádzajú s produktom, pretože ho nechce robiť nikto iný. Musí to byť inak.

Hneď ako sa rozhodne, že Ak má byť produkt vyvíjaný, musí si každý (produktoví manažéri, konzultanti, predaj) pridať svoju horčicu a robiť tak rýchlo. Musia, je to súčasť ich práce, nemôžu sa len tak odvážiť. Pokiaľ sa tak nestalo, vývoj sa nezačne, pretože požiadavky sú stále nejasné, je to také jednoduché. (Skutočnosť, že niektoré časti, ktoré prídu na sto percent, je možné pripraviť v určitom okamihu, je iná vec. Platí to však predovšetkým Líniové veci pod kapotou).

A to „pridanie horčice“ tiež nie je jednosmerka. Dotazy a diskusie môžu a mali by byť urobené. Ľudia sa často pýtajú na veľmi špeciálne veci: „Chceme tlačidlo XY“, a keď sa ho spýtate a zamyslíte sa, ukáže sa, že XY je s rozbaľovacím zoznamom ešte lepší.

Vzhľadom na to, čo je spomenuté v tejto fáze a klasifikované ako dôležité (nie všetko, čo individuálny konzultant považuje za dôležité, je skutočne dôležité - ale to isté platí aj pre vývojárov), vývojový tím zostavuje prototyp. Keď je predstavený, nikto si nemôže sťažovať, že „nefunguje“ - pokiaľ to skutočne nefunguje tak, ako je uvedené.

Najmä knižný tip, ale najskôr si pozriem, či ho v knižnici nájdem, až potom si ho kúpim. Sám o sebe sa zdá byť veľmi dobrý.

S trochou hľadania ho nájdete dokonca za 4,95 eura:
https://www.amazon.de/Praxis-Softwareentwicklung-G%C3%BCnter-Rothhardt/dp/B0029GQ0ZW/ref=sr_1_2?s=books&ie=UTF8&qid=1518522238&sr=1-2
Cesta do najbližšej knižnice je nákladnejšia a mali by ste mať vo svojej vlastnej poličke dobré odborné knihy.

To nie. Na začiatku sú požiadavky väčšinou nejasné a tiež sa časom menia.

Názov vlákna je „Ako naplánovať väčší projekt správne?„

A na začiatku správneho plánovania sú jasné požiadavky. Pokiaľ chýbajú, žiadne nie sú pravá Plánovanie, len neisté plánovaniesnaží, ktoré je možné kedykoľvek znovu zhromaždiť.

Ak je to každému (vrátane vedenia) jasné, nič nebráni tomu, aby sa vývoj „motal“ a „štúdie uskutočniteľnosti“, pretože to je všetko. Ale ak vývoj dostane za to ranu („strácate čas a nič z toho nevychádza“), potom je čas sa opýtať, čo sa vlastne očakáva a čo by malo vyjsť.

Nemôže sa stať, že vývoj bude pracovať na produktovom manažmente/predaji/konzultácii a vymyslí si, ktoré produkty s ktorými vlastnosťami budú v budúcnosti potrebné.