“Being Agile” is like “being in love”. No guarantee that it means the same thing to any two teams.
Seen on Twitter from “jasongorman”
Qualche contesto: Scrum ( http://en.wikipedia.org/wiki/Scrum_(development) ) è una metodologia di sviluppo software (ma non solo) appartenente alla famiglia agile ( http://agilemanifesto.org ), un insieme di metodologie nate come risposta diretta al paradigma dominante del project management, waterfall, prende in prestito molti principi della lean manufacturing e fu formalizzata quando 17 pionieri della metodologia agile nel 2001 scrissero il Manifesto Agile. Se conosci un minimo l’approccio di Twproject, e dai un’occhiata ai principi agili, noterai una certa somiglianza.
Scrum non riguarda solo lo sviluppo software: vedi un’applicazione reale di Scrum al di fuori dell’IT http://www.scrumalliance.org/resource_download/548 .
Kanban: su Wikipedia:
http://en.wikipedia.org/wiki/Kanban
Paragonato a Scrum:
http://www.infoq.com/minibooks/kanban-scrum-minibook
“Kanban uses a visual control mechanism to track work as it flows through the various stages of the value stream. Typically, a whiteboard with sticky notes, or an electronic card wall system, is used”
Quando tornammo alla versione 4 di Twproject dopo aver esaminato alcune pubblicazioni sul metodo agile, e in particolare riconsiderando la prospettiva Scrum, divenne progressivamente più chiaro che mappare le idee Scrum su questa o quella funzionalità di un software è inevitabilmente una semplificazione e potrebbe essere anche un “tradimento” della fisolofia agile: poiché queste metodologie riguardano il modo di approcciarsi ai problemi, e in dettaglio quando entriamo in ogni caso particolare presentano grandi variazioni; vedi
Agile Project Management with Scrum by Ken Schwaber, Microsoft Press
che è pieno di esempi.
Da questa prospettiva, il punto principale non è e non deve essere il software di project management che stai usando. Ci torneremo nelle considerazioni finali.
Stiamo assumendo qui di avere familiarità con i concetti di metodologie agili e Scrum. Anche gli esempi sono incentrati sullo sviluppo software, ma la linea, se valida, è valida in generale.
Nella nostra esperienza successo e produttività sono legate a come gestisci due aspetti della gestione del lavoro:
- Modellare accuratamente le complessità del tuo ambiente di lavoro – e qui ovviamente Twproject ti assiste splendidamente
- Portare questa complessità verso qualcosa di semplice, leggero, gestibile velocemente e aggiornabile dal singolo utente.
Molte delle idee che circondano la gestione “agile” e il “getting things done” ruota intorno a questo processo.
Esempi di mappatura
Figure 3 Burn down chart con Twproject
Se si decide di usare un software di project management per gestire le procedure agili, si dovrebbe fare attenzione a non prendere decisioni semplicistiche.
Considera per esempio i backlog: la raccolta dei backlog è il passo più semplice; come raccogli i backlog? Potresti farlo su un documento condiviso di Google; così dal punto di vista del software di PM, il tuo backlog è un documento non strutturato che il software non gestisce. Può essere un insieme di entità distinte, per esempio ToDo? Può essere fatto con progetti con descrizioni dettagliate e stima del lavoro; e così via.
In molti esempi di insegnamento di Scrum vediamo schede attaccate alla lavagna, e alcuni software usano questa idea per l’interfaccia utente. Forse ci stiamo scordando che un progetto di sviluppo potrebbe avere circa 800 schede. Come posso attaccarle tutte alla lavagna? Non può funzionare. Serve qualcosa di più flessibile e potente di una lavagna che sia vera o digitale. Solo in alcuni casi può essere usata una lavagna – e ora Twproject ha la lavagna Kanban per fare proprio questo – vedi 4.5 Bulk management, 4.6 Organize – Kanban – Planner.
Stand-up meeting: perché il backlogging è oggetto del management-by-software e non lo è il meeting? Questa è una tipica ed errata prospettiva da hacker, perché alcune persone invece focalizzano la loro gestione più sull’agenda che sulla loro lista dei to-do. E avrai progetti con entrambi i tipi di persone (e molti altri).
Un esempio: vediamo un esempio di struttura di progetto e assegnazione: supponi di avere un cliente, uno sviluppatore capo, e un gruppo di sviluppatori, D1, D2, D3; vuoi raccogliere il backlog, e fondamentalmente il tuo obiettivo è quello di lasciare che gli sviluppatori lavorino tranquillamente e con un insieme stabile di requisiti per un mese. Modellare questo in Twproject non è un grande impegno, puoi supportare questa procedura in diversi modi; per esempio potresti avere un progetto di root ROOT, sul quale tutti sono assegnati come “reader”, e lo sviluppatore capo come project manager; hai un progetto figlio BACKLOG, dove il cliente è assegnato come “worker”, così da contribuire all’inserimento del backlog; il backlog è inserito come ToDo ssu questo progetto BACKLOG.
Adesso crea una nuova fase, figlio di ROOT chiamato FIRST SPRINT, sposta il sotto insieme di ToDo, e assegna D1, D2 e D3 come “workers”, di modo che loro possano modificare e chiudere le ToDos, ma nessuno esternamente cambierà l’insieme dei ToDos. Questo è tutto.
Su questa struttura, Twproject ti offre strumenti per andare avanti, lavorare comodamente, collegare questo progetto con altri strutturati diversamente; potrebbe essere anche un figlio di un progetto strutturato in modo completamente diverso. Puoi strutturare il progetto stesso del BACKLOG come un albero; potresti avere diversi sprint in parallelo; potresti avere dopo lo sprint un workflow di approvazione, e anche in questo caso Twproject ti supporta con progetti di tipo process.
Puoi guardare il video tutorial, oppure seguire le indicazioni di seguito:
Considerazioni finali sul metodo Agile
Figure 4 Kanban-like ToDo management
Una considerazione molto importante è che metodologie particolari, come lo Scrum, aiutano a risolvere certe classi di problemi, ma non copriranno mai la totalità delle attività lavorative di un’azienda. In realtà, i testo originali di Scrum texts sono scritti con piena coscienza di questo limite.
Quindi sarebbe estremamente non-agile avere un software specifico per i progetti “agili”, e uno per gli altri. E anche i progetti “agili” avranno tante varianti, che si inseriranno nella metafora agile a livelli diversi, e difficilmente in un angolo “modello di software Scrum”.
Alla fine ci siamo accorti che la mappatura tra la metodologia e il software (o la carta) richiede grande flessibilità; l’agilità è nella metodologia, nom nel software. Se vuoi usare un software, dovrebbe essere sufficientemente flessibile da lasciarti mappare i progetti, fase, ToDo, a persone e clienti, in infiniti modi, ma in modo che tutti i dati provenienti da progetti e metodologie diverse finiscano nello stesso posto.
Quindi no, Twproject non è un ancora un altro strumento Scrum, è uno strumento di gestione che può aiutare anche le aziende che hanno deciso di usare Scrum per alcuni progetti. In particolare abbiamo diversi strumenti che ti aiuteranno a tenere traccia delle statistiche direttamente nella pagina di dettaglio del progetto.
Mouse over lo stato per avere maggiori dettagli
Accedi al grafico burn down selezionando “grafico burn-down” nella sidebar nera:
Il grafico generato è utile se nella vita del progetto sono stati inseriti stime e worklog .
Si noti che ci sono due scale, sulla sinistra e sulla destra del grafico, una per le ore di lavoro, una per le ToDo aperte. Il grafico burn down non è supportato in Internet Explorer – per questa funzionalità usa un altro browser. Sulla parte bassa della pagina, abbiamo diversi grafici a torta rappresentanti lo stato corrente dei ToDo e come erano all’avvio del progetto.
Leggi di più su Twproject e Scrum qui: