Ciclo di vita del software. Mischia passo dopo passo

Tutti hanno sentito parlare di Agile. Se recentemente qualcuno potrebbe non conoscere questa parola, allora nel gennaio di quest'anno lo stesso German Gref, il capo di Sberbank, ha iniziato ad attaccare il paese con tutte le sue armi con la sua evangelizzazione di approcci flessibili alla gestione, e ora Agile ha già suonato per tutti.

Scrum è l’implementazione pratica dei principi Agile. È un approccio che, secondo il suo ideatore Jeff Sutherland, permette di fare il doppio nella metà del tempo.

Probabilmente ti piacerebbe saperne di più su Agile e Scrum per essere sempre aggiornato. Non è più possibile immaginare il mondo IT senza Agile e questa “infezione” si sta rapidamente diffondendo alle tradizionali aziende offline.

Per rimanere informati potete leggere il nuovo libro di Jeff Sutherland, Scrum. Un metodo rivoluzionario di gestione dei progetti." Ci vorranno diversi giorni. Un modo alternativo per leggere rapidamente libri aziendali americani intelligenti è leggere un riassunto, una rivisitazione, un riassunto del nostro partner: la società Smart Reading. Ci vorrà mezz'ora e imparerai sicuramente tutte le idee chiave senza acqua.

Scrum è emerso circa 20 anni fa come metodo efficace per aumentare la produttività nello sviluppo di software. Avendo guadagnato popolarità nella Silicon Valley, Scrum ottenne rapidamente l'accettazione in altri settori di business. I suoi creatori, Ken Schwaber e Jeff Sutherland, hanno studiato le migliori pratiche mondiali delle aziende di successo e sono giunti alla conclusione che il modello "a cascata", precedentemente utilizzato per lavorare su progetti IT, è irrimediabilmente obsoleto. Non ha soddisfatto le aspettative del cliente perché il lavoro procedeva lentamente, seguendo rigorosamente il piano a lungo termine, e spesso il risultato non era quello effettivamente necessario.

La gestione sistematica del progetto dall’alto verso il basso crea l’illusione di controllo e fiducia nel processo di lavoro, ma in realtà il risultato è imprevedibile. Nonostante la disponibilità di chilogrammi di carta con piani dettagliati, giustificazioni, grafici e tabelle, le scadenze non vengono rispettate, i budget vengono superati e i dipendenti si sentono frustrati, sentendo l’inutilità delle loro attività.

Acquisisci familiarità con i principi chiave di Scrum e forse l’argomento ti interesserà così tanto che non potrai più evitare di leggere il libro di Sutherland.

Le persone sono più importanti dei processi

Nelle aziende stesse misure differenti La burocrazia si propone innanzitutto di costruire processi, credendo che la disorganizzazione sia la radice di tutti i problemi. Ma se questa radice esiste, allora sono i dipendenti insoddisfatti del proprio lavoro, che ignorano i clienti e le loro esigenze, che non sono in grado di realizzare il proprio potenziale e avere successo. Rovinano tutto.

Scrum riguarda dipendenti felici e non processi infinitamente snelli e costosi.

Vieni domani nel tuo ufficio e probabilmente vedrai molte persone simili lì. È importante mettere le persone al centro dell’organizzazione, non i capi o i processi.

Il prodotto è più importante della documentazione

Un altro passatempo favorito burocrazia: descrivi tutto all'infinito, crea tonnellate di documentazione, spendi una buona metà delle risorse su di essa e quindi ritarda le scadenze. Ciò che è importante non sono i pezzi di carta, ma se la tua organizzazione e il tuo team riescono a creare esattamente il prodotto di cui i clienti hanno veramente bisogno. Se hai un ottimo prodotto e nessuna documentazione, non è male. È così che nel 2007 è arrivato sul mercato il primo iPhone.

Scrum riguarda il significato e non la creazione di quanti più pezzi di carta possibile allo scopo di creare quanti più pezzi di carta possibile.

Probabilmente sono importanti anche una colossale documentazione interna e una descrizione di ogni passo intrapreso nel percorso verso il prodotto finito, ma un numero crescente di aziende ora fa a meno di queste sciocchezze. E sono i tuoi concorrenti. I tuoi concorrenti sempre più veloci.

La collaborazione con il cliente è più importante di un contratto perfettamente redatto

Per realizzare un buon prodotto è necessario lavorare, creare, risolvere problemi, inventare e realizzare idee. Tutto ciò che distrae da questo è spazzatura. Devi costruire un rapporto tale con il cliente in modo che partecipi costantemente al tuo lavoro, veda come sarà il prodotto se segui la strategia attuale e comprenda le prospettive per ottenere un prodotto adatto a lui. Questo può essere fatto se hai una relazione con il cliente e non solo un contratto.

Scrum riguarda la comprensione e la collaborazione, non gli avvocati che coprono i punti deboli.

È necessario costruire un rapporto con il cliente in cui non sia necessario scambiarsi requisiti e condizioni cartacei infiniti e senza vita e concludere pile di contratti. La situazione ideale è quando siete partner gentili e comprensivi, collaboratori che lavorano per raggiungere lo stesso obiettivo e non è necessario essere assicurati da contratti e dedicare molto tempo a questo. Contratti e documenti sono un modo per proteggersi. Costruisci una relazione in cui nessuna delle parti ha bisogno di difendersi.

La capacità di cambiare è più importante che attenersi ai piani

Dicono che la cosa peggiore sia passare tutta la vita a realizzare un prodotto che nessuno finirà per utilizzare. Immagina di aver passato tre anni a sviluppare qualcosa che poi non ha funzionato perché si è rivelato non reclamato sul mercato. Ciò è dovuto ai piani grandiosi elaborati all'inizio e al loro rigoroso rispetto. E se il piano triennale fosse sbagliato? Spenderai un sacco di soldi e rimarrai al verde.

Scrum riguarda la scienza e il significato, non la fede e le speranze irragionevoli.

Come essere? Secondo Scrum, dovresti avere un grande obiettivo, ma raggiungerlo in modo iterativo, senza cercare di prevedere ogni tuo passo in un lontano futuro. In piccole iterazioni di 2-4 settimane, muoviti verso l'obiettivo, guarda indietro, fai una retrospettiva, valuta ciò che hai fatto, scarta il risultato dell'ultima iterazione se non ti avvicina all'obiettivo. In questo modo puoi evitare stupidi grandi fallimenti. L’iteratività è un approccio scientifico. Le speranze nella correttezza dei grandi progetti sono un po' come la religione.

Le posizioni e i titoli non sono importanti: ciò che conta è ciò che fai

Più alto è il livello del capo, meno conosce direttamente la creazione del prodotto e le complessità del suo lavoro, delle sue proprietà e capacità. Oggi, gli approcci al management sono di moda quando i capi non sono più particolarmente necessari, le gerarchie vengono cancellate e le organizzazioni diventano piatte. Le posizioni non sono importanti quando si tratta di lavoro pratico sulla creazione di un prodotto, sulla ricerca delle esigenze degli utenti, sulla verifica di varie ipotesi e sullo sviluppo iterativo attivo.

Scrum riguarda la fiducia, non la forza e la violenza.

I boss classici sono creati per il controllo e la repressione. Se il team è composto da professionisti appassionati, fidati e direttamente coinvolti nella creazione di valore, non hanno bisogno di un capo-sorvegliante con un titolo bello ma inutile.

Intorno a questi principi chiave di Scrum sono stati creati vari strumenti per aiutare a raggiungere gli obiettivi nel più breve tempo possibile, con un alto livello di prevedibilità, al minor costo. Assicurati di immergerti in questo argomento: è interessante e, molto probabilmente, senza la conoscenza di Agile e Scrum in futuro non sarai in grado di ottenere un lavoro interessante e ben retribuito.

Quindi, puoi imparare tutto su Scrum in dettaglio dal libro del suo creatore Jeff Sutherland. In alternativa, puoi leggere il riassunto di questo libro nella biblioteca elettronica Smart Reading in 20–30 minuti.

Lifehacker e Smart Reading suggeriscono di provare questo nuovo modo per apprendere rapidamente l'intera essenza di libri molto intelligenti, ma molto spessi. Sul sito web di Smart Reading troverai diverse centinaia di riassunti di grandi libri che potresti non leggere mai per intero.

Mischia(skrʌm "mischia") è una metodologia di gestione del progetto. L'enfasi principale nell'utilizzo di questa metodologia è sul controllo di qualità del processo di sviluppo. Mischiaè una delle “metodologie” di sviluppo software più popolari. Oltre a gestire progetti di sviluppo software, Mischia può essere utilizzato anche per supportare i programmi.

Nell'articolo "The New Product Development Game" (Harvard Business Review, gennaio-febbraio 1986), Hirotaka Takeuchi e Ikujiro Nonaka notarono che i progetti su cui lavorano piccoli team di specialisti tendono a produrre risultati migliori. Hanno fatto riferimento all'"approccio rugby" Mischia(spingendo, arrampicandosi attorno alla palla).

Metodo della prima volta Mischiaè stata presentata al pubblico, documentata, chiaramente inquadrata e descritta congiuntamente da Schwaber e Jeff Sutherland, che hanno lavorato insieme negli anni successivi per descrivere e presentare tutte le loro esperienze e migliori pratiche per la gestione dei progetti in un unico insieme, la metodologia conosciuta oggi come How Mischia.

Utilizzo Mischia Nella fase di pianificazione, si tratta di dividere un progetto di sviluppo software in diverse brevi iterazioni fisse, altrimenti chiamate sprint. Sprint. Ogni iterazione successiva, in base alla sua priorità, termina con la fornitura di software funzionante con nuove funzionalità all'utente finale. Allo stesso tempo, la breve durata rigorosamente fissa dello sprint conferisce prevedibilità e flessibilità al processo di sviluppo.

Processo di gestione dei progetti Scrum

Terminologia del progetto Scrum

• Sprint- fase di sviluppo;
• Arretrato di sprint- compiti per la fase di sviluppo;
• Arretrato del progetto- elenco dei requisiti di funzionalità.

Iterazione dello sprint

base MischiaÈ Sprint- la fase di sviluppo durante la quale vengono eseguiti determinati lavori sul prodotto. Lo sviluppo completo di un progetto è composto da brevi fasi Quello dello sprint. Funzioni che devono essere implementate su ciascuno Sprint"e, sono tassativamente fisse e non possono essere modificate durante lo sprint; sono suddivisi in compiti che hanno punteggi e priorità.

Prima di ciascuno Sprint prodotto Pianificazione dello sprint, su cui viene valutato il contenuto Arretrato del progetto e si forma Arretrato di sprint, contenente attività (Storia, Bug, Attività) che devono essere completate nello sprint corrente. Ogni sprint dovrebbe avere un obiettivo che sia un fattore motivante che può essere raggiunto completando le attività Arretrato di sprint.

