Dipende dal progetto, se lavori da solo su un piccolo progetto, potrebbe essere perfettamente logico eseguire la tua ricerca e indagine tecnologica come parte dello sviluppo. E anche se non fa parte di Agile, ovviamente è possibile utilizzare una metodologia Agile per aggiungere un controllo a questo. Tuttavia, ciò rende molto difficile prevedere il processo o il time box. Potrebbe andare bene, anche più velocemente, se lavori da solo su un piccolo progetto che è interamente tuo, lascia che le tue esigenze si spieghino man mano che le impari. Usa buoni principi lungo la strada, ed essere coerente e non dovresti aver bisogno di ridimensionare troppo.
Al lavoro usiamo metodi Kanban, Scrum e più tradizionali a cascata. Dipende dal progetto, trovo che gli sviluppi complessi con requisiti ben definiti non siano i più adatti per l'agilità, molti però non saranno d'accordo.
Prima di iniziare a lavorare anche su un progetto agile (tutto tranne il più semplice), creiamo dei documenti. Abbiamo un mock up (se sei focalizzato), una serie di requisiti e una specifica funzionale.
Si chiederà allo sviluppo di creare le specifiche tecniche dalle specifiche funzionali, e durante questo processo specificheremo la tecnologia e svolgiamo qualsiasi ricerca iniziale di cui abbiamo bisogno. Questo processo mi sembra così importante, in quanto offre l'opportunità di vedere lacune nei requisiti / specifiche funzionali e offre le grandi decisioni tecnologiche in anticipo alle persone con esperienza e conoscenza del sistema per prendere tali decisioni.
La cosa significativa però è che le specifiche funzionali potrebbero essere un elenco di punti elenco e le specifiche tecniche di solito saranno un modello, con alcuni punti elenco e sterzi tecnologici, forse solo 3 o 4 pagine in alcuni casi.
Anche quando si esegue un progetto agile creiamo la documentazione:
- Tutta la documentazione ha un costo.
- Lo sviluppo contro i requisiti di alto livello in movimento e mal definiti ha un costo.
- Il corretto equilibrio rispetto a quanto sopra dipende dal tuo progetto, dalla cultura e dalle persone.
- Documentiamo Just in time, i documenti non sono aggiornati.
- Documentiamo abbastanza a sufficienza / appena sufficiente.
- Non conserviamo o aggiorniamo questi documenti, non ci impegniamo molto. Sono piccoli. Ci aspettiamo di buttarli via.
- Appianiamo le grandi incognite come le decisioni relative alle tecnologie, i requisiti nebulosi e l'architettura all'avanguardia.
- Sappiamo cosa stiamo sviluppando prima di iniziare.
- Crediamo che gli sviluppatori debbano prendere decisioni informate sulla documentazione e discutere di eventuali problemi.
- Apprezziamo la comunicazione sulla documentazione, in quanto tale ci aspettiamo che tutti i soggetti coinvolti comunichino spesso.
- Documentiamo i sistemi (panoramica) dopo lo sviluppo, non durante, non prima.
Si vede che c'è una piccola cascata nel nostro processo agile.
Se lavori da solo, crea un modello iniziale (diagramma!) e gioca con e scegli la tecnologia, e poi quando hai questo concetto dei requisiti di alto livello, vai avanti e sviluppa in modo iterativo agile, ma considera buoni principi e coerenza come si va e sarà necessario ri-fattorizzare meno, più ri-fattore come si va.
Ma in generale, se c'è un costo reale coinvolto (non un hobby), sai cosa stai sviluppando prima di scrivere il codice, ma non sprecare troppo tempo a scrivere documentazione che diventerà ridondante velocemente mentre cambierai idea e dovresti cambiare idea durante lo sviluppo man mano che diventi più informato. E il tuo progetto potrebbe cambiare radicalmente, ma partire da una base ben definita e ben definita.