Giusto mix di pianificazione e programmazione su un nuovo progetto

10

Sto per iniziare un nuovo progetto (un gioco, ma non è importante). L'idea di base è nella mia testa ma non tutti i dettagli.

Non voglio iniziare a programmare senza pianificare, ma sto seriamente combattendo la mia voglia di farlo. Voglio una pianificazione prima per impedire il refactoring dell'intera app solo perché una nuova funzionalità a cui potrei pensare lo richiede. D'altra parte, non voglio pianificare più mesi (tempo libero) e iniziare perché ho un po 'di paura che perderò la mia motivazione in questo momento.

Quello che sto cercando è un modo di combinare entrambi senza che uno domini l'altro. Dovrei realizzare il progetto in termini di mischia? Devo creare storie utente e poi realizzarle? Dovrei lavorare in base alle funzionalità? (Ho una certa esperienza nella mischia e nel classico modo "specifica per codificare".)

Aggiornamento : che ne dici di iniziare con un "clic fittizio" e implementare la funzionalità in un secondo momento?

project-management agile

— WarrenFaith
fonte

5

Sei sulla strada giusta. Non è necessario dedicare mesi alla pianificazione, ma dovresti assolutamente avere una sorta di piano.

La pianificazione ti aiuterà a organizzare i tuoi pensieri, a identificare le tecnologie di cui potresti aver bisogno, a chiarire i punti problematici e a fornirti una tabella di marcia per lavorare da cui puoi scomporre in obiettivi misurabili.

Inoltre, potresti dedicare qualche giorno alla pianificazione solo per scoprire che questo è uno spreco di tempo. Forse durante la pianificazione, ti rendi conto che sei fuori dalla tua portata o che ciò che stai cercando di fare non può essere commercializzato. È meglio scoprirlo ora in modo da poter reinvestire il tuo tempo in altre idee che hai, piuttosto che percorrere questa strada solo per perderti nei boschi, circondato da filari filari e tracce di logica fallibile che torce il tuo cervello in nodi.

— jmort253
fonte

La piattaforma di targeting è il mio lavoro quotidiano, quindi conosco la maggior parte delle tecnologie che voglio usare. Immagino che userò una mischia semplice e un piano di base. Quindi posso iniziare con alcuni arretrati e fare la pianificazione su ogni iterazione.

— WarrenFaith,

Continui a scrivere "pianificazione" in modo errato. Ho pensato di segnalarlo dal momento che non riesco a modificare il tuo commento :) Ma sì, penso che la mischia sia un ottimo approccio in quanto mantiene la flessibilità e ti dà la possibilità di decidere se vale la pena lo sforzo per continuare il progetto.

— jmort253,

Oo In tedesco è il contrario: pianificare con una n e programmare con due m ...: D Grazie!

— WarrenFaith,

@WarrenFaith - Siamo spiacenti! Questo è il mio etnocentrismo che viene fuori! Grazie per aver ricordato il mio errore;)

— jmort253

11

Pianificare il prodotto minimo praticabile e implementarlo. Quindi ascolta i tuoi utenti e pianifica il prossimo miglioramento logico e implementalo. Ripetere.

— Steven A. Lowe
fonte

3

.... e ogni volta che hai un'idea per qualcosa che ritieni possa essere interessante, basta scrivere l'idea in scrum-backlog ma non implementarla fino a quando non viene realizzato il minimo prodotto possibile.

— k3b,

la domanda principale è ancora quanto dovrei pianificarla in profondità. Se anche tu potessi darmi quel consiglio, avrai la risposta accettata.

— WarrenFaith,

1

@WarrenFaith: caratteristiche - >> storie - >> casi di test.

— Steven A. Lowe,

4

Indipendentemente da quanto tempo dedichi alla pianificazione e alla progettazione del tuo programma, alla fine riscrivi sempre parti di esso. È come la gravità, non è intelligente negare la sua esistenza.

