Share
Mentre l'obiettivo principale di Scrum è l'organizzazione e la gestione dei progetti, magro è più l'ottimizzazione dei processi al fine di produrre rapidamente prodotti di qualità. Può essere il tuo primo passo verso l'adozione dei principi Agile, o potrebbe essere qualcosa a cui il tuo team si evolve, quando Scrum non è abbastanza. Vi invito a leggere la storia del mio team e come siamo passati da Scrum a un processo di sviluppo più snello.
Lean è un insieme di principi definiti dall'industria automobilistica giapponese negli anni '80. L'ingegnere di qualità Toyota, John Krafcik, ha coniato il termine, osservando i processi e gli strumenti utilizzati Eliminate lo spreco nella produzione automobilistica di massa. Solo nel 2003 Mary e Tom Poppendieck hanno introdotto Lean come un processo di sviluppo software nel loro libro, Lean Software Development: An Agile Toolkit.
Mentre Scrum è un insieme di regole e ruoli, Lean è un insieme di principi e concetti con una manciata di strumenti. Entrambe sono considerate tecniche Agile e condividono la stessa ideologia di fornire velocemente, riducendo al contempo difetti ed errori. Sottolineo sempre l'adattabilità di Agile, ma non posso ignorare il fatto che Scrum si presenta come un insieme di regole obbligatorie. In effetti, i fan religiosi di Scrum avrebbero urlato blasfemia per non aver seguito le regole di Scrum nella lettera.
Lean, d'altra parte, è più aperto; i suoi seguaci presentano il processo come un insieme di raccomandazioni altamente adattabili.
Incoraggia il team o l'azienda a prendere decisioni, e si adatta alle decisioni e alle sorprese di ogni giorno che il tuo team e la tua società affrontano.
Mentre il mio team maturava e sfruttava Scrum, sentivamo che alcuni aspetti di ciò ci trattenevano. Siamo diventati una squadra abbastanza disciplinata e omogenea. Alcuni incontri non erano più appropriati per noi e abbiamo iniziato a renderci conto che gli incontri quotidiani non erano efficienti. Abbiamo appreso che i problemi dovrebbero essere risolti più velocemente e abbiamo sentito la necessità di evitare queste procedure che ci hanno trattenuto.
Siamo andati avanti.
Lean espone due concetti principali, ma le idee principali sono: eliminare gli sprechi e migliorare il flusso di lavoro.
Se qualcosa si rompe, si romperà venerdì.
Tutto ciò che ostacola la produzione è uno spreco. Ciò include il tempo perduto, i materiali rimanenti e una forza lavoro inutilizzata. I difetti nel prodotto finale sono rifiuti; spreca tempo per risolverli, spreca denaro per sostituirli e spreca risorse per trovare altre soluzioni.
Il concetto di spreco si traduce piacevolmente nel mondo dello sviluppo del software. I rifiuti possono essere descritti da consegne in ritardo, bug e programmatori che non hanno nulla da fare (non confondere questo con "i programmatori dovrebbero programmare otto ore al giorno senza pausa e youtube").
Il concetto Lean di Toyota si concentra sul flusso di produzione. In uno stabilimento di produzione, il flusso è una catena di procedure che trasformano le materie prime nei loro prodotti finali. Queste procedure possono essere molto diverse tra loro e richiedere tempi diversi per il completamento, ma possono essere migliorate per renderle più efficienti. È una battaglia costante per trovare e migliorare i colli di bottiglia nel processo.
Un flusso ideale è quello in cui ogni fase richiede la stessa quantità di tempo e sforzo per produrre la stessa quantità di prodotti.
Questo non significa che ogni processo dovrebbe costare la stessa quantità di denaro, ma ogni processo dovrebbe essere in grado di completare con la stessa facilità.
Ironia della sorte, Scrum è stato lo strumento che alla fine ci ha portato a realizzare gli sprechi nel nostro progetto. Mentre abbiamo aderito al puro Scrum in alcune aree della nostra produzione, abbiamo iniziato a identificare bug e / o ritardi che potremmo facilmente evitare adottando un approccio diverso.
A quel punto sapevamo poco di Lean. Leggiamo alcuni articoli sull'argomento, ma abbiamo fatto la cosa sbagliata e li abbiamo ignorati, perché eravamo così concentrati sul nostro processo Scrum. Eravamo quasi convinti che Scrum fosse il Santo Graal, ma la nostra "mitragliatrice di Scrum" iniziò a sbagliare. Avevamo bisogno di aprire le nostre menti.
Per lo sviluppo del software, i principi di Lean sono stati adattati ai sette seguenti.
Il passaggio da Scrum a Lean è stato davvero liberatorio.
Nello sviluppo del software, è possibile trovare ed eliminare gli sprechi riconoscendo le cose che devono essere migliorate. In senso pragmatico, tutto ciò che non è un valore diretto per il cliente è uno spreco. Per fornire alcuni esempi: lo spreco è un bug, un commento nel codice, una funzione inutilizzata (o usata raramente), i team che aspettano altri team, che prendono una chiamata personale ... hai l'idea. Qualunque cosa che trattiene te, la tua squadra o il tuo prodotto è uno spreco, e dovresti prendere le misure appropriate per rimuoverlo.
Ricordo che uno dei nostri problemi era la frequente necessità di reagire più velocemente di due sprint. Lo sviluppo negli sprint e il rispetto delle regole di Scrum vieta di cambiare le storie assegnate allo sprint attuale. Una squadra deve adattarsi quando un utente trova un bug e ha bisogno di una correzione, o quando il cliente più importante vuole una funzionalità che possa essere facilmente integrata in due giorni. Scrum non è abbastanza flessibile in questi casi.
Attribuire un valore elevato all'istruzione.
Hai rifiuti e naturalmente vuoi meno rifiuti in futuro. Ma perché ci sono rifiuti? È più che probabile che provenga da un membro del team che non sa come affrontare un particolare problema. Va tutto bene; nessuno sa tutto. Attribuire un valore elevato all'istruzione.
Identificare le aree che richiedono il maggior miglioramento (in termini di conoscenza) e iniziare la formazione. Più tu e il tuo team siete a conoscenza, più è facile ridurre gli sprechi.
Ad esempio, l'apprendimento di Test Driven Development (TDD) può ridurre il numero di errori nel codice. Se hai problemi con l'integrazione di moduli di diversi team, potresti voler imparare cosa Integrazione continua significa e attuare una soluzione adeguata.
Puoi anche imparare dal feedback degli utenti; questo ti permette di imparare come gli utenti usano il tuo prodotto. Una funzione usata frequentemente può essere accessibile solo navigando attraverso cinque menu. Questo è un segno di spreco! Inizialmente potresti incolpare tali rifiuti su programmatori e progettisti (e potresti essere corretto), ma gli utenti tendono a usare il tuo software in modi che non avresti mai voluto. Imparare dai tuoi utenti aiuta ad eliminare questo tipo di spreco. Ti aiuta anche a eliminare i requisiti errati o incompleti. Il feedback degli utenti può guidare un prodotto su percorsi che altrimenti non avresti mai considerato.
Ad un certo punto, il mio team ha identificato che alcuni moduli avrebbero potuto essere scritti meglio se avessimo saputo di più sul dominio all'inizio. Naturalmente, non c'è modo di tornare indietro nel tempo, e riscrivere un enorme pezzo di codice non è pratico. Abbiamo deciso di investire del tempo per conoscere il dominio quando è stato assegnato un compito più complesso. Ciò potrebbe richiedere alcune ore o addirittura settimane, a seconda della complessità del problema.
Ogni decisione ha un costo. Potrebbe non essere immediato e materiale, ma il costo è lì. Le decisioni di differimento ti aiutano a prepararti pienamente ai problemi che devi affrontare. Probabilmente l'esempio più comune di decisione tardiva è con la progettazione del database.
Le decisioni non devono essere di natura tecnica; comunicare con i clienti ti aiuta a prendere decisioni che influiscono sul modo in cui ti avvicini alle caratteristiche dei tuoi prodotti.
Ma gli utenti non sempre sanno quello che vogliono. Rimandando le decisioni relative alle funzionalità fino a quando gli utenti hanno effettivamente bisogno della funzione, si avranno maggiori informazioni sul problema e si potranno fornire le funzionalità necessarie.
Scegli la metodologia Agile che funziona meglio per te e il tuo team.
Quattordici anni fa, il team ha preso la decisione di archiviare la configurazione dell'applicazione in un database MySQL. Hanno preso questa decisione all'inizio del progetto, e ora la squadra attuale (il mio team) ha un onere difficile da portare. Fortunatamente, quel prodotto non è più in sviluppo attivo, ma dobbiamo ancora mantenerlo di volta in volta. Quello che dovrebbe essere un compito semplice finisce per essere enormemente monumentale.
Dal lato positivo, abbiamo imparato dagli errori dei nostri predecessori. Facciamo le decisioni di programmazione, architettoniche e di progetto il più tardi possibile. In realtà, abbiamo imparato questa dura lezione prima di adottare Lean. Scrivi il codice aperto e disaccoppiato e scrivi un design che sia persistente e indipendente dalla configurazione. È certamente più difficile da fare, ma alla fine ti risparmia molto tempo in futuro.
Qualche tempo fa, abbiamo aggiunto una funzionalità al nostro prodotto che comprime i dati sul disco. Sapevamo che sarebbe stato utile e volevamo aggiungerlo al nostro prodotto il più rapidamente possibile. Abbiamo iniziato con una semplice funzionalità, evitando decisioni in merito alle opzioni e alla configurazione fino a un momento successivo. Gli utenti hanno iniziato a fornire feedback dopo alcuni mesi e abbiamo preso tali informazioni per prendere decisioni in merito alle opzioni e alla configurazione della funzione. Abbiamo modificato la funzione in meno di un giorno e non un singolo utente si è lamentato o ha richiesto più funzionalità. È stata una modifica facile da fare; abbiamo scritto il codice sapendo che avremmo apportato una modifica in futuro.
Viviamo in un mondo in continua evoluzione. I programmi che scriviamo oggi sono per computer che saranno obsoleti in due anni. La legge di Moore è ancora valida e continuerà ad esserlo.
La velocità di consegna è tutto in questo mondo frenetico.
Fornire un prodotto in tre anni ti mette dietro le quinte, quindi è molto importante dare valore ai tuoi clienti il prima possibile. La storia ha dimostrato che un prodotto incompleto con una quantità accettabile di bug è meglio di niente. Inoltre, hai un feedback inestimabile per gli utenti.
La nostra azienda ha fatto un sogno: consegnare dopo ogni sprint. Naturalmente, questo è poco pratico nella maggior parte dei casi. I nostri utenti non volevano un prodotto aggiornato ogni settimana o mese. Quindi, mentre ci sforziamo di rilasciare ogni versione del nostro codice, non lo facciamo. L'abbiamo imparato "veloce" è ciò che l'utente percepisce - non ciò che siamo fisicamente in grado di fare. Nel settore dei nostri prodotti, veloce significa aggiornamenti regolari ogni pochi mesi e correzioni di bug critiche in pochi giorni. Questo è il modo in cui i nostri utenti percepiscono "velocemente"; altri tipi di prodotti e industrie hanno definizioni diverse di "veloce".
I programmatori erano risorse racchiuse in cubicoli, che eseguivano silenziosamente i loro compiti per la loro azienda. Questa era l'immagine prominente di un programmatore alla fine degli anni '90, ma non è più così.
La storia ha dimostrato che quell'approccio e la tradizionale gestione del progetto a cascata non sono adatti per il software.
A un certo punto è stato così grave che solo il 5% circa di tutti i progetti software è stato effettivamente consegnato. Le aziende e i prodotti da milioni di dollari hanno fallito il 95% delle volte, causando enormi perdite.
Lean ha identificato che i programmatori immotivati hanno causato questo spreco. Ma perché la mancanza di motivazione? Bene, i programmatori e i team di sviluppo non sono stati ascoltati. L'azienda ha definito compiti e microgestito i dipendenti che sono stati visti solo come risorse che producono codice sorgente.
Lean incoraggia i manager ad ascoltare i programmatori e incoraggia i programmatori ad insegnare ai loro manager il processo di produzione del software. Incoraggia inoltre i programmatori a lavorare direttamente con clienti e utenti. Ciò non significa che gli sviluppatori facciano tutto, ma dà loro il potere di gonfiare l'evoluzione della produzione. Sorprendentemente, avere quella sensazione di "Conosci questa fantastica funzionalità che piacciono agli utenti? È stata una mia idea!"è un grande fattore motivazionale.
Ma non pensate che funzioni solo per grandi squadre; il nostro team è piccolo La nostra azienda ha solo una manciata di sviluppatori, quindi siamo sempre stati vicini ai nostri utenti. Quella relazione ci ha permesso di influenzare il nostro prodotto al di là di ciò che i nostri dirigenti avrebbero potuto inizialmente immaginare.
Tutto ciò che ostacola la produzione è uno spreco.
L'integrità riguarda la robustezza del tuo prodotto ed è il modo in cui i clienti vedono il tuo prodotto nel suo complesso. L'integrità riguarda l'uniformità dell'interfaccia utente, l'affidabilità e la sicurezza e l'utente che si sente sicuro utilizzando il prodotto. L'integrità è l'immagine completa che l'utente crea per il tuo prodotto. Ad esempio, l'integrità dell'interfaccia utente implica l'aspetto grafico tra pagine, schermate, moduli o anche tra l'interfaccia utente del sistema e il sito Web dell'azienda.
Ma l'integrità può anche essere osservata e praticata a livello di codice sorgente. L'integrità può significare che i tuoi moduli, classi e altri pezzi sono scritti in modo simile. Usi gli stessi principi, schemi e tecniche nella tua base di codice, anche tra squadre diverse. Integrità significa che devi refactoring frequentemente il tuo codice. È un lavoro continuo e senza fine, e dovresti cercare, ma non raggiungerlo mai.
Mantenere l'integrità nel nostro codice sorgente è un compito difficile. Ci siamo resi conto che trovare il codice duplicato è la cosa più difficile da fare, e per duplicazione, non intendo un paio di righe di codice duplicato nello stesso metodo o classe.
Non si tratta nemmeno di cercare in moduli diversi lo stesso identico codice; si tratta di trovare quei pezzi di logica comune, estraendoli nelle proprie classi e usandoli in più punti.
Trovare la duplicazione logica è molto difficile e richiede una conoscenza approfondita del codice sorgente.
Sono stato sullo stesso progetto per più di un anno, e sono ancora sorpreso quando trovo il codice duplicato. Ma questa è una buona cosa; abbiamo raggiunto un punto in cui effettivamente vediamo queste cose e agiamo su di esse. Da quando abbiamo iniziato a rimuovere attivamente la logica duplicata ad alto livello, la nostra qualità del codice è aumentata. Siamo un passo avanti verso il raggiungimento dell'integrità.
Gli utenti non sempre sanno cosa vogliono.
Quando crei la tua applicazione, devi pensare ai componenti di terze parti su cui fai affidamento per sviluppare il tuo prodotto, così come le altre terze parti con cui il tuo prodotto comunica. La tua applicazione deve integrarsi con il design di un dispositivo o del sistema operativo su un PC desktop. Non è più semplice utilizzare un'app che si integri con il sistema di notifica dello smartphone e l'interfaccia utente riflette l'interfaccia utente del sistema operativo?
Sì, vedere il tutto non è così facile. Devi staccarti dai piccoli dettagli e guardare il tuo prodotto da lontano. Uno dei momenti memorabili nello sviluppo del nostro prodotto è stato quando ci siamo resi conto che dobbiamo fare affidamento su ciò che altri programmatori producono in altri progetti. Ci siamo resi conto che il kernel del sistema, programmato da altri, è uno di questi componenti di terze parti su cui ci basiamo.
A un certo punto, quel componente di terze parti è cambiato. Avremmo potuto semplicemente applicare dei cerotti alla nostra applicazione, o avremmo potuto prendere la strada facile e incolpare i programmatori che hanno scritto quel componente. Invece, abbiamo risolto il problema con le corna e risolto il problema nel kernel di terze parti. Vedere il tutto e lavorare con esso può essere disordinato, ma può fare la differenza tra un prodotto e un grande prodotto.
Esistono diversi strumenti e tecniche per far funzionare Lean. Preferisco Kanban, uno strumento basato su una scheda simile al piano di pianificazione di Scrum. Immagina una tavola Kanban come un doppio imbuto.
A sinistra c'è l'infinita lista di storie che dobbiamo affrontare. Tutti i racconti finiti si accumulano sulla destra e il gestore o il proprietario del prodotto determina quando pubblicare una nuova versione, in base a questo elenco.
Nel mezzo è il nostro efficace processo Kanban. Il prodotto dovrebbe essere in uno stato stabile e pronto per il rilascio quando completeremo una storia. Questo non significa necessariamente che una funzionalità sia stata eseguita; il prodotto potrebbe avere alcune funzionalità parzialmente implementate. Ma la stabilità, la sicurezza e la robustezza del prodotto dovrebbero essere la qualità della produzione.
Stavamo andando abbastanza bene con il nostro sprint attuale. Era un solito lunedì, una giornata tranquilla con poca emozione, ma mercoledì abbiamo iniziato a vedere dei problemi. Va bene, succede sempre. Superare queste difficoltà, tuttavia, ha richiesto un po 'di tempo in più. Il proprietario del nostro prodotto ha concordato con noi di continuare a lavorare sulla funzione corrente e di prolungare lo sprint attuale di tre o quattro giorni in più.
Venerdì è arrivato con una sorpresa. Conosci la regola: se qualcosa si rompe, si romperà venerdì. Un cliente importante e potenziale ha richiesto una determinata funzionalità prima di firmare un contratto con la società. Abbiamo dovuto reagire (e veloce!). Una nuova versione era obbligatoria ... Ma aspetta! Siamo nel bel mezzo di uno sprint. Il prodotto dovrebbe essere pronto per il rilascio entro la fine dello sprint. Cosa facciamo? Scrum direbbe di fare la nuova funzione nel prossimo sprint, ma siamo già in ritardo con lo sprint attuale! Quello è stato il momento in cui abbiamo iniziato a capire che dobbiamo pensare più in piccolo di uno sprint individuale. Dobbiamo essere in grado di adattarci più rapidamente e, se necessario, dobbiamo rilasciarlo prima.
Una scheda Kanban sembra abbastanza simile a una plancia di pianificazione Scrum, ma con alcune aggiunte per meglio adattarsi al processo Lean.
La prima colonna a sinistra è il backlog completo: tutto ciò che dobbiamo fare a un certo punto. All'estrema destra, hai l'altra canalizzazione, contenente tutte le storie completate (ma non rilasciate).
Nel mezzo è il nostro processo. Queste colonne possono variare a seconda di ogni team e processo. In genere è consigliabile avere almeno una colonna per le attività successive e un'altra per le storie attualmente in sviluppo. L'immagine sopra mostra molte più colonne per presentare meglio il processo di sviluppo.
Il Fare colonna elenca le attività che dobbiamo completare. Poi abbiamo Design, dove gli sviluppatori lavorano sulla progettazione delle storie attuali. La quarta colonna è Sviluppo, la vera codifica. Finalmente, il analisi colonna elenca le attività in attesa di revisione da parte di un altro compagno di squadra.
Nessuno sa tutto.
Se confronti questa tavola Kanban con una plancia di mischia, noterai immediatamente le ovvie differenze. Innanzitutto, ogni colonna ha un numero, che rappresenta il numero massimo di storie che possono risiedere in quella colonna. Abbiamo quattro cose da fare, quattro in fase di progettazione, tre in fase di sviluppo e due in fase di test. L'arretrato e le attività completate non hanno tale limite.
Il valore di ogni colonna deve essere definito dal team. Nell'immagine sopra, ho assegnato numeri arbitrari alle colonne; i tuoi numeri potrebbero differire in modo significativo. Inoltre, i numeri non sono definitivi. Adeguare i numeri quando identificate e rimuovete i colli di bottiglia.
Una delle qualità più sorprendenti di Kanban e Lean è l'importanza della collaborazione e della riallocazione dello sforzo. Come puoi vedere alla lavagna, ogni colonna del nostro processo contiene carte con persone su di esse. Ci sono otto sviluppatori sulla scheda di esempio: una squadra abbastanza grande! La scheda presenta sempre lo stato corrente di chi sta facendo cosa in un dato momento.
Secondo il nostro consiglio, ci sono tre persone che lavorano sul design, due coppie che lavorano sullo sviluppo e un test dello sviluppatore. Le storie passano alla colonna successiva mentre il lavoro nella colonna corrente è completo e, a seconda del tipo di sviluppo e organizzazione del team, lo stesso sviluppatore può continuare a lavorare sulla stessa storia mentre si muove attraverso il processo.
Supponiamo di avere persone specializzate. Quindi la funzione principale dei tre designer è la progettazione, i quattro sviluppatori scrivono il codice e il tester solitario verifica principalmente il prodotto / funzione. Se un designer termina una storia, la storia passa allo sviluppo e un'altra storia dalla lista delle cose da fare viene trascinata in design.
Questo è un processo normale. Una storia è stata spostata dal design allo sviluppo, e ora lo sviluppo è al massimo delle sue storie. Ma cosa succede se un altro designer finisce un'altra storia? Ciò fornisce al team di sviluppo quattro storie: una situazione indesiderata.
Lean vuole evitare la congestione. È vietato spostare una storia nella colonna successiva se supera il massimo della colonna. In questo caso, le risorse devono essere riassegnate; il progettista che ha terminato il proprio compito deve scegliere cosa fare dopo. La sua prima opzione è quella di estrarre un'altra attività dalla colonna delle cose da fare, ma non può farlo perché ha bisogno di passare la sua attività appena terminata al team di sviluppo (cosa che non può fare). La sua unica altra opzione è iniziare a lavorare su una storia di sviluppo. Potrebbe non essere il miglior sviluppatore, ma i suoi sforzi aiuteranno a mantenere il flusso del processo.
Se il tester finisce l'ultima storia nella sua colonna, potrebbe aiutare il progettista nel suo compito di sviluppo.
È fantastico! La squadra può riorganizzarsi al volo! Vedi uno spreco? Vedi un collo di bottiglia nel flusso? Agisci immediatamente!
Una volta completata la storia nella colonna di sviluppo, il tester torna a testare, il designer a progettare e gli sviluppatori raccolgono la storia su cui il progettista e il tester stavano lavorando. Ma tieni presente che non devi seguire quella prescrizione esatta; lo sviluppatore potrebbe iniziare a progettare mentre designer e tester hanno finito di sviluppare la loro storia. Tocca a voi!
La nostra tavola è tornata alla normalità.
È vietato spostare una storia nella colonna successiva se supera il massimo della colonna.
Ho guardato con nostalgia mentre il nostro mischia ha smantellato la nostra tavola. Pezzo dopo pezzo, ha abbattuto la nostra amata tavola, che poi è diventata una montagna di carta accartocciata.
Un altro collega entrò nella stanza, qualche enorme foglio di carta bianca in mano. Il nostro consiglio stava per rinascere in qualcosa di diverso, qualcosa di più adatto alle nostre esigenze. Dopo che i fogli di carta erano sul muro, abbiamo avviato una riunione ad hoc per definire le colonne necessarie per definire il nostro processo. Abbiamo quindi discusso la quantità di storie che dovrebbero essere in ogni colonna. Dopo che tutto è stato accuratamente dipinto e sistemato sul muro, abbiamo sperimentato quella strana sensazione ... tristezza per il vecchio ma felicità per il nuovo.
Abbiamo fatto qualcosa che molti chiamano, Scrum-Ban. Abbiamo mantenuto alcuni concetti di mischia, come i ruoli di scrum master e product owner, e valutiamo e valutiamo ancora le storie. Ma ora ci concentriamo su Lean e Kanban, preservando il flusso, scoprendo e fissando rifiuti e colli di bottiglia.
Il passaggio da Scrum a Lean è stato davvero liberatorio. I membri del team sono diventati molto più amichevoli l'uno con l'altro e abbiamo capito che dovremmo offrire aiuto non appena non c'è nulla nella nostra rubrica. Questa sensazione che gli sviluppatori contano ci ha fatto riflettere sul progetto nel suo insieme; ci preoccupiamo di più per il progetto di quanto non abbiamo mai fatto prima.
Lean non è sempre stato considerato Agile. Ancora oggi, alcuni Agilisti rifiutano di riconoscerlo come una metodologia Agile. Ma sempre di più, i programmatori accettano Lean come una delle ultime metodologie Agile.
Come uno dei miei saggi colleghi ha sottolineato, Lean e Kanban ti permettono di seguire questa metodologia da solo. Quindi, se sei uno sviluppatore solitario e hai bisogno di alcuni strumenti per semplificarti la vita, prova alcuni strumenti Kanban gratuiti.
Il sito Web di AgileZen offre un account gratuito che consente di tenere traccia di un singolo progetto.
Ho trovato uno dei migliori strumenti Kanban online gratuiti; Lo uso persino ogni giorno per tracciare e pianificare lo sviluppo degli articoli e dei corsi che fornisco per Tuts +. Naturalmente, puoi sempre aggiornare il tuo account AgileZen, se devi monitorare più progetti.
In questo articolo, abbiamo esaminato Lean e Kanban come un'evoluzione di Scrum. Questo significa che Lean è meglio di Scrum? Assolutamente no! Dipende dai progetti e dalle persone con cui lavori. Come sempre, scegli la metodologia Agile che funziona meglio per te e il tuo team.
Accentsconagua