Siamo un gruppo di liberi professionisti che collaborano alla realizzazione di siti Web e app e di recente abbiamo iniziato a utilizzare Scrum. Ci stiamo godendo Scrum e la sua trasparenza, ma stiamo riscontrando un problema con il budget dell'equazione.
Sembra che Scrum non consideri i budget, ma siamo troppo nuovi per saperlo con certezza.
C'è un modo per considerare i budget e il costo delle attività in Scrum, o va contro quello che Scrum sta cercando di ottenere usando i Story Points?
Scrum non considera direttamente cose come budget o scadenze. Invece, sembra fornire alla gestione del programma le informazioni di cui hanno bisogno per gestire coscienziosamente i budget e le scadenze. I punti storia sono un esempio eccellente. Per conto proprio, i punti della storia dicono niente su quanto tempo impiegherà un compito. Parlano della complessità del compito. Tuttavia, è ragionevole considerare una "velocità", che è il numero medio di punti a settimana della tua squadra e cercare di determinare per quanto tempo X dovrebbe prendere. Velocity è uno strumento molto popolare e molto potente per il budgeting in SCRUM.
La mia opinione sulla teoria alla base di questo è che la maggior parte dei sistemi che considerano esplicitamente i budget o le scadenze hanno una strong tendenza a spingere gli sviluppatori a dare stime sbagliate per adeguarsi al budget. Spesso le informazioni chiave vengono soffocate perché mostrerebbero quanto è lontana la pianificazione del team. Credo che la soluzione di SCRUM a questo problema sia cercare di concentrarsi sull'assicurare che le informazioni scorrano correttamente prima, e solo in quel caso prendere in considerazione le scadenze.
SCRUM incoraggia la personalizzazione. Potresti essere in grado di regolare il flusso di lavoro in base alle esigenze della tua particolare società.
I punti storia sono in genere una misura della complessità dell'implementazione . Sebbene esista una correlazione tra complessità e costi, nella maggior parte degli scenari il costo sarà influenzato da una serie di altri fattori.
Quindi, i punti della storia possono darti una stima approssimativa dei costi di implementazione, ma sarà così difficile da non farci affidamento.
Il punto principale di SCRUM (e altri approcci iterativi o agili) è che non si sa quale lavoro e quanto è necessario per "finire" il progetto. In qualsiasi momento durante il progetto è possibile aggiungere, ampliare o rimuovere nuove attività in base al feedback del cliente. Questo è il motivo per cui SCRUM e altre metodologie agili optano per rendere il software di lavoro ogni iterazione per dare al cliente la sensazione di progresso invece di "tradizionale" ci sono x% fatti quando x% di [budget è speso] / [tempo pianificato trascorso] metriche.
Questo è un problema per qualsiasi forma di metriche predittive, come il costo totale stimato o il tempo necessario, perché non hai un'idea fugace di quanto lavoro sia effettivamente necessario fare. Ci sono modi per indovinare, ma più il progetto diventa complesso e grande, maggiore è l'incertezza che si ottiene. E non so se il tuo cliente starà bene con una stima di 1 anno + - 9 mesi e con relativo costo totale.
Se hai davvero bisogno di stimare il costo totale e il tempo speso, mi libererò di SCRUM e andrò per un approccio più tradizionale dove proverai a stimare tutte le attività necessarie per completare il progetto e quanto lavoro è necessario per terminarle. Almeno ottieni una parvenza di certezza che le tue ipotesi potrebbero essere corrette.
Leggi altre domande sui tag scrum freelancing budget