A quali tipi di progetti è considerato adatto SCRUM?

SCRUM è una metodologia generica che può funzionare bene per la maggior parte dei progetti e le dimensioni del team, ma è meno utile per i grandi team che realizzano progetti di grandi dimensioni. L'enorme numero di persone coinvolte in alcuni progetti rende estremamente difficile quasi impossibile una metodologia agile perché è necessaria una struttura più rigida per mantenere l'ordine. L'industria aerospaziale è un buon esempio di un'industria che tende ad avere progetti enormi in cui gli approcci agili non sono sempre fattibili.

Qualsiasi tipo di progetto! Funziona bene sia per progetti grandi che piccoli.

Le persone lo hanno usato per pianificare matrimoni, traslochi, ecc. Quindi, nemmeno per progetti software.

Sono fermamente convinto che ci siano molte operazioni commerciali che potrebbero beneficiare di un approccio simile a Scrum.

Si noti che Scrum non è una metodologia, ma un framework.

Scrum funzionerà al meglio in un team interfunzionale di 5-9 sviluppatori lavorando su un progetto di dimensioni di dimensioni medio-grandi (da 4 mesi a più anni). Se il tuo progetto è più grande, puoi ridimensionarlo con Scrum of Scrums .

Non discuterò qui la cosa interfunzionale, ma qui ci sono i ufficiali La guida di Scrum indica la dimensione della squadra:

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog

Lo sprint è di circa un mese.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Penso che non abbia senso usare un framework basato su un processo iterativo con progetti inferiori ai 4 mesi. 4 mesi = 4 sprint. Devi anche considerare di ottenere un velocità a> dopo 3 sprint.

Detto questo, io personalmente uso una versione limitata di Scrum per progetti più piccoli. Ma non puoi davvero chiamarlo Scrum allora. In quel caso particolare, stai usando alcuni principi base di Scrum nella tua implementazione del framework.

per cominciare, pensa a SCRUM come a una serie di linee guida per l'implementazione di pratiche agili. Non pensarlo mai come un "libro sacro" su come fare progetti. Per molti progetti in cui è richiesto un flusso costante di attività, Kanbam è più appropriato, ad esempio.

I progetti agili tendono a crollare dove stai facendo progetti che richiedono una data di fine fissa o un costo fisso. Sebbene tu possa ancora fare questi progetti usando i metodi Agile, la necessità di pianificare tutto in anticipo per determinare se è probabile che tu colpisca il bersaglio non è il solito modo agile - in agile tendi a continuare a lavorare finché non finisci le cose per fare, o senza tempo per farlo. Per la maggior parte dei progetti questo va bene, dato che i requisiti cambiano comunque durante il progetto.