Cum să planificați corect un proiect (mai mare) Comunitate C.

Bună seara comunitate forum,

Eu vreau doar să știu,
ce trucuri și sfaturi folosiți pentru a urmări proiectele și mai mari și pentru a estima cât de mult va dura acum,
să fie aproape de finalizare.

Fie că este următorul mare joc sau cel mai bun sistem de operare din lume.
Cumva acestea trebuie să fi fost planificate și organizate,
pentru că nimeni nu se va așeza doar cu o idee și va începe programarea până când totul nu se potrivește.

Cum structurați planificarea?
Cât de adânc ar trebui să intri în detalii?

Se presupune că cei care intenționează să facă acest lucru câștigă cei mai mulți bani pentru că nu este atât de ușor. Pur și simplu, începeți cu problema principală („sistemul de operare”) și o împărțiți în 2 sau 3 subprobleme („hardware” și „interfață cu utilizatorul”), pe care apoi le împărțiți în două sau trei subprobleme și faceți acest lucru până când obțineți la un moment dat a ajuns la secvențele programului.

Cumva acestea trebuie să fi fost planificate și organizate,
pentru că nimeni nu se va așeza doar cu o idee și va începe programarea până când totul nu se potrivește.

Multe proiecte apar în același mod. Asta nu înseamnă că nu se realizează nicio proiectare software. Dar planificarea întregului proiect în avans, inclusiv intervalul de timp, se întâmplă foarte rar și, de obicei, nu funcționează atât de bine.

ps: Bazat pe proiecte cu adevărat uriașe. Jocurile nu sunt proiecte uriașe, cel puțin nu atunci când construiești pe un motor terminat. Și proiectele „mijlocii” pot fi planificate destul de bine, mai ales dacă cineva este deja familiarizat cu „domeniul”.

Deci, experiența mea anterioară îmi spune, pe de o parte, că ar trebui să o planific exact așa cum este descris mai sus și, pe de altă parte, că este mai bine să mergi înainte și să programe, apoi să ștergi totul și să o faci din nou fără toate greșelile, pentru că cumva îmi lipsește practica de a planifica totul de la zero.

Pe de altă parte, cred doar că ar trebui să mă gândesc foarte atent la ceea ce ar trebui să poată face programul. dacă vreau să construiesc o mașină, nu o înșurubez doar, ci mă gândesc la cerințe (ce putere, ce combustibil, tracțiunea față sau spate), planificați, calculați și apoi la un moment dat este înșurubată.

deci, dacă sunteți interesat de metodele în sine, căutați „inginerie software” pe Amazon sau în biblioteca universității locale.

Așadar, experiența mea anterioară îmi spune, pe de o parte, că ar trebui să o planific exact așa cum este descris mai sus și, pe de altă parte, că este mai bine să începi doar să programe, apoi să ștergi totul și să o faci din nou. .

Puteți face o planificare clasică de sus în jos (adică de la ideea generală până la detalii) numai dacă aveți o imagine de ansamblu a proiectului în întregime și cine face asta? Pentru asta ar fi trebuit să fi făcut ceva foarte asemănător înainte.

Dacă nu este cazul, luați în considerare în schimb planificarea de jos în sus, mai întâi proiectați piesele, dezvoltați prototipuri utilizabile (*) și apoi aflați cum să puneți totul împreună.

Probabil că veți avea nevoie de mai multe iterații și aici, până când totul se simte bine, dar puteți face erorile de planificare foarte costisitoare (la jumătatea drumului pentru a vă da seama că planul general nu este bun sau puteți petrece la fel de mult timp pentru ultimele 10 la sută ca pentru primele 90) Sperăm să o eviți, planificând casa doar după ce ai blocuri funcționale.

(*) „Prototipuri utilizabile” înseamnă: funcționalitate suficientă pentru a începe ceva, dar nu neapărat antiglonț în orice situație.

Pe de altă parte, cred doar că ar trebui să mă gândesc foarte atent la ceea ce ar trebui să poată face programul.

