Quando si esplorano i diversi prodotti di lavoro, le attività ed i ruoli contenuti in RUP (Rational Unified Process),
ci si potrebbe domandare:
-
Ho bisogno di questo?
-
Come classificare tutte queste voci per stabilire quali siano quelle necessarie per il progetto?
-
Non è ovvio che RUP è adatto solo a progetti grossi?
L'argomento 'personalizzazione' si occupa di tutte queste domande.
Lo scopo di un progetto software è di generare un prodotto. Un buon processo consenta al progetto di creare un prodotto
che soddisfa le esigenze dei suoi stakeholder, nei tempi stabiliti e entro il budget previsto. Per ulteriori
informazioni, consultare l'artefatto: Prodotto.
La chiave per ottenere un buon processo è di personalizzarlo in modo da renderlo il più semplice
possibile, mentre sono sostenuti i Principi chiave.
Nella personalizzazione di un processo devono essere considerate le linee guida qui incluse. Una guida maggiormente
dettagliata viene fornita con Concetto:
personalizzazione di RUP.
Un problema comune a molti progetti è che spesso sono pesantemente focalizzati su una particolare area, fino al punto
da rimanere imbrigliati nei dettagli di quella particolare area, prima di essere sicuri di avere una buona idea di
quali elementi "chiave" siano implicati nel ciclo di vita dell'intero processo di creazione di un prodotto di qualità.
In genere è meglio occuparsi di tutti gli elementi chiave di un processo in maniera leggera, prima di concentrare
pesantemente l'attenzione su una particolare area di problemi.
Una volta pronto il framework per un processo di qualità, un progetto può efficacemente concentrarsi su quella
particolare area che è stata identificata come maggior contribuente ai problemi. Questa selezione si basa
sull'identificazione dei rischi per il progetto e sull'assegnazione di una priorità ad essi, e determinare delle
precoci strategie di mitigazione per i rischi identificati.
Non includere attività o prodotti di lavoro che non possono essere giustificati in modo chiaro
Il bene intenzionato responsabile di progetto o tecnico del processo potrebbero disporre di un lungo elenco di
auspicabili metriche, controlli, report ecc. Tuttavia, le attività ed i prodotti di lvoro costano tempo r denaro.
Alcuni di questi costi, ad esempio l'interazione giornaliera con la serie di tool dell'ambiente, potrebbero essere o
non essere visibile ma essere coinvolti in una inferiore produttività sulle attività standard.
È necessario distinguere le esigenze critiche del processo dall'elenco di voci desiderate e stabilire se i vantaggi
superano il costo.
Proteggere gli sviluppatori dal processo
Probabilmente si ha a disposizione del personale altamente specializzato, con preziosi skill nella progettazione,
implementazione e test. Non lasciare che trascorrano ore ogni settimana a riempire moduli, a migliorare la
documentazione o a lottare tool lenti. Se queste attività sono necessarie, prendere in considerazione di assegnarle a
del personale di supporto qualificato.
Ridurre al minimo i prodotti di lavoro formali intermedi
Il formato dei prodotti di lavoro intermedi (quelli che non intesi per il prodotto finale) non è importante come
l'attività ed il ragionamento necessari a produrli. Non importa il loro aspetto o quali tool si utilizzano per crearli,
a patto che servano allo scopo. Come ha affermato Dwight D. Eisenhower "Il piano non è nulla; la pianificazione è
tutto".
Una trappola in cui è facile ricadere è il formalizzare i prodotti di lavoro troppo presto. Le prime versioni dei
prodotti di lavoro spesso evolvono rapidamente e restano mutevoli per qualche tempo come rappresentazioni diverse,
mentre vengono esplorate le loro implicazioni. La documentazione formale può impedire questo processo; si può perdere
molto tempo a ripulire un prodotto di lavoro largamente espandibile. Nei primi stadi di un prodotto di lavoro spesso
sono sufficienti dei diagrammi tracciati a mano libera e delle semplici descrizioni su schede indicizzate e, per alcuni
progetti, potrebbe essere tutto ciò che è necessario.
Un prodotto di lavoro può essere personalizzato in modo tale da poter essere gestito in qualunque forma. Ad esempio, il
documento Visione può essere catturato come pagina Web, il Piano del progetto come file Microsoft Project e l'Elenco
dei rischi come tipo di requisito di Rational
RequisitePro .
Creare quando possibile
Alcuni progetti spendono tempo a riempire maschere di documenti formali tagliando ed inserendo informazioni
manualmente. Considerare invece di produrre dalla fonte i documenti richiesti, utilizzano tool come Rational SoDA o negoziare un modo più semplice di fornire le stesse
informazioni, ad esempio utilizzando Rational
Rose Publisher per creare un modello di progettazione basato su Web.
In molti casi è possibile saltare del tutto un prodotto di lavoro perché le informazioni vengono fornite implicitamente
nell'ambiente. Ad esempio, piuttosto che generare la sezione del Piano di gestione requisiti che elenca gli attributi
dei tipi di requisiti, è possibile fornire soltanto il progetto personalizzato Rational RequisitePro con i tipi di
requisiti applicabili e la tracciabilità, e in seguito esaminarlo con le parti interessate. Un altro esempio è fornire
alle parti interessate una versione di sola lettura dei file Microsoft Project, piuttosto che duplicare grafici in un
Piano di sviluppo software separato.
Utilizzare Web
Un prodotto di lavoro utile è quello che comunica informazioni preziose. Queste informazioni devono essere a
portata di mano per chi ne ha bisogno. La tecnologia Web è un meccanismo eccellente per questo genere di scopo. Se i
requisiti, la progettazione e l'implementazione sono disponibile su Web, non è necessario creare una grossa mole di
documentazione cartacea, rapidamente obsoleta.
Utilizzare tool integrati
Selezionare i tool adatti al processo e personalizzare il processo per adattarli ai tool. I risultati desiderati sono
un processo ed un insieme di tool entrambi semplice da utilizzare. I tool integrati in genere forniscono maggiore
congruenza e metriche e report più informativi, dei tool non integrati.
Rivedere regolarmente il processo per perfezionarlo e ridurne la complessità. Se il personale non è convinto che ogni
passo del processo fornisca del valore aggiunto al prodotto finale, probabilmente il processo non funziona.
Personalizzare mantenendo le pratiche
RUP incoraggia la personalizzazione. Tuttavia, la personalizzazione non è una licenza per saltare il processo del
tutto. L'essenza di RUP è insita nelle sue pratiche. Seguire lo spirito di quelle pratiche, quando si
personalizzano le attività ed i prodotti di lavoro per soddisfare le proprie necessità.
|