Как правилно да планирате (по-голям) проект C Общност

Добър вечер форум общност,

просто искам да знам,
какви трикове и съвети използвате, за да следите дори по-големи проекти и да прецените колко време ще отнеме сега,
да е близо до завършването си.

Независимо дали е следващата страхотна игра или най-добрата операционна система в света.
По някакъв начин те трябва да са били планирани и организирани,
защото никой няма просто да седне с идея и да започне да програмира, докато всичко се побере.

Как структурирате планирането?
Колко дълбоко трябва да навлизате в подробности?

Очевидно тези, които планират да направят това, печелят най-много пари, защото не е толкова лесно. Казано по-просто, започвате с основния проблем ("операционна система") и го разделяте на 2 или 3 подпроблеми ("хардуер" и "потребителски интерфейс"), които след това разбивате на два или три подпроблеми и правите това, докато не получите в някакъв момент е стигнал до програмните последователности.

По някакъв начин те трябва да са били планирани и организирани,
защото никой няма просто да седне с идея и да започне да програмира, докато всичко се побере.

Много проекти се появяват по същия начин. Това не означава, че не е направен софтуерен дизайн. Но планирането на целия проект предварително, включително времевата рамка, това се случва много рядко и след това обикновено не се получава толкова добре.

ps: Въз основа на наистина огромни проекти. Игрите не са огромни проекти, поне не когато надграждате завършен двигател. И „средно големи“ проекти могат да бъдат планирани доста добре, особено ако вече сте запознати с „домейна“.

Така че предишният ми опит ми казва от една страна, че трябва да го планирам точно както е описано по-горе, а от друга страна, че е по-добре просто да продължа и да прогресирам, след това да изтрия всичко и да го направя отново, без всички грешки, защото някак ми липсва практика да планирам всичко от нулата.

От друга страна, просто мисля, че трябва да помисля много внимателно какво всъщност трябва да може да направи програмата. ако искам да построя кола, не просто я прецаквам, а мисля за изискванията (коя мощност, кое гориво, задвижване отпред или отзад,.), планирам, изчислявам и след това в един момент тя ще бъде прецакана.

така че, ако се интересувате от самите методи, потърсете „софтуерно инженерство“ на amazon или в местната университетска библиотека.

Така че предишният ми опит ми казва, от една страна, че трябва да го планирам точно както е описано по-горе, а от друга страна, че е по-добре просто да продължа и да прогресирам, след това да изтрия всичко и да направя всичко отначало .

Можете да направите класическо планиране отгоре надолу (т.е. от общата идея до детайла) само ако имате общ преглед на проекта като цяло и кой го прави? За това би трябвало да сте направили нещо много подобно преди.

Ако случаят не е такъв, помислете за планиране отдолу нагоре, като първо проектирате частите, разработвате използваеми прототипи (*) и след това разберете как да съберете всичко това.

Вероятно и тук ще ви трябват няколко итерации, докато всичко се почувства както трябва, но можете да направите наистина скъпите грешки при планирането (по средата на осъзнаването, че общият план не е добър, или да отделите толкова време за последните 10 процента, колкото за първите 90) надяваме се да го избегнете, като планирате къщата само след като имате функционални градивни елементи.

(*) „Използвани прототипи“ означава: достатъчна функционалност, с която да започнете нещо, но не непременно защитена от куршуми във всяка ситуация.

От друга страна, мисля, че трябва много внимателно да помисля какво всъщност трябва да може да направи програмата.

Какво програмата трябва да може (и какво ли още не) трябва да се обмисли предварително, така е. Но трябва да отделите от какво Като.

ако искам да построя кола, не просто я прецаквам, а мисля за изискванията (коя мощност, кое гориво, задвижване отпред или отзад,.), планирам, изчислявам и след това в един момент тя ще бъде прецакана.

Разбира се, правите това, ако вече сте построили автомобил или ако вече знаете как се строят колите, защото други вече са построили много автомобили.

В повечето случаи (за съжаление) първо се иска нещо, след това трябва бързо да покажете маска на екрана, след това се кима и когато голият скелет е окачен с месо, излизат всички, които само кимват предварително и осъзнават, че те всъщност го искаха толкова много различно.

За първата ми дипломна работа трябваше да създам програма, която трябваше да се основава на гола DOS повърхност, но с индивидуални маски, прозорци за селекция, изскачащи прозорци, линии, рамки, удобни редактори на линии (разделени от низове цяло число и плувка) и скачане напред и назад в рамките на отделни елементи.

