Quali fasi di un tradizionale progetto a cascata dovrebbe sostituire Scrum?

Naviga le tue risposte
3

Io e il mio team stiamo utilizzando Scrum per gestire progetti di sviluppo software. Nella mia azienda c'è stato un passaggio verso una maggiore struttura in tutti i progetti IT utilizzando una metodologia a cascata. Questo per me va bene in quanto ci sono molti progetti di sviluppo non software che trarranno grandi benefici da questo e non stanno minacciando il nostro uso di Scrum.

Tuttavia, abbiamo bisogno di capire come i nostri processi Scrum (che fanno un ottimo lavoro nel prendere i requisiti di un Product Owner e trasformarli in un software funzionante) si inseriscano nel più ampio processo di progetto.

Il nostro nuovo processo di progetto a cascata include attività esplicite per le seguenti cose (non necessariamente sequenziali e non necessariamente in questo ordine):

  1. Produzione e approvazione del business case.
  2. Resourcing.
  3. Analisi dei requisiti.
  4. design.
  5. Crea.
  6. Prova.
  7. Formazione.
  8. Comunicazioni.
  9. Vai dal vivo.
  10. Rischio & Gestione dei problemi.
  11. Realizzazione dei vantaggi.

Ricorda che potrebbe essere necessario un progetto per fornire più di un semplice software. Può anche includere l'infrastruttura del server per ospitare il software e l'infrastruttura di rete / desktop per renderlo disponibile agli utenti.

Penso che Scrum gestirà 3, 4, 5 e amp; 6 felicemente ma probabilmente solo per i team che lo trovano aggiunge valore, che è probabilmente solo lo sviluppo del software ...

Potremmo far sì che altri team lo usino per la produzione di prodotti infrastrutturali, ma non ne vedono l'esigenza o il vantaggio e nemmeno io (Scrum è adatto a progetti grandi e rischiosi e stanno creando un sacco di PC standard ).

Allo stesso modo, potremmo avere una User Story nel Product Backlog per il Project Manager (non tipicamente un membro dello Scrum Team) per produrre un piano di realizzazione dei benefici.

Ci stiamo avvicinando correttamente? C'è un modo migliore per integrare questi due stili di lavoro o sono esclusivi e dovremmo usare l'uno o l'altro?

    
posta Nick 09.01.2013 - 15:01
fonte

1 risposta

5

Scrum è una metodologia di project management completa che affronta tutti gli aspetti del ciclo di vita del progetto. A differenza dei progetti gestiti usando un processo sequenziale in cui le cose accadono generalmente una volta e poi vengono rivisitate se necessario man mano che il progetto avanza, Scrum abbraccia un approccio più iterativo - tutto viene affrontato durante ogni iterazione.

Nell'elenco delle cose che hai identificato, l'unico che può accadere in anticipo, all'inizio del progetto è la creazione del business case. È probabile che una qualche specie di scopo, visione e ambito siano stabiliti una volta, e quindi rivisitati solo se necessario. Tutto il resto accade in ogni iterazione, in genere lo Scrum Master è responsabile di garantire che il progetto disponga di risorse sufficienti, facilitando la comunicazione tra le entità interne e gestendo i rischi del progetto. I requisiti sono forniti e classificati in base alle priorità attraverso il Product Owner, e il team è responsabile della stima della quantità di lavoro necessaria per realizzare ogni requisito e quindi di perfezionare continuamente i prodotti di progettazione, implementazione, test e documentazione durante il progetto. Ogni iterazione, in teoria, risulta in un prodotto pronto per essere distribuito a un cliente (un "prodotto potenzialmente spedibile").

Il processo di per sé di solito non risolve esattamente il modo in cui la formazione e "andare in diretta" o le attività di implementazione avvengono. Ovviamente, se il tuo team di sviluppo è responsabile del supporto di una di queste attività, vorrai crearsi del tempo per ciascuna di esse e tenerne conto quando esegui le attività di pianificazione sprint. Se sono gestiti da una squadra diversa, non c'è nulla che dice che devono usare Scrum. Dovrebbero, tuttavia, aspettarsi un prodotto funzionante che contenga nuove funzionalità e / o correzioni di bug su base regolare (al termine di ogni iterazione timebox), ma se fanno qualcosa con quel prodotto funzionante dipende da loro.

Potrebbe non essere appropriato che ogni progetto utilizzi lo stesso ciclo di vita, specialmente se non aggiunge valore o se sarebbe troppo difficile o dispendioso in termini di tempo per passare dai processi attuali a qualcosa di nuovo e diverso. Ad esempio, il team che produce e gestisce l'infrastruttura potrebbe non essere in grado di produrre tutto l'hardware all'interno di una singola iterazione di sviluppo del software. È necessario pianificare le nuove distribuzioni in base alle attività: non è possibile distribuire l'hardware non eseguito, né spedire software incompleto.

Se lo sviluppo del software trarrà vantaggio dall'utilizzo di una metodologia iterativa e incrementale, non c'è nulla di sbagliato nell'utilizzarlo anche se tutti gli altri utilizzano ancora una metodologia sequenziale. Finché, naturalmente, non ha un impatto negativo sul business - stai ancora rilasciando software di alta qualità che aggiunge valore al cliente in tempo, al budget? I tuoi processi si scontrano in modo tale che le persone sono inattive? Considera quelli e riduci al minimo i tempi di inattività massimizzando il valore consegnato ai tuoi clienti.

    
risposta data 09.01.2013 - 15:27
fonte

Leggi altre domande sui tag

Una patch per un progetto opensource eredita la stessa licenza? Quali sono i vantaggi e gli svantaggi di avere un sottodominio per ogni account utente?