Dimentica la codifica e crea un ambiente di sviluppo per un momento. Se vuoi intraprendere un grande progetto, la prima cosa che devi fare è ottenere un handle sullo scopo e ambito del progetto.

Quello che raccomando è aprire un word processor e scrivere un documento sugli "obiettivi del progetto". Descrivi qual è l'idea e lo scopo generale del software che vuoi scrivere. Quindi elencare gli obiettivi di funzionalità del progetto. Non intendo specularlo, ma piuttosto descrivo le diverse funzionalità che il prodotto finito dovrebbe supportare. Quindi, se stavi scrivendo un software per gestire una scuola, potresti elencare la "gestione degli insegnanti" come una parte della funzionalità, e quindi descrivere cosa includerebbe tale funzionalità (tenere traccia delle informazioni di contatto, della pianificazione della lezione, ecc.)

Quindi la parte più difficile: non è qualcosa che devi fare davanti, ma mentre vai avanti. Ogni aspetto importante delle funzioni di inserimento che si desidera aggiungere è la verifica della funzionalità descritta nel documento degli obiettivi e si noti che è possibile vivere senza nella prima versione del programma. Questa è la chiave per la gestione dell'ambito.
Uno dei motivi principali per cui le persone falliscono nei progetti più grandi è che non sanno quando smettere di lavorarci. Non pensano che sia "fatto" perché le idee continuano a venire e non viene mai rilasciato. Alla fine perdono interesse e tu hai ancora un altro capolavoro finito a metà. Quindi vuoi essere sicuro di avere una buona padronanza della funzionalità che è veramente importante per raggiungere la parte fondamentale del tuo obiettivo. Questo è il tuo primo obiettivo.

Questo è il modo in cui inizio tutti i progetti non banali ora. Mi aiuta a mantenere l'attenzione e aiuta a mantenere la portata e lo scopo "in evoluzione" durante lo sviluppo.

Penso che Linus lo metta al meglio

Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project. -- Linus Torvalds

What should be my first step to reach my goal in more efficient and effective way?

Suppongo che tu abbia già fatto progetti prima e che tu sia in un college / università che non insegna controllo versione / sorgente. Se vuoi vedere alcuni progetti puoi sempre andare a repository open source come Github (usa Git), Bitbucket (utilizza Mercurial), Codice Google (utilizza Mercurial, Git e Subversion), < a href="http://www.codeplex.com/"> CodePlex (Mercurial e Subversion / TFS), SourceForge (Many), ecc. e dare un'occhiata al loro codice base. La cosa che hanno in comune è che stanno usando il software di controllo del codice sorgente.

Ci sono molte informazioni su come usarle, quindi ti suggerisco di imparare come usarlo, perché questa è una pratica standard del settore. Ecco alcune guide visive per aiutarti:

• link
• link

You know, when one project is came my mind, I don't know what I should do. Many times, I ignore it.

C'è solo così tanto che puoi fare nel tuo tempo libero. Inizia in piccolo : crea un progetto da zero, mettilo in un repository di codice sorgente. Applica modifiche al tuo repository del codice sorgente ogni volta che vuoi aggiungere qualcosa al tuo piccolo progetto. Col tempo diventerà grande e, se mai vorrai tornare indietro, puoi sempre ripristinare o ripristinare le modifiche apportate con il sistema di controllo della versione.

È perfettamente normale essere colpiti dalla sindrome della "carta bianca".

Hai un grande progetto in mente, che sembra fantastico, ma quando ti siedi alla scrivania cercando di fare qualcosa, improvvisamente blocchi e non sei in grado di fare nulla. Poi apri il solitario e fai un nuovo disco.

In realtà devi iniziare a fare qualcosa correlato al progetto, in modo da sentirti nato.

Potresti non voler scrivere codice immediatamente. Puoi iniziare scrivendo ciò che il tuo progetto deve effettivamente fare, o ti piacerebbe che lo facesse. Prendi carta e penna e inizia a scrivere. Puoi iniziare dai dettagli o da un'immagine più grande. Prova entrambi, guarda cosa è meglio.

Puoi provare a definire le funzionalità del progetto, le diverse parti, il modo in cui quelle parti comunicano tra loro. Mi sento a mio agio con il post-it, sono divertenti e puoi cambiarli man mano che progredisci. Lascia che seguano la tua mente e le tue idee.