Така че програмата е нараснала както отдолу нагоре, така и отгоре надолу. Отдолу нагоре първо дефинирайте основните елементи и тези, които се надграждат върху тях. Така напр. Линия и квадрат, направени от четири линии.

В същото време разбийте програмата отгоре на отделните основни елементи, напр. Основно с избор на отделните основни функции и след това разделянето им стъпка по стъпка, докато се срещнат „отгоре“ и „отдолу“. След това, ако е необходимо, кодирайте 1-2 елемента от всяко ниво, за да получите общ преглед на необходимото време и да добавите всички елементи. И тогава не забравяйте да осигурите буфер за непредвиденото, в зависимост от опита 10 - 100%.

PS: Dr. Гюнтер Ротхард разглежда книгата „Практика за разработване на софтуер“, която е разглеждала темите много подробно. Но е от 1987 г. и следователно едва ли е достъпен. Но може би все още има библиотеки за заемане.

Също така мисля, че комбинацията отгоре надолу и отдолу нагоре е най-добра.
Ако правите само отгоре-надолу, техническите препятствия се откриват твърде късно и, обратно, при отдолу-нагоре ви липсва основно разбиране за цялостната архитектура.
Специално за прототип, трябва да разработите пиърсинг, който се основава на архитектурата и вече съдържа някои технически подробности.

Но планирането на проект е нещо повече от просто писане на код, това включва всички под-елементи от софтуерното инженерство (и други нетехнически, като инфраструктура, екипна комуникация и т.н.).

Екранната маска не е „голият скелет“, а напротив, кожата, която е изтеглена върху нея в края. Ръководителите на проекти не трябва да объркват това и не трябва да позволяват на хората, които вземат решения да вярват в това.

Вземащите решения, които само кимват и не задават въпроси, показват, че не са разбрали проекта. Опитните ръководители на проекти знаят, че и желание обратната връзка. Когато взимащите решения са помолени не просто да кимват, а да подпишат (с имената си на лист хартия), тогава те обикновено се събуждат.

Благодаря ви за многобройните много полезни отговори.

Особено съветът за книгата, но първо ще видя дали мога да го намеря в библиотеката, преди да го купя. Само по себе си изглежда много добре.

За да преведа цялото съображение от чистата теория до осезаем пример, започнах грубо да планирам „игрален механизъм“.

Ако се позова на основната концепция, която беше спомената тук, тогава това беше планиране отгоре -> надолу.
Следва следващо добавяне отдолу -> НАГОРЕ.
Веднага след като това приключи, отделните модули ще бъдат специално разработени и цялата структура ще бъде разширена, ако е необходимо.

Разбрах ли това правилно или допуснах грешка тук?

Има една красива поговорка, която означава: „Въпросът беше за небето, отговорът беше въже“.

Знам само, че има определено изпитано основно оборудване.
Напр. брошура с протокол с адресиране на съдържанието или (подобно на джокей колело), висяща по модел или работен план според модел x, y, z.
Можете да направите това по-късно на напр. Обработвайте оценки като тази.

Вместо (доказан) теоретичен модел, като софтуер може да се използва друга програма. Електронните таблици или операционните системи също започнаха от малки.

Що се отнася до основните чернови/планове, не мога да направя, без да драскам с хартия и молив.

В случай на програми, има и досаден въпрос кой е най-новият (основен/официален) код или къде бях за последно?
Решението тук отново е прозрачността - която може да се изрази и в дисциплинирани или ритуализирани действия.

Добри помощни средства за планиране все още са плакати и бележки A5. Плакатите също могат да бъдат слепени добре, ако се нуждаете от наблюдение на ширината на стената/размера на краля.

Екранната маска не е „голият скелет“, а напротив, кожата, която е изтеглена върху нея в края. Ръководителите на проекти не трябва да бъркат това и не трябва да позволяват на хората, които вземат решения да вярват в това.

Мисля, че сега отново е нещо различно от това, което първоначално поискахте. Изискванията и условията са напълно различни. С игрален двигател вие сте загрижени за чистия дизайн на софтуера. Проектът е много управляем, възможните изисквания са ограничени и имате по-малко заинтересовани страни.
При „големите“ и реални проекти далеч не става дума само за дефиниране на диаграми на класовете възможно най-чисто на открито. Тогава повечето проблеми идват от факта, че трябва да правите много с установени структури, противоречащи на изискванията, неясни изисквания, всякакви функции, които съществуват от десетилетия и пречат на нови изисквания, но които не можете да се отървете без важни клиенти да се разстрои и т.н.

