Dovrei creare un'applicazione con tutte le funzionalità o una versione ridotta e poi aggiungere lentamente funzionalità?

L'esperienza sicuramente porta alla creazione di qualcosa di piccolo e semplice, e al suo arrivo agli utenti il prima possibile. Aggiungi funzionalità e funzionalità così come vengono richieste dagli utenti.

Le probabilità sono molto buone (confinanti con certe) che ciò che vogliono / chiedi non assomiglierà a quello che avresti costruito da solo (se non del tutto).

Per quanto le cose si complicano man mano che si aggiunge alla tua applicazione originale: ecco perché Agile (e le metodologie più simili) pongono una strong enfasi sul testing e sul refactoring. Refactoring significa ripulire il codice mentre apporti le modifiche e una solida suite di test (che esegui ogni volta che apporti modifiche) assicura che se / quando introduci bug ne conosci (quasi) immediatamente, in modo che quando rilasci qualcosa a i tuoi utenti hai una ragionevole sicurezza che funzioni effettivamente.

Hai idea se sono seri nell'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 apparire come prossime (e sì l'esperienza ha un ruolo qui) e altre che non puoi immaginare in questa fase (sono abbastanza sicuro che le persone che hanno chiesto l'app non le possano immaginare).

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

Mi avvicinerei a questo caso come segue: creerei l'infrastruttura (la struttura che menzioni) 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 andare avanti con le funzionalità effettive. Dopo tutto, nessuno ha chiesto di includere diversi tipi di appuntamenti.

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

Spesso non disponi di informazioni sufficienti per creare un programma inizialmente completo. Test e feedback dei clienti rivelano quasi sempre parti del tuo 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 rifattorizzando il codice e il risultato è raramente pulito come un design solido che è stato seguito dall'inizio.

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

Dall'esperienza personale: crea il tuo MVP (Prodotto minimo vitale) e quindi aggiungere le funzionalità in base al feedback che si riceve. È facile ottenere tonnellate di funzionalità senza che nessuno le usi.

Altrettanto importante è l'esperienza utente che usi per risolvere il problema. Convalida il flusso di lavoro che crei con i tuoi utenti effettivi e poi aggiungi ulteriori funzionalità. In questo modo puoi concentrarti sul valore fondamentale che stai creando.