O forse puoi iniziare a prototipare alcune funzioni o classi. Puoi usare qualsiasi lingua tu preferisca per questo, anche quella che non esiste e che hai appena inventato.

Dopo un po 'di tempo avrai qualcosa su cui lavorare e il tuo progetto non sarà solo per te. Hai effettivamente fatto qualcosa.

Quando ti senti a tuo agio per avviare effettivamente il processo di sviluppo, è il momento di pianificare, documentare, realizzare prototipi, raccogliere tutte le tecnologie e i software necessari e così via.

Ma non iniziare finché non senti è il momento giusto!

Grandi progetti sono formati da molti progetti o pezzi più piccoli. Potresti avere una grande idea o un requisito del progetto, ad esempio un'applicazione che gestisce i contatti.

Scomposizione; chiediti, 'quali sono i pezzi più piccoli di cui ho bisogno per fare questo?'

Una volta definite le parti più piccole, ripetere; potresti scoprire che alcune parti devono essere ulteriormente suddivise. L'idea è quella di definire gli obiettivi più gestibili per ciascuno dei pezzi più piccoli. Impara ad usare i principi disciplinati nella progettazione e nello sviluppo (come Agile-TDD) e gli obiettivi più piccoli e più gestibili saranno soddisfatti.

Crea una struttura

Hai una grande idea, ma non sai come andrai a realizzare il tuo compito. Crea uno schema di ciò che stai per fare. Annota i passaggi che farai, di cosa avrai bisogno, di quali lingue utilizzerai, ecc. Assicurati di aver organizzato tutto, altrimenti il progetto sarà completamente distrutto.

Pianifica i passaggi

Ho già detto questo, ma è davvero importante. Se si dispone del tempo di mappatura, è possibile avere una data di fine prevista di quando il progetto sarà terminato e per quanto tempo saranno necessari i passaggi del progetto. Questa è, ancora una volta, organizzazione e ti farà continuare a correre.

Trova gli strumenti per il lavoro

Se stai per iniziare un grande progetto, avrai bisogno di aiuto. Per l'organizzazione del codice e un buon sistema di controllo della versione, Git è ottimo perché mantiene tutto il codice in un unico repository. Per maggiori informazioni su Git, guarda il link che ti ho dato.

Dovrai anche assicurarti di utilizzare le lingue che ti aiuteranno a fare ciò che stai cercando di fare. Assicurati di essere in grado di creare il tuo progetto prima di iniziare. Non sto dicendo che non imparo nulla di nuovo, ma impara prima di iniziare.

Richiedi assistenza

Solitamente i grandi progetti non vengono eseguiti da soli. Contatta gli studenti, le persone della tua comunità che possono programmare e chiunque altro pensi possa aiutarti prima di iniziare. Non aver paura di chiedere.

Inizia!

Non fare il lollygag, aspettando che qualcun altro inizi il tuo progetto e poi dica "Ho avuto quell'idea!". Ti perseguiterà per sempre ...

Forse è pieno di cliché, ma ... ti invio.

Per essere in grado di gestire un grande progetto hai bisogno principalmente di una cosa: esperienza. L'esperienza ti offre tutto ciò di cui hai bisogno:

• Conoscenza: più tempo dedichi ai progetti le conoscenze più generali e specifiche che ottieni
• Fiducia: gestire grandi progetti richiede fiducia, la fiducia viene dalla conoscenza e generalmente il fatto che ogni pezzo del lavoro è qualcosa che hai fatto prima o hai visto persone che lo facevano
• Rete professionale: se il progetto è veramente grande, dovrai capire che non puoi realizzarlo da solo, quindi preparati a sapere chi puoi chiedere o dove trovi le informazioni chiave che stai cercando

Quindi puoi fare due cose:

• Immergiti e guarda come va. Probabilmente farai molti errori, ma la chiave è imparare da loro.
• Trova un lavoro in cui puoi osservare in modo specifico le persone che gestiscono grandi progetti

Spero che questo aiuti.

La mia definizione di "grande progetto" è "un progetto in cui il problema principale è il coordinamento dei partecipanti e la comunicazione tra loro" (un progetto medio è quando la gestione è difficile quanto i problemi tecnici, uno piccolo è quando i problemi tecnici sono più importanti di quelli di gestione, si noti che un progetto a lungo termine di una persona può essere un grande progetto: coordinare e comunicare con il proprio sé futuro non è molto diverso dal fare lo stesso con qualcun altro).

