IT Management blog

Purtroppo saro' all'estero fino al 4 Dicembre per un corso di (indovinate un po'?) ITIL Service Management (ne avevamo parlato un po' di post fa'...).

Se mi sara' possibile provero'a scrivere anche da li' senno' a risentirci a fra una settimana...

Se vi affidano un progetto di sviluppo software e potete comprare un solo libro, fate che sia questo:

Software Project Survival Guide
di Steve McConnell
Edizione Paperback: 250 pagine
Casa editrice: Microsoft Press, U.S. 
Lingua Inglese
ISBN: 1572316217
Link ad Amazon.co.uk...

L'autore e' un nome ben noto nel campo dello sviluppo software (e' anche autore di "Code Complete" e "Rapid Development" tra gli altri).

L'autore non si affida ad una particolare metodologia di Project Management (PMBOK, PRINCE2 o altro) ma innaffia con fiumi di buon senso i lettori. Rispetto alle metodologie di sviluppo software, l'autore sposa in pieno il metodo delle "staged delivery", ma anche se non si fosse di quella religione, il libro rimarrebbe senz'altro utile. Il difetto principale di questo libro e che non cita nessuna delle metodologie consolidate (RUP, UML), pur usandone in alcuni casi i concetti.

Nel post precedente abbiamo parlato (brevemente) del Problem Management secondo ITIL. Accenniamo ad alcuni aspetti pratici in questo post.

Da dove partire per implementare il Problem Management? Innazitutto e' fondamentale che il processo di Incident Management sia implementato (vedi qui e qui) in quanto fornisce gli input al processo:

• Dettagli sugli incidenti occorsi, categorizzati opportunamente per poter essere analizzati
• Eventuali workarounds gia' identificati nella risoluzione degli incidenti (i workaround possono essere sviluppati dal problem management, ma spesso vengono anche sviluppati nell'incident management)

Altri punti da tenere presente sono i seguenti:

• I tecnici addetti all'incident management devono avere accesso alla lista aggiornata dei Known Errors (Known Errors Database), che include anche i workaround, in modo da poter risolvere tutti gli incidenti correlati in modo rapido. In questo modo, l'implementazione del Problem Management aiuta ad ottimizzare il processo di Incident Management
• Le informazioni su ogni incidente vanno collegate al problema corrispondente. Questo aiuta a dare visibilita' dell'impatto di ogni problema (quanti incidenti sono generati dal singolo problema) e quindi a definirne la priorita' E' utile che questo meccanismo di prioritizzazione sia in qualche modo automatizzato, in modo che i problemi a piu' alta priorita' (che causano la maggior parte degli incidenti) siano affrontati prima.
• Idealmente le persone che si occupano dei problemi devono essere diverse da quelle che si occupano di incidenti, perche' diverso e' il target (utente finale vs. infrastruttura). La stessa persona puo' occuparsi di entrambi solo se ha molto chiara la differenza tra i due.
• Non sempre e' facile capire la "root cause" degli incidenti, spesso questa e' la fase piu' delicata del processo di Problem Management a monte della determinazione che il problem e' un Known Error. Questa parte si puo' dividere nelle seguenti fasi:
• • Definizione del Problema. Gli incidenti, essendo visti dal punto di vista dell'utente possono avere una definizione completamente diversa dal problema. Per esempio, una connessione di rete configurata male potrebbe generare incidenti di tipo "errore nella stampa" se quella connessione serve un print server. In questo senso una corretta definizione puo' gia' essere fondamentale nel trovare la soluzione.
  • Stabilirne le Cause. In questa parte possono essere utili delle metodologie formali per la "root cause analysis" quali quelle di Kepner and Tregoe oppure di Ishikawa (i famigerati diagramma a lisca di pesce).

Un ultimo aspetto da tenere presente e' che per un processo di Problem Management efficiente e' necessario avere una fotografia dell'infrastruttura IT che si presti ad una analisi strutturata. Questa "fotografia" viene generata nel processo di Configuration Management, di cui diremo in un post successivo...

Abbiamo fatto riferimento al processo di Problem Management quando abbiamo parlato di ITIL in generale (qui) e ne abbiamo accennato in relazione al processo di Incident Management in ITIL (qui).

L'obiettivo del Problem Management e' di minimizzare l'impatto sul business degli incidenti (vedi qui per la definizione) e dei problemi causati da errori nell'infrastruttura IT, e di prevenire la ricorrenza di tali incidenti. Per poter raggiungere questo obiettivo, il Problem Management cerca di determinare la "root cause" (causa ultima) degli incidenti, e focalizza la propria attenzione a migliorare o correggere queste situazioni.

La differenza con l'incident management e' evidente. Mentre l'incident management e' focalizzato all'utente, qui e adesso, il problem management e' focalizzato all'infrastruttura nel lungo termine.

Il problem management ha degli elementi di reattivita' ed altri di proattivita'. E' reattivo nel senso che i problemi possono rendersi evidenti dal moltiplicarsi degli incidenti. E' proattivo nel senso che e' possibile (consigliata) l'identificazione dei problemi prima che generino incidenti.

Il processo di Problem Management ha bisogno di un processo di Incident Management ben implementato che fornisca gli input di cui ha bisogno (incidenti) in forma strutturata ed analizzabile.

Le attivita' di Problem management includono: 

• Controllo dei Problemi (problema e' la causa di uno o piu' incidenti)
• Control degli Errori (un problema diventa errore se la causa ultima e' nota o se esiste un workaround)
• Prevenzione dei Problemi (Problem Management proattivo)
• Creazione di Workarounds

Le informazioni relative ai problemi ed errori (Known Error Database) vengono gestite dal processo di Problem Management. Queste informazioni sono utilissime al processo di Incident Management.

I benefici del Problem management sono i seguenti:

• Miglioramento della qualita' del servizio IT 
• Riduzione del volume degli incidenti
• Risoluzione permanente dei problemi
• Possibilita' di ottimizzare il processo di organizational learning

In un post successivo analizzeremo il Problem management nella pratica....

Survey effettuata su 127 specialisti di IT service management su ITIL:

Il 77% cita la qualita' del servizio come il driver principale di progetti di implementazione ITIL. Il 55% cita l'allineamento dell'IT al business.

Solo il 32% degli intervistati dice che la loro organizzazione ha una strategia formalizzata su ITIL.

Il 72% degli intervistati cita la resistenza dell'organizzazione come barriera all'implementazione di ITIL, mentre il 34% non sa da dove iniziare.

Fonte: Evergreen Systems Inc., 2006 ITIL Benchmark Assessment

1. Un progetto pianificato male impiega circa tre volte la durata prevista, mentre uno pianificato secondo le best practices del project management solo il doppio....

2. Non ci sono project manager bravi, ma solo project manager fortunati...

3. I project manager che hanno studiato non le chiamano scuse, le chiamano metriche...

4. Ci sono due tipi di software: il software che non funziona e la prossima release...

5. Piu' tempo ci metti a fare reports su cio' che stai facendo, meno tempo hai per fare le cose che dovresti. Si raggiunge la stabilita' quando si impiega tutto il tempo a fare reports sul nulla che si fa (legge di Cohn)...

Abbiamo accennato al Project Office in un post precedente, ne parliamo brevemente in questo post.

Il Project Management Office (PMO), e' un ufficio che centralizza e coordina la gestione del progetti in un organizzazione. Il PMO, spesso, si occupa della pianificazione coordinata dei progetti e dell'assegnazione di priorita' (Project Portfolio Management, ricordate?...) ed al loro collegamento agli obiettivi dell'organizzazione.

Molto spesso, nella realta', i PMO si limitano a definire degli standard interni di modalita' e tecniche di gestione dei progetti e a controllarne il rispetto. Quest'ultima interpretazione e' pero' riduttiva rispetto ai potenziali vantaggi che un PMO puo' dare ad una organizzazione.

Le responsabilita' di un PMO possono includere le seguenti:

• Condivisione e coordinamento delle risorse su tutti i progetti
• Identificazione degli standard aziendali per la gestione di progetto
• Controllo delle metriche di tutti i progetti (tempi e costi principalmente)
• Coordinamento degli standard di qualita' dei progetti
• Gestione centralizzata dei rischi (che a volte possono essere condivisi tra piu' progetti)
• Tutoring ai project manager

Il beneficio che un PMO puo' dare all'organizzazione e' quello di vedere le problematiche dei progetti da un punto di vista piu' alto, mentre il Project Manager e' tipicamente focalizzato al successo del proprio progetto. In alcuni casi il PMO potrebbe sacrificare un progetto (in termini di risorse per esempio) per diminuire i rischi in un altro progetto piu' strategico.

Il Center for Business Practices (CBP) ha condotto uno studio sullo stato del project management nel 2006, intervistando 364 professionisti di Project Management in organizzazioni che hanno concluso un totale di 16.110 progetti nei 12 mesi precedenti.

Nelle interviste si e' evidenziato un miglioramento del 20% sul successo dei progetti, della customer satisfaction e qualita' di progetto. La produttivita', i costi, e la qualita' dei requirements sono invece migliorati del 10%.

Un altro elemento di progresso evidenziato e' che poco piu' di un terzo delle organizzazioni contattate ha implementato una struttura di project office che copre tutta l'organizzazione, mentre solo il 14,5% dice di non avere un project office (parleremo di project office in un post successivo). Tre anni prima, nel 2003, solo il 22% aveva una struttura di project office che copriva tutta l'organizzazione, mentre il 55% non ne aveva proprio.

Il 68% delle risposte evidenziava una visione positiva del project management, mentre il rimanente 32% lo considerava un mera funzione amministrativa o, peggio, un costoso livello di burocrazia aggiuntivo.

In un post precedente parlavo di Incident Management in ITIL, e promettevo di parlarne in modo un po' piu' pratico in un post successivo. Ne parlo qui.

Se volessi implementare l'Incident Management nella mia organizzazione, cosa dovrei fare? Alcuni punti dal quale iniziare, senza pretesa di completezza, sono i seguenti:

• Assicurarsi della volonta' dell'organizzazione di farlo (cio' che gli anglosassoni chiamano "management commitment"). E se la volonta' non c'e', puo' essere utile vendere i vantaggi dell'incident management al management (vedi post precedente per i benefici) in modo da convincerli
• Implementare il Service Desk nella propria organizzazione (vedi post relativi qui e qui) 
• Assicurarsi che ci siano risorse umane dedicate all'incident management. Eventualmente le risorse umane possono anche ruotare tra incident management ed altre attivita', tenendo pero' presente che gli skill potrebbero diluirsi eccedendo con la rotazione.
• Formare le risorse umane a comprendere il processo di incident management e le relazioni con altri processi ("process awareness")
• Mettere l'utente al centro del servizio. Questo e' un'atteggiamento mentale che deve essere comune a tutte le risorse umane impiegate nei processi di Incident management. Da non sottovalutare.
• Creare una knowledge base condivisa per la risoluzione degli incidenti. Per evitare che la knowledge base rimanga un corpo estraneo al processo e' necessario che 1. la consultazione della knowledge base faccia parte del processo (il tecnico dovrebbe consultarla come prima azione per vedere se incidenti simili sono gia' successi e come sono stati risolti) e che 2. la knowledge base venga aggiornata come risultato del processo (ogni volta che un incidente non capitato prima viene risolto, la soluzione andrebbe registrata sulla knowledge base)
• Avere un tool software di assegnamento/tracciamento degli incidenti che implementi il processo. Il tool deve essere parte della knowledge base (i tecnici devono avere accesso a tutti gli incidenti per poter vedere le soluzioni gia' implementate).
• Formalizzare le procedure di incident management e formare il personale su quelle procedure (ne parliamo piu' in basso).

 Tipici aspetti da formalizzare sono i seguenti:

• Definire i livelli di servizio da rispettare (andrebbero negoziati con gli utenti/clienti) per ogni tipo di incidente.
• Definire le priorita' degli incidenti in base a criteri obiettivi (matrice urgenza/impatto)
• Monitorare i livelli di servizio in maniera periodica (giornaliera o almeno settimanale)
• Formalizzare accordi con gruppi esterni qualora gli incidenti vadano scalati (OLA o Operating Level Agreement)
• Definire il ciclo di vita degli incidenti per evitare che vi siano "zone morte" in cui non si sa chi e' responsabile.

E' da tenere presente che il processo di incident management ha forti relazioni con altri processi (Problem Management e Configuration management tra gli altri), ma di questo diremo piu' in la'

L'IT, come tutte le esperienze umane, vive di marchi e di simboli. Uno di questi nomi che risuona negli ultimi anni e' "agile", inteso come Gestione di progetti "agile" e sviluppo software "agile".

Questo nome, associato ai progetti software, nasce nel 2001, quando un gruppo di "praticanti" di nuove religioni di metodologie di sviluppo software decisero, sulla base di innumerevoli esperienze, che era fondamentale l'interazione tra sviluppatori e "business experts". Questo gruppo ha creato un Manifesto per lo sviluppo "agile".

In essenza, il credo di questo nuovo modo di vedere i progetti di sviluppo software e' stato sintetizzato come segue (liberamente tradotto):

• Gli individui e le interazioni piu' che processi e gli strumenti
• Software funzionante piu' che completa documentazione
• Collaborazione con gli utenti piu' che contratti
• Rispondere ai cambiamenti piu' che seguire i piani

In pratica, nonostante si riconosca l'importanza degli elementi a destra nelle frasi riportate, si ritengono piu' importanti quelli a sinistra.

Wikipedia describe le metodologie Agili nel modo seguente:

La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppando il software in finestre di tempo limitate chiamate iterazioni che, in genere, durano qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del software: pianificazione (planning), analisi dei requisiti, analisi, implementazione, test e documentazione.

Anche se il risultato di ogni singola iterazione non ha sufficienti funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delle iterazioni, deve avvicinarsi semprè di più alle richieste del cliente. Alla fine di ogni iterazione il team deve rivalutare le priorità di progetto.

I metodi agili preferiscono la comunicazione in tempo reale, preferibilmente faccia a faccia, a quella scritta (documentazione). Il team agile è composto da tutte le persone necessarie per terminare il progetto software. Come minimo il team deve includere i programmatori ed i loro clienti. (con clienti si intendono le persone che definiscono come il prodotto dovrà essere fatto. Possono essere dei product manager, dei business analysts, o veramente dei clienti)

Cio' che cambia, ed e' una sorta di rivoluzione copernicana, e' l'obiettivo: la piena soddisfazione del cliente e non solo l'adempimento di un contratto.

Le metodologie agili servono a diminuire significativamente i costi di sviluppo del software e a ridurre al minimo la parte di progettazione (spesso la piu' costosa). Queste metodologie, quindi, rivoluzionano i vecchi sistemi di ingegneria del software (modello a cascata, modello a spirale, etc.), basati su una raccolta formale delle specifiche e su un processo strutturato dello sviluppo software. Queste metodologie non vedono le specifiche come un elemento fisso, ma ne colgono l'aspetto reale del cambiamento, le necessita' degli utenti di fatto spesso cambiano e/o si chiariscono meglio con l'avanzare del progetto. Le metodologie Agili consentono di rivedere di continuo le specifiche e di cambiarle durante lo sviluppo mediante un forte scambio di informazioni e di pareri con il committente.

Tra queste metodologie vi sono le seguenti:

• Extreme Programming
• SCRUM
• Feature Driven Development
• DSDM
• Crystal
• Lean Software Development