Sprint sempre limitato nel tempo (1-4 settimane) ed ha la stessa durata per tutta la vita del prodotto. Al completamento Sprintè necessario ottenere una nuova versione funzionante, ma non definitiva, del prodotto.

Elenco dei requisiti del progetto Backlog del progetto

Arretrato del progetto- questo è un documento che contiene un elenco di tutti i requisiti funzionali per il progetto, vale a dire un elenco delle funzionalità del programma che devono essere implementate. Gli elementi dell'elenco devono essere ordinati per importanza. Man mano che il progetto avanza, l'elenco e le priorità possono cambiare, a seconda delle esigenze del cliente, delle nuove idee o del cambiamento delle condizioni.

Nel classico Mischia resta inteso che il cliente del progetto potrà apportare eventuali modifiche direttamente durante il progetto, ma non in quello attuale Sprint. Nella maggior parte dei casi, il budget per lo sviluppo del software è fisso. Ciò significa che anche la capacità del Cliente di influenzare lo stato di avanzamento dell’implementazione è limitata. Tuttavia, se necessario, è possibile redigere un “Accordo Aggiuntivo” al contratto, tenendo conto delle modifiche nelle componenti finanziarie del progetto, poiché la necessità di aggiungere o modificare eventuali funzioni del progetto è molto rilevante per il Cliente. Ciò contribuisce allo sviluppo del progetto di cui il cliente ha bisogno e non di quanto formalmente presentato nelle specifiche tecniche.

Pertanto, come Arretrato Di norma, viene utilizzato un elenco di compiti dalle specifiche tecniche, delineate e sancite nel contratto, oltre alle modifiche fissate in accordi aggiuntivi che sorgono durante il corso del lavoro.

Elenco dei requisiti dello sprint Backlog dello sprint

Arretrato di sprint Arretrato di sprint contiene funzionalità del progetto per una specifica fase dello Sprint"a.

Ruoli nella gestione dei progetti Scrum

Secondo il metodo Mischia Nel processo di produzione ci sono determinati ruoli, divisi in 2 gruppi: "maiali" e "polli". Questi nomi sono stati usati a causa del seguente scherzo comune:

La gallina suggerisce al maiale: “Apriamo un ristorante!” Il maiale guarda sorpreso la gallina e risponde: “Buona idea, ma come la vuoi chiamare?” La gallina ci pensa un attimo e risponde: “Perché non chiamarlo “Uova e Pancetta”?”
“Non funzionerà”, risponde il maiale, “perché poi dovrò dedicarmi interamente al progetto e tu sarai coinvolto solo parzialmente”.

Secondo Mischia I "maiali" creano il prodotto, mentre le "galline" non sono così interessate al prodotto finito. A loro non importa se il progetto avrà successo o meno, avrà scarso effetto su di loro. Pertanto, le richieste, i desideri e le idee dei "polli" vengono presi in considerazione, ma non è consentito loro di essere direttamente coinvolti nel processo Progetto Mischia.

Classico Mischia utilizza 3 ruoli base ( "Maiali") :

• Proprietario del prodotto (PO): il proprietario del prodotto rappresenta gli interessi del cliente nel progetto.
  P.O. non è un membro del team di sviluppo, ma un collegamento tra il team di sviluppo e il cliente, vale a dire questo deve essere un rappresentante del cliente. Poiché il ruolo impone requisiti elevati in termini di esperienza e competenza dell'individuo nello sviluppo e nello sviluppo del progetto e richiede anche una costante partecipazione personale al progetto (che non è sempre possibile per il cliente), questo ruolo viene solitamente svolto dal project manager .
• Scrum master (SM) "leader servitore" - un membro del team che garantisce il rispetto dei principi Mischia.
  Ruolo S.M. non implica alcun potere aggiuntivo per il progetto. Compito S.M.- aiutare la squadra a massimizzare la sua efficacia rimuovendo gli ostacoli, assistendo, formando e motivando la squadra, assistendo l'OP.
• Team di sviluppo (DT) - team di sviluppo.
  Il team di sviluppo è composto da specialisti che lavorano direttamente al progetto.
  • Secondo The Scrum Guide, un DT dovrebbe avere le seguenti qualità: S.M. deve auto-organizzarsi. Nessuno (compreso P.O. E ) non può indicare D.T. Arretrato del progetto come convertire
  • in un prodotto funzionante;
  • deve essere multifunzionale e possedere tutte le competenze necessarie per creare un prodotto funzionante;
  L’intero team dovrebbe essere responsabile del progetto, non i singoli membri. ) non può indicare Dimensione della squadra consigliata Mischia, di regola, sono 6...8 persone. Secondo gli ideologi , squadra taglia più grande richiede troppo grandi risorse

sulla comunicazione, mentre un team più piccolo aumenta i rischi (per la possibile mancanza delle competenze richieste) e riduce la quantità di lavoro che può essere completata in un dato periodo di tempo. Ruoli aggiuntivi ( Ruoli accessori Mischia () nella metodologia) :

• "Polli" Mischia Gli stakeholder sono gli individui che avviano il progetto e per i quali il progetto trarrà beneficio. Sono coinvolti;
• solo durante lo sprint review meeting
• Revisione dello sprint

Responsabili delle risorse umane;

Esperti di consulenza. Lavorare per fasi Il compito principale Proprietario del prodotto e la corretta definizione delle priorità in base agli obiettivi aziendali del progetto. Allo stesso tempo, dentro Proprietario del prodotto Di norma non si tratta di piccoli compiti, come modificare l’interfaccia di un modulo, ma di compiti aziendali più grandi, ad esempio “implementare un’autorizzazione unica attraverso i social network”.

All'inizio di ogni fase, la squadra seleziona dall'elenco Arretrato del progetto quante attività può realisticamente completare in una fase Sprint"a. Si suddivide in sottoattività e chiarisce le scadenze.

Riunione di pianificazione dello sprint

All'inizio di una nuova iterazione Sprint"aè necessario effettuare una pianificazione adeguata. Per farlo da Arretrato"a progetto, vengono selezionate le attività che sono Sprint squadra ) non può indicare deve adempiere. In base alle attività selezionate, a Sprint arretrato"a.

Ogni attività di sprint deve essere stimata in ore uomo ideali. La risoluzione del problema dovrebbe richiedere dalle 8 alle 16 ore, vale a dire non più di due giorni lavorativi. Se necessario, l'attività può essere suddivisa in sottoattività.

Durante la pianificazione viene discussa e determinata la procedura per l'attuazione dell'intero ambito di lavoro. La durata dell'incontro è strettamente limitata (non più di un giorno lavorativo) e dipende dalla durata dell'iterazione e dall'esperienza del team.

Controllo quotidiano, riunioni quotidiane

Riunioni quotidiane, altrimenti chiamato Riunione in piedi viene effettuato ogni giorno. Per tutto Sprint"a la squadra si riunisce regolarmente allo stesso tempo. Ogni membro della squadra ) non può indicare deve rispondere a tre domande:

• Cosa è stato fatto ieri?
• Cosa verrà fatto oggi?
• Quali sono i problemi?

Durante la conduzione Incontro giornalieroÈ importante non abbassarsi a discutere i dettagli tecnici del progetto o a chiarire formalmente lo stato del progetto.

Arresto dello sprint, conclusione anomala

Interrompere lo sprint prima del previsto può essere fatto in situazioni eccezionali. Se la squadra si rende conto che non può raggiungere l'obiettivo dello sprint nel tempo assegnato, può fermarsi Sprint. Inoltre, lo sprint può essere interrotto dal proprietario del progetto se scompare la necessità di raggiungere l'obiettivo dello sprint.

Dopo l'interruzione dello sprint, si tiene una riunione con la squadra ) non può indicare, dove vengono discusse le ragioni della chiusura. Successivamente, il comando procede con l'esecuzione di quello successivo Sprint"a.

Grafico del burn-down

Per visualizzare lo stato del progetto, viene utilizzato un grafico di burndown delle attività Grafico del burn-down, indicando la quantità di lavoro completato e rimanente in relazione al tempo totale assegnato per lo sviluppo del progetto. Il grafico deve essere aggiornato regolarmente (quotidianamente) per mostrare i progressi e i costi del lavoro sullo sprint e sul progetto in tempo reale. Grafico del burn-down deve essere disponibile per tutti i membri del progetto.

Esistono due tipi di grafico:

• un grafico di burndown dello sprint che rappresenta la quantità di attività completate e non completate nello sprint corrente;
• grafico di burndown per un progetto, che rappresenta il volume delle attività completate e non completate del prodotto finito prodotto software(di solito costruito su diversi sprint).

Caratteristiche di un progetto Scrum

1. In un progetto Scrum, le modifiche ai requisiti possono essere apportate in qualsiasi momento.
In questo modo puoi cambiare Portafoglio prodotti durante l'esecuzione. Ciò rende difficile l’applicazione dei principi Mischia in progetti a costo fisso/tempo fisso. Ideologia Mischia sostiene che è impossibile prevedere in anticipo tutti i cambiamenti, quindi non ha senso pianificare in anticipo l'intero progetto, limitandosi alla pianificazione just-in-time, ovvero pianificando solo quei lavori che devono essere completati negli Sprint più vicini.

2. In un progetto Scrum, la principale fonte di informazioni affidabili è l'esperienza empirica dei partecipanti.
La Scrum Guide parla della necessità di un’implementazione completa e accurata delle disposizioni Mischia a causa dell’assenza di un leader e di un manager formale.

3. La motivazione del team gioca un ruolo importante nel successo di un progetto Scrum.
Uno dei principi fondamentali Progetto Mischia sono la presenza di un team multifunzionale e auto-organizzato di sviluppatori DT. La ricerca condotta dai sociologi mostra che il numero di dipendenti automotivati ​​e capaci di auto-organizzazione non è elevato. Pertanto, solo una piccola parte dei dipendenti è in grado di lavorare in modo efficace Progetto Mischia senza cambiamenti significativi nei ruoli, con conseguente utilizzo non corretto dei principi Scrum.

Pro e contro di un progetto Scrum

Uno dei principali vantaggi, dal punto di vista del Cliente, è il rapido avvio di un progetto Srcum con le funzioni più prioritarie e il budget più basso possibile. Pertanto, Scrum è incentrato sul cliente. Scrum offre al cliente la possibilità di apportare modifiche ai requisiti in qualsiasi momento, ma non garantisce che tali modifiche verranno implementate. La possibilità di modificare i requisiti è interessante per molti clienti di software. Inoltre, Scrum semplifica il monitoraggio dell'avanzamento del lavoro.

Tuttavia, modifiche ai requisiti Progetto Mischiaè accompagnato anche da una modifica del budget del progetto. Un compromesso ragionevole consiste nel concludere un accordo per lo sviluppo di un progetto con una ripartizione per fasi, oltre ad accordi aggiuntivi per le modifiche che emergono durante lo sviluppo del progetto.