Il primo passo per essere in grado di gestire (con un "ruolo principale") un grande progetto è partecipare a qualche grande progetto senza avere un ruolo guida. Il secondo passo è raggiungere il livello di ruolo principale mentre viene seguito da qualcuno che ha esperienza con esso.

Un approccio alternativo è aumentare progressivamente la dimensione dei progetti e imparare dalla tua esperienza ...

Alcune idee sono mature per un ingegnere solo per saltare a destra e iniziare a scrivere il codice. Questi progetti potrebbero essere grandi o potrebbero essere piccoli, ma tutti hanno una cosa in comune: un problema ben definito da risolvere. Ho avviato progetti come questo innumerevoli volte, ed è solo una questione di me che costruisco una disciplina intorno a scrivere una buona documentazione in anticipo, e che segua le migliori pratiche in materia di controllo del codice sorgente, comunicazione e collaborazione.

I grandi progetti per i quali tutto quello che ho è il germe di un'idea, un po 'più di preparazione nella mia esperienza. La prima cosa che faccio è iniziare a parlare della mia idea con altri per vedere se qualcuno condivide la mia comprensione del problema che sto risolvendo e per convalidare il mio approccio pianificato per risolvere il problema. Quindi porta un amico o due fuori per una birra, o invitali nella tua stanza del dormitorio per Cheetos. Ma divertiti con questo processo perché è attraverso questo processo che potresti capire meglio il problema che stai risolvendo, trovare altre grandi idee che puoi portare a risolvere il problema, esercitarti a vendere la tua idea agli altri e magari anche iniziare a costruire un team di persone per aiutarti a risolverlo.

Dividi le cose grandi in cose più piccole.

Non puoi lavorare su "raggiungere la pace nel mondo". Invece si lavora sul divieto delle armi di distruzione di massa, si incoraggia la democrazia, si fornisce aiuto allo sviluppo, si incoraggia lo scambio culturale e scientifico e così via.

Penso che molte di queste risposte non siano toccate da qualcosa di tangibile, e costringendo te stesso a farlo.

A volte rimani bloccato in 'terra pensante' dove ti senti come se tutto ciò che è rimasto è la noia di battere a macchina le cose, ma in realtà iniziare su una porzione di dimensioni del tuo progetto e l'implementazione è sia divertente che impegnativa.

Conosco un sacco di persone che sono così, incluso me, finché non me ne vado davvero. Non faccio niente, non posso-semplicemente- pensare e pianificare un progetto. Devo scegliere un pezzo che posso facilmente implementare, e arrivare ad esso e poi il flusso inizia.

non c'è motivo di fare nulla senza uno scopo. Hai bisogno di storie utente che mostrino la necessità del codice che vuoi scrivere. Dovresti incorniciare queste storie utente nel seguente formato:

Come [X]
Voglio [Y]
in modo che [Z]

Questo può sembrare semplicistico, ma ti dà la struttura per definire non solo l'utente, ma anche per specificare la necessità e il risultato finale in una singola frase. Ne avrai molti di questi. Ne uscirai di più man mano che il tempo progredisce. Dopo averne alcuni puoi iniziare lo sviluppo sul tuo codice. Quando hai più idee o scopri altre cose. Torna indietro e scrivi più user story in modo da non dimenticarli. Questo è il miglior punto di partenza.

Sviluppo guidato dal comportamento utilizza questo approccio e il sito al link ha diversi esempi di utilizzo di questo formato per esprimere storie di utenti.

Penso che sarà il modo più rapido e organizzato per passare dall'idea al codice.

Vorrei prendere una pila di stickies gialli e un pennarello magico e sedermi in una stanza dove c'è una grande lavagna bianca in modo da poter fare un brainstorming.

Vorrei solo iniziare a scrivere frasi semplici che mi vengono in mente come Menu principale, Report, Database, Autenticazione, ecc. Le incollerei sulla lavagna bianca e fissavo e ottenevo altre idee per esempio come la principale il menu dovrebbe apparire:

Apri file, Salva file, Salva con nome, Stampa ecc. e incollali nella lavagna bianca nel menu principale.

