A career as a Cobol programmer might not be as sexy as slinging Java code or scripting in Ruby, but if you buckle down and learn hoary old Cobol, you could land one of the safest, most secure jobs in IT.
Analyst reports indicate that Cobol salaries are on the upswing. The language is easy to learn, there's a healthy demand for the skills, and offshore Cobol programmers are in short supply -- plus, the language itself holds the promise of longevity. All that loose talk about mainframes going away has subsided, and companies committed to big iron need Cobol pros to give them love.
Il Critical Chain Method (CCM) trova le sue origini a partire da un libro scritto nel 1984 da Goldratt ("The Goal" – edizioni Gower) e trova i suoi punti di forza nel fatto che propone delle soluzioni ai classici problemi che si incontrano quando si pianifica seguendo l'approccio più classico del Critical Path Method (CPM).
Di fatto il CCPM (critical chain Project Management) è un mix delle best practices che si possono trovare nelle seguenti teorie:
PMBOK: Pianificazione e controllo.
TOC (Theory of Constraints): Rimozione dei colli di bottiglia per risolvere i vincoli di sistema.
Lean: Eliminazione dello spreco.
Six Sigma: Riduzione delle variazioni dall’ottimo.
I maggiori problemi che il CCM si propone di risolvere sono i seguenti:
Over estimating: le stime, quando fatte, sono sempre in eccesso
Questo problema è un classico nella definizione dei piani di lavoro. Spiegato in breve, poiché si sa che:
- le stime spesso vengono tagliate - spesso, all’inizio di un progetto, i dettagli non sono chiari
per ovviare a questi problemi si tende sistematicamente a sovrastimare i task con maggiore incertezza, in modo crearsi delle contingency, nel caso in cui le cose vadano male. Questo processo è solitamente amplificato man mano che le stime sono presentate a diversi stackeholder e genera alla fine una sovrastima del costo/durata del progetto.
Student Syndrome: Spesso si inizia a lavorare duramente solo verso la fine del task.
Si tratta di un problema generato da schedulazioni troppo generose o da progetti molto lunghi: in genere succede che si inizi a lavorare su un task non quando è schedulato il suo inizio ma quando si avvicina la scadenza dello stesso. I motivi sono spesso sia legati agli altri punti che presenteremo in seguito (multitasking, parkinson law) sia semplicemente psicologici: sino a che non si sente la pressione non si inizia a lavorare.
Parkinson’s Law: Il lavoro si espande sino a utilizzare tutto il tempo disponibile.
In questo caso si tratta di una famosa legge empirica nel Project Management. Detto in altre parole la legge afferma che se noi per un task che dura 10 giorni ne assegniamo 15, succederà difficilmente che il lavoro venga completato in 10 giorni, ma "magicamente", verrà concluso in 15. Non sto a dilungarmi sulle motivazioni della legge, ma le evidenze sperimentali sono più che note.
Nella preparazione di un articolo sulla CCM (critical chain Management) ho raccolto (da un articolo inglese) una checklist di suggerimenti che mettono assieme principi della TOC (Theory of Constraints) del Lean e dell'agile, che vale la pena di avere sempre sott'occhio nelle fasi di pianificazione e gestione progetto:
Eliminate Safeties from Each Task
Management Must Not Insist on Each Task Starting & Finishing “On Time”
Stagger Tasks in the Schedule Using Finish to Start Constraints
Start Right Jobs at Right Time Using Prioritized Task List
Focus on Meeting Milestone Dates, Not Task Dates
Single Integrated Schedule
Update Official Schedules Daily with Actual Starts, Remaining Duration, & Actual Finishes
Predict Milestones Based on Buffer Penetration
Focus on Task Throughput, NOT on Task Costs
Counter Parkinson’s Law
Conserve Available Float/Slack on Each Task, Reduce Time Available
Counter Student Syndrome
Start Each Task As Early As Possible
Claim Early Finishes Immediately
When Problems Occur, Solve the Problem vice Starting New Task
Decrease Frequency & Duration of Meetings
Resolve Conflicts Immediately at the Jobsite
Eliminate Bad Multi-tasking
Resources Focus on One Job at a Time, Work to Completion
Keep WIP Low!
Request Only Resources Necessary to Accommodate Priority Work
Request Only Overtime Necessary to Recover Buffer on Priority Work
Move Resources When Work is Done to Next Priority Work Quickly
Work Right Jobs instead of Easy Jobs
Plan for New Work & Scope Changes vice Complaining About it
Ultimo aggiornamento Mercoledì 22 Dicembre 2010 16:20
Sviluppo di una vision condivisa
Scritto da Administrator
Lunedì 01 Febbraio 2010 17:27
Questo articolo idealmente continua l'articolo in cui trattavo i punti di attenzione principali quando si cambia ambiente di lavoro, ma lo specifica al caso in cui ci venga assegnato un team di professionisti IT. Qui vorrei trattare dell'importanza della creazione di una vision, un'idea, un punto di arrivo che ci indichi che cosa si vuole raggiungere con questo team.
Non vorrei sembrare americano o banalizzare troppo il concetto: la creazione di una propria vision è fondamentale e si tratta di un processo lungo che coinvolge sia aspetti personali (che cosa mi da la maggiore soddisfazione nel mio lavoro) che aspetti professionali (dove voglio arrivare). In aggiunta, tale processo non è statico, ma nell'evoluzione della carriera è soggetto a dei cambiamenti come reazione ad stimoli o semplicemente a una crescita personale.
La propria vision deve essere frutto di una riflessione personale, che ci costruiamo durante e a seguito dell'analisi della situazione in cui lavoreremo.
Ma ciò non basta. La propria idea di cosa si sarà “da grandi” deve essere condivisa dal gruppo di lavoro e (cosa difficile) non deve essere in contrasto con quella più generale dell'azienda. Per questo motivo alla fase di elaborazione personale deve seguire una fase di confronto prima con i propri superiori e poi con i propri collaboratori.
Una buona pratica può essere quella di discutere prima con i propri responsabile e poi tenere una o due sessioni di brainstorming, in modo da coinvolgere le persone e successivamente chiudere con decisioni e un impegno preciso a perseguire gli obiettivi.
Ultimo aggiornamento Lunedì 06 Settembre 2010 11:25
Exit Criteria
Scritto da Administrator
Venerdì 11 Dicembre 2009 21:19
Ogni progetto ha un inizio ed una fine.
Questo significa che ci saranno dei criteri da soddisfare per iniziare una fase, ma che ci saranno dei criteri specifici anche per considerare la fase completata.
Molto spesso ci preoccupiamo di cosa ci serve per iniziare (entry criteria), ma non ci curiamo abbastanza dei criteri necessari per segnare una fase come chiusa (exit criteria), a meno che non siano specificati nel contratto (e a volte anche se sono specificati nel contratto...).
Non essere in credo di rispettare o non essere in grado di chiudere correttamente gli exit criteria spesso causa problemi alle fasi successive, o anche peggio se team diversi sono coinvolti nel progetto: ad esempio se il team di sviluppo passa il controllo al team che si occuperà della manutenzione è molto importante che la documentazione soddisfi dei criteri ben definiti in termini di qualità e completezza. Se questo non accade anche la modifica più semplice richiederà l'analisi del codice sorgente, che, come risaputo, è una pratica poco efficiente.
Ultimo aggiornamento Venerdì 10 Settembre 2010 11:47
Organizzazione di un team IT
Scritto da Administrator
Sabato 06 Febbraio 2010 16:40
In questo articolo, che continua la serie degli articoli riferiti al cambio di lavoro/team/progetto, vorrei elencare una serie di azioni pratiche da valutare nel momento in cui si assume la guida di un nuovo team. Non mi sono concentrato sulle attività di pianificazione quanto sugli aspetti più soft, che si apprendono solo con l'esperienza.
L'articolo, per rimanere breve, si sviluppa come una check-list. Nel seguito, se necessario le varie tematiche saranno trattate in articoli singoli.
I contenuti sono orientati ad un team che deve sviluppare software, ma spero sarà possibile trarne spunti positivi anche per team coinvolti in altri campi.
Se siamo coinvolti in un progetto o ne dobbiamo assumere la responsabilità, cerchiamo di reperire tutte le informazioni possibili e soprattutto di verificare i contenuti del contratto (milestones, deliverables, SLA, exit criteria per il lavoro, aree di responsabilita ... ). Spesso infatti l'ignoranza di clausole o semplicemente di paragrafi del contratto porta a conseguenze disastrose.
Creiamo immediatamente un log delle attività/task da realizzare. Con un log di attività pregresse riusciamo subito ad avere una idea, magari imprecisa della situazione che stiamo affrontando. Un buon punto di partenza, di solito è il piano di lavoro (se esiste) ma anche le interviste con i membri del team o altri stakeholder (stando attenti a evitare di aggiungere deliverables che non sono nello scopo del progetto). Attenzione il piano di lavoro (o ancora meglio il project management plan) fa parte di una metodologia ben definita e deve sempre esistere, ma quello che dobbiamo fare qui è passare dalle attività presentate in un documento, a un controllo di cosa stiamo facendo e di cosa faremo a breve.
Definiamo gli obiettivi del nostro lavoro. Se siamo in assenza di piano di lavoro è importantissimo crearne uno. In caso contrario, data la vision e il backlog del lavoro, dovrebbe essere semplice definire gli obiettivi a breve e medio termine. Attenzione gli obiettivi dovranno essere documentati e accettati dal team e dai propri superiori.
