Ci sono diversi tipi di ambiente di produzione quando si tratta di rilasciare software:
Leggi l’articolo su Medium pubblicato in Serious Scrum
Applicazioni cloud come Gmail, che hanno il loro ambiente di produzione nel cloud e non sono installate localmente nell’infrastruttura dei clienti Applicazioni desktop come Libre Office installate sul laptop del cliente finale I prodotti software aziendali come SAP che vengono rilasciati in moduli da SAP SE e successivamente devono essere personalizzati per adattarsi alle esigenze del cliente Rilasciare software nel cloud Nelle piattaforme native cloud, tutto è sotto il controllo dell’organizzazione proprietaria del prodotto.
In Scrum è fondamentale avere un prodotto rilasciabile alla fine di ogni Sprint. Per essere in grado di rilasciare così frequentemente è necessario avere una buona branching strategy. Fortunatamente ci sono gli strumenti che permettono di gestire il software nel miglior modo possibile sia in termini di tools che di processo.
Git e Gitflow il sistema di versionamento più utilizzato per la gestione del codice sorgente è Git. Git dà la possibilità di creare branch in maniera molto semplice, veloce e senza richiedere troppe risorse hardware.
Di seguito alcune risposte interessanti su Scrum, date da Jeff Sutherland, in merito ad alcuni quesiti posti dalla community di Quora.
Perché lo Scrum Master è chiamato così, un appellativo così altisonante per un ruolo che è essenzialmente amministrativo? Leggi su Quora
Il lavoro dello Scrum Master è un incrocio tra l’allenatore e il capitano della squadra di calcio e la chiave per la prestazione vincente della squadra. Disintegrare il ruolo dello Scrum Master facendolo diventare un segretario è il motivo per cui il 58% dei team Scrum fallisce o è in ritardo, esaurisce il budget, e genera insoddisfazione nei clienti.
Puoi leggere l’articolo in inglese su Medium pubblicato in Serious Scrum
Cosa suggerisce Scrum I prodotti aziendali variano in complessità. Per gestirli possono essere necessari gruppi di 2-3 persone fino ad arrivare a gruppi che coinvolgono più di 100 persone. Il Product Owner e lo Scrum Master non si devono conteggiare a meno che non eseguano loro stessi anche l’implementazione degli elementi di backlog. Quando la complessità del prodotto aumenta e il numero delle persone coinvolte nello sviluppo inizia a crescere c’è la necessità di prendere delle decisioni su come suddividere i gruppi.