- Oct 2021
-
www.productheroes.it www.productheroes.it
-
Avere un limite su ogni colonna ti assicura che gli Item si spostino velocemente da una colonna all’altra, visto che questo è l’unico modo per inserire nuovi Item.
Quale è il vantaggio principale del #[[WIP limit]] nella metodologia #agilekanban ?
Sta nel fatto che determinando un numero limite di task da poter inserire nella colonna allora spostare i task da una colonna all'altra (quindi avanzare nello sviluppo) sarà il solo modo per poter inserire nuovi task dal #[[product backlog]] alla board
-
Il Pull system funziona in modo diverso, ovvero con un limite sul numero di elementi inseribili in ogni singola colonna della board, questo limite viene chiamato WIP Limit, ovvero Work in Progress Limit.
In che modo differisce il sistema di #pull tra metodologia #agilescrum e #agilekanban ?
La differenza principale emerge nel fatto che nella metodologia kanban su ogni colonna della board kanban c'è un numero limite di task che si possono inserire, questo numero limite viene chiamato #[[WIP limit]]
-
La principale differenza è che nel Kanban non esistono le sprint. Il processo di sviluppo è continuo.
Quale è la differenza principale tra #agilescrum e #agilekanban ?
La differenza principale è nelle tempistiche dello sviluppo, nella metodologia scrum il processo è di breve durate ed iterativo, in quella kanban invece lo sviluppo è continuo
-
Per tracciare i progressi si usa una board chiamata Scrum Board, Agile Board o per fare un po’ di casino Kanban Board.Di solito ci sono 4 colonne: To Do, Doing o Progress, Test o QA, Done. La premessa di tutto è che queste due metodologie non sono prescrittive per cui ogni team poi può decidere di aggiungere o rimuovere colonne in base alle proprie esigenze.Il Movimento ideale degli Item sulla scrumboard è da sinistra verso destra, se il movimento è al contrario c’è qualcosa che non va.
In che modo avviene il tracciamento dei progressi nei progetti di sviluppo, che siano #agilescrum o #agilekanban ?
Avviene tutto tramite delle board kanban divise in colonne e in cui si deve passare da sinistra a destra.
-
Questa parte è il Pull di cui stavamo parlando prima, ovvero gli item vengono “tirati” dal backlog e non “pushati” da qualcun altro.
In cosa consiste la parte #pull delle metodologie #agilescrum e #agilekanban ?
Essenzialmente si riferisce all'atto con cui i team prendono dal #[[product backlog]] i task su cui si devono concentrare e non vedono questi task essere imposti loro dall'alto e/o qualcuno di esterno.
Compito di #[[product owner]] e #[[scrum master]] è quello di fare di tutto per permettere al team di concentrarsi sullo sviluppo ed implementazione, nel minor tempo possibile e maggiore efficacia, sui task che sono stati inseriti nello #[[sprint backlog]]
-
Quello che accade tra il product backlog, ovvero la mega-lista di cose da fare, e il customer, ovvero l’utente che userà il tuo prodotto, è quello che distingue Scrum da Kanban.
Cosa sono, in una frase, le metodologie #agilescrum e #agilekanban ? Che funzione assolvono?
Essenzialmente portano tutto quello che c'è nel #[[product backlog]] da quella lista al customer.
-
Alcune caratteristiche del Product Backlog:Ogni Item in Backlog deve aggiungere valore all’utente finaleIl Backlog deve essere ordinato e prioritizzatoIl Backlog è un documento vivente. Il processo di revisione e modifica giornaliera del Backlog da parte del Product Owner si chiama Backlog GroomingI dettagli di ogni Item dipendono tipicamente dalla loro posizione sul Backlog: in alto tanti dettagli, in basso pochi dettagli.
Quali sono alcune caratteristiche fondamentali del #[[product backlog]] ?
L'atto di pulizia e aggiornamento del backlog è definito come #[[backlog grooming]]
-
Il Product Backlog è la lista prioritizzata di tutto ciò che si vorrebbe fare (occhio a queste due parole!) all’interno del progetto. Qui sta una delle prime intuizioni semplicissime, ma geniali, dei due metodi.Il fatto che un Item sia in backlog non vuol dire che verrà sicuramente affrontato, sviluppato e rilasciato.
Cosa è il #[[product backlog]] e cosa è presente al suo interno?
Si tratta di una lista prioritizzata di tutto quello che si vorrebbe fare all'interno del progetto.
Importante è l'aspetto del "si vorrebbe", il fatto che qualcosa sia in backlog non significa necessariamente che sarà poi sviluppato e rilasciato.
All'interno di questo backlog si possono trovare #userstory oppure task tecnici oppure bug oppure knowledge task.
-
Secondo i principi dell’Agile, come abbiamo visto nel post precedente, il software viene consegnato al customer in piccoli pezzi che incrementano il valore del software progressivamente, inoltre il feedback dal customer viene preso costantemente in considerazione e diventa parte essenziale del ciclo di sviluppo.
Quale è la differenza principale tra metodologia #waterfall ed #agile ?
La differenza principale è nelle modalità di rilascio del prodotto: nella metodologia waterfall il rilascio avviene interamente e di blocco, nel caso invece di agile il rilascio avviene in fasi iterative e frequenti, piccoli rilasci e implementazioni ad ogni fase.
Nel metodo agile, ad ogni iterazione, il #[[product owner]] raccoglie i feedback di utenti e stakeholder e le utilizza per le prossime iterazioni, inserendole nel #[[product backlog]]
-
n una cascata (waterfall), infatti, l’acqua cade sempre dall’alto verso il basso e così funziona nello sviluppo software Waterfall:Il responsabile di prodotto definisce i requisiti di tutto il progettoIl team di sviluppo realizza il progetto per interoIl progetto viene consegnato al customer tutto in una voltaTutto va nella stessa direzione. Dall’alto verso il basso. Sempre
Come è caratterizzato il metodo #waterfall di sviluppo?
È il metodo classico di sviluppo, in maniera unidirezionale il responsabile di prodotto #[[product owner]] fornisce agli sviluppatori i requisiti di tutto il progetto, questi li implementano per intero, l'intero progetto viene fornito ai consumatori in un'unica volta.
-
-
www.productheroes.it www.productheroes.it
-
Nell’esempio di Giuseppe potremmo chiamare la nostra Epic “Funzionalità di login”. All’interno di quest’ultima andremo poi a inserire le varie User Stories come “Frontend – processo login”, “Backend- processo login”, “Processo di recupero password” e così via fino ad aver completato la nostra funzionalità di login.Per non perdere di vista le varie Epic, andiamo a nostra volta a raggrupparle all’interno di “iniziative”. Tornando al nostro esempio possiamo chiamare la nostra iniziativa “Sito e-commerce – primo rilascio”. All suo interno inseriremo tutte le Epic che riteniamo indispensabili per il rilascio del nostro sito.”
In che modo si può risolvere il problema della mancanza di contesto per le #userstory ?
-
Uno dei problemi nell’uso delle User Story è la mancanza di contesto attorno alla storia. Esistono diversi stratagemmi per risolvere.
Quale è il problema maggiore che emerge dall'utilizzo delle #userstory ?
La mancanza di contesto, questa rende difficile sia l'empatizzare con l'utente sia avere chiaro l'obiettivo e la natura delle implementazioni.
-
Il formato tipico delle User Story ci impone di fare una scelta e decidere le priorità. Quando scrivete una User Story focalizzatevi sempre sulla funzione più importante. Scrivete User Story separate per dettagliare i bisogni differenti. Può creare ridondanza ma vi permetterà di condividere con chiarezza quali sono le priorità.
In che modo fare #userstory ci permette di determinare delle priorità nella creazione del #prodotto ?
Ogni user story deve essere focalizzata su una sola cosa, un solo tipo di utente, un solo obiettivo, una sola azione ed in questo modo dovremo scrivere diverse user story per ogni caso, poi tra le diverse user story stabilire delle priorità ed un peso.
-
Come prima cosa descriviamo quale utente stiamo servendo. A prima vista si potrebbe pensare che l’utente è unico per un prodotto. In realtà ogni prodotto ha una varietà di utenti con diversi intenti.In un e-commerce possiamo sicuramente distinguere tra utenti alla prima visita, utenti registrati, utenti che hanno fatto 1 o più acquisti, e così via. Inoltre molti prodotti hanno alle spalle un servizio e spesso una parte dello sviluppo è dedicata ad utenti interni come per esempio il servizio clienti.
Quanti utenti e quali utenti possiamo distinguere normalmente in un #prodotto ?
Ci sono tanti utenti ad utilizzare un prodotto ognuno contraddistinto da diversi intenti
-
L’utente a cui ci stiamo rivolgendoil bisogno che vogliamo soddisfareil motivo per cui dobbiamo soddisfarlo. Un po’ di esempi pratici renderanno tutto molto più chiaro!Ma, prima di partire con gli esempi, voglio dirvi quali sono per me le 2 caratteristiche essenziali delle User Story: chiarezza e confronto.
Quali sono le caratteristiche alla base delle #userstory ?
Ogni #userstory deve descrivere in maniera fondamentale l'utente a cui ci stiamo rivolgendo, il bisogno che questo utente ha e che noi vogliamo soddisfare ed il motivo per cui dobbiamo e vogliamo soddisfarlo.
-
Il concetto più interessante che introducono le User Story è quello di mettere l’utilizzatore del nostro prodotto (lo User) al centro dell’attenzione durante il processo di sviluppo. Pari importanza è data anche all’identificazione del bisogno che ogni funzionalità promette di soddisfare (la storia).
Cosa sono le #userstory e perché è importante utilizzarle come alternativa alla classica requisitazione?
Le #userstory contribuiscono a mettere lo user al centro del percorso di sviluppo, inoltre attraverso una storia forniscono anche l'identificazione dei bisogni di questo utente e come ogni funzionalità possa essere capace di risolvere questi bisogni.
Queste sfumature si perdono nel corso della classica requisitazione in cui il #productowner fornisce requisiti ai tecnici senza nemmeno spiegarne il motivo.
-
Mi piace molto la definizione di User Story di Mike Cohn: ogni User Story è la promessa di una conversazione. Per Mike quello che c’è scritto nella User Story non è molto importante, è solo un promemoria per innescare una discussione con tutto il team.
Quale è la definizione di #userstory ?
-