Ce programul ar trebui să poată (și ce nu) ar trebui luat în considerare în prealabil, așa este. Dar trebuie să separi de ce La fel de.

dacă vreau să construiesc o mașină, nu o înșurubez doar, ci mă gândesc la cerințe (ce putere, ce combustibil, tracțiunea față sau spate), planificați, calculați și apoi la un moment dat este înșurubată.

Sigur, faci asta dacă ai construit deja o mașină sau dacă știi deja cum sunt construite de obicei mașinile, deoarece alții au construit deja multe mașini.

În majoritatea cazurilor (din păcate) se solicită mai întâi ceva, apoi ar trebui să arăți rapid o mască de ecran, apoi se dă din cap, iar când scheletul gol este atârnat cu carne iese toți cei care au dat din cap doar din cap și își dau seama că chiar au vrut-o atât de diferit.

Pentru prima mea teză, a trebuit să creez un program care trebuia să se bazeze pe o suprafață DOS goală, dar cu măști individuale, ferestre de selecție, ferestre pop-up, linii, cadre, editoare de linii confortabile (separate prin șiruri întregi și plutitoare) și sărind înainte și înapoi în elemente individuale.

Deci, programul a crescut atât de jos în sus, cât și de sus în jos. În primul rând, definiți elementele de bază de bază de jos și cele care se bazează pe ele. Deci, de ex. Linie și pătrat format din patru linii.

În același timp, descompuneți programul de sus în elementele individuale de bază, de ex. Principal cu selectarea funcțiilor de bază individuale și apoi împărțirea lor pas cu pas până se întâlnesc „deasupra” și „dedesubtul”. Apoi, dacă este necesar, codificați 1-2 elemente din fiecare nivel pentru a obține o prezentare generală a timpului necesar și pentru a adăuga toate elementele. Și apoi nu uitați să oferiți un tampon pentru neprevăzut, 10 - 100% în funcție de experiență.

PS: Dr. Günter Rothardt folosește cartea Praxis der Softwareentwicklung, care a tratat subiectele în detaliu. Dar este din 1987 și, prin urmare, nu este disponibil. Dar poate că mai sunt încă biblioteci de împrumutat.

De asemenea, cred că este mai bună combinația de sus în jos și de jos în sus.
Dacă faceți doar top-down, obstacolele tehnice sunt descoperite mult prea târziu și, dimpotrivă, cu bottom-up, nu aveți o înțelegere de bază a arhitecturii generale.
Mai ales pentru un prototip, ar trebui să dezvoltați un piercing bazat pe arhitectură și care conține deja câteva detalii tehnice.

Dar planificarea unui proiect este mai mult decât simpla scriere a codului, aceasta include toate sub-elementele din ingineria software (și alte tipuri non-tehnice, cum ar fi infrastructura, comunicarea în echipă etc.).

Masca ecranului nu este „scheletul gol”, dimpotrivă, pielea care este trasă peste el la final. Liderii de proiect nu ar trebui să confunde acest lucru și nu ar trebui să lase factorii de decizie să creadă acest lucru.

Factorii de decizie care fac din cap și nu pun întrebări arată că nu au înțeles proiectul. Managerii de proiect cu experiență știu asta și dorință feedback-ul. Când factorii de decizie sunt rugați să nu doar să dea din cap, ci să semneze (cu numele lor pe o bucată de hârtie), atunci se trezesc de obicei.

Vă mulțumim pentru numeroasele răspunsuri foarte utile.

Mai ales sfatul cărții, dar voi vedea mai întâi dacă îl găsesc în bibliotecă înainte să-l cumpăr. În sine pare a fi foarte bun.

Pentru a conduce întreaga considerație de la teoria pură la un exemplu tangibil, am început să planific aproximativ un „motor de joc”.

Dacă pun în legătură conceptul de bază menționat aici cu acest lucru, atunci acesta a fost planificarea de sus -> în jos.
Urmează o adăugare Bottom -> UP.
De îndată ce acest lucru este finalizat, modulele individuale ar fi dezvoltate în mod specific și întreaga structură ar fi extinsă dacă este necesar.