Debolezza importante Mischiaè quello di creare un team multifunzionale auto-organizzato. La formazione di un team di sviluppo efficace per un progetto Scrum è spesso associata alla mancanza di specialisti adeguati (conoscenza + esperienza + stipendio) sia nell'azienda che nel mercato del lavoro.

Si dovrebbe notare che Mischia non adatto per soddisfare gli ordini governativi, dove tutto deve essere concordato prima dell'inizio dello sviluppo del software, ad es. Sono state formate le specifiche tecniche e determinati i requisiti, stabilite le scadenze delle fasi e approvato il budget.

Classic Scrum implica che il cliente del progetto possa apportare eventuali modifiche durante il corso del progetto, ma non nell'attuale fase di sviluppo. Tuttavia, in questo caso, il budget è per lo più fisso e anche la capacità del cliente di influenzare l’avanzamento dell’implementazione è limitata.

Tuttavia, la necessità di aggiungere o modificare eventuali funzioni del progetto è molto urgente per il cliente. Questo aiuta a sviluppare un progetto di cui il cliente ha realmente bisogno e non quello formalmente descritto nelle specifiche tecniche. Pertanto, come arretrato, di norma, viene utilizzato un elenco di compiti dalle specifiche tecniche, delineate e sancite nel contratto, oltre ai miglioramenti fissati in accordi aggiuntivi che sorgono durante il lavoro.

Principi di base dell'organizzazione del lavoro nei team Scrum

1. Organizziamo il processo di sviluppo dell'applicazione in piccoli team funzionali che contengono tutti gli specialisti necessari. Per fare ciò, selezioniamo una persona: uno Scrum Master, che sarà responsabile del mantenimento dei processi nel team e di un'atmosfera costruttiva.
   

   Il backlog è un documento che contiene un elenco di tutti i requisiti per il progetto (visione del progetto, elenco di ciò che dovrebbe essere implementato). Gli elementi dell'elenco sono ordinati per importanza. Man mano che il progetto avanza, l'elenco e le priorità possono cambiare, a seconda delle esigenze del cliente, delle nuove idee o del cambiamento delle condizioni.

2. Suddividiamo i requisiti in piccole parti funzionali, orientate all'utente, quanto più indipendenti possibile l'una dall'altra, creando un backlog di prodotto. Quindi classifica gli elementi del tuo arretrato in base all'importanza e fai una stima relativa della dimensione di ciascuna storia. Seleziona una persona separata: il proprietario del prodotto, che sarà responsabile dei requisiti e delle relative priorità, coprendo tutte le parti interessate.
3. Eseguiamo tutto il lavoro in breve tempo, da 1 a 4 settimane, iterazioni fisse – sprint, consegnando funzionalità complete alla fine di ciascuna di esse, che possono essere immesse sul mercato se necessario – incremento del prodotto. Il team, in base alla sua velocità, raccoglie i compiti per un'iterazione invariante nel tempo: uno sprint. Ogni giorno si tiene una riunione Scrum in cui il team sincronizza il proprio lavoro e discute i problemi. Mentre lavorano, i membri del team si occupano degli elementi arretrati in base alla priorità.
   

   Uno sprint è una breve fase di sviluppo del progetto. Le funzioni che devono essere implementate ad ogni sprint sono fisse e non possono essere modificate durante lo sprint. Sono suddivisi in attività e le attività hanno valutazioni e priorità. Nello Scrum classico si presuppone che la durata dello sprint sia fissa e vada dalle 2 alle 4 settimane, a seconda dell'esperienza del team.

4. Alla fine di ogni sprint, conduci una revisione dello sprint per ottenere feedback dal proprietario del prodotto e una retrospettiva dello sprint per ottimizzare i processi. Il product Owner può quindi modificare i requisiti e le relative priorità e iniziare un nuovo sprint.

“Di tutte le sfide che la NASA ha dovuto affrontare nel mandare l’uomo sulla Luna, il controllo è stato forse la più impegnativa”.

— Roger Launis, storico della NASA

Nel corso della storia, l’umanità ha accumulato un elenco impressionante di progetti complessi implementati con successo. Dalla costruzione delle Piramidi di Giza all'invio di un uomo sulla Luna, gli sforzi umani più audaci hanno richiesto il lavoro coordinato di migliaia di persone. E questo implica un complesso sistema di gestione dei progetti.

E anche se solo pochi di noi dovranno affrontare compiti di questa portata, la maggior parte dei lettori di questo blog incontrerà la gestione dei progetti in un modo o nell’altro. Secondo le stime del PMI, entro il 2020 ci saranno – e molti altri professionisti dovranno spesso gestire, almeno a livello personale, dei mini-progetti.

In termini semplici, il Project Management è la gestione e l'organizzazione di tutto ciò che è necessario per raggiungere un obiettivo, ovviamente nel rispetto dei tempi e del budget. Che si tratti di sviluppare un nuovo software, condurre una campagna di marketing o sbarcare esseri umani su Marte, la gestione dei progetti ti consente di raggiungere il successo.

Tutti i progetti sono diversi. Non esiste un sistema di project management perfetto e adatto a ogni tipo di progetto. Inoltre, non esiste un sistema adatto a ogni manager e conveniente per tutti i membri del team. Tuttavia, durante l'esistenza del project management, molti approcci efficaci, metodi e standard che possono essere adottati. Oggi parleremo dei più popolari.

Gli approcci sviluppati sono molto diversi tra loro. Differiscono per ambiti di applicazione, dettaglio, autonomia e formalizzazione. Nel titolo li abbiamo chiamati “metodi” per comodità, ma in realtà l’articolo presenta standard, concetti, metodi e framework utilizzati nella gestione dei progetti. Lo scopo di questo articolo è fornire la panoramica più ampia degli approcci esistenti nella gestione dei progetti.

In questo articolo vedremo:

• Gestione classica del progetto
• Agile
• Mischia
• Pendere
• Kanban
• SeiSigma
• PRINCIPE2

E prima di esaminare metodi specifici, rispondiamo alla domanda ovvia: “Perché abbiamo bisogno di sistemi e metodi di gestione dei progetti?”– Diamo un’occhiata, ovviamente, brevemente alla storia del project management e definiamo i termini fondamentali del project management.

Perché "gestione del progetto"?

I nomi di Neil Armstrong e Buzz Aldrin rimarranno per sempre nella storia come simboli di una delle più grandi conquiste dell'umanità: lo sbarco dell'uomo sulla luna. Tuttavia, i maggiori contributori a questo evento sono stati i 400.000 dipendenti della NASA e le 20.000 aziende e università che hanno lavorato insieme alla missione Apollo.

Nel 1961, John Kennedy stabilì il compito di far atterrare un uomo sul satellite della Terra e di riportarlo indietro, nonostante a quel tempo la NASA avesse inviato un uomo nello spazio per soli 15 minuti. Un obiettivo così ambizioso ha richiesto un’incredibile quantità di risorse, cooperazione, innovazione e pianificazione.

Secondo il libro della NASA Managing the Moon Program, il problema principale non era " cosa fare?", e in quel “ come fare così tanto in così poco tempo? Secondo il Dr. Max Faget, capo dell'ingegneria presso Centro spaziale prende il nome da Lyndon Johnson (Centro spaziale Lyndon B. Johnson, JSC), quindi la NASA non aveva idea di come mettere tutto azioni necessarie alle 10. Pertanto, il primo passo è stato “suddividere il progetto in fasi gestibili”.

Era quindi importante accelerare ogni singola fase e garantire che i team e le aziende che lavoravano in ciascuna fase comunicassero efficacemente tra loro e fornissero risultati in tempo. Questo compito fu affidato al dottor George E. Muller, che gestì ogni parte del progetto Apollo, dalla Casa Bianca al fornitore stesso. piccolo dettaglio. Per facilitare il controllo del progetto, ha deciso di suddividerlo in 5 aree: controllo del programma, ingegneria dei sistemi, test, affidabilità e qualità e operazioni di volo. Il diagramma di controllo del programma Apollo è mostrato in Figura 1.

Questo sistema in 5 fasi - chiamato "Fasi GEM" dalle iniziali del Dr. Mueller - è stato progettato "per concentrarsi sul test del prodotto e sulla progettazione per essere testato", come osserva lo stesso Mueller. Il controllo del programma ha determinato cosa era necessario fare, ha gestito i budget e i requisiti e ha gestito le interrelazioni degli elementi del programma. L'area Systems Engineering era responsabile dello sviluppo di nuovi dispositivi e componenti, Testing era responsabile di garantire che questi nuovi elementi funzionassero, Affidabilità e Qualità controllavano gli elementi sviluppati per garantire la conformità ai requisiti e agli standard e Operazioni di volo era responsabile di garantire che questi i nodi funzionerà durante il volo.

Molti inizialmente erano scettici riguardo al metodo proposto da Muller, ma alla fine riuscì a convincere i membri del programma della necessità di seguire questo algoritmo. Questo sistema ha dimostrato la sua efficacia: il progetto è stato completato con successo e, si potrebbe addirittura dire, trionfalmente, prima delle scadenze indicate. Ciò è stato possibile solo suddividendo un progetto su larga scala in fasi gestibili e ripetibili, consentendo a molte singole aziende e specialisti di lavorare allo stesso ritmo. È così che la gestione del progetto ha dimostrato la sua efficacia nella corsa allo spazio.

Una breve storia del Project Management

La gestione del progetto non è stata inventata dalla NASA o dal Dr. Mueller. Le piramidi egiziane e la Grande Muraglia cinese sono il prodotto della gestione di progetti risalenti alla preistoria. Sfortunatamente, non esiste alcuna prova documentale di come questi progetti siano stati implementati e gestiti, e l’attuale gestione dei progetti è separata dalle conoscenze dei secoli passati.

Il modo più ovvio per implementare un progetto è suddividerlo in fasi o singole attività. Come una ricetta culinaria: compri gli ingredienti, li mescoli correttamente, cucini e servi. Lo strumento più semplice La gestione del progetto è una lista di controllo delle azioni che devono essere intraprese per raggiungere un obiettivo. Semplice ed efficace.

Tuttavia, se sei uno chef e prepari non un piatto, ma diversi, ad esempio un'insalata (la cui preparazione consiste in 3 fasi) e un dessert (che deve solo essere servito), allora avrai bisogno di un strumento che ti consente di tenere traccia del tempo impiegato su ciascuno di essi e del tempo in cui dovrebbero essere pronti. E qui viene in soccorso uno dei primi moderni strumenti di project management: il diagramma di Gantt, presentato su figura 2.