Всъщност да, но установих, че "взимащите решения" обикновено не могат/не искат да мислят повече от цветна картина.

Всъщност да, но установих, че "взимащите решения" обикновено не могат/не искат да мислят повече от цветна картина. По-специално в публичната служба това преминава от служители, лекари и преподаватели до отговорните лица, вземащи решения в министерствата.
В добре управляваните компании нещата стоят малко по-различно. Но не винаги. Всеки иска да види нещо цветно, защото може да го намери за красиво или не красиво.

Може би това създава силно недоразумение. Ако напр. една програма се нуждае, казва какво трябва да може да направи или можете да постигнете съгласие по функции описателно/единодушно - тогава функциите/инструментите са най-важните.
Например https://www.tipp10.com/de/
Тук става въпрос главно за основните функции (учене за въвеждане на текст), базата данни (подобрения или пропуски в записа, статистика) или за разходите и преди всичко, че програмата работи като такава (имам Dos-Konsoleprg, който работи по подобен начин, но поне толкова добър). Ракета въздух-земя, която удря определени танкове на земята, не е чудодейна функция, трябва да бъде.

Кога програмистите на Linux получават идеята, че компютрите с браузър, базиран на прозорец, не трябва да се сриват при преместване на прозорците?
Моето задължение по този въпрос (под капака, сложна тема) е, че браузърът Netscape може да се използва без грешки с мишката в системите на Unix преди повече от 20 години.
(Не знам как е днес, или важен драйвер липсва в системите на Unix, мишката не работи, интернет не работи (модулът не е разпознат и т.н.)
или екранът остава напълно черен. Мишка/интернет нищо най-често.)

Тогава остава първото впечатление, че продуктът е твърде сложен или „не работи“ и го използва само неохотно.
.
След това се пробвате в следващата версия като разработчик
.
Тогава на масата идват продуктови мениджъри и консултанти .

. И това ни води до версия 3, измина една година и все още няма нищо подходящо за клиентите. За съжаление това е нормалният случай, когато разработчиците измислят продукта, защото никой друг не иска да го направи. Трябва да е различно.

Веднага след вземане на решението, че Ако продуктът ще бъде разработен, всеки (продуктови мениджъри, консултанти, продажби) трябва да добави горчицата си и да го направи незабавно. Те трябва, това е част от работата им, те не могат просто да се осмелят. Докато това не се е случило, разработката не започва, тъй като изискванията все още са неясни, това е толкова просто. (Фактът, че определени части, които ще дойдат сто процента могат да бъдат подготвени в даден момент, е друг въпрос. Но това важи преди всичко Подредете нещата под капака).

И това „добавяне на горчица“ също не е еднопосочна улица. Запитвания и дискусии могат и трябва да се правят. Често хората питат много специални неща: „Искаме бутона XY“, а когато попитате и се замислите, се оказва, че XY е още по-добър със падащ списък.

С това, което се споменава и класифицира като важно в тази фаза (не всичко, което отделен консултант счита за важно, всъщност е важно - но същото важи и за разработчиците), екипът за разработка създава прототип. Когато е представен, никой не може да се оплаче, че „не работи“, освен ако всъщност не работи, както е обсъдено.

С малко търсене можете да го намерите дори за 4,95 евро:
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
Пътуването до най-близката библиотека е по-скъпо и трябва да имате добри специализирани книги на собствения си рафт.

Веднага след вземане на решението, че Ако продуктът ще бъде разработен, всеки (продуктов мениджъри, консултанти, продажби) трябва да добави горчицата си и да го направи незабавно. Те трябва, това е част от работата им, те не могат просто да се осмелят. Докато това не се е случило, разработката няма да започне, тъй като изискванията все още са неясни, толкова е просто.

Не, не. В началото изискванията обикновено са неясни и също се променят с течение на времето.

Заглавието на нишката е „Как да планираме по-голям проект правилно?"

И в началото на правилното планиране има ясни изисквания. Докато липсват, няма такива правилният Планиране, просто несигурно планиранеопитва, които могат да бъдат събрани отново по всяко време.

Ако това е ясно на всички (включително и на ръководството), няма нищо, което да попречи на разработката да „играе наоколо“ и „проучвания за осъществимост“, защото това е всичко. Но ако разработката получи удар ("губите време и нищо не се получава"), тогава е време да попитате какво всъщност се очаква и какво трябва да излезе.

Не може да се случи, че разработката върши работата по управление на продукти/продажби/консултации и измисля кои продукти с какви свойства ще са необходими в бъдеще.