Questa cosa generalizzante e astratta ti distrae. Agile ti insegnerà molto rapidamente a diventare pragmatico. C'è ancora molto da imparare affrontando problemi in piccole parti altamente specifici. Una volta che fai a pezzi ogni parte, la ripetizione di questo processo ti aiuterà a imparare il processo e a costruire la conoscenza del dominio allo stesso tempo, avanzando così verso frazioni sempre più grandi del tutto mentre accumuli sempre più di questi piccoli pezzi. / p>
Potresti aver descritto il tuo "grande sistema di back-end con un singolo punto di ingresso" molto più esattamente senza fare un'analogia.
Penso che leggendo nel tuo racconto "fetta verticale", stai cercando di creare qualcosa come un'epica MVP per cominciare. Hai il mio applauso per questa intenzione. È molto caratteristico di una startup snella e qualcosa che ho fatto anche in passato.
Lo scopo di un MVP è l'apprendimento: testare le assunzioni più rischiose ("de-risk") e convalidare quegli elementi chiave. Quindi il prossimo passo è rompere questa grande idea nelle ipotesi. Dato che questo è così vago e ipotetico, farò delle ipotesi per dimostrare questo processo di "abbattimento". Eccoci:
- Il valore parte di Come utente, voglio conoscere il significato della vita, in modo che io sappia perché esisto è "in modo che io sappia perché io esistere".
- "in modo che io sappia perché esisto" risponde alla domanda filosofica ampia e molto "radicale" "Perché esisto?"
- Se "Deep Thought" può rispondere alla domanda radice "Perché esisto?", è logico supporre che possa rispondere a molte più domande derivate e specifiche, come ad esempio "Che cos'è 1 + 1?"
- Possiamo definire una porzione verticale come "Come utente, voglio calcolare l'aritmetica di base, così posso convalidare la mia comprensione aritmetica"? (o qualcosa di simile senza senso)
- Forse non è una sezione verticale completa di tutti gli interni complessi per il calcolo della radice, ma testerà il sistema di input della query, il sistema di consegna risultato / output e alcune infrastrutture arbitrarie per modellare l'acquisizione di una query / richiesta e parte della pipeline di elaborazione (forse)
- Diciamo che la nostra epica è Come utente, voglio calcolare l'aritmetica di base, così posso convalidare la mia comprensione aritmetica e la nostra prima storia è Come utente, voglio valutare 1 + 1, così posso verificare l'aritmetica di base . Boom! ora hai qualcosa di concreto ed esplicito puoi anche scrivere un test end-to-end per (forse)
Potresti ancora voler infrangere questa storia in flussi di utenti attorno all'input, all'output, ecc. mentre scopri di più. Ma questo processo di scoperta è facilitato dalla discussione che ti piace (questi punti elenco). Mentre ti costringi a fare brainstorming e tagliare le cose, scopri di più sul dominio e i dettagli si materializzano. Le cose diventano concrete ed esplicite, o almeno le costringi a farlo.
A proposito, anche questo è sbagliato: "Non possiamo fornire nulla di utile all'utente fino a quando l'intero sistema di back-end non sarà completo".
Proprio come un'azienda può costruire una facciata di un sistema automatizzato usando servizio di portineria , anche tu puoi fare lo stesso e fornire valore . Se la tua storia "1 + 1" si verifica e hai una sorta di test automatico che asserisce il risultato "2", puoi implementarlo usando il codice statico per superare il test giusto? ( Think TDD .) Non ha nemmeno bisogno di utilizzare inizialmente un operatore binario.
È possibile distribuirlo totalmente alla produzione e mostrare all'utente il modo in cui il prodotto (Deep Thought) può ragionare e produrre un risultato da una query molto specifica. Non devi dire che è "hard coded". Stai provando a testare le ipotesi in maniera agile e a catturare il feedback in un ciclo stretto.
Questo è ciò che sono agili e snelli: catturare l'apprendimento il più velocemente possibile. Ciò è reso possibile da una dimensione di batch il più piccola possibile. Il risultato di questo processo è il minimo spreco possibile.