Inventato indipendentemente da K O Il ruolo di Korol Adamecki e Henry L. Gantt all'inizio del XX secolo, il diagramma di Gantt mostra un programma di progetto basato sulle date di fine e di completamento delle attività. Vengono inserite le attività, la loro durata e le relazioni, quindi viene calcolato il percorso critico, la catena più lunga di attività correlate che determinano la durata del progetto. Le relazioni tra l'inizio e la fine dei diversi compiti sono molto importanti: non puoi servire la zuppa ai tuoi ospiti finché non l'hai cucinata, vero?

Quindi, un progetto tipico è molto simile a un progetto di preparazione e servizio della cena, solo che ha molti più compiti, relazioni, scadenze e tipi di risorse. Per i progetti con scadenze ravvicinate, il diagramma di Gantt aiuta a decidere quando è meglio avviare determinate attività per ridurre i tempi di implementazione. E per i progetti con forti vincoli di risorse, il diagramma di Gantt offre l'opportunità di costruire un diagramma sotto forma di una catena di processi guidata dagli eventi per la pianificazione delle risorse.

Vari progetti sono necessari diversi livelli di controllo. Ad esempio, se pubblichi una serie di articoli in , le scadenze rigorose non sono così importanti. Molto più importante è un processo chiaro in cui sia possibile strutturare ciascun articolo, delineare ciascuno di essi, ottenere feedback, apportare modifiche, completare l'articolo, correggere le bozze e pubblicare. Invece di gestire tempo e risorse, gestisci il processo.

Per tali progetti, i metodi di gestione del progetto Agile e gli approcci correlati come Lean, Kanban e altri sono più adatti. Esistono anche metodi che consentono di gestire sia il flusso di lavoro, il tempo e le risorse: 6 Sigma e Scrum.

Sistemi popolari di gestione dei progetti

Nel corso della storia del project management, sono stati creati molti metodi diversi di gestione dei progetti per soddisfare quasi tutte le esigenze. Anche se non manderai un uomo sulla luna e non disponi della stessa quantità di risorse, troverai comunque lo strumento adatto a te. La cosa principale è capire cosa è più importante per il tuo progetto - scadenze, risorse, rispetto del processo o più fattori contemporaneamente - e quindi scegliere un metodo di gestione del progetto incentrato sul raggiungimento di questo indicatore.

Prima di esaminare i metodi più popolari, definiamo alcuni termini chiave.

Termini di base della gestione del progetto

Agile: Un approccio flessibile iterativo-incrementale alla gestione di progetti e prodotti, focalizzato sulla formazione dinamica dei requisiti e sulla garanzia della loro implementazione come risultato della costante interazione all'interno di gruppi di lavoro auto-organizzati composti da specialisti in vari campi. Esistono molti metodi basati sulle idee Agile, i più popolari dei quali sono Scrum e Kanban.

Percorso critico: Una sequenza continua di lavori ed eventi dall'evento iniziale a quello finale, che richiede il maggior tempo possibile per completarlo.

Catena di eventi di processi (diagramma EPC): un diagramma che mostra la sequenza di implementazione del lavoro del progetto in base alla disponibilità e al carico di lavoro delle risorse

Riserva temporale: L'intervallo di tempo in cui è possibile ritardare l'inizio dei lavori senza influire sulla durata complessiva del progetto. Pertanto, il lavoro sul percorso critico avrà un float pari a zero.

Traguardo (punto di controllo,pietra miliare): Evento chiave, indicando, ad esempio, la fine di una tappa. In un diagramma di Gantt viene indicata un'attività con durata pari a zero.

Responsabile del progetto (responsabile del progetto,progettomanagerPM ): Leader del team di progetto responsabile della gestione del progetto (pianificazione, implementazione e chiusura del progetto).

Risorse: Elementi necessari per la realizzazione del progetto. Le risorse includono tempo, attrezzature, materiali, dipendenti, ecc.

Sprint (Sprint): Un'iterazione (ciclo di lavoro) in Scrum, della durata da una settimana a un mese, durante la quale viene creata una versione funzionante di un prodotto o un elemento di esso che sia di valore per il cliente.

Gestione del progetto “classico” o “tradizionale”: Il metodo più utilizzato di gestione del progetto, basato sul cosiddetto “Waterfall” o ciclo a cascata, in cui l'attività viene trasferita in sequenza attraverso fasi simili a un flusso.

Gestione classica del progetto

Il modo più ovvio per rendere il tuo progetto più gestibile è suddividere il processo di esecuzione in fasi sequenziali. È su questa struttura lineare che si basa la gestione tradizionale dei progetti. In questo senso, assomiglia a un gioco per computer: non puoi passare al livello successivo senza completare quello precedente. Il diagramma del flusso di lavoro è mostrato in Figura 3.

Questo approccio si concentra su progetti in cui esistono rigide restrizioni sulla sequenza delle attività. Ad esempio, costruendo una casa: non puoi costruire muri senza fondamenta.

In genere ci sono 5 fasi della gestione classica del progetto, ma è possibile aggiungere fasi aggiuntive se il progetto lo richiede.

5 fasi della gestione tradizionale:

Fase 1. Iniziazione. Il project manager e il team definiscono i requisiti del progetto. In questa fase, si tengono spesso riunioni e sessioni di brainstorming per determinare quale dovrebbe essere il prodotto del progetto.

Fase 2. Pianificazione. In questa fase, la squadra decide come raggiungere l’obiettivo fissato nella fase precedente. In questa fase, il team chiarisce e dettaglia gli obiettivi e i risultati del progetto, nonché l’ambito di lavoro per esso. Sulla base di queste informazioni, il team crea un programma e un budget, valuta i rischi e identifica le parti interessate.

Fase 3. Sviluppo. Questa fase non è implementata per tutti i progetti; di norma fa parte della fase di pianificazione. Nella fase di sviluppo caratteristica di progetti tecnologici, si determina la configurazione del futuro progetto e/o prodotto e le modalità tecniche per realizzarlo. Ad esempio, nei progetti IT, in questa fase viene selezionato un linguaggio di programmazione. ( Nella pratica domestica, questa fase di solito non viene distinta e il termine "sviluppo" non viene utilizzato - ca. trans.)

Fase 4. Implementazione e test. In questa fase avviene il lavoro principale vero e proprio del progetto: scrivere il codice, costruire un edificio e simili. A seguito dei piani sviluppati, si inizia a creare il contenuto del progetto, definito in precedenza, e il controllo viene effettuato in base alle metriche selezionate. Nella seconda parte di questa fase il prodotto viene testato, viene verificata la rispondenza ai requisiti del Cliente e delle parti interessate. La parte di test identifica e corregge le carenze del prodotto.

Fase 5. Monitoraggio e completamento del progetto. A seconda del progetto, questa fase può consistere in un semplice trasferimento dei risultati del progetto al Cliente, o in un lungo processo di interazione con i clienti per migliorare il progetto e aumentare la loro soddisfazione, e supportare i risultati del progetto. Quest'ultimo vale per progetti nel campo del servizio clienti e del software.

Quanto sopra descritto è la base su cui costruire vari metodi gestione del progetto. Progetti diversi richiedono fasi diverse di implementazione: alcuni richiedono tre fasi, altri molto di più. A volte viene utilizzata la cosiddetta “cascata iterativa”, in cui ogni fase è un sottoprogetto, durante il quale le attività vengono implementate in iterazioni fisse. Ma l'essenza rimane la stessa: il progetto è suddiviso in fasi che vengono eseguite in una sequenza rigorosamente definita.

Dato che la gestione classica del progetto è strettamente legata al tempo di esecuzione delle attività, solitamente predeterminato in fase di pianificazione, gli strumenti di pianificazione del calendario e della rete sono eccellenti per implementare i progetti con questo approccio. Lo strumento più comune per la pianificazione e la pianificazione della rete è il diagramma di Gantt precedentemente menzionato. Esistono molti strumenti per realizzarlo: da semplici fogli di calcolo come Excel e Smartsheet a pacchetti software professionali come Microsoft Project e Primavera.

Punti di forza gestione classica del progetto

Oggi si dice spesso che il classico approccio a cascata è superato, ma non pensa di perdere terreno. Il grande vantaggio di questo approccio è che richiede al cliente e al management aziendale di determinare cosa desiderano ricevere già nella prima fase del progetto. L'inclusione anticipata apporta una certa stabilità al progetto e la pianificazione consente di semplificare l'attuazione del progetto. Inoltre, questo approccio prevede il monitoraggio e il test delle prestazioni, che è assolutamente necessario per progetti reali di varie dimensioni.

Potenzialmente, l'approccio classico consente di evitare lo stress dovuto alla presenza di tempo libero in ogni fase, previsto in caso di eventuali complicazioni e rischi. Inoltre, con una fase di pianificazione eseguita correttamente, il project manager sa sempre di quali risorse dispone. Anche se questa stima non è sempre esatta.

Punti deboli del project management classico

Il principale punto debole del project management classico è l’intolleranza al cambiamento. Gestione Toyota, famoso per aver creato sistemi come Lean e Kanban vengono spesso criticati per il fatto che applicano l’approccio classico allo sviluppo di software per la propria azienda, e proprio per la loro mancanza di flessibilità.

Il pilastro dell'approccio classico ora sono i progetti di costruzione e ingegneria, in cui il contenuto del progetto rimane praticamente invariato durante l'intero progetto. Ma se nel tuo progetto le risorse e il tempo non sono vincoli fondamentali e il contenuto del progetto è soggetto a modifiche, forse dovresti dare un'occhiata più da vicino ad altri sistemi di gestione dei progetti.

Agile

Come accennato in precedenza, non tutti i progetti possono essere strutturati in modo tale da essere implementati utilizzando l’approccio progettuale classico. Tornando all'esempio dello chef, preparare un piatto è l'ideale per l'approccio "a cascata", ma preparare e servire in tempo una cena di quattro portate sarà quasi impossibile se per iniziare si deve aspettare che sia finito un piatto ogni volta. preparandone un altro.

Ed è qui che entra in gioco Agile, una famiglia di metodi flessibili iterativi-incrementali per la gestione di progetti e prodotti. Secondo questo approccio il progetto non viene suddiviso in fasi sequenziali, ma in piccoli sottoprogetti, che vengono poi “assemblati” in un prodotto finito. Lo schema di funzionamento è mostrato in Figura 5.

Pertanto, l'avvio e la pianificazione di alto livello vengono eseguite per l'intero progetto, mentre le fasi successive: sviluppo, test e altre vengono eseguite separatamente per ciascun mini-progetto. Ciò consente di trasferire i risultati di questi mini-progetti, i cosiddetti incrementi, più velocemente e, quando si avvia un nuovo sottoprogetto (iterazione), è possibile apportarvi modifiche senza costi elevati e impatto sul resto del progetto.