Mentre le idee ti scoppiano in testa scrivili ... buono, cattivo, stupido, qualsiasi cosa sia appena diventata ceativa. Attaccali alla lavagna. Quando guardi la lavagna, più idee emergeranno e emergeranno modelli. Ad un certo punto inizierai a capire ciò che pensi di sviluppare.

Gli stickies gialli sono fantastici e possono essere spostati abbastanza rapidamente.

Una volta che le cose iniziano a venire insieme, dividi questi pensieri in gruppi. Quindi puoi fare un brainstorming a livello di singolo gruppo. Scatterei le immagini della lavagna bianca in varie fasi, nel caso in cui tu voglia vedere cosa assomigliava venti minuti fa prima che le cose si spostassero.

Alla fine, avrai una buona idea dei principali pezzi di roba che devono essere fatti. Potresti ottenere una singola cartella per ognuno di questi blocchi e continuare a lanciare idee su di loro mentre vengono da te.

Se tutto ciò che hai è una "Grande Idea", avrai bisogno di molte cose (che sono descritte molto bene in altre risposte), e in particolare queste 2: tempo e motivazione .

La maggiore difficoltà quando lavori da solo su un progetto personale è che, di solito, non hai molto tempo da dedicare ogni settimana e quindi non vedi molti progressi e inizi a perdere la motivazione.

Così come è già stato detto, fai piccoli passi , questa è la chiave.

Ma non è tutto, devi prendere piccoli e gratificanti passaggi ! Cioè, passi che ti porteranno il valore più grande e dimostrerai i concetti chiave della tua grande idea.

Ad esempio, se lavori su un nuovo software di super todo list con grandi interazioni utente . Non iniziare con le risorse di archiviazione e database finché non ne hai davvero bisogno. Inizia con l'innovativa interfaccia utente: è divertente e ha valore. Ciò ti renderà orgoglioso, ti manterrà motivato e ti consentirà di controllare molto presto che la tua idea sia davvero buona.

La prima cosa che devi fare è sederti e descrivere questa idea per iscritto. Fino a quel momento non diventerà un progetto, e anche allora, hai un po 'di lavoro per portarlo dall'essere effimero come un'idea a qualcosa di tangibile come un progetto.

Una volta che sei arrivato così lontano, puoi iniziare a guardarlo trasformandolo in un progetto, identificando come potresti scomporlo in passaggi discreti che possono essere implementati in modo logico.

Quindi delinea una linea temporale per l'implementazione di tali passaggi. Rivedi i progressi a intervalli regolari in modo da mantenere un certo controllo su quel processo, piuttosto che avere idee striscianti che non hai mai pensato in primo luogo e aggiungerli al mix.

Identifica un traguardo iniziale e mirare a quello. Meno si aderisce a questo, più il progetto rischia di affondare sotto il peso di idee aggiuntive, e più scoraggiato si può ottenere sul completarlo come sembra di vivere per sempre.

Lo sforzo del codice è in genere di circa il 20% (+ -10%) del budget di un progetto. Concentrarsi sull'ottenere codice corretto è inutile, c'è l'80% dello sforzo che non hai affrontato, quindi ottenere una perfetta gestione del codice ti lascia solo con 20 del lavoro svolto.

Che cosa succede se il tuo progetto non ha utenti? E se fosse perfetto, ma pubblicato una settimana dopo il file "Acme Patent Trolls" per un brevetto sull'idea, e si rivela essere il prossimo Facebook?

Guarda i seguenti problemi standard del ciclo di vita del progetto Requisiti, progettazione, codice, test, integrazione, distribuzione, rilevamento e correzione dei difetti, gestione delle modifiche dei requisiti (richieste di miglioramento). Pianificazione dei rilasci, allocazione delle risorse (quante ore sono previste per il giorno, e lo farai effettivamente sul progetto), Legal (Freedon per operare) ecc.

Se tutto quanto sopra è a posto, anche il codice molto cattivo avrà successo. Se nessuno dei precedenti è a posto, il codice migliore fallirà.

Non sono un uomo che scommette, ma ci metterei dei soldi per far fallire il tuo primo progetto "grande", in molti e vari modi che non puoi immaginare. Non preoccuparti, vai avanti e fallisci, impara da esso e fai il prossimo. Non partire sarebbe il vero crimine. Se ci riesci per la prima volta, hai una solida carriera nella gestione aziendale, non nella programmazione.