Bisogna rendersi conto che il refactoring è una parte normale dello sviluppo ed è solo una questione di decidere quando lo fai. Aspetta di lungo e finisci con enormi quantità di spaghetti, chiedendo una riscrittura completa. Non divertente.

Il mio suggerimento è di pianificare un po ', ma iniziare a programmare al più presto e refactor, refactor, refactor per mantenere il codice in forma. Il principio DRY (non ripeterti) è un ottimo indicatore per questo.

— Martin Wickman
fonte

Grazie per la tua risposta. So che il refactoring non è niente di insolito, ma non voglio impedire il refactoring causato dalla mancata planata.

— WarrenFaith,

@Warren - la mancata pianificazione non impedisce il refactoring. Puoi codificare la soluzione sul computer o tentare di codificarla nella tua testa o sulla carta. Penso che entrambi siano inefficaci. Inizia a scrivere, sapendo che lo cambierai in seguito.

— Kevin Cline,

@kevin cline: Ok, facciamo la differenza tra il refactoring del codice esistente per nuove funzionalità o miglioramenti e riscriviamo quasi l'intera app per una nuova funzionalità. Posso vivere con il primo, non proprio con il secondo ..

— WarrenFaith

@WarrenFaith: fintanto che il codice è stretto e in forma, dovresti essere in grado di evitare le riscritture. L'unica volta che ho visto riscrivere è quando il sistema è diventato una grande palla di fango (nessun refactoring) o un cambiamento tecnico fondamentale (cambio di piattaforma).

— Martin Wickman,

3

Quando sono in questa posizione, a volte utilizzo TDD (test driven development) e inizio a pianificare alcuni test per la parte più complessa del sistema che sto sviluppando. In alternativa, posso mettere insieme qualche pseudo codice di alto livello, sempre per le aree più complesse. Trovo che questo processo mi offra un piano d'azione libero e mi aiuti a identificare quali aree potrebbero richiedere più tempo.

Per me questo approccio funziona perché vive da qualche parte tra programmazione e programmazione. Una volta che hai le idee di prova e / o lo pseudo codice, puoi esaminare ogni sezione logica e implementare il codice. Spesso affronta prima la parte più difficile di una soluzione proposta, perché in genere la parte più difficile è la caratteristica principale dell'applicazione e puoi sempre ritardare eventuali campane e fischietti.

Dato che commentate che la maggior parte del codice è nella vostra testa e siete pronti per tuffarvi e programmare, l'uso di questo approccio può aiutarvi a focalizzarvi su ogni sezione senza che la vostra mente venga offuscata dal sistema nel suo insieme.

Per riassumere in modo più succinto, si potrebbe dire "affrontare prima la parte più difficile, dividere e conquistare, con pseudo codice e / o piani TDD"!

— BradB
fonte

Non sono un fan di TDD ma grazie comunque!

— WarrenFaith,

Non sto necessariamente dicendo di usare TDD, il mio punto era che è qualcosa che uso come struttura per "pianificare" il mio codice. In questo modo non sto saltando dritto nella scrittura del mio codice e non sto trascorrendo molto tempo a scrivere documenti di massa / piani di progetto che sono un po 'troppo lontani dalla codifica reale. Si tratta di trovare il mezzo felice. In linea di principio puoi ottenere la stessa cosa con carta e penna. Devo anche sottolineare che non scrivo un test per TUTTO - solo le aree più complesse.

— BradB,

3

Prova a rendere il codice modulare. È probabile che qualsiasi altra cosa tu pianifichi venga espulsa durante la prossima iterazione.

— DavidK01
fonte

2

Consiglierei di scrivere almeno le tue idee. A seconda delle dimensioni del progetto potrebbe non essere necessaria molta pianificazione formale. Se tuttavia è molto grande, potresti voler evitare un mal di testa e passare un paio di giorni a fare qualche pianificazione più approfondita.

— Kenneth
fonte