Cosa è SCRUM? Può essere applicato nei progetti Security SAP? Quali sono i vantaggi?
Perché dovresti valutare di utilizzarlo se già non lo applichi in azienda?
Cosa è SCRUM?
Si tratta di un framework di lavoro. Letteralmente significa mischia, questo nome è stato preso dal rugby in quanto è il momento dove la squadra, compatta, cerca di spostarsi verso una certa direzione.
Inizialmente è stato applicato allo sviluppo di software, ma può essere adattato anche ad altri tipi di progetti.
Il concetto più elementare di questo modello è quello di evitare di progettare nei minimi dettagli qualcosa a tavolino, realizzarlo e poi mostrarlo alla fine di tutto il processo al tuo cliente.
Ma al contrario definire dei piccoli gruppi di lavoro, creare dei prototipi, condividerli immediatamente con il cliente per avere dei feedback e "aggiustare il tiro", senza aspettare troppo.
E la metodologia waterfall?
La metodologia waterfall, ancora largamente utilizzata oggi, nata attorno agli anni cinquanta, è l'esatto opposto di SCRUM. Si tratta di una metodologia per la gestione dei progetti basata su queste principali macro fasi:
- Requisito (Requirements)
- Progettazione (Design)
- Implementazione (Implementation
- Controllo (Verification)
- Gestione ordinaria (Maintenance)
Sono parecchi i difetti di questa metodologia:
- Statisticamente i costi non sono quasi mai rispettati
- Così come le tempistiche, sono spesso disattese
- Sono richieste molte funzionalità che non saranno mai utilizzate realmente
- Diventa più complesso cambiare qualcosa quando il progetto è in uno stadio molto avanzato
- È difficile conosce tutto in anteprima. E quindi diventa complicato progettare ogni sua parte
Dove interviene scrum quindi?
- Si lavora per prototipi, piccoli "sprint" che hanno l'obiettivo di creare qualcosa di tangibile e reale, in modo che sia mostrato al tuo cliente e se ne condividano feedback immediati, in modo da "sistemare" quanto emerso nel prossimo sprint
- Ogni gruppo, nel caso di più gruppo deve essere allineato ed avere uno Scrum Master di riferimento, le figure di riferimento nella metodologia sono il Product Owner ed il teamd di sviluppo (molto orientate allo sviluppo del software)
- Ogni team è formato da persone con competenze diverse per avere una visione globale del progetto
- Un dashboard di lavoro viene definito per capire le cose da fare, quelle in corso e quelle completate
- Periodicamente è necessario svolgere degli allineamenti (a seconda del tipo chiamato Scrum call giornaliera o scrum planning nel caso di avvii una nuova attività per definirne gli obiettivi)
Pur essendo relativamente semplice da cogliere nella sua essenza, può non essere così immediato applicarlo in azienda.
SAP Security e SCRUM come?
Come Aglea cerchiamo di applicare la metodologia nei progetti interni ed esterni.
Come?
- Definendo per ogni progetto, il team di progetto, e le varie responsabilità
- Utilizzando Microsoft Planner e Microsoft Teams per collaborare e condividere le informazioni di progetto, usando Microsoft Stream per condividere conoscenza, a volte un video è molto più efficace di testo o audio
È fondamentale avere uno strumento, che non siano solo le mail o excel che permetta di gestire in maniera agile lo sviluppo delle attività.
Certo, potremmo utilizzare anche Microsoft Project, ma per le tipologie di progetto che seguiamo può essere sufficiente Planner.
In Stream abbiamo caricato più di 2 giorni di video dedicati alla formazione interna sulle tematiche di Security SAP.
Quali i punti di attenzione a mio avviso?
- Devono essere ben definiti i ruoli all'interno del team e soprattutto quale sia l'obiettivo, questo spesso può non essere così chiaro
- Il team non deve essere formato da troppe persone (per i nostri progetti 3/4 persone è già un numero molto elevato)
- La chiamata di allineamento.
- A volte può essere una ripetizione delle attività che si stanno portando avanti, ognuno dovrebbe dire, cosa sta facendo, quali sono le difficoltà ed eventuali criticità. In modo molto conciso, questo a volte non avviene sforando le tempistiche dalla chiamata e perdendo il significato della stessa. Ovvero non ci stiamo allineando ma stiamo iniziando a discutere di problematiche (cosa che non andrebbe affrontata durante un allineamento)
- Non tutti conoscono la metodologia e come funziona. Spesso viene proposta ma senza conoscerne effettivamente le modalità di applicazione
- Alcune società non hanno gli strumenti per poter applicare quanto oggi è necessario per collaborare in maniera efficace
- Non esiste la possibilità di fare call o condividere lo schermo (non sto scherzando, in alcune società, e non parliamo di fruttivendoli o gelatai, o perché i sistemi sono troppo obsoleti oppure perché ci sono dei vincoli di security o perché "non è possibile" di fatto non si riesce a condividere dati o banalmente fare call dove si condivide lo schermo.
- Non sono utilizzati strumenti di collaborazione integrata tra cliente e fornitore. Si va avanti a suon di file excel o project da scambiare via mail (con il rischio di non sapere a quale versione si è arrivati)
- Capita di dover porre tutte le attenzioni sul fare la presentazione perfetta, limitando le forze sul contenuto della stessa
- Il formalismo e la burocrazia infinita. Migliaia di righe di verbali gestiti tramite word o excel, perdendo di vista l'obiettivo del progetto e puntando al fatto che sia perfetto dal primo momento
Come ragionare a mio avviso?
- Immagina cosa vuoi fare ed il tuo obiettivo. Lo so che può sembrare scontato. Ma a volte anche noi siamo chiamati da clienti dove la mappatura dei processi o la revisione degli stessi viene associata al "rivediamo cosa fanno le persone nei sistemi" e quindi alla profilazione. Non sempre argomenti simili coincidono necessariamente.
- Non dare per scontato che sia tutto semplice ed immediato da realizzare.
- Punta al minimo, per poi migliorare a seguito. A volte devi capire ed entrare nel progetto per cogliere alcuni aspetti, che non sono applicabili nella realtà così istantaneamente, anche se logicamente dovrebbero esserlo.
- Trova sempre qual è il valore dell'attività che stai svolgendo. Stai rivedendo le autorizzazioni per "fare ordine", per "migliorare la gestione ordinaria", per "rispondere ad un audit" etc..
- Immaginati una strategia e dividi in "sprint" il percorso, non sempre è possibile fare tutto e spesso non conviene fare tutto assieme. Vedi anche punto 3. Vedere come va può essere utile per migliorare o modificare scelte future.
- Ammetti il fallimento. Sbagliare può è utile e serve anche per sperimentare. Ricordati cosa non ha funzionato per il futuro!
Bibliografia
Ecco dove puoi trovare il libro di riferimento e come partire:
- Scrum: The Art of Doing Twice the Work in Half the Time autore: J.J. Sutherland