Sviluppo di un'app Web da un progetto, come devo dividere il lavoro?

Non ci sarà una sola risposta a questo, anche se sembrano esserci quelli che pensano che ci sia. Potrebbero avere ragione, ma il mio istinto dice "no". Ecco alcuni pensieri iniziali.

I) Obiettivi generali per la vita durante il processo di sviluppo

L'approccio scelto deve consentirti di raggiungere i seguenti obiettivi:

1. SEMPRE hai qualcosa da dimostrare agli stakeholder
2. SEMPRE avere la prossima cosa "in cucina"
3. SEMPRE essere in grado di rispondere alle domande degli stakeholder riguardo all'incirca quando saranno in grado di vedere una demo di tali e tali funzionalità.
4. SEMPRE essere in grado di essere flessibile se le parti interessate lo richiedono per cambiare la sequenza di implementazione.
5. Essere in grado di distribuire il lavoro in caso di opportunità.

II) Crea un ambiente di squadra all'inizio

Anche se al momento sei l'unico sviluppatore, assicurati di impostare tutto come se ci fosse un'intera squadra che lavorava al tuo progetto. È sorprendente quanto velocemente tendiamo a perdere le discipline di base quando lavoriamo da soli - lavora sempre come se facessi parte di una squadra, anche se gli altri membri sono "virtuali".

Ci sono alcune decisioni sulla progettazione e sull'implementazione che vorresti fare prima.

III) Feature Set Sequence

Hai intenzione di presentare il prodotto intero e completo sulla prima versione "live", invece di farlo iterativamente? Se iterativamente, è necessario determinare il set di funzionalità che comprende il prodotto minimo vitale (MVP). Quindi dovrai impostare (o suggerire agli stakeholder) gli incrementi delle caratteristiche (pietre miliari) per i primi cicli. Una volta fatto, avrai un programma e sarai in grado di cadere in una cadenza di progettazione / sviluppo / test / rilascio che fornisca risultati attesi nel tempo previsto. Questa cadenza, seguita in modo coerente, è molto importante per costruire la fiducia degli stakeholder. Anche se la versione iniziale deve contenere tutte le funzionalità, ancora vuoi adottare un approccio iterativo, identificando l'MVP per te stesso e aggiungendo in modo incrementale le funzionalità. Perché? Perché fin dal primo minuto in cui inizi, il tuo unico obiettivo è quella prima demo .

IV) Architettura

Hai già uno stack tecnologico scelto. Assicurati che il tuo stack di Choses supporti:

1. prototipazione abbastanza rapida
2. Test abbastanza semplice
3. Automazione di ogni fase della cadenza.

V) Epics, Stories and Sprints

Solo perché lavori da solo e sei il tuo maestro di mischia, non lesinare sulle Discipline e sui Rituali Agili. Sebbene a volte tale rigore si ritenga ridicolo (perché mai dovresti avere uno stand-up quotidiano con te stesso?), Produrre i risultati Agile offrirà agli stakeholder una visione abbastanza affidabile del tuo lavoro. Questo crea fiducia (giustificata) e dice (sinceramente) che sai davvero cosa stai facendo. Dimentica di creare un'impressione: concentrati sul fare la cosa giusta e ciò creerà l'impressione per te.

Sezione di opinione

Alcuni negozi adottano l'approccio secondo cui l'intero progetto è un Epic e ogni funzionalità è una User Story. Ho sperimentato ambienti in cui l'allineamento tra Story e Sprint è stato rigorosamente applicato, e altri in cui è molto più rilassato. Personalmente mi piace allineare Epics con Features in un approccio Epic (Feature) / Story / Task / SubTask, in cui Story e Sprint sono allineati. Questo ci consente di completare una storia in uno Sprint e consente l'assegnazione dei punti della storia in modo più accurato. Compiti e attività secondarie facilitano la distribuzione del lavoro, anche se al momento non è possibile distribuirlo a nessuno ;-) Allora? È ancora una buona idea

Spero che questi pochi pensieri ti aiutino a iniziare bene.

I would like to know how I should go about splitting up the work into tasks/stories for developing a web application?

1. Inizia con l'impostazione del framework per il codice, la creazione di script, l'integrazione continua e la distribuzione automatizzata. Per eseguire un test end-to-end è necessario almeno una pagina; poiché nulla funzionerà, la prima pagina dovrebbe essere la pagina di errore.

2. Successivamente avrai bisogno di iscrizione e autenticazione. Non puoi fare molto senza questi !! Inizia con i flussi di base ("percorso felice") e quindi aggiungi flussi alternativi, ad es. password errata o utente bloccato.

   Una volta completato il # 2, passa il sito ai tuoi penetration tester o ottieni AppScans in parallelo con il # 3 e successivi.

3. Quindi, crea una pagina che mostri il tuo layout e le tue risorse. È qui che trovi modelli di layout, comportamenti reattivi e standard di carattere e colore.

   Una volta completato il # 3, trasferisci il sito ai professionisti o alle parti interessate di UX per assicurarti che sia tutto in ordine e completa il tuo primo round di test cross-browser in modo da poter rilevare eventuali problemi strutturali.

4. Da questo punto in poi, l'ordine in cui implementate le funzionalità è determinato dagli stakeholder aziendali. In generale, vorrai iniziare con i flussi di base e successivamente aggiungere flussi alternativi.