Metodologia di sviluppo dal punto di vista dello sviluppatore!!!

La metodologia di sviluppo secondo uno sviluppatore consiste nell'utilizzare il seguente percorso per lo sviluppo dell'applicazione Ruby on Rails.

1. Scrivi un elenco di obiettivi, ruoli e caratteristiche

• Obiettivi – quali sono gli obiettivi dell’intero progetto – aziendali e non. Questo ti aiuterà a decidere quali funzionalità sono importanti
• Ruoli: chi utilizzerà il sito: visitatori, membri registrati, amministratori? Persone diverse hanno visualizzazioni diverse delle stesse informazioni sul sito?
• Funzionalità – quali sono le categorie base di interazione sul sito? Ad esempio: Utenti: registrazione, utilizzo dei forum e blog; Amministratori: moderare il contenuto dell'utente

2. Scrivi un elenco di storie

• Una storia è diversa da una funzionalità perché rappresenta un singolo filo di interazione dal punto di vista di un particolare utente.
• È comune esprimere le storie nella forma "Come ____ voglio ____ in modo da poter _____." Ciò ti costringe a rispondere a tre domande importanti: a chi è rivolto? Cosa vogliono fare? Perché vogliono farlo?
• Se non riesci a completare una storia in questo formato, è probabile che tu non abbia ancora una risposta a una di queste tre domande, quindi dovrai riflettere un po' per ottenere le risposte prima che la storia diventi utilizzabile.
• Esempio: "Come amministratore, desidero bandire gli utenti dal forum, in modo da poter migliorare la qualità dei contenuti inviati dagli utenti sul sito.
• Scrivi queste storie su dei bigliettini. Questo ti aiuterà nella stima e nella definizione delle priorità.

3. Stimare le storie

• La stima è un argomento vasto di per sé, ma l’idea di base è associare un particolare livello di impegno a ciascuna storia.
• Le scale più comuni sono 0/1/2/3/4, 0/1/2/4/8. Non penso che questo sia incredibilmente importante, ma scegli qualcosa e mantienilo.
• Non fissarti troppo sull'esattezza delle stime. Molti fattori influiscono sul tempo impiegato per finire una storia, quindi piccole differenze nella complessità della storia tendono a perdersi nel rumore.
• Il tuo obiettivo qui è differenziare le cose che richiedono poco impegno, come le storie che ti porteranno a creare un modello semplice con un controller REST, dalle storie che richiedono uno sforzo elevato, come interfacciare la tua applicazione con un'API impegnativa di terze parti o una storia che ti richiederà di utilizzare una tecnologia con cui non hai molta familiarità.
• Scrivi il preventivo su ogni carta.

4. Dai priorità alle storie

• Riorganizza le carte nell'ordine in cui vorresti affrontare le storie.
• Solo il proprietario del prodotto può davvero prendere questa decisione. Ci sono molti aspetti che entrano in gioco nella definizione delle priorità: scadenze, test degli utenti, valore aziendale, ecc. La stima può avere molto a che fare con la definizione delle priorità, perché mette in luce il costo opportunità. Forse il proprietario del prodotto desidera davvero quella dashboard di amministrazione dettagliata, ma se tutte le storie per farlo funzionare ammontano a 40 punti, vale la pena dedicare un mese solo a questa funzionalità. Forse il proprietario del prodotto vuole ancora la storia
• Ci sono storie che non rientrano nel minimo indispensabile del prodotto da lanciare? Se è così, dovresti spostarli verso il basso. Prova a completare un'app funzionante il più rapidamente possibile in modo da poterla mostrare agli utenti.
• A questo punto, di solito sposto le mie carte in Pivotal Tracker, ma conosco molte persone che preferiscono carta e penna.

5. Prova a completare la prima storia

• Inizia con il cetriolo Scrivi una funzionalità di Cucumber che copra l'interazione dell'utente con il sito dall'inizio alla fine. Definisci i passaggi non definiti man mano che li raggiungi e quando raggiungi il primo errore, sai che c'è un comportamento che desideri che la tua app non abbia (questo accadrà molto rapidamente all'inizio, perché la tua app vuota non lo fa avere molto comportamento).
• Se ho interazioni Javascript che sono una parte fondamentale dell'interazione dell'utente, provo a farle testare a Cucumber utilizzando il tag @javascript.
• Continua su Rspec Scrivi il test per il comportamento che vorresti avere.
• Scrivi il tuo codice Scrivi il codice per far passare la specifica. Questo ti porterà attraverso l'applicazione dal routing all'interfaccia utente, ai modelli, allo schema del database, al controller. Affronterai questi pezzi di codice nell'ordine a cui ti indirizzano i test.
• Ripeti finché il cetriolo non passa e hai finito con la storia.
• Ora è il momento giusto per sistemare lo stile CSS, presupponendo che tu abbia completato la progettazione. Se lavoro da solo o senza un designer, mi piace provare a realizzare il wireframe dell'interfaccia utente su carta o in qualcosa come Balsamiq Mockups prima ancora di iniziare a scrivere il codice della storia.

6. Accetta la storia

• La storia è accettabile? Fa quello che volevi? In caso contrario, devi tornare indietro e farlo funzionare come avrebbe dovuto. Scrivere in anticipo i test sul cetriolo aiuta a evitare che ciò accada.
• Superano tutti i tuoi test? Non hai rotto la build, vero? Se è così, devi riparare ciò che hai rotto.
• Se lavori da solo, potrebbe essere utile che qualcun altro si occupi dell'accettazione per te, poiché potrebbe essere difficile vedere il tuo lavoro con occhi obiettivi.

6. Ripetere fino al termine

Questo è il modo in cui faccio le cose. Non è affatto l'unico modo per fare le cose, ma è un modo molto comune di fare le cose in Rails. Penso che ci sia un buon dibattito sul valore della stima agile, o di particolari tecnologie come Cucumber vs. Steak o RSpec vs Test::Unit, ma la maggior parte degli sviluppatori Rails concorderà sul fatto che il flusso di lavoro corretto è: 1) Identificare un storia singola 2) Scrivi i test 3) Completala. 7. Distribuzione

Consigliamo di distribuire l'applicazione sul cloud a causa della scalabilità, del tempo di attività, del rapporto costo-efficacia e di molti altri fattori. Siamo esperti nella distribuzione su cloud, che si tratti di Heroku, Rackspace o AWS.

Strumenti: - Capistrano, Apache, Passenger, Heroku, GIT/SVN (viene utilizzato principalmente GIT)

8. Supporto post-implementazione

Una volta che l'applicazione è attiva, è sempre necessario supportarla in modo che l'utente finale possa vivere un'esperienza piacevole. Utilizziamo AMC per le applicazioni che sviluppiamo e impegniamo risorse per occuparci di nuovi miglioramenti di funzionalità, correzioni di bug e manutenzione del server 24 ore su 24, 7 giorni su 7. In breve, garantiamo così che anche l'applicazione che sviluppiamo sia gestita e mantenuta bene!

Strumenti: - BugZilla, Redmine, Pivotal Tracker, Helpdesk