Quindi, per rispondere alla tua domanda, mettere via gli strumenti software ed estrarre i tuoi strumenti di "pianificazione aziendale". Risolvete perché lo state facendo, per chi poi perché e quando lo vogliono. (Puoi essere il tuo cliente, ma fai comunque l'esercizio). Scrivi questo in un "Business plan" e costruisci dal loro.

1. che aspetto ha il successo?
2. quali sono le incognite nel progetto?
3. quali sono le note nel progetto?
4. cosa puoi fare per eliminare / scoprire le incognite, convertirle in note?
5. cosa puoi fare per riunire i noti per raggiungere il successo?
6. qual è il prossimo passo concreto da compiere per far progredire il progetto?

ripeti l'ultimo passo fino a quando il progetto è finito; accetta che ci possano volere anni e continuare ad andare avanti

Tutte le risposte qui sono belle e tutte, ma in tutta onestà, non importa quanto controllo di versione, gitting, flow-chart e mark-up fai, tutto ciò che conta è che tu abbia un'applicazione funzionale, un'applicazione funzionale è definita come quella che risolve il problema per cui è stata concepita, tutte le altre cose sono praticamente irrilevanti.

Inizia la codifica, codificalo in una fase funzionale, esegui alcuni test, esegui il debug, avvialo e riattivalo con nuove funzionalità e funzionalità (se lo ritieni necessario), molto nel modo di un avvio snello - che è un agile metodo di gestione e sviluppo per creare meno sprechi (o come qualcuno definito: capolavori incompleti).

Dato che sei uno studente, assumerò che tu intenda uno studente grande e non professionale. Quest'ultimo richiede ulteriori considerazioni commerciali e di collaborazione. Ho appena iniziato un nuovo progetto la scorsa settimana, quindi il processo è nuovo nella mia mente.

La prima cosa che faccio è ricercare soluzioni e librerie esistenti . Non mi piace reinventare la ruota quando possibile. Questa ricerca è anche un grande fattore nella scelta di una lingua per il progetto. Alcune lingue hanno un codice esistente migliore per determinate attività.

La prossima cosa che faccio è creare una cartella e metterla sotto controllo del codice sorgente . Oggi è semplice come git init . .

Avanti I ottieni "Ciao mondo" lavorando . Questo mi consente di sapere che il mio ambiente di sviluppo è impostato correttamente.

Avanti ottieni "Ciao mondo" per le librerie di terze parti che funzionano . Questo è il minimo indispensabile per mostrare che sto collegando e usando correttamente la libreria. Ad esempio, per una libreria di database, si connette e si esegue una query semplice. Per un toolkit GUI, sta visualizzando una finestra.

Avanti imposta gli script di compilazione e i framework di test . Questo è ant o makefile o altro, ed è molto più facile da configurare quando il tuo progetto è ancora piccolo.

Avanti crea strutture dati . Chiamato anche il livello "modello". Questa è la parte che memorizza tutto ciò che il tuo programma deve ricordare per fare il suo lavoro. Realizzo molto design su carta, quindi aggiungo solo degli stub. Questa parte del disegno è solitamente la più semplice. Ad esempio, un programma di scacchi avrà bisogno di oggetti per memorizzare la griglia di gioco, i giocatori, i pezzi, le sequenze di mosse, ecc.

A questo punto, ho una buona base per un programma e di solito è abbastanza ovvio quale sarà il prossimo passo per quel particolare progetto. Poi faccio un piccolo passo alla volta, con un codice che funziona in qualche modo lungo tutto il percorso.

Elenco di cose da fare quando si avvia un nuovo progetto:

1. crea una nuova directory
2. crea makefile copiando alcuni template di makefile esistenti
3. crea alcuni file di intestazione e implementazione
4. assicurati che sia compilato
5. inizia a utilizzare il controllo della versione
6. decidere le convenzioni di denominazione per classi, funzioni, membri dati, variabili
7. scrivi la tua prima lezione
8. assicurati che la tua classe sia indipendente e che ogni funzione membro sia indipendente dalle altre funzioni membro
9. crea diversi oggetti creando funzioni come main ()
10. ripeti i passaggi 7-10 finché il tuo programma non è pronto
11. compilalo
12. spedirlo agli utenti finali