Dovrei creare un'applicazione completamente funzionante o una bare bones e poi aggiungere lentamente funzionalità?

Lavoro in uno stabilimento di produzione che ha incaricato l'IT di creare un programma di programmazione per l'officina (che è molto necessario). Sulla base dell'esperienza di altri, sarebbe meglio impiegare meno tempo e costruire un framework di base utilizzabile e poi basarsi su quello aggiungendo funzionalità o iniziare creando una soluzione completamente implementata immediatamente. Sono uno sviluppatore da circa un anno e non ho molta esperienza con la creazione iniziale di app di queste dimensioni. Mi sono appoggiato all'idea che un'app barebone sia la prima strada da percorrere a causa dell'estrema necessità di un qualche tipo di programma digitale, ma sono preoccupato che l'aggiunta di funzionalità casuali dopo il fatto potrebbe diventare un po 'confusa. Se ti trovassi nella stessa situazione in quale direzione ti spingeresti?

L'esperienza porta sicuramente a costruire qualcosa di piccolo e semplice, e a trasmetterlo agli utenti il ​​prima possibile. Aggiungi funzionalità e funzionalità come richiesto dagli utenti.

È molto probabile (al limite di alcuni) che ciò che vogliono / chiedono non assomigli molto a quello che avresti costruito da solo (se non del tutto).

Per quanto riguarda le cose che diventano disordinate quando si aggiunge all'applicazione originale: ecco perché Agile (e la maggior parte delle metodologie simili) pongono una forte enfasi su test e refactoring. Rifattorizzare significa ripulire il codice quando si apportano modifiche e una solida suite di test (che si esegue ogni volta che si apportano modifiche) garantisce che se / quando si introducono bug si conoscono (quasi) immediatamente, in modo che quando si rilascia qualcosa su i tuoi utenti hai la ragionevole certezza che funzioni davvero.

Hai idea se siano seri sull'app, quindi potresti non voler creare framework, ecc. Ecc.

Tuttavia, è necessario trovare un equilibrio. Lo sviluppo agile ti suggerisce di concentrarti su ciò che è richiesto dall'app in questa fase, ma ciò non significa che devi limitarti trascurando il design di base. Ci sono cose che possono facilmente essere viste come in arrivo (e sì, l'esperienza gioca un ruolo qui) e altre che non puoi immaginare in questa fase (sono abbastanza sicuro che le persone che hanno chiesto l'app non possano nemmeno immaginarle).

Non conosco i dettagli dell'app di pianificazione ma posso immaginare che il "tipo di appuntamenti" sia qualcosa che ti imbatterai presto. Forse la gente non lo chiede ora, non è ragionevole aspettarsi tale funzionalità.

Affronterò questo caso nel modo seguente: Costruirò l'infrastruttura (il framework di cui parli) creando una tabella nel database per contenere i tipi di appuntamento ma non mi preoccuperei di creare l'interfaccia per aggiungere o selezionare i tipi. Vorrei codificare un tipo di base e passare alle caratteristiche attuali. Dopo tutto, nessuno ha chiesto di includere diversi tipi di appuntamenti.

Quindi, in futuro, se le persone tornano da te chiedendo questa funzione, hai la struttura e costruisci solo il mid / front-end.

Spesso, non si dispone di informazioni sufficienti per creare un programma inizialmente completo. Test e feedback dei clienti rivelano quasi sempre parti del progetto iniziale che non erano buone come in teoria.

Detto questo, se il problema è ben compreso e sei in grado di scrivere inizialmente un programma completo, questo è meglio perché altrimenti stai costantemente riformattando il codice e il risultato è raramente pulito come un solido progetto che è stato seguito dall'inizio.

Per lo meno, penso che sia importante riflettere attentamente sul tipo di funzionalità di cui il tuo programma potrebbe aver bisogno. In questo modo, è possibile progettarlo in modo che tali funzioni possano essere facilmente aggiunte all'interno della struttura esistente.

Dall'esperienza personale: costruisci il tuo MVP (prodotto minimo vitale) e quindi aggiungi funzionalità in base al feedback che ricevi. È facile ottenere tonnellate di funzionalità e non farle usare a nessuno.

Importante è anche l'esperienza dell'utente che si utilizza per risolvere il problema. Convalida il flusso di lavoro che crei con i tuoi utenti effettivi, quindi aggiungi ulteriori funzionalità. In questo modo puoi concentrarti sul valore fondamentale che stai costruendo.