Come faccio a sapere se sto usando le metodologie Scrum?

In primo luogo, consiglierei questo post di Programmatori SE perché raggiunge punti buoni abbastanza rapidamente: Che cos'è la metodologia agile?

Il nucleo del funzionamento all'interno di una metodologia Agile è lo sviluppo iterativo, in modo da creare valore, adattarsi alle mutevoli esigenze del cliente e avere sempre un'app funzionante di fronte a te (come Andrew ha risposto ).

Per alcuni buoni punti tra Agile e un altro approccio a cascata, che sembra essere stato nella tua cronologia, vedi: Do not Go Chasing Waterfalls (Mini-waterfall vs Agile) , il risultato di quel post è

Stop thinking in terms of:

1. Get the requirements
2. Design the solution
3. Develop the solution
4. Test

Start thinking in terms of:

1. Figure out the first thing the user wants
2. Build a small piece, making sure it is right
3. Check with the user to see how to make it better
4. Continue until user is happy

Se dovessi dire che stai operando in modo Agile, o con i principi Agile in mente, non ti sbaglieresti; la mia domanda per te sarebbe perché stai cercando di convincere il tuo capo di questo? Se è perché devi spiegare te stesso perché la tua metodologia viene accettata negativamente dai tuoi clienti / all'interno dell'azienda, questa è una cosa - e non penso che tu spieghi che Agile cambierà il fatto che le persone internamente sono infelici (se lo sono).

Tuttavia, se è per informarlo delle tue pratiche di sviluppo in modo che tu possa (e lui o lei possa) gestire le aspettative dei gruppi di stakeholder, allora fantastico! In questo caso, hai un po 'più del framework che puoi mettere in atto, anche come sviluppatore solitario , per mantenersi sano e continuare a spedire la tua app.

Considera "Scrum Framework in 30 secondi" :

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wishlist, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Ecco come potrebbe mappare la tua situazione:

• Mantieni il tuo backlog - il tuo elenco di cose che tu / le parti interessate vuole fare - includendo una linea guida approssimativa di prioritizzazione (ad es. show-stoppers, nice-haves, cose promesse da una certa data)
• Determina per te quanto spesso vuoi rilasciare (ogni settimana? ogni 2 settimane? ecc.) e rispettare questo programma
• All'inizio di ogni ciclo di sprint (ogni settimana, ogni 2 settimane o qualsiasi altra cosa tu decida), guarda l'arretrato e determina quante di queste cose puoi fare, inserendole in raggruppamenti tematici, se possibile. Pianifica i prossimi due sprint in anticipo se puoi (metti due sprint di materiale in un "bucket")
• Dì al tuo capo "questo è ciò che mi sto impegnando per data X, questo è ciò che mi sto impegnando per data Y" - spara basso fino a quando non ottieni un controllo su ciò che puoi impegnare a
• Dì a tutti gli altri che nulla viene aggiunto all'elenco delle cose da fare per lo sprint (a meno che non si tratti di un bug di wild show stop), ma verrà preso in considerazione per la valutazione dello sprint successivo.
• Alla fine dello sprint, osserva le cose che sono state fatte, pensa a cosa potresti fare meglio, rilascia l'app, fai un respiro e ricomincia.

Non suona molto lontano da quello che stai facendo - o sei pronto a farlo - ora, ma fornisce una piccola struttura attorno al tuo lavoro che dovrebbe essere utile.

Sto scrivendo questo nella speranza che qualcuno più saggio ed esperto nel mondo reale Scrum possa dirmi tutti i miei errori.

Vedo Scrum come un modo per fornire e creare valore per il cliente. Gli sprint di Scrum e gli story board sono tutti incentrati sul valore del cliente. E Agile significa essere in grado di adattarsi e fornire un rapido valore per il cliente. Quale valore fornirebbe al cliente un'intera riscrittura di un'applicazione esistente? Questa è la prima domanda. Il secondo è che dire che riscrivi un'intera applicazione non mi sembra molto agile.

Nella mia mente il modo Agile di "riscrivere" questa applicazione sarebbe valutare ciascuna delle nuove funzionalità che si stanno aggiungendo e vedere se possono essere scritte in piccoli moduli usando C # e i punti di integrazione di Microoft Office in Excel. In questo modo, con il passare del tempo, gran parte del codice verrà scritto in un linguaggio di gestione moderno e in runtime.

La cosa più grande con Agile e persino la metodologia SCRUM è di avere sempre un'applicazione funzionante. Aggiungi funzionalità complete funzionalità ad ogni iterazione. Per questa stessa natura non è possibile una "riscrittura" completa. Tuttavia, dopo un lungo periodo di aggiunta di nuove funzionalità di lavoro, potenzialmente utilizzando un meccanismo di integrazione diverso come C #, avrai a tutti gli effetti una nuova applicazione.

Quando ti ho capito bene, questo riguarda principalmente te e il tuo capo. Quello che stai facendo non è mischia, immagino (hai incontri giornalieri di scrum? Io non la penso così.) Per me sembra che tu stia facendo solo uno sviluppo incrementale classico a piccoli passi, supportato da un elenco di problemi / requisiti e alcuni gestione della configurazione leggera. Alcuni la chiamano "agile" al giorno d'oggi, ma per me sembra essere solo una parola di fantasia per una vecchia saggezza.

However, my boss (non-IT trained) thinks what I am doing are just adhoc changes and that i am not looking at the "bigger picture".

[...] maybe borrow a buzzword to confuse him

Non penso che questa sia una buona strategia. Se il tuo capo non vede il valore nel tuo lavoro, non dovresti confonderlo con parole d'ordine. Invece dovresti rendere il valore più trasparente.

Ad esempio: mantieni un log delle modifiche? Voglio dire, un log delle modifiche per l'utente finale, che non si riferisce a nessuna modifica al codice interno, ma una in cui ogni utente (e il tuo capo) può vedere quali nuove funzionalità / modifiche di funzionalità sono state implementate in ciascuna versione. Questo può iniziare.

Ciò che non capisco è ciò che il tuo capo pensa a come dovrebbe apparire l'immagine più grande e perché il tuo approccio non va in quella direzione. Da quello che stai dicendo, non stai solo apportando modifiche ad hoc, stai anche pianificando e implementando cambiamenti più grandi e tutte le modifiche sono motivate dai requisiti degli utenti. Quindi ovviamente stai seguendo un "quadro più ampio".

Oppure il tuo capo pensa che la soluzione VBA di Excel debba essere sostituita da un'applicazione .NET a lungo termine? In questo caso, consiglierei di scegliere un percorso che possa essere seguito in modo incrementale. Una riscrittura C # potrebbe non essere la cosa migliore per raggiungere questo obiettivo. Un approccio migliore potrebbe essere quello di eseguire il porting di parti di Excel-VBA in VB.NET, passo dopo passo. Ho fatto qualcosa di simile in passato utilizzando Excel-DNA . Usando VB.NET quando hai un sacco di codice VBA esistente, il porting è molto più facile.

Riguardo alle riscritture, raccomando questo fantastico articolo di Joel Spolsky .