Nonostante il fatto che Agile sia diventato di moda relativamente di recente, l’idea dello sviluppo iterativo non è nuova. (sulla storia dell'apparizioneAgile può essere letto – circa). La famiglia delle metodologie flessibili ha ricevuto il suo nome attuale nel 2001 con la pubblicazione del Manifesto Agile, che ha stabilito i valori e i principi fondamentali dello sviluppo di software flessibile, che si basano sul lavoro di squadra e sull’adattamento, persino sull’“amore” per il cambiamento.

Agile in sé non è un metodo di gestione del progetto. Si tratta piuttosto di un insieme di idee e principi su come i progetti dovrebbero essere implementati. Già sulla base di questi principi e delle migliori pratiche sono stati sviluppati metodi flessibili individuali o, come a volte vengono chiamati, framework: Scrum, Kanban, Crystal e molti altri. Questi metodi possono essere molto diversi tra loro, ma seguono gli stessi principi.

Punti di forzaAgile

Il vantaggio più importante di Agile è la sua flessibilità e adattabilità. Può adattarsi a quasi tutte le condizioni e processi dell'organizzazione. Questo è ciò che determina la sua attuale popolarità e quanti sistemi in vari campi sono stati creati sulla sua base.

Uno dei principi Agile è: “Reagire al cambiamento è più importante che seguire un piano”. Questa risposta rapida e relativamente indolore al cambiamento è il motivo per cui molte grandi aziende stanno cercando di rendere i propri processi più flessibili. Inoltre, Agile è ottimo per progetti a tempo indeterminato, come il lancio di un servizio o di un blog.

Il dominio di Agile è lo sviluppo di prodotti nuovi e innovativi. In tali progetti di sviluppo prodotto esiste un elevato grado di incertezza e le informazioni sul prodotto vengono rivelate man mano che il progetto avanza. In tali condizioni diventa impossibile realizzare un progetto “a cascata”: non ci sono informazioni per la pianificazione.

Lati deboliAgile

A differenza di PRINCE2 e PMBOK, Agile non è né una metodologia né uno standard. Agile è un insieme di principi e valori. Il punto debole è che ogni team dovrà creare autonomamente il proprio sistema di gestione, guidato dai principi Agile. Si tratta di un processo lungo e complesso che richiederà cambiamenti in tutta l’organizzazione, dalle procedure ai valori fondamentali. Questo è un percorso spinoso e non tutte le organizzazioni possono farlo.

Questo percorso richiederà al leader del cambiamento non solo conoscenza e perseveranza, ma anche notevoli risorse amministrative, nonché costi. Fortunatamente, esistono serie di pratiche già pronte che semplificano la trasformazione Agile di un’organizzazione. Tali set includono il framework Scrum, il metodo Kanban e molti altri: Crystal, LeSS, SAFe, Nexus.

Mischia

Creato nel 1986, il framework Agile è considerato il più strutturato della famiglia Agile. Creato nel 1986, combina elementi del processo classico e le idee di un approccio agile alla gestione dei progetti. Il risultato è stato una combinazione molto equilibrata di flessibilità e struttura.

Seguendo i precetti dell'Agile, Scrum scompone il progetto in parti immediatamente utilizzabili dal Cliente per ottenere valore, chiamato product backlog. E nonostante il fatto che "product backlog" sia una traduzione abbastanza corretta e venga utilizzato nella letteratura professionale, nella pratica russa viene spesso utilizzato semplicemente "backlog". Quindi a queste parti viene data la priorità dal Product Owner, il rappresentante del cliente nel team. I “pezzi” più importanti sono i primi ad essere selezionati per l'esecuzione in uno Sprint: così vengono chiamate le iterazioni in Scrum, che durano da 2 a 4 settimane. Alla fine dello Sprint, al Cliente viene presentato un incremento lavorativo del prodotto, quei “pezzi” molto importanti che possono già essere utilizzati. Ad esempio un sito web con parte delle funzionalità o un programma che già funziona, anche se parzialmente. Successivamente, il team di progetto inizia lo Sprint successivo. La durata dello Sprint è fissa, ma il team la sceglie autonomamente all'inizio del progetto, in base al progetto e alla propria performance.

Per garantire che il progetto soddisfi i requisiti del Cliente, che tendono a cambiare nel tempo, prima dell'inizio di ogni Sprint, il contenuto del progetto non realizzato viene rivalutato e ad esso vengono apportate modifiche. Tutti partecipano a questo processo: il team di progetto, lo Scrum Master (Scrum Master, leader del team di progetto) e il Product Owner. E la responsabilità di questo processo ricade su tutti.

Come già accennato, il Product Owner è il rappresentante del Cliente nel progetto, o rappresenta tutti i clienti del progetto futuro se non c'è alcun Cliente. Per fare ciò, deve conoscere a fondo le loro esigenze e il loro modo di pensare, nonché comprendere il prodotto e la sua tecnologia di produzione. Lo Scrum Master è progettato per aiutare i partecipanti al progetto a comprendere e accettare meglio i valori, i principi e le norme della pratica Scrum. È un leader e un mediatore tra il mondo esterno e la squadra. Il suo compito è garantire che nessuno interferisca con la capacità del team di lavorare in modo indipendente e confortevole sui compiti assegnati. Il team è responsabile di garantire che alla fine dello sprint tutte le attività necessarie siano completate e le consegne siano completate.

La struttura di base dei processi Scrum ruota attorno a 5 incontri principali: allineamento del backlog, pianificazione dello Sprint, incontri di stand-up giornalieri, riepilogo dello Sprint e retrospettiva dello Sprint.

Per molte persone, Scrum può sembrare difficile da implementare: un nuovo processo, nuovi ruoli, molta delega e un sistema completamente nuovo. struttura organizzativa. Ma questo è un approccio flessibile e allo stesso tempo strutturato all'attuazione del progetto, che, a differenza di vago e principi generali Agile non permetterà che il lavoro vada nella direzione sbagliata.

Punti di forzaMischia

Scrum è stato sviluppato per progetti che richiedono "vittorie rapide" combinate con tolleranza al cambiamento. Inoltre, questo quadro è adatto a situazioni in cui non tutti i membri del team hanno sufficiente esperienza nell'area in cui viene implementato il progetto: la comunicazione costante tra i membri del team consente alla mancanza di esperienza o qualifica di alcuni dipendenti di beneficiare di informazioni e aiuto da parte di colleghi.

Il canale televisivo online Netflix è un ottimo esempio di rapida consegna dei risultati. Il sito Web delle risorse viene aggiornato ogni due settimane grazie a Scrum, che non solo ti consente di lavorare ad alta velocità, ma accumula anche l'esperienza dell'utente e consente di identificare ciò che è più importante per i clienti.

Durante ogni iterazione, gli sviluppatori aggiungono e testano nuove funzionalità del sito e rimuovono quelle che non sono state utilizzate dai clienti. Secondo il team di Netflix, il vantaggio principale di Scrum è che ti permette di “fallire velocemente”. Invece di impiegare molto tempo e grandi spese per preparare un rilascio di grandi dimensioni, le consegne bisettimanali di Scrum sono di piccole dimensioni. Sono facili da monitorare e, se qualcosa va storto, correggilo rapidamente.

Lati deboliMischia

Scrum è molto esigente nei confronti del team di progetto. Dovrebbe essere piccolo (5-9 persone) e interfunzionale, ovvero i membri del team dovrebbero avere più di una competenza necessaria per implementare il progetto. Ad esempio, uno sviluppatore di software deve avere conoscenza di test e analisi aziendale. Questo viene fatto in modo che una parte della squadra non “rimanga inattiva”. diverse fasi progetto, e anche affinché i dipendenti possano aiutarsi e sostituirsi a vicenda.

Inoltre, i membri del team devono essere “giocatori di squadra”, assumersi attivamente la responsabilità ed essere in grado di organizzarsi. Trovare una squadra così matura è molto difficile!

Scrum non è adatto a tutti i team e tutte le organizzazioni anche perché il processo proposto potrebbe non essere adatto allo sviluppo di un prodotto specifico, ad esempio una macchina industriale o la costruzione di un edificio.

Pendere

Agile ci dice di suddividere il lavoro in pacchetti piccoli e gestibili, ma non ci dice come gestire lo sviluppo di quel pacchetto. Scrum ci offre i suoi processi e procedure. Lean, a sua volta, aggiunge un diagramma del flusso di lavoro ai principi Agile in modo che ogni iterazione venga completata con la stessa qualità.

In Lean, come in Scrum, il lavoro è suddiviso in piccoli pacchetti di consegna che vengono implementati separatamente e indipendentemente. Ma in Lean esiste un flusso di lavoro per lo sviluppo di ciascun pacchetto di consegna, con passaggi simili a quelli creati per il Progetto Apollo. Come nel classico project management, queste possono essere le fasi di pianificazione, sviluppo, produzione, test e consegna - o qualsiasi altra fase necessaria per l'implementazione di alta qualità dei progetti.

Le fasi Lean e la loro flessibilità ti permettono di essere sicuro che ogni parte del progetto sia implementata come richiesto. Lean non ha confini chiari delle fasi, poiché Scrum non ha confini dello Sprint. Inoltre, a differenza della classica gestione dei progetti, Lean consente di eseguire più attività in parallelo in fasi diverse, il che aumenta la flessibilità e aumenta la velocità di esecuzione del progetto.

Come Agile, Lean è più un concetto, un modo di pensare, piuttosto che qualcosa scolpito nella pietra. Utilizzando le idee Lean, puoi creare in modo indipendente un sistema che soddisfi i tuoi requisiti di gestione del progetto.

Punti di forzaPendere

Se ti piacciono le idee di Agile, ma il progetto richiede una qualità molto coerente e un'esecuzione precisa, Lean fornisce una serie di strumenti per soddisfare questi requisiti. Lean combina flessibilità e struttura come Scrum, ma in un modo leggermente diverso.

Lati deboliPendere

Non tutte le parti del progetto richiedono studio e attenzione altrettanto dettagliati e meticolosi. Ma Lean assume esattamente questo approccio per ogni compito e fase. Questo è il principale svantaggio dell’utilizzo del Lean per progetti grandi ed eterogenei.

Inoltre, a differenza di Scrum, Lean non offre un flusso di lavoro chiaro per l’implementazione di “pezzi” del progetto, il che contribuisce all’estensione della sequenza temporale del progetto. Questo problema può essere risolto con una leadership efficace e una comunicazione chiara: la cosa principale da ricordare è questa.

Kanban

Lean sembra un po’ astratto di per sé, ma se combinato con Kanban diventa molto più facile da usare per costruire il proprio sistema di gestione dei progetti. Creato dall’ingegnere Toyota Taiichi Ono nel 1953, Kanban è molto simile a un diagramma di flusso della produzione industriale. All'ingresso di questo processo entra un pezzo di metallo e all'uscita si ottiene una parte finita. Anche in Kanban, l'incremento di un prodotto viene passato di fase in fase e alla fine c'è un articolo pronto per la consegna.

Inoltre, il creatore di Kanban si è ispirato ai supermercati, vale a dire al loro principio: "tenere sugli scaffali solo ciò di cui il cliente ha bisogno". Pertanto, Kanban ti consente di lasciare un'attività incompiuta in una delle fasi se la sua priorità è cambiata e ci sono altre attività urgenti. Un articolo inedito per un blog, un post senza data di pubblicazione o un pezzo di codice per una funzionalità che potrebbe non essere inclusa nel prodotto sono tutti normali per il lavoro Kanban.

Kanban è molto meno rigido di Scrum: non limita la durata degli sprint, non ci sono ruoli, ad eccezione del product Owner. Kanban consente persino a un membro del team di gestire più attività contemporaneamente, cosa che Scrum non consente. Inoltre, le riunioni sullo stato del progetto non sono regolamentate in alcun modo: puoi farlo a tuo piacimento o non puoi farlo affatto.

Per lavorare con Kanban, è necessario definire le fasi del flusso di lavoro. In Kanban, sono rappresentati come colonne e le attività sono rappresentate da carte speciali. La carta si muove attraverso le fasi, come una parte di una fabbrica che si sposta da una macchina all'altra, e ad ogni fase il tasso di completamento aumenta. Di conseguenza, riceviamo un elemento del prodotto pronto per la consegna al cliente. Un tabellone con colonne e carte può essere reale o elettronico: anche qui Kanban non impone alcuna restrizione agli utenti.

Il tuo sistema Kanban può essere flessibile quanto vuoi: in molti modi, Kanban è una visualizzazione dell'idea di Agile. Ma Kanban ha 4 pilastri su cui poggia l’intero sistema:

1. Carte: Per ogni attività viene creata una scheda individuale in cui vengono inserite tutte le informazioni necessarie sull'attività. Quindi, tutto informazione necessaria il compito è sempre a portata di mano.
2. Limite al numero di attività per fase: Il numero di carte in una fase è strettamente regolato. Grazie a ciò diventa immediatamente chiaro quando si verifica un “inceppamento” nel flusso delle operazioni, che viene prontamente eliminato.
3. Flusso continuo: Le attività in backlog vengono aggiunte al flusso in ordine di priorità. Quindi il lavoro non si ferma mai.
4. Miglioramento continuo (Kaizen)Kaizen)): Il concetto di miglioramento continuo è emerso in Giappone alla fine del XX secolo. La sua essenza è l'analisi costante del processo produttivo e la ricerca di modi per migliorare la produttività.

