Un cretino

Il collega inglese S.G. è da giovedi scorso ufficialmente un cretino. D’ora in poi poco prima di iniziare una conversazione con lui mi prenderò qualche istante di riflessione in modo da lasciare che il giudizio si formi con chiarezza nella mia mente e crei il contesto necessario alle sue successive affermazioni:”Sto parlando con un cretino”.

Chiunque abbia anche solo una vaga esperienza di progetti IT basati sull’implementazione di una applicazione software sa che per soddisfare un requisito utente è sempre opportuno privilegiare l’adozione di una funzionalità standard già presente nell’applicazione rispetto alla creazione di feature personalizzate: nel primo caso si utilizza una caratteristica del software che (sperabilmente) ha superato determinati test di qualità, non sono richieste ulteriori attività di progettazione, sviluppo, test e documentazione, e se il software è disegnato con un minimo di accortezza ci si deve attendere che tale funzionalità sia preservata nelle future versioni del software.

Anche quando si è costretti a sviluppare una funzionalità personalizzata, qualora essa diventi in seguito parte del software standard (in genere questo accade quando gli architetti dell’applicazione riconoscono che di quella particolare feature beneficerebbe l’intera comunità di utenti ed è quindi opportuno renderla disponibile a tutti), durante la pianificazione della migrazione del sistema alla nuova realease io prenderei in seria considerazione la possibilità di dismettere la versione “custom” della funzionalità e sostituirla con la sua controparte “built-in” perché da quel momento in poi aprofitterei di tutti i vantaggi citati sopra. È evidente che questa considerazione di principio deve essere accompagnata da una valutazione di costi e benefici: se il costo della conversione da “personalizzato” a “standard” è superiore ai benefici a lungo termine derivanti dal passaggio, è bene lasciar perdere.

Giovedi ho dovuto sprecare alcuni minuti del mio prezioso tempo (che sarebbero stati molti di più se non ci avessi dato un taglio brusco) per spiegare a S.G. questo elementare concetto che secondo me avrebbe già dovuto far parte del suo bagaglio culturale. E invece alla fine mi sono persino sentito replicare:”Se la funzionalità personalizzata fa quello che deve e soddisfa il requisito originale perché sostituirla con una standard?”. Per la serie: se funziona non toccare niente, non pensarci nemmeno, è male.

A S.G. non dovrebbe essere consentito di stare lì, nella posizione di responsabilità in cui si trova a propalare idee perniciose che esercitano un’influenza nefasta sulle menti dei nostri giovani business analyst.

Perché?

Perché è un cretino.

Karl Lagerfeld’s design specifications

Original Sketch by Karl Lagerfeld - Special Collections FIT

Se siete sviluppatori di software, la prossima volta che vi arriva sul tavolo un documento di design specifications di, diciamo, difficile interpretazione e non immediata comprensione prima di dare inizio alle vostre “geek lamentations” e infastidire i colleghi business analyst e solution architect riflettete sul fatto che le povere (si fa per dire) sarte che lavorano per i grandi stilisti di moda come Karl Lagerfeld, per esempio, si devono basare su roba come quella qui a fianco per realizzare gli abiti concepiti nella mente dell’Artista.

Bellissimi, splendidi schizzi ma pur sempre schizzi e guai a sbagliare le proporzioni, l’ampiezza del bavero, la lunghezza della manica.

Comunque Karl è un genio è il suo sito internet è uno dei più originali che abbia mai visto.

Poveraccio il web developer…

BABOK v2.0

Il 31 Marzo 2009 è stata rilasciata la BABOK (Business Analysis Book Of Knowledge) v2.0. I membri della IIBA la possono scaricare gratuitamente dal sito dell’associazione mentre i non iscritti possono acquistarla per 29.95 USD.

L’esame per la certificazione CBAP (Certified Business Analyst Professional) continuerà a essere basato sulla BABOK v1.6 fino al 31 Luglio 2009, dopodiché seguirà la versione 2.0.

La presentazione SlideShare qui sotto vi spiega quali sono i passaggi necessari per candidarsi all’esame CBAP.

Perché mi rallegro #11

Superato anche il terzo esame per la certificazione BACP: Writing and Managing Requirements Documents.

Punteggio: 30/30

A maggio il quarto e ultimo corso: Business Process Modeling.

Business Analyst Certification Program

IIBA® is a registered trademark owned by International Institute of Business Analysis.

Ho iniziato un paio di mesi fa il percorso di certificazione per Business Analyst offerto dall’ International Institute for Learning: Business Analyst Certification Program (BACP).

Il corso verte sul contenuto del Business Analysis Body of Knowledge (BABOK^® v1.6, sta per uscire la v2.0), l’equivalente della PMBOK dei project manager. Tuttavia la certificazione BACP non è equivalente alla certificazione Project Manager Professional  e per diventare un business analyst professionista occorre acquisire la certificazione CBAP^® (Certified Business Analyst Professional) fornita dall’International Institute for Business Analysis (IIBA^®) (sorta di equivalente del Project Management Institute) attraverso un esame simile a quello richiesto per i PMP.

La spina dorsale del percorso di apprendimento è costituita dalle 6 Knowledge Areas della BABOK^®:

• Enterprise Analysis (EA)
• Requirements Planning and Management (RP&M)
• Requirements Elicitation (RE)
• Requirements Analysis and Documentation (RA&D)
• Requirements Communication (RC)
• Solution Assessment and Validation (SA&V)

La versione mind map delle knowledge areas e dei relativi task la trovate qui: BABOK^® Knowledge Areas

Il programma BACP si articola in 4 corsi:

• Business Analysis Fundamentals: 12 ore (se siete già PMP, dà diritto a 12 PDU)
• Facilitation Skills: 18 ore (18 PDU)
• Writing and Managing Requirements Documents: 12 ore (12 PDU)
• Business Processes Modeling:18 ore (12 PDU)

I corsi si seguono online attraverso il meccanismo delle virtual classroom che devo riconoscere essere piuttosto efficace.

Ogni corso è seguito da un esame della durata di un’ora da effettuarsi online entro trenta giorni dal completamento del corso corrispondente: 30 domande sul contenuto del corso, della BABOK^® e su situazioni da analizzare.

Ho superato il primo esame due settimane fa (punteggio 28/30).

Il Business Analyst non coincide esattamente con il ruolo di Solution Architect, presente nella nostra organizzazione, che si fa carico di trasformare i requisiti in una soluzione software nell’ambito di un progetto. Il BA è invece la figura preposta a far emergere, documentare, mantenere, verificare e validare i requisiti ed è più coinvolto nel Product Life Cycle (PdLC) più che nel Project Life Cycle (PLC).

Tuttavia, le conoscenze, tecniche e best practices del ruolo del BA sono un prezioso strumento anche per una figura di Solution Architect come la nostra. Sullo sviluppo di queste pratiche penso che baserò gli obiettivi del team per l’anno prossimo. Salvo cataclismi…

Bazzicando il sito dell’International Institute for Business Analysis mi sono imbattuto nel blog del loro istituto, molto interessante per gli addetti ai lavori.

Lo trovate qui: http://blog.theiiba.org/