Ho utilizzato SCRUM in tre diversi progetti negli ultimi quattro anni. Uno dei vantaggi di SCRUM sembra essere la sua flessibilità e adattabilità, ad esempio rispetto alle mutevoli esigenze dei clienti. Un altro vantaggio è che la direzione può facilmente monitorare lo stato di avanzamento di un progetto.
La flessibilità di SCRUM può essere un vantaggio per esempio quando si implementa unapplicazione web, dove i requisiti cambiano molto velocemente ei clienti capiscono davvero cosa vogliono dopo aver visto un prototipo.
Daltra parte ci sono altri tipi di progetti software (ad esempio nel settore aerospaziale settore) dove i requisiti sono piuttosto fissi: ottieni un documento di specifica dei requisiti e devi tornare sei mesi dopo con un software funzionante e una documentazione completa. Per questo tipo di progetti dubito che sia necessaria la flessibilità offerta da SCRUM (nel senso che non è necessario costruire prototipi e mostrarli al cliente per ottenere un feedback sui requisiti): è piuttosto necessario un approccio molto strutturato e sistematico, che probabilmente viene ripetuto più e più volte per ogni progetto con poco spazio per la sorpresa.
Quindi SCRUM è considerato dai suoi fautori una metodologia di sviluppo software di uso generale o è considerato particolarmente adatto per determinate categorie di progetti o aree di applicazione?
Per Ad esempio, di recente ho guardato il sito Web di unazienda che produce software per lindustria aerospaziale e ho notato che utilizza il modello V. Un sostenitore di SCRUM direbbe che SCRUM è meno adatto per questo tipo di progetti o suggerirebbe piuttosto che questa azienda dovrebbe provare a passare a SCRUM?
Nota che non sto chiedendo lopinione dei lettori di questo forum, ma voglio sapere qual è lopinione consolidata tra i proponenti di SCRUM: SCRUM è considerato generico o piuttosto adatto a determinate classi solo dei progetti? In questi ultimi casi, per quali tipi di progetti?
Commenti
- Vedere stackoverflow.com / questions / 596916 / quando-non-dovresti-scrum e eweek.com/c/a/IT-Management/…
- Che ” ottenga un documento di specifica dei requisiti e devi tornare sei mesi dopo con un software funzionante ” è un mito. Anche quando costruisci qualcosa come un compilatore per un linguaggio definito formalmente (dove i requisiti funzionali sembrano essere davvero chiari e fissi), devi decidere e dare la priorità alle cose da implementare, ci sono requisiti non funzionali da discutere con lutente , e hai diversi gradi di libertà per decidere come risolvere le cose. Quindi un approccio agile ha senso anche per questo tipo di progetti.
- ” Quindi un approccio agile ha senso anche per questo tipo di progetti. “: sebbene agile possa essere più flessibile, anche altri metodi lo sono. Possono essere altri metodi abbastanza flessibili e agile è troppo flessibile per alcuni progetti. Sto solo facendo brainstorming qui.
- ” Che ” ottieni un documento di specifica dei requisiti e devi tornare sei mesi dopo con un software funzionante ” cosa è un mito. “: non ‘ la penso così . Mentre puoi cambiare rapidamente letichetta di un pulsante su una pagina web perché i clienti hanno cambiato idea dopo averla guardata, non puoi cambiare facilmente una parte critica di un software avionico che controlla una parte in movimento di un aereo. Forse saranno necessarie modifiche tardive, ma mi chiedo se un metodo agile sia il modo giusto per gestirle o se hai bisogno di uniterazione più complessa di un altro metodo (ad esempio il modello V).
Answer
SCRUM è una metodologia generica che può funzionare bene per la maggior parte dei progetti e le dimensioni dei team, ma è meno utile per i team grandi che lavorano molto progetti. Lenorme numero di persone coinvolte in alcuni progetti rende qualsiasi metodologia agile estremamente difficile o quasi impossibile perché è necessaria una struttura più rigida per mantenere lordine. Lindustria aerospaziale è un buon esempio di un settore che tende ad avere grandi progetti in cui gli approcci agili non sono “sempre fattibili.
Commenti
- Cè qualsiasi informazione su quando un progetto è considerato troppo grande per essere fatto con SCRUM? Considera ad esempio un progetto di 18 mesi per un team di 15 persone: un tale team trarrebbe vantaggio da SCRUM o sarebbe adatto anche un altro modello come il modello V Il motivo per cui lo chiedo è che in 18 mesi i requisiti e limplementazione abbiano tempo sufficiente per maturare e stabilizzarsi e forse la flessibilità fornita da SCRUM non è realmente necessaria.Piuttosto, in questo caso è adatto un approccio più a medio-lungo termine. Cè della letteratura su questo?
- @Giorgio il tempo del progetto ‘ non ha molta importanza, ma 15 persone sono sufficienti per trarre vantaggio dalla creazione di mischia multipla gruppi, ma è ancora nella gamma gestibile per SCRUM. quando la gestione della comunicazione inizia a diventare un lavoro a tempo pieno per il tuo team, è tempo di iniziare a guardare un modello a V
- Dici sul serio? Prima stavamo usando un modello V e siamo passati a SCRUM. In realtà abbiamo la sensazione che ‘ siamo diventati più lenti proprio per questo motivo: troppa contabilità.
- @Giorgio che sarebbe vero per qualsiasi passaggio, tu sei allinizio ti sembrerà più lento perché è nuovo, come ha detto Pierre 303, hai unidea migliore dopo alcuni sprint.
- @Giorgio – che ‘ è vero, molte ” ” metodologie agili sono più pesanti dei processi pesanti che ‘ dovrebbero Rimpiazzare! Ovviamente questo significa che ‘ si sbagliano: si suppone che agile sia leggero e libero e che appaia caotico agli estranei. Significa che la tua squadra deve essere molto organizzata e disciplinata, ma ‘ è generalmente un vantaggio. Prova invece Crystal di Alistair Cockburn (uno dei fondatori di Agile).
Answer
Qualsiasi tipo di progetto ! Funziona bene sia per progetti grandi che per piccoli.
Le persone lo hanno usato per pianificare matrimoni, traslochi ecc. Quindi, non solo per progetti software.
Sono fermamente convinto che ci sono molte operazioni aziendali che potrebbero trarre vantaggio da un approccio simile a Scrum.
Commenti
- La tua opinione è condivisa dai proponenti di SCRUM, cioè dagli autori che hanno codificato e promosso SCRUM?
- Sì, è stato detto di recente da Cheryl Hammond ( blog.bsktcase.com ), una consulente ALM con Northwest Cadence in una conferenza dal titolo ” A Scrum Masters Day In The Life: The New Visual Studio “. Puoi guardarlo qui: msevents.microsoft.com/CUI/…
Answer
Nota che Scrum non è una metodologia, ma un framework.
Scrum funzionerà meglio in un c ross-functional team da 5 a 9 sviluppatori che lavorano su un progetto di dimensione medio-grande (da 4 mesi a più anni). Se il tuo progetto è più grande, puoi ridimensionare con Scrum of Scrums .
Non discuterò la cosa interfunzionale qui, ma qui sono ciò che la Guida ufficiale di Scrum ci dice per la dimensione del team:
Sviluppo ottimale La dimensione della squadra è abbastanza piccola da rimanere agile e abbastanza grande da completare un lavoro significativo. Meno di tre membri del team di sviluppo riducono linterazione e si traducono in minori guadagni di produttività. I team di sviluppo più piccoli possono incontrare vincoli di abilità durante lo Sprint, impedendo al team di sviluppo di fornire un incremento potenzialmente rilasciabile. Avere più di nove membri richiede un coordinamento eccessivo. I grandi team di sviluppo generano troppa complessità per essere gestita da un processo empirico. I ruoli Product Owner e Scrum Master non sono inclusi in questo conteggio a meno che non stiano anche eseguendo il lavoro dello Sprint Backlog
Uno sprint dura circa un mese.
Gli sprint sono limitati a un mese di calendario. Quando lorizzonte di uno Sprint è troppo lungo, la definizione di ciò che si sta costruendo può cambiare, la complessità può aumentare e il rischio può aumentare. Gli sprint consentono la prevedibilità garantendo lispezione e ladattamento dei progressi verso un obiettivo almeno ogni mese di calendario. Gli sprint limitano anche il rischio a un mese di calendario di costo.
Penso che non abbia senso utilizzare un framework basato su un processo iterativo con progetti più piccoli di 4 mesi. 4 mesi = 4 sprint. Devi anche considerare che ottieni una velocità più precisa dopo 3 sprint.
Detto questo , Personalmente uso una versione limitata di Scrum per progetti più piccoli, ma allora non puoi chiamarla davvero Scrum. In quel caso particolare, stai usando alcuni principi fondamentali di Scrum nella tua implementazione del framework.
Answer
per i principianti , pensa a SCRUM come a una serie di linee guida per limplementazione di pratiche agili. Non pensarlo mai come un “libro sacro” su come realizzare progetti. Per molti progetti in cui è richiesto un flusso costante di attività, Kanbam è più appropriato, ad esempio.
I progetti Agile tendono a cadere dove “stai facendo progetti che richiedono una data di fine fissa o un costo fisso. Anche se puoi ancora realizzare questi progetti utilizzando metodi Agile, la necessità di pianificare tutto in anticipo determinare se è probabile che tu raggiunga lobiettivo non è il solito modo agile: in agile tendi a continuare a lavorare finché non finisci le cose da fare o non hai tempo per farlo. Per la maggior parte dei progetti va bene poiché i requisiti cambiano comunque durante il progetto.
Commenti
- Il modo in cui agiamo nel nostro team è lasciare che il cliente fissi una priorità sulle storie (dalla più importante alla meno importante), stimiamo le storie degli utenti utilizzando le carte da poker e pianifichiamo quante più storie possiamo implementare fino alla scadenza. Se risultiamo più veloci, programmiamo più storie, in base a ciò che viene dopo nella lista delle priorità.
- Ho letto di nuovo la tua risposta dopo alcuni mesi ed è davvero illuminante. +1