Am înțeles asta corect sau am greșit aici?

Există o zicală frumoasă care înseamnă: „Întrebarea a fost despre cer, răspunsul a fost o frânghie”.

Știu doar că există anumite echipamente de bază încercate și testate.
De exemplu. o broșură de protocol cu adresarea conținutului sau (asemănătoare cu roata de jockey) agățată de-a lungul unui model sau a unui plan de lucru conform modelului x, y, z.
Puteți face acest lucru mai târziu la, de ex. Gestionează astfel de evaluări.

În loc de un model teoretic (dovedit), un alt program poate fi folosit ca model în software. De asemenea, foile de calcul sau sistemele de operare au început să fie mici.

Când vine vorba de schițe/planuri de bază, nu mă pot descurca fără a mâzgăli cu hârtie și creion.

În cazul programelor, există și întrebarea enervantă despre care este cel mai recent cod (principal/oficial) sau unde am fost ultima dată?
Soluția aici este din nou transparența - care poate fi exprimată și printr-un comportament disciplinat sau ritualizat.

Ajutoarele de planificare bune sunt încă afișe și note A5. Afișele pot fi, de asemenea, lipite între ele dacă aveți nevoie de monitorizarea lățimii pereților/a dimensiunii king-size.

Pentru a conduce întreaga considerație de la teoria pură la un exemplu tangibil, am început să planific aproximativ un „motor de joc”.

Cred că acum este ceva diferit de ceea ce ai cerut inițial. Cerințele și cerințele sunt complet diferite. Cu un motor de joc, sunteți preocupat de designul pur al software-ului. Proiectul este foarte ușor de gestionat, cerințele posibile sunt limitate și aveți mai puține părți interesate.
În proiectele „mari” și reale, nu este de departe vorba doar de definirea diagramelor de clasă cât mai curate posibil în aer liber. Atunci majoritatea problemelor provin din faptul că trebuie să faci multe lucruri cu structuri stabilite, cerințe contradictorii, cerințe neclare, orice caracteristici care există de zeci de ani și interferează cu noile cerințe, dar de care nu poți scăpa fără clienți importanți a supara etc.

De fapt da, dar am constatat că „factorii de decizie” de obicei nu pot/nu vor să gândească mai departe decât o imagine colorată.

De fapt da, dar am constatat că „factorii de decizie” de obicei nu pot/nu vor să gândească mai departe decât o imagine colorată. În special în serviciul public, acest lucru merge de la angajați, medici și profesori la factorii de decizie responsabili din ministere.
În companiile bine conduse, lucrurile stau puțin diferit. Dar nu in totdeauna. Toată lumea vrea să vadă ceva colorat, pentru că poate i se pare sau nu frumos.

Poate că acest lucru creează o puternică neînțelegere. Dacă de ex. un program are nevoie, spune ce trebuie să poată face sau poți conveni asupra funcțiilor într-un mod descriptiv/unanim - atunci funcțiile/instrumentele sunt cele mai importante.
De exemplu https://www.tipp10.com/de/
Aici este vorba, în principal, de funcțiile de bază (învățarea de a scrie), baza de date (îmbunătățirea sau înregistrarea lacunelor, statistici) sau costurile și, mai presus de toate, că programul funcționează ca atare (am un Dos-Konsoleprg care funcționează similar, dar cel puțin la fel de bine). O rachetă aer-suprafață care lovește anumite tancuri de la sol nu ar trebui să fie o funcție miraculoasă.

Când au programatorii Linux ideea că computerele cu un browser de Internet bazat pe ferestre nu ar trebui să se blocheze atunci când ferestrele sunt mutate?
Trebuie să fac acest lucru (sub capotă, subiect complex) este că browserul Netscape ar putea fi folosit fără erori cu mouse-ul pe sistemele Unix acum 20 de ani.
(Nu știu cum este astăzi, fie un driver important lipsește din sistemele Unix, mouse-ul nu funcționează, internetul nu funcționează (modulul nu este recunoscut etc.)
sau ecranul rămâne complet negru. Mouse/Internet Nix cel mai răspândit.)

