Processo di sviluppo software per un part time Progetto universitario per 1 sviluppatore?

Il primo principio del Agile Manifesto è di avere una preferenza per la collaborazione della squadra sui processi. Ciò che questo significa per te è non farsi prendere con XP o Scrum o qualche altro processo con nome, ma fare qualcosa per le tue esigenze specifiche. Alcuni approcci che possono davvero aiutare:

• User story per tenere traccia di requisiti / caratteristiche e stima (punti della storia). Fornisce una struttura sufficiente per capire il design di alto livello senza impantanarsi nei dettagli.
• BDD o TDD , tanto più importante perché lavori da solo. Senza un apposito testatore, hai due cappelli da indossare. Se codifichi i tuoi test, ti aiuteranno a scoprire quando per errore interrompi qualcosa.
• Controllo della versione. Usalo, salverà la tua pelle, anche se sei una sola persona. Meglio ancora, utilizzare una soluzione ospitata esternamente con backup regolari. Esistono diverse opzioni come GitHub o alcuni equivalenti che ti consentono di avere repository privati. Niente di peggio della sensazione di affondamento prima del d-day (giorno di consegna) e ti sei appena reso conto che sei caduto in un buco di rabbia che aveva un pozzo senza fondo. Il repository ti consentirà di tornare a una versione sana e scegliere un percorso diverso.
• iterazioni brevi. Non più spesso di una volta alla settimana, ma non meno di una volta ogni due settimane. Hai bisogno di feedback costanti e l'iterazione settimanale può funzionare davvero bene. Ad ogni iterazione dovresti avere qualcosa che funzioni, anche se con più funzioni. Se continui a scorrere troppo spesso farai girare le ruote e non farai abbastanza. Se non lo fai scorrere abbastanza spesso sarà troppo lungo senza feedback (cioè il tuo ciclo di test) e i problemi diventano più problematici da risolvere.

Non c'è niente che ti impedisca di utilizzare un processo agile con un solo sviluppatore, anche se alcuni come XP richiedono la programmazione delle coppie, quindi dovresti utilizzare una metodologia diversa.

È stato sostenuto che XP è una forma particolarmente fragile di sviluppo Agile. In XP Refactored gli autori sottolineano che se non si adotta solo una delle funzionalità di XP, l'intera cosa può fallire abbastanza male.

Non puoi fare saldi quotidiani, a meno che il tuo tutor / supervisore sia disponibile tutti i giorni alla stessa ora. Quindi dovrai scegliere le funzioni che usi.

I brevi cicli di iterazione ti aiuteranno e potrai utilizzare i tuoi tutorial settimanali (?) per discutere i progressi compiuti nell'ultima settimana e ciò che speri di ottenere nella prossima settimana.

Per i miei progetti personali utilizzo Kanban personale per la visualizzazione complessiva del processo.

...Unlike other personal productivity tools, Personal Kanban is a pattern – it is not an edict. You can mold it into whatever shape or form works best for you at the time. Personal Kanban is also scalable – it can work with just you, or with your family, or even with work groups.

There are only two real rules with Personal Kanban:

1. Visualize your work
2. Limit your work-in-progress

It’s just that simple. After you’ve used this “introductory’ kanban for a little while, your understanding of the nature of your work will evolve. As it does, your kanban will likewise evolve...