Dipende dal progetto, se stai lavorando da solo su un piccolo progetto, potrebbe avere perfettamente senso svolgere la tua ricerca e indagine tecnologica come parte dello sviluppo. E sebbene non faccia parte di Agile, ovviamente una metodologia Agile potrebbe essere usata per aggiungere un certo controllo a questo. Tuttavia, ciò rende il processo molto difficile da prevedere / o time box. Potrebbe andare bene, anche più veloce, se lavori da solo su un piccolo progetto interamente tuo, lascia che i tuoi requisiti si svolgano mentre li impari. Usa i buoni principi lungo il cammino, sii coerente e non dovresti ricorrere a un nuovo fattore.
Al lavoro utilizziamo Kanban, Scrum e approcci a cascata più tradizionali. Dipende dal progetto, trovo che sviluppi complessi con requisiti iniziali ben definiti non siano più adatti all'agile, molti però non saranno d'accordo.
Prima di iniziare a lavorare anche su un progetto agile (tutto tranne il più semplice), creiamo della documentazione. Abbiamo un modello (se focalizzato), una serie di requisiti e una specifica funzionale.
Lo sviluppo verrà chiesto di creare le specifiche tecniche dalle specifiche funzionali e durante questo processo specificheremo la tecnologia ed eseguiremo tutte le ricerche iniziali di cui abbiamo bisogno. Questo processo mi sembra così importante, in quanto offre l'opportunità di vedere le lacune nei requisiti / specifiche funzionali - e dà le grandi decisioni tecnologiche davanti alle persone con l'esperienza e la conoscenza del sistema per prendere tali decisioni.
La cosa significativa, tuttavia, è che le specifiche funzionali potrebbero essere un elenco di punti elenco e le specifiche tecniche saranno di solito un modello, con alcuni punti elenco e direttori tecnologici, forse solo 3 o 4 pagine in alcuni casi.
Anche durante l'esecuzione di un progetto agile creiamo documentazione:
- Tutta la documentazione ha un costo.
- Lo sviluppo contro lo spostamento e la definizione errata di requisiti di alto livello ha un costo.
- Il corretto equilibrio con quanto sopra dipende dal tuo progetto, dalla cultura e dalle persone.
- Documentiamo Just in time, i documenti non sono aggiornati.
- Documentiamo a malapena / quanto basta.
- Non conserviamo o aggiorniamo questi documenti, non ci impegniamo molto. Sono piccoli. Ci aspettiamo di buttarli via.
- Risolviamo le grandi incognite come decisioni tecnologiche, requisiti confusi e architettura in prima fila.
- Sappiamo cosa stiamo sviluppando prima di iniziare.
- Confidiamo che gli sviluppatori prendano decisioni informate sulla documentazione e discutano di eventuali problemi.
- Apprezziamo la comunicazione sulla documentazione, in quanto tale ci aspettiamo che tutte le persone coinvolte comunichino spesso.
- Documentiamo i sistemi (panoramica) dopo lo sviluppo, non durante, non prima.
Vedi 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, quindi quando hai questo concetto di requisiti di alto livello, corri avanti e sviluppi in modo agile iterativo, ma considera buoni principi e coerenza man mano che procedi e dovrai ripensare di meno, più ripensare man mano che procedi.
Ma in generale, se c'è un costo reale (non un hobby), sai cosa stai sviluppando prima di scrivere il codice, ma non perdere troppo tempo a scrivere documentazione che diventerà ridondante in fretta poiché cambierai idea e dovresti cambia idea durante lo sviluppo man mano che ti informi meglio. E il tuo progetto potrebbe cambiare enormemente rotta, ma iniziare da una base valida e ben definita.