Dove è Fallito Waterfall e possiamo scrum aiutarci ad avere successo nei nostri progetti?

Naviga le tue risposte
3

Lascia che ti spieghi la nostra situazione. Siamo una piccola azienda con circa 20 dipendenti e per tutto il tempo abbiamo praticato il modello standard a cascata con poco successo (a causa di frequenti cambiamenti di requisiti e mancanza di direzione).

Così un giorno il nostro CTO è arrivato e ci ha informato di SCRUM e tutti noi eravamo convinti che questo modello funzionasse alla grande per una piccola squadra come noi. Sfortunatamente tutti noi non abbiamo alcuna esperienza nella pratica di SCRUM e ci siamo affidati principalmente a risorse e libri online.

Quindi arriviamo a un nuovo progetto che stiamo per iniziare e stiamo facendo qualcosa del tipo:

  1. Raccogli i requisiti dell'utente del dominio aziendale
  2. Prepara una specifica dei requisiti con interfaccia utente e funzionalità (ci sono già stati necessari settimane)
  3. Incontra nuovamente l'utente del dominio aziendale per vedere se sono necessarie modifiche
  4. Una volta che l'utente aziendale è d'accordo con le specifiche, inseriremo tali funzionalità nel catalogo prodotti
  5. Spezza queste funzionalità in attività e assegnale allo sprint

Dovremmo invece adottare un approccio più agile? come

  1. Raccogli i requisiti degli stakeholder
  2. Inizia a creare storie di utenti epici e corri con gli stakeholder
  3. Rompi quelle storie epiche in storie più piccole (supportate con un po 'di ui) e    assegnare a uno sprint breve (2 settimane)
  4. Mostriamo loro ciò che abbiamo fatto per le 2 settimane, riceviamo i loro feedback e pianifichiamo il prossimo sprint

Data la natura dei nostri progetti in cui siamo costantemente confrontati con le sfide di requisiti volatili e una mancanza di direzione, dove i punti Scrum / Agile di cui sopra ci beneficeranno e perché i metodi sopra Waterfall ci stanno fallendo?

    
posta CliffC 06.06.2013 - 09:19
fonte

3 risposte

5

Il secondo approccio è molto più nello spirito di agile / scrum, ma richiede anche l'impegno da parte del cliente a visitare regolarmente per vedere i progressi e discutere ulteriori funzionalità.

Se il cliente è a disagio con un tale impegno di impegno da parte loro, o se ha già una buona idea di ciò che vuole avere, allora il tuo primo approccio potrebbe essere più costruttivo.

Uno dei punti chiave della mischia è che il cliente ottiene una grande voce nell'ordine in cui vengono prodotte le cose, quindi lascia che indichino chiaramente quali funzionalità preferirebbe avere prima e quali caratteristiche potrebbero finire nel cestino se il il budget si allunga troppo. E non sollevare storie se il cliente cambia idea su alcuni requisiti / storie, specialmente se non sono ancora stati implementati.

Un approccio alternativo, in un modo più scrumico, ma simile al primo approccio, è come questo:

  1. Raccogli i requisiti
  2. Dividere i requisiti in storie e inserirli in un backlog
  3. Inizia il primo sprint con le storie "crea architettura" e "proposta UI"
  4. Durante lo sprint, discuti le tue proposte con il cliente
  5. Affina il backlog
  6. Alla fine di ogni sprint, seleziona le prossime X storie principali dal backlog da implementare.
risposta data 06.06.2013 - 10:09
fonte
4

Il vantaggio principale di SCRUM (e metodi agili in generale) è che si ottiene un feedback migliore e più rapido (sulle implementazioni, non solo sulle specifiche) degli stakeholder, e quindi c'è meno rischio di lavorare settimane e mesi su qualcosa che finisce non essere quello che volevano. Inoltre, spesso consegna le funzioni più utili prima (a causa delle priorità e del ciclo di rilascio dello sprint).

Se siete tutti d'accordo che trarrete vantaggio da questi vantaggi, e se gli stakeholder sono disposti a fare la loro parte (fornire feedback più frequenti), allora sì, dovreste SCRUM (il secondo processo descrivi) invece di waterfall (il primo processo che descrivi non ha nulla a che fare con SCRUM).

    
risposta data 06.06.2013 - 09:56
fonte
2

Sembra che tu stia tornando a procedure vecchie / conosciute. Un concetto chiave di SCRUM / sviluppo agile è che non si dispone di una specifica anticipata di grandi dimensioni. Ovviamente è necessario conoscere l'intera vista dall'inizio, ma non è necessario specificare tutti i dettagli. Questo è ciò che porta a un processo a cascata, il che è negativo perché non è flessibile e le modifiche o le nuove informazioni sono costose.

Quando si inizia con Scrum, si dovrebbe avere uno Scrum-Master esperto, uno che lo faccia per parecchio tempo. Se non ne hai uno nella tua squadra, dovresti assumerne uno. Almeno per i primi pochi sprint.

Dovresti anche avere il supporto della tua gestione (come fai tu), e il supporto del tuo cliente, perché (s) ha bisogno di fornire il proprietario del prodotto. Questo ultimo punto (disponibilità del cliente / proprietario del prodotto) è nella mia esperienza molto spesso non è il caso. Agile potrebbe ancora avere senso in questi casi, perché puoi cambiare la direzione più facilmente e potrebbe ottenere feedback rapidi sul tuo lavoro.

BTW: in genere non si specifica come dovrebbe essere l'interfaccia utente. Questo è un requisito implicito che deriva dalla descrizione della funzione. Naturalmente ci sarà una guida di stile che copre tutti i concetti di base dell'interfaccia utente, ma non fai particolari cose dell'interfaccia utente per caratteristiche diverse, a meno che questo non sia lo scopo della funzione.

    
risposta data 06.06.2013 - 09:59
fonte

Leggi altre domande sui tag

Quante incongruenze derivano dall'elevata flessibilità di Javascript? Qual è la migliore pratica per quando controllare se qualcosa deve essere fatto?