Apoi rămâne prima impresie că produsul este prea complicat sau „nu funcționează” și îl folosește doar cu reticență.
.
Apoi, încercați mâna la următoarea versiune ca dezvoltator
.
Apoi, managerii de produse și consultanții vin la masă .

. și asta ne aduce la versiunea 3, a trecut un an și încă nu este disponibil nimic potrivit pentru clienți. Din păcate, acesta este cazul normal când dezvoltatorii vin cu produsul, deoarece nimeni altcineva nu vrea să o facă. Trebuie să fie altfel.

De îndată ce se ia decizia, acea Dacă produsul urmează să fie dezvoltat, toată lumea (manageri de produs, consultanți, vânzări) trebuie să își adauge muștarul și să facă acest lucru cu promptitudine. Trebuie să facă asta, face parte din treaba lor, nu se pot aventura doar afară. Atâta timp cât acest lucru nu s-a întâmplat, dezvoltarea nu începe, deoarece cerințele sunt încă neclare, este atât de simplu (faptul că anumite părți care vor veni sută la sută pot fi pregătite la un moment dat este o altă problemă. Dar asta se aplică în primul rând Așezați lucrurile sub capotă).

Și că „adăugarea muștarului” nu este, de asemenea, un sens unic. Întrebările și discuțiile pot și trebuie făcute. Adesea oamenii întreabă lucruri foarte speciale: „Vrem butonul XY” și, atunci când întrebi și te gândești la asta, se dovedește că XY este chiar mai bun cu o listă derulantă.

Cu ceea ce este menționat și clasificat ca important în această fază (nu tot ceea ce un consultant individual consideră important este de fapt important - dar același lucru este valabil și pentru dezvoltatori), echipa de dezvoltare construiește un prototip. Când este prezentat, nimeni nu se poate plânge că „nu funcționează” - decât dacă de fapt nu funcționează așa cum sa discutat.

Mai ales sfatul cărții, dar voi vedea mai întâi dacă îl găsesc în bibliotecă înainte să-l cumpăr. În sine pare a fi foarte bun.

Cu o mică căutare îl puteți găsi chiar și la 4,95 euro:
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
Călătoria la cea mai apropiată bibliotecă este mai scumpă și ar trebui să aveți cărți de specialitate bune pe propriul raft.

De îndată ce se ia decizia, acea Dacă produsul urmează să fie dezvoltat, toată lumea (manageri de produs, consultanți, vânzări) trebuie să își adauge muștarul și să facă acest lucru cu promptitudine. Trebuie să facă asta, face parte din treaba lor, nu se pot aventura doar afară. Atâta timp cât acest lucru nu s-a întâmplat, dezvoltarea nu va începe, deoarece cerințele sunt încă neclare, este atât de simplu.

Nu, nu. La început, cerințele sunt de obicei neclare și, de asemenea, se modifică în timp.

Titlul firului este „Cum să planifici un proiect mai mare corect?"

Și la începutul unei planificări adecvate există cerințe clare. Atâta timp cât lipsesc, nu există cel corect Planificare, doar planificare nesigurăîncearcă, care pot fi colectate din nou oricând.

Dacă acest lucru este clar pentru toată lumea (inclusiv pentru conducere), nu există nimic care să împiedice dezvoltarea să „încurce” și să organizeze „studii de fezabilitate”, pentru că asta este tot. Dar dacă dezvoltarea primește o lovitură pentru ea („pierzi timpul și nu iese nimic din el”), atunci este timpul să întrebi ce se așteaptă de fapt și ce ar trebui să iasă.

Nu se poate ca dezvoltarea să facă munca de management al produselor/vânzări/consultanță și să gândească ce produse cu care proprietăți vor fi necesare în viitor.