Punti di forzaKanban

Come Scrum, Kanban è adatto a team abbastanza coesi con una buona comunicazione. Ma a differenza di Scrum, Kanban non ha scadenze rigide, il che è positivo per i team motivati ​​ed esperti.

A impostazione corretta e gestione, Kanban può apportare grandi vantaggi a un team di progetto. Calcolo accurato del carico di lavoro del team, posizionamento corretto delle restrizioni e concentrazione sul miglioramento continuo: tutto ciò consente a Kanban di risparmiare seriamente risorse e rispettare scadenze e budget. E tutto questo unito alla flessibilità.

Lati deboliKanban

Spesso puoi sentire che Kanban, a differenza di Scrum, ti consente di lavorare con quasi tutti i team. Ma non è così. Kanban è più adatto per i team le cui competenze dei membri si sovrappongono tra loro. In questo modo, possono aiutarsi a vicenda a superare le difficoltà nella risoluzione dei problemi. Senza questo, Kanban non sarà così efficace come potrebbe essere. Inoltre, come già accennato, Kanban è più adatto nei casi in cui non ci sono scadenze rigide. Per scadenze strette è preferibile l’approccio classico o Scrum.

6 Sigma (Sei Sigma)

Anche Motorola, insieme a Toyota, ha contribuito allo sviluppo della gestione globale dei progetti. L'ingegnere dell'azienda Bill Smith ha creato il concetto di 6 Sigma nel 1986. Si tratta di una versione più strutturata di Lean rispetto a Kanban, che aggiunge maggiore pianificazione per risparmiare risorse, migliorare la qualità e ridurre il numero di difetti e problemi.

L'obiettivo finale del progetto è la soddisfazione del cliente riguardo alla qualità del prodotto, che può essere raggiunta attraverso un processo continuo di miglioramento di tutti gli aspetti del progetto, basato su un'analisi approfondita degli indicatori. Il concetto 6 Sigma presta particolare attenzione all'eliminazione dei problemi emergenti.

A questo scopo è stato proposto un processo in 5 fasi noto come DMEDI:

• Definizione (Definire): La prima fase è molto simile alle fasi iniziali di altri sistemi di gestione dei progetti. Determina il contenuto del progetto, raccoglie informazioni sui prerequisiti del progetto e stabilisce gli obiettivi.
• Misurazione (Misurare): 6 Sigma si concentra sulla raccolta e l'analisi dei dati quantitativi su un progetto. In questa fase si determina quali indicatori determineranno il successo del progetto e quali dati dovranno essere raccolti e analizzati.
• Studio (Esplorare): Durante la fase di ricerca, il project manager decide come il team può raggiungere i propri obiettivi e soddisfare tutti i requisiti in tempo e nel rispetto del budget. In questa fase, è molto importante che il project manager pensi fuori dagli schemi quando risolve i problemi che si presentano.
• Sviluppo (Sviluppare): In questa fase vengono implementati i piani e le decisioni prese nelle fasi precedenti. È importante capire che in questa fase è necessario un piano dettagliato che descriva tutte le azioni necessarie per raggiungere i tuoi obiettivi. Anche in questa fase viene misurato lo stato di avanzamento del progetto.
• Controllo (Controllo): Tappa chiave nella metodologia 6 Sigma. Il suo compito principale è il miglioramento a lungo termine dei processi di implementazione del progetto. Questa fase richiede un'attenta documentazione delle lezioni apprese, l'analisi dei dati raccolti e l'applicazione delle conoscenze acquisite sia nei progetti che in tutta l'azienda nel suo insieme.

6 Sigma è molto simile a Kanban, solo con fasi stabilite di implementazione delle attività: pianificazione, definizione degli obiettivi e test di qualità. Molto probabilmente, ci saranno molte più riunioni di squadra quando si utilizza 6 Sigma rispetto a quando si utilizza Kanban, ma il processo di implementazione del progetto è più strutturato ed è più difficile per il team andare fuori strada. E, come Kanban, 6 Sigma può essere adattato con relativa facilità alle esigenze di un’azienda o di un team specifico. Un requisito rigoroso è solo un'attenta misurazione e controllo degli indicatori del progetto nelle fasi di implementazione: senza di ciò, il miglioramento continuo a lungo termine dei processi di implementazione del progetto è impossibile.

Punti di forza del 6 Sigma

Il concetto 6 Sigma fornisce un quadro chiaro per l’implementazione del progetto e il miglioramento continuo del processo. Definendo gli obiettivi, quindi analizzandoli e rivedendoli attentamente, si ottengono dati quantitativi per comprendere meglio il progetto e prendere decisioni migliori. Sebbene la raccolta, l’analisi dei dati e l’elaborazione delle lezioni possano richiedere del tempo, ciò migliorerà e ottimizzerà i processi di implementazione del progetto e quindi farà risparmiare risorse in futuro.

6 Sigma è adatto a progetti difficili che coinvolgono molte attività nuove e complesse. Questo approccio consente di implementare gli elementi del progetto, imparare dagli errori e migliorare la qualità in futuro.

Debolezze del 6 Sigma

Il problema con 6 Sigma è che, sebbene l’obiettivo principale dichiarato sia ridurre i costi e aumentare l’efficienza, spesso la soddisfazione del cliente viene in primo piano. Date alcune differenze negli obiettivi nelle diverse fasi di un progetto, i team spesso finiscono con la confusione sulle priorità, e questo non è facile da evitare.

Inoltre, il leitmotiv principale di 6 Sigma è: “Tutto può sempre essere fatto ancora meglio”. Ciò può demotivare i dipendenti che non si sentono soddisfatti del proprio lavoro. Inoltre, se il progetto è un progetto una tantum e l’azienda non prevede di implementare progetti simili in futuro, tutti i costi di analisi e lezioni di apprendimento potrebbero essere vani.

PRINCIPE2

La NASA non è l'unica organizzazione governativa che ha contribuito allo sviluppo della gestione dei progetti. Il governo britannico apprezza da tempo l'efficacia della gestione dei progetti e nel 1989 è stata creata la metodologia britannica PRINCE2. Il nome deriva dall'acronimo " PR oggetti IN C controllato E versione ambienti 2 ”, che si traduce in “Progetti in ambiente controllato versione 2”. A differenza dei metodi agili, PRINCE2 non adotta un approccio iterativo al progetto. Se confrontato con altri prodotti, PRINCE2 può essere paragonato a un ibrido tra l'approccio classico alla gestione dei progetti e l'attenzione alla qualità di 6 Sigma.

La metodologia PRINCE2, a differenza, ad esempio, del corpus di conoscenze PMBOK, non contiene:

• Aspetti specialistici della gestione dei progetti, come quelli specifici del settore;
• Pratiche e strumenti specifici di gestione del progetto, come diagramma di Gantt, WBS, ecc.

PRINCE2 si concentra sugli aspetti gestionali del progetto, espressi in 7 principi, 7 processi e 7 temi di progetto.

• 7 principi definiscono le regole generali della gestione del progetto secondo PRINCE2, definiscono le basi della metodologia;
• 7 processi definiscono le fasi per avanzare attraverso il ciclo del progetto;
• 7 argomenti: aspetti che vengono monitorati per raggiungere il successo del progetto.

All'inizio di un progetto, PRINCE2 ci chiede di definire 3 aspetti principali del progetto:

• Aspetto business (Questo progetto porterà benefici?)
• Aspetto del consumatore (quale prodotto è necessario, cosa faremo?)
• Aspetto delle risorse (ne abbiamo abbastanza per raggiungere il nostro obiettivo?)

PRINCE2 ha una struttura del team di progetto più chiaramente definita rispetto alla maggior parte degli approcci di gestione dei progetti. Ciò è dovuto al fatto che PRINCE2 si concentra su progetti governativi su larga scala e grandi organizzazioni.

Secondo PRINCE2, ogni membro del team ha un ruolo chiaro in ciascuno dei 7 processi:

• Inizio del progetto (Starting suUN progetto): Durante questo processo viene nominato un project manager e vengono determinati i requisiti prestazionali generali del prodotto. Il Project Manager, il cui obiettivo principale è l'attenzione ai dettagli, riferisce al Comitato direttivo del progetto, che è responsabile della gestione complessiva del progetto. È il comitato direttivo che garantisce che il progetto rimanga sulla buona strada ed è il responsabile ultimo del suo successo.
• Inizio progettoUN progetto): Durante questo processo, il project manager scrive un "documento di avvio del progetto", che contiene un piano graduale per il progetto. Le fasi possono durare quantità diverse tempo, ma, come nell'approccio classico, si susseguono rigorosamente uno dopo l'altro.
• Gestione del progetto (Diretting UN progetto): Questo processo consente al comitato direttivo di assumersi la responsabilità complessiva del successo del progetto senza impantanarsi nei dettagli che rientrano nell'ambito di competenza del project manager.
• Controllo di scenaling UN palcoscenico): Durante l'attuazione del progetto, anche in condizioni ideali, verranno apportate alcune modifiche. Il processo Stage Control implementa uno dei principi PRINCE2: il principio della gestione per eccezione. È responsabilità del project manager monitorare le deviazioni dai parametri pianificati del progetto in termini di tempistica, contenuto, budget, ecc. durante la fase di implementazione Se tali deviazioni superano l'autorità conferita al project manager dal Comitato Direttivo (. nella terminologia PRINCE2 - tolleranze), il project manager è obbligato a informare il Comitato Direttivo e proporre soluzioni per uscire dalla situazione.
• Gestione della creazione del prodotto (Gestire Prodotto Consegna): Il processo di gestione della creazione del prodotto è l'interazione tra il project manager e il team manager per creare uno dei prodotti del progetto. Le responsabilità del project manager in questo processo includono la delega dell'autorità di creare il prodotto al team manager e l'accettazione del prodotto creato.
• Gestione dei confini dello stadio (Managing UN palcoscenico confine): Durante questo processo, il project manager fornisce tutto al comitato direttivo informazione necessaria valutare i risultati della fase superata e prendere una decisione sul passaggio alla fase successiva.
• Completamento del progetto (ClosingUN progetto): Una delle differenze tra PRINCE2 è che il processo di completamento di un progetto non è suddiviso in una fase o fase separata, come nell'approccio classico, ma viene eseguito come parte della fase finale di creazione del prodotto. Lo scopo del processo è confermare che il prodotto del progetto è stato accettato o che il progetto non può più fornire nulla di utile.

PRINCE2 può essere adattato a progetti di qualsiasi dimensione e qualsiasi area tematica. La metodologia offre raccomandazioni specifiche per modificare il ciclo di vita del progetto, modello di ruolo e una serie di documenti obbligatori in conformità con le esigenze del progetto.

Punti di forza di PRINCE2

• Adattabilità alle caratteristiche dell'organizzazione;
• Disponibilità di una chiara descrizione dei ruoli e della distribuzione delle responsabilità;
• Focus sui prodotti del progetto;
• Alcuni livelli di gestione;
• Focus sulla fattibilità economica;
• Sotto sequenza lavoro di progetto;
• Enfasi sull'acquisizione di esperienza e sul miglioramento continuo.

Debolezze di PRINCE2

• Mancanza di pratiche di settore;
• Mancanza di strumenti specifici per lavorare nel progetto.

Il miglior sistema di gestione dei progetti... per te!

Il project management è una scienza, ma non è una scienza esatta. In questo ambito non esistono basi incrollabili né soluzioni universali. Se riesci a trovare un metodo ideale per il tuo progetto, considerati molto fortunato, perché la maggior parte dei manager meno fortunati deve impegnarsi per creare e configurare i propri sistemi di gestione dei progetti. Questi sistemi possono essere composti da elementi sistemi esistenti o addirittura creati completamente da zero, come nel caso della missione Apollo. La cosa principale è usare qualcosa che ti dia almeno una certa struttura e ti permetta di ricordare ciò che è importante per il tuo progetto.

Questa guida per sviluppatori e tester di software ti aiuterà a comprendere e iniziare a utilizzare la metodologia agile SCRUM.

Impara i termini basilari ma importanti utilizzati nel processo Agile Scrum insieme a un esempio di vita reale del processo completo.

SCRUM è un processo agile che è una combinazione di modelli iterativi e incrementali.

Uno dei principali svantaggi del modello a cascata tradizionale è che finché non viene completata la prima fase, l'applicazione non passa alla fase successiva. Se accade che ci siano dei cambiamenti in una fase successiva del ciclo, allora sarà molto difficile effettuare questi cambiamenti, poiché ciò comporterà la revisione delle fasi precedenti e la rifacimento dei cambiamenti.

Alcune delle caratteristiche principali di SCRUM sono:

• Squadra organizzata e propositiva
• Non ci sono requisiti documentali, è sufficiente avere testi accurati al punto.
• Il team funzionale lavora come una singola unità.
• Stretta connessione con l'utente, aiutando a comprenderne le funzionalità.
• Esiste un asse temporale preciso di massimo 1 mese.
• Invece di fare tutto in una volta, Scrum fa un po’ di tutto in un dato periodo di tempo.
• Prima di intraprendere qualsiasi azione vengono considerate le caratteristiche e la disponibilità delle risorse.

Per comprendere bene questa metodologia, è importante comprendere i termini chiave di SCRUM.

Termini importanti di SCRUM:

1. Squadra di mischia

Uno Scrum Team è un team di 7 +/- 2 membri. I membri del team sono un mix di sviluppatori competenti, tester, addetti ai database, operatori di supporto, ecc., nonché il proprietario del prodotto e lo Scrum Master. Tutte queste persone lavorano a stretto contatto durante un dato periodo ricorsivo per sviluppare ed eseguire le funzioni specificate.

2. Sprint

Uno sprint è un periodo di tempo standard in cui il lavoro deve essere completato e pronto per la revisione o il rilascio del prodotto. In genere questo periodo dura da due settimane a un mese. Quando diciamo che facciamo 1 sprint in un mese, significa che lavoriamo per un mese sui compiti e li prepariamo per la revisione entro la fine di quel mese.

3. Proprietario del prodotto

Il Product Owner è il principale venditore o l'utente principale dell'applicazione in fase di sviluppo.

Il Product Owner è la persona che rappresenta il lato cliente. Ha l'autorità finale e deve essere sempre a disposizione della squadra. Lui/lei deve essere disponibile quando qualcuno ha bisogno che venga spiegato qualcosa. È importante che il Product Owner comprenda e non fissi nuovi requisiti nel bel mezzo dello sprint o quando è già iniziato.

4. Maestro della mischia

Lo Scrum Master è il coordinatore dello Scrum team. Lui/lei garantisce che il team di mischia sia produttivo e progressista. In caso di qualsiasi interferenza, lo Scrum Master la trova e la risolve per il team.

5. Storia dell'utente

Le storie degli utenti sono requisiti o funzioni che devono essere completate. In Scrum non abbiamo questi grandi documenti sui requisiti, al contrario, i requisiti sono indicati in un paragrafo, solitamente in questo formato:

Come<тип пользователя>

Voglio<доступная цель>

per il successo<результат/причина>

Per esempio:

In qualità di amministratore, desidero poter bloccare una password per limitare l'accesso non autorizzato nel caso in cui l'utente inserisca la password sbagliata 3 volte di seguito.

Ci sono alcune caratteristiche delle storie degli utenti che devono essere rispettate. Le storie degli utenti dovrebbero essere concise, realistiche, possibilmente valutative, complete, negoziabili e testabili.

Ogni user story ha un criterio di accettazione che deve essere chiaramente definito e compreso dal team. I criteri di accettazione descrivono dettagliatamente le storie degli utenti e forniscono documenti supportati. Ciò consente di dettagliare le storie degli utenti. Qualsiasi membro del team può scrivere i criteri di accettazione. Il team di verifica basa i propri casi/condizioni di test su questi criteri.

6. “Epica”

Le epiche sono storie di utenti vaghe. Oppure possiamo dire che si tratta di storie utente non definite e archiviate per sprint futuri. Prova a collegarlo con la vita, immagina di andare in vacanza. Dato che partirai la prossima settimana, hai tutto pianificato: prenotazioni alberghiere, visite turistiche, borsa da viaggio preparata, ecc. Ma per quanto riguarda le tue vacanze l'anno prossimo? Hai solo una vaga idea di poter andare nel posto XYZ, ma non hai un piano dettagliato.

“Epic” è come la tua vacanza l’anno prossimo: sai che puoi andare, ma dove, quando e con chi – non ci sono ancora pensieri su questo argomento.

Allo stesso modo, ci sono funzionalità che dovrebbero essere implementate in futuro, ma i loro dettagli non sono ancora noti. In genere, un'opportunità inizia con un'"epopea" e viene poi suddivisa in storie che possono essere realizzate.

7. Registro dei desideri del prodotto

Un registro dei desideri del prodotto è una sorta di segmento o fonte in cui sono archiviate tutte le storie degli utenti. È gestito dal proprietario del prodotto. Un registro dei desideri del prodotto può essere considerato come una lista dei desideri del proprietario del prodotto, che le dà la priorità in base alle esigenze aziendali. Durante la pianificazione (vedere la sezione successiva), una delle user story viene presa dal backlog, il team inizia a fare brainstorming, concettualizzare, perfezionare e decidere collettivamente (con il contributo del product Owner) quale user story accettare.

8. Arretrato di sprint

Viene presa una storia utente alla volta dal registro dei desideri del prodotto. Il team Scrum fa brainstorming, determina la fattibilità e decide su quale storia lavorare durante un dato sprint. L'elenco complessivo di tutte le user story su cui un team Scrum sta lavorando durante un dato sprint è chiamato sprint backlog.

9. Punti della storia dell'utente:

Questi punti sono una rappresentazione numerica della complessità della user story. Sulla base di questi punteggi, vengono determinati il ​​punteggio e il carico di lavoro di una storia. I punti non sono assoluti, sono relativi. Per garantire che i nostri sforzi e le nostre stime siano corretti, dobbiamo verificare se le storie degli utenti sono grandi. Più piccola e chiara è la user story, più accurata sarà la stima.

A ciascuna user story viene assegnato un punteggio di Fibonacci (1, 2, 3, 5, 8, 13, 21). Più alto è il numero, più complessa è la storia.

Per essere più precisi, quindi

• Se scommetti 1/2/3 punti significa che la storia è breve e ha una difficoltà bassa.
• Se dai 5/8 punti allora è di media difficoltà e
• 13 e 21 punti – la storia è molto complicata.

La difficoltà qui risiede nello sviluppo e nella quantità di lavoro di test

Per decidere quanti punti assegnare, lo Scrum team inizia il brainstorming e decide collettivamente. Può succedere che il team di sviluppo dia 3 punti ad una storia specifica perché per loro potrebbero essere 3 righe di codice sostitutivo, ma il team di testing darà 8 punti perché ritiene che questa sostituzione di codice avrà un impatto maggiore sui moduli, quindi il quantità di lavoro ce ne sarà di più durante i test. Ma non importa quanti punti dai, devi giustificare la tua decisione. Pertanto, si verifica una sessione di brainstorming e la squadra decide quanti punti mettere.

Ogni volta che decidi quanti punti scommettere, considera i seguenti fattori:

• Relazione della cronologia con altre applicazioni/moduli,
• Insieme di abilità delle risorse
• La complessità della storia
• Apprendimento narrativo,
• Criteri di accettazione della storia dell'utente

Se non sei a conoscenza di una storia in particolare, non ridimensionarla.
Se vedi che il punteggio di una storia è molto alto, suddividilo in storie più piccole.

10. Grafico di burndown delle attività

Un grafico di burndown delle attività presenta un grafico che mostra i v/s stimati dell'impegno effettivo delle attività di Scrum.

Questo è un meccanismo di tracciamento per uno sprint specifico. Ogni giorno vengono monitorate le attività per verificare se le storie stanno procedendo verso il completamento o meno.

Esempio: per capirlo, guarda l'immagine:

Ho scelto:

• Sprint di due settimane (10 giorni)
• 2 risorse per il lavoro effettivo dello sprint.

"Storia" -> la colonna mostra le user story prese per lo sprint. "Compito" -> la colonna mostra un elenco di attività associate alle storie degli utenti.

“Ambito di lavoro” -> la colonna mostra la quantità di lavoro. Questa misura rappresenta ora la quantità totale di lavoro necessaria per completare l'attività. Non descrive la quantità di lavoro di una persona in particolare.

“Giorno 1 – Giorno 10”->– le colonne mostrano il tempo rimanente fino alla fine della storia. Tieni presente che questo NON è il tempo che è già passato, MA il tempo che rimane ancora.

“Quantità di lavoro stimata” -> indicatore della quantità totale di lavoro. Per "Inizio" questo è semplicemente il totale dell'intera attività: SUM (C5:C15)

La quantità totale di lavoro da completare in 1 giorno è 70/10 = 7. Pertanto, alla fine del primo giorno, la quantità di lavoro dovrebbe essere ridotta a 70-7 = 63. Allo stesso modo, questo viene calcolato per tutti i giorni fino al 10, quando l'importo del lavoro stimato deve essere pari a zero (riga 16)

“Quantità di lavoro rimanente” -> Come suggerisce il nome, questa è la quantità di lavoro rimanente prima che la storia venga completata. Può anche succedere che la quantità effettiva di lavoro diventi maggiore o minore del previsto.

È possibile utilizzare funzioni e grafici in Excel per creare questo grafico di burndown delle attività.

Fasi del grafico di burndown delle attività:

1. Inserisci tutte le storie (colonna A5 – A15)
2. Inserisci tutte le attività (colonna B5-B15)
3. Inserisci i giorni (giorno 1 – giorno 10)
4. Inserisci la quantità di lavoro iniziale (riassumi le attività C5-C15)
5. Applicare la formula per calcolare la “quantità di lavoro stimata” per ciascun giorno (dal giorno 1 al giorno 10). Inserisci la formula in D15 (c16-$C$ 16/10) e trascinala su tutti i giorni.
6. Per ogni giorno, inserisci la quantità effettiva di lavoro. Inserisci una formula in D17 (SOMMA (D5:D15)) per sommare la quantità di lavoro rimanente e trascinala su tutti gli altri giorni.
7. Seleziona questo e crea un grafico come questo:

11. Velocità della squadra

Il numero totale di punti che una squadra di mischia accumula in uno sprint è chiamato velocità della squadra. Un team Scrum viene giudicato in base alla sua velocità. Va detto che va tenuto presente che il raggiungimento del numero massimo di punti NON è l'obiettivo qui, ma buona qualità risultati, aumenta il livello di comfort del team Scrum.

Per esempio: Per uno sprint specifico: il numero totale di user story è 8. Ciascuna di esse ha un certo numero di punti

Pertanto, la velocità è la somma dei punti = 30

12. Definizione di “pronto”:

La storia è REALIZZATA in Scrum solo quando c'è sviluppo, piena garanzia di qualità e opportunità di entrare in produzione.

Attività in SCRUM:

N. 1: riunione di pianificazione

L'incontro di pianificazione è il punto di partenza di SCRUM. Questo è un incontro in cui si riunisce l'intero team Scrum. Il product Owner seleziona le storie degli utenti dal product backlog in base alla priorità e il team inizia il brainstorming. Durante la discussione, lo Scrum team determina la complessità della storia e la misura secondo la serie di Fibonacci. Il team definisce le attività e la quantità di lavoro (in ore) che potrebbe essere svolta per completare l'implementazione della user story.

La “Pre-pianificazione della riunione” precede la riunione. Questo è come il compito che un team Scrum fa prima di incontrarsi per una riunione di pianificazione formale. Il team cerca di annotare le dipendenze o altri fattori di cui vorrebbe discutere durante la riunione.

N. 2: Completamento degli obiettivi dello sprint

Come suggerisce il nome, è compito del team Scrum completare il proprio compito e spostare la user story sullo stato “fatto”.

#3: Riunione Daily Scrum (chiamata)

Durante il ciclo dello sprint, ogni giorno il team di mischia si riunisce per non più di 15 minuti (potrebbe trattarsi di una chiamata, consigliata all'inizio della giornata). Durante l’incontro vengono poste tre domande:

1. Cosa ha fatto il membro del team dall'ultimo incontro?
2. Cosa intende fare oggi il membro del team?
3. Ci sono ostacoli per la squadra?

Lo Scrum Master lavora per risolvere questi problemi. Se un partecipante incontra qualsiasi tipo di difficoltà, lo Scrum Master aiuta a risolverlo.

#4: Revisione dei risultati

Alla fine di ogni ciclo di sprint, il team SCRUM si riunisce di nuovo e dimostra l'implementazione delle storie degli utenti al product Owner. Il Product Owner può raccogliere le storie in base ai propri criteri di accettazione. È ancora una volta responsabilità dello Scrum Master presiedere questo incontro.

#5: Incontro retrospettivo

Una riunione retrospettiva avviene dopo la revisione dei risultati. Il team SCRUM raccoglie, discute e documenta i seguenti punti:

1. Cosa è andato bene nello sprint precedente (migliore pratica)
2. Ciò che non è stato fatto molto bene
3. Lezioni imparate
4. Elementi di azione.

Il team Scrum deve continuare a seguire le migliori pratiche, ignorare le “cattive pratiche” e implementare le lezioni apprese negli sprint successivi. Un incontro retrospettivo aiuta a migliorare continuamente il processo SCRUM.

Come viene eseguito il processo? Esempio!

Dopo aver letto i termini tecnici di SCRUM, vorrei provare a dimostrare l'intero processo con un esempio.

Passo 1: Immaginiamo un team SCRUM di 9 persone, composto da 1 proprietario, 1 Scrum master, 2 tester, 4 sviluppatori e 1 amministratore del database.

Passo 2: Un ciclo di sprint, ad esempio, durerà 4 settimane. Quindi, abbiamo uno sprint di 1 mese: dal 5 giugno al 4 luglio.

Passaggio n.3: il Product Owner ha un elenco prioritario di storie utente nel registro dei desideri del prodotto.

• Il Product Owner prende 1 storia dalla lista dei desideri del prodotto, la descrive e la trasmette al team per il brainstorming.
• L'intero team discute e si rivolge direttamente al proprietario del prodotto per spiegare in dettaglio la storia dell'utente.
• Altre storie utente sono accettate allo stesso modo. Se possibile, il team può continuare e anche misurare le storie.

Dopo la discussione, i membri del team tornano al posto di lavoro e

• Definiscono i loro compiti individuali per ogni storia.
• Calcola la quantità esatta di tempo di cui avranno bisogno per lavorare. Come calcola il partecipante questo tempo? Controlliamo:

Ore lavorative totali = 9

Meno 1 ora per una pausa, meno 1 ora per le riunioni, meno 1 ora per e-mail, discussioni, risoluzione dei problemi, ecc.
Quindi ore di lavoro effettive = 6

Numero totale di giorni lavorativi durante lo sprint = 21 giorni.
Totale ore disponibili = 21 * 6 = 126

Il membro è in vacanza 2 giorni = 12 ore (questo varia per ogni membro, alcuni possono prendersi una vacanza, altri no.)
Numero di ore effettive = 126-12 = 114 ore.

Ciò significa che il partecipante sarà generalmente disponibile per 114 ore durante questo sprint. Pertanto, dividerà il suo compito di sprint individuale in modo tale da completarlo in 114 ore.

• Il parere finale sulla user story dal product backlog è completato e la storia viene spostata nello sprint backlog.
• Per ogni storia, ogni membro del team annuncia i propri compiti specifici. Se vuoi discutere di questi problemi, puoi misurarli o ridimensionarli (pensa alla serie di Fibonacci!).
• Lo Scrum Master o il team inseriscono nel programma i propri compiti individuali e i tempi per ciascuna storia.
• Una volta completate tutte le storie, annota lo Scrum Master velocità iniziale e lo Sprint inizia ufficialmente.

Passaggio n.6: Una volta iniziato lo sprint, ogni membro del team inizia a lavorare sui compiti assegnati.

Passaggio n.7: Il team si incontra ogni giorno per 15 minuti e discute 3 domande:

• Cosa hanno fatto ieri?
• Cosa hanno intenzione di fare oggi?
• C'è qualche interferenza?

Passaggio n.8: Lo Scrum Master tiene traccia quotidianamente dei progressi utilizzando un grafico Burndown

Passaggio n.9: In caso di interferenza, lo Scrum Master la risolve.

Passaggio n.10: Il 4 luglio la squadra si riunisce di nuovo per rivedere i risultati. Ogni membro del team dimostra la storia dell'utente implementata al proprietario del prodotto.

Passaggio n.11: Il 5 luglio l'équipe si riunisce nuovamente per un incontro retrospettivo in cui si discute

• Cosa è andato bene?
• Cosa non è andato bene
• Elementi di azione.

Passaggio n.12: Il 6 luglio il team si incontra di nuovo per il prossimo incontro di pre-pianificazione dello sprint e il ciclo continua.

(Clicca per ingrandire l'immagine)

Programmi utilizzabili per le attività SCRUM:

Esistono molti strumenti che possono essere ampiamente utilizzati per tenere traccia delle attività di Scrum. Ecco qui alcuni di loro:

• XPlanner
• VersioneUno
• Sprintometro
• ScrumNinja

Conclusione:

All'inizio, le persone potrebbero incontrare alcune difficoltà nel tentativo di padroneggiare questa tecnica, ma con la pratica vedrai che SCRUM fa miracoli. SCRUM concentra le risorse in modo che tu possa vedere evolvere la tua applicazione.

Molte organizzazioni temporanee incoraggiano il team (come compito di mischia) a dedicare un paio d'ore all'autoapprendimento e allo sviluppo. Anche durante la revisione, i membri del gruppo mostrano ciò che hanno imparato e talvolta presentano programmi o applicazioni che hanno sviluppato. Personalmente apprezzo questo metodo perché offre alle persone la possibilità di ampliare le proprie conoscenze e di mettere in mostra le proprie capacità.