Како правилно да се испланира (поголема) проект Ц Заедница

Добра вечер заедница за форуми,

само сакам да знам,
какви трикови и совети користите за да следите уште поголеми проекти и да процените колку време ќе трае сега,
да биде во близина на неговото завршување.

Без разлика дали тоа е следната одлична игра или најдобриот ОС на светот.
Некако овие мора да биле испланирани и организирани,
затоа што никој нема да седне со идеја и да започне со програмирање сè додека не се вклопи.

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

Очигледно, оние кои планираат да го направат ова, заработуваат најмногу пари затоа што не е така лесно. Едноставно, започнувате со главниот проблем („оперативен систем“) и го разложувате на 2 или 3 подпроблеми („хардвер“ и „кориснички интерфејс“), кои потоа ги разложувате на два или три подпроблеми и го правите тоа додека не добиете во одреден момент пристигна во секвенците на програмата.

Некако овие мора да биле испланирани и организирани,
затоа што никој нема да седне со идеја и да започне со програмирање сè додека не се вклопи.

Многу проекти се случуваат на ист начин. Тоа не значи дека не е направен дизајн на софтвер. Но, однапред планирање на целиот проект, вклучително и временска рамка, што се случува многу ретко и тогаш обично не функционира толку добро.

пс: Врз основа на навистина огромни проекти. Игрите не се огромни проекти, барем не кога работите на готов мотор. И „средните“ проекти можат да бидат планирани доста добро, особено ако некој е веќе запознат со „доменот“.

Моето претходно искуство ми кажува од една страна дека треба да го испланирам точно како што е опишано погоре, а од друга страна дека е подобро само да започнам да прогретирам, потоа да избришам сè и да го направам одново без сите грешки, затоа што некако ми недостасува пракса да планирам сè од нула.

Од друга страна, мислам дека треба многу внимателно да размислувам за тоа што програмата всушност треба да биде способна да направи. ако сакам да направам автомобил, не го заебавам само, туку размислувам за барањата (која моќност, кое гориво, погонот на предните или задните тркала) планирам, пресметам и потоа во одреден момент ќе се зезнам.

па ако ве интересираат самите методи, побарајте „софтверски инженеринг“ на Амазон или во локалната универзитетска библиотека.

Моето претходно искуство ми кажува од една страна дека треба да го испланирам точно како што е опишано погоре, а од друга страна дека е подобро само да започнам со прогресија, а потоа да избришам сè и да го сторам тоа одново .

Можете да направите класично планирање од горе надолу (т.е. од целокупната идеја до деталите) ако имате преглед на проектот во целост, и кој го прави тоа? За тоа ќе мораше да имате направено нешто многу слично претходно.

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

Овде веројатно ќе ви требаат неколку повторувања сè додека сè не се чувствува како што треба, но можете да направите навистина скапи грешки при планирањето (на половина пат да сфатите дека целокупниот план не е добар или да потрошите толку време за последните 10 проценти како за првите 90) се надевам дека избегнувајте го со планирање на куќата само откако ќе имате функционални градежни блокови.

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

Од друга страна, само мислам дека треба многу внимателно да размислувам за тоа што програмата всушност треба да биде способна да направи.

Што програмата треба да биде во можност (и што уште не) треба да се разгледа претходно, така е. Но, од што треба да одделите Како што.

ако сакам да направам автомобил, не го заебавам само, туку размислувам за барањата (која моќност, кое гориво, погонот на предните или задните тркала) планирам, пресметам и потоа во одреден момент ќе се зезнам.

Секако, тоа го правите кога претходно сте граделе автомобил или кога веќе знаете како обично се градат автомобили затоа што другите веќе имаат изградено многу автомобили.

Во повеќето случаи (за жал) прво нешто се бара, тогаш треба брзо да покажете маска на екранот, потоа дајте со климање, и кога голиот скелет ќе се обеси со месо, излегуваат сите што само кимнаа претходно и сфаќаат дека тие всушност го сакаа толку поразлично.

За мојата прва теза морав да креирам програма што требаше да се базира на гола површина на ДОС, но со индивидуални маски, прозорци за избор, скокачки прозорци, линии, рамки, удобни уредници на линии (одделени со низи цел број и плови) и скокање напред и назад во рамките на одделни елементи.

Значи, програмата порасна и оддолу нагоре и одгоре-надолу. Пред сè, дефинирајте ги основните основни елементи одоздола и оние што се надоврзуваат на нив. На пример, линија и квадрат составени од четири линии.

Во исто време, поделете ја програмата од горе во одделни основни елементи, на пр. Главно со избор на индивидуални основни функции, а потоа поделете ги чекор по чекор додека не се сретнат „горе“ и „подолу“. Потоа, доколку е потребно, кодирајте 1-2 елементи од секое ниво за да добиете преглед на потребното време и додајте ги за сите елементи. И тогаш не заборавајте да обезбедите тампон за непредвидени, 10 - 100% во зависност од искуството.

ПС: Др. Гинтер Ротард ја повторува книгата Praxis der Softwareentwicklung, која се занимаваше со темите многу детално. Но, тоа е од 1987 година и затоа е тешко достапно. Но, можеби има уште библиотеки за позајмување.

Исто така мислам дека комбинацијата од горе надолу и оддолу нагоре е најдобра.
Ако правите само од горе надолу, техничките пречки се откриваат предоцна и, обратно, со оддолу нагоре, ви недостасува основно разбирање за целокупната архитектура.
Особено за прототип, треба да развиете пирсинг кој се базира на архитектурата и веќе содржи некои технички детали.

Но, планирањето проект е повеќе од само пишување код, тука спаѓаат сите подточки од софтверското инженерство (и други нетехнички, како што се инфраструктура, тимска комуникација, итн.).

Маската на екранот не е „голиот скелет“, напротив, кожата што се влече над неа на крајот. Лидерите на проектите не треба да го мешаат ова и не треба да ги оставаат носителите на одлуки да веруваат во ова.

Носителите на одлуки кои само кимаат со главата и не поставуваат прашања, покажуваат дека не го разбрале проектот. Искусните менаџери на проекти го знаат тоа и желба повратните информации. Кога од носителите на одлуки се бара да не климаат само со главата, туку да потпишат (со нивните имиња на парче хартија), тогаш тие обично се будат.

Ви благодариме за бројните многу корисни одговори.

Особено совет на книгата, но прво ќе видам дали ќе ја најдам во библиотеката пред да ја купам. Само по себе, се чини дека е многу добро.

Со цел да го наведам целото размислување од чистата теорија до опиплив пример, почнав грубо да планирам „мотор на игри“.

Ако го поврзам основниот концепт што беше споменат овде со ова, тогаш тоа беше врвно - долу планирање.
Следно ќе следи дно -> Додаток нагоре.
Веднаш штом ова ќе биде завршено, индивидуалните модули ќе бидат специфично развиени и целата структура ќе се прошири доколку е потребно.

Дали го разбрав тоа правилно или направив грешка тука?

Постои една убава изрека што значи: „Прашањето беше за рајот, одговорот беше јаже“.

Знам само дека има одредена испробана и тестирана основна опрема.
Пр. Протоколна брошура со адресирање содржина или мешавина (како џокеј-тркало) по модел или работен план според моделот x, y, z.
Ова може да се направи исто како подоцна во пр. Евалуациите.

Наместо (докажан) теоретски модел, друга програма може да се користи како модел во софтвер. Табели или оперативни системи, исто така, започнаа мали.

Кога станува збор за основните нацрти/планови, не можам да направам без да чкртам со хартија и молив.

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

Добри средства за планирање сè уште се постери и белешки А5. Постерите исто така можат добро да се залепат заедно, ако ви треба следење на ширина на wallид/големина на кралот.

Мислам дека сега е повторно нешто поразлично од она што првично го бараше. Барањата и барањата се сосема различни. Со мотор за игри, се грижите за чистиот дизајн на софтверот. Проектот е многу податлив, можните барања се ограничени, а имате помалку засегнати страни.
Во „големите“ и реални проекти, не станува збор само за дефинирање на дијаграми на часови што е можно почисто на отворено. Тогаш повеќето од проблемите доаѓаат од фактот дека треба да направите многу со одгледуваните структури, спротивставени барања, нејасни барања, какви било карактеристики што постојат со децении и се мешаат во новите барања, но од кои не можете да се ослободите без важни клиенти да вознемири итн.

Всушност да, но открив дека „носителите на одлуки“ обично не можат/не сакаат да размислуваат подалеку од шарената слика.

Всушност да, но открив дека „носителите на одлуки“ обично не можат/не сакаат да размислуваат подалеку од шарената слика. Особено во јавниот сервис, ова оди од вработените, лекарите и професорите до одговорните донесувачи на одлуки во министерствата.
Во добро водени компании работите се малку поинакви. Но, не секогаш. Секој сака да види нешто шарено, затоа што може да го најде убаво или не убаво.

Можеби ова создава силно недоразбирање. На пример, ако ви треба програма што вели што мора да биде во можност да направите, или можете да се согласите за функциите на описен/едногласен начин - тогаш функциите/алатките се најважни.
На пример https://www.tipp10.com/de/
Тука главно станува збор за основните функции (учење за пишување), базата на податоци (подобрувања или празнини за снимање, статистика) или трошоците и, пред сè, програмата да работи како таква (имам програма за конзола ДОС која работи слично но барем толку добро). Ракета земја-земја што погодува одредени резервоари на земјата не е чудотворна функција, треба да биде.

Кога програмерите на Линукс добиваат идеја дека компјутерите со Интернет прелистувач заснован на прозорци не треба да се расипуваат кога се преместуваат прозорците?
Мојата обврска на ова (под хауба, комплексна тема) е дека прелистувачот 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
Патувањето до најблиската библиотека е поскапо, а на вашата полица треба да имате добри специјалистички книги.

Веднаш штом ќе се донесе одлуката, тоа Доколку производот треба да се развие, секој (менаџери на производи, консултанти, продажба) мора да ја додаде својата синап и да го стори тоа навремено. Тие мораат, тоа е дел од нивната работа, тие не можат само да се осмелат. Сè додека тоа не се случило, развојот нема да започне затоа што барањата се сè уште нејасни, толку е едноставно.

Не, не На почетокот, барањата се обично нејасни и исто така се менуваат со текот на времето.

Насловот на темата е „Како да се планира поголем проект правилно?"

И на почетокот на правилното планирање има јасни барања. Сè додека ги нема, ги нема вистинскиот Планирање, само несигурно планирањесе обидува, што може да се собере повторно во секое време.

Ако ова им е јасно на сите (вклучително и на раководството), нема што да го спречи развојот да се „збрка“ и да се организираат „физибилити студии“, бидејќи тоа е сè. Но, ако развојот добие удар за тоа („губите време и ништо не доаѓа од тоа“), тогаш е време да прашате што всушност се очекува и што треба да излезе.

Не може развојот да ја извршува работата на управување со производи/продажба/консалтинг и да размисли кои производи со кои својства ќе бидат потребни во иднина.