Monday, February 13, 2006 

Corso Software Project Management

Ho finalmente messo online il programma del mio corso Software Project Management. Come si evince dal nome :-), il corso e' dedicato al PM di progetti software, che non sono progetti come gli altri.
Oltre al programma, trovate alcuni cenni al corso in un mio post di ottobre, ed alcuni cenni (ed altri riferimenti) ad argomenti comunque correlati in un post di novembre.

Labels: , ,

Comments:
Caro Carlo, ti "curo" ormai da tempo su questo argomento e ora che hai pubblicato il programma del corso ho una domanda: tutti gli argomenti elencati sono presenti per dare un'overview il + completa possibile sul tema (senza particolari preferenze) oppure perche' le consigli tutte a seconda dei contesti?

Riassumendo e semplificando: c'e' una linea che consigli a dispetto delle altre (leggendo il blog direi di si...)?

C'e' una parolina che ancora non ho letto nei tuoi post anche se la maggior parte di quello che scrivi (e che condivido) riporta a quelle idee.... :-D
 
Marco, chissa' se ho capito :-)))

In generale, un aspetto a mio avviso errato di gran parte dei metodi che vedo proposti dai vari guru di turno e' il desiderio di essere applicabili ad ogni tipo di progetto.
Uno dei fondamenti del corso e' invece che in progetti diversi, e talvolta [spesso] in momenti diversi nella vita di un progetto, occorre usare approcci diversi. Da cui l'utilita' di introdurre alcuni concetti (progetti dog / skunk / colt / cow / bull, ignorance orders, ecc) per cercare di capire il tipo di progetto che dobbiamo affrontare e quindi come affrontarlo.

Un altro caposaldo e' che non si diventa bravi manager solo perche' si e' [stati] bravi tecnici, ma che occorre acquisire conoscenze specifiche. Da cui l'enfasi su alcuni argomenti (pianificazione dinamica, negoziazione, ecc, ma anche dinamiche sociali, con ispirazioni varie da Weinberg).

Un altro aspetto ancora e' che per evitare la sindrome del SuperLeader (sempre di Weinberg) ci servono strumenti di monitoraggio che non richiedono al manager di entrare nel microdettaglio del codice. E cosi' via.

In genere le tecniche sono piu' o meno fondamentali in funzione del tipo di progetto. In un dog / skunk, non faremo grande uso delle Slip Chart, in un Bull sicuramente si.
Sinora non ho trovato aziende che sviluppano solo progetti che ricadono in una sola categoria, e che quindi possono essere affrontati tutti nello stesso modo. Ne ho viste molte che ci provano :-), ma non dovrebbero.

Poi lo sai :-D che io non condivido, in senso assoluto, alcuni valori fondamentali di XP. Credo invece che nei progetti / momenti opportuni, una certa agilita' faccia bene, cosi' come che in tanti altri, una pianificazione ed un design accurato siano una vera e propria necessita'...

Sono andato vicino a risponderti? :-D
 
Carlo,

si, ci sei andato vicino :-)

Pero' ancora non mi do per vinto perche' tutto quello che dici e' corretto ed un "caposaldo" degli approcci agili che sono adattivi per definizione e riconoscono l'assoluta stupidita' di un approccio universale quindi devo pensare che qualcosa che hai letto/sentito fosse sbagliato e ti ha lasciato un'idea distorta.

Posso dire che concordo al 100% con quanto Armour scrive nei capitoli 6 e 7 del suo libro :-D
 
Non so se vale :-). E' un po' come dire che il RUP e' cosi' generale che anche XP e' RUP. Si puo' fare, ma non vale :-).

Provo a dirlo in modo piu' netto :-) anche per gli altri che leggono, visto che noi due un pochino ne abbiamo gia' parlato in altre occasioni.
Ci sono progetti dove a mio avviso e' fondamentale passare una grande quantita' di tempo a capire quello che serve realmente all'utente invece di realizzare le sue "storie" [pun intended :-)], poi a progettare con grande cura una architettura in grado di reggere gli sviluppi futuri [e quindi pensare per bene anche agli sviluppi futuri, perche' in tanti casi si puo' prevedere un ragionevole futuro], poi dedicare tempo ad una progettazione di dettaglio sempre mirata a reggere bene modifiche ed estensioni future, e poi ovviamente passare ad una realizzazione value-driven + risk-driven, quando ci si riesce, perche' magari ci sono parti infrastrutturali che valore ne danno poco ma sono fondamentali.
Progetti dove ha molto senso investire in artefatti che non siano codice (quindi tipicamente modelli), tenendoli separati dal codice e tenendoli vivi perche' quello e' il nostro strumento ideale per pensare.

Se mi dici che anche questo e' agile, allora si, suggerisco sempre metodi agili :-). Pero' non so se vale :-).

Cio' che sicuramente e' vero e' che in diversi casi, a fianco di quanto sopra, suggerisco di condurre alcuni esperimenti in ottica skunk, per risolvere alcuni elementi di rischio, ma poi i risultati con ogni probabilita' li uso per migliorare l'architettura, non per fare una early release...
Ma ripeto, questo vale per certi progetti, non certo per tutti.

A latere: prendendo ad esempio XP (non so se vale dirmi che non e' agile :->, anche se ovviamente agile != XP) a me non sembra cosi' adattativo come dici. Anzi, le sue pratiche sono molto ben definite, e tutto sommato parecchio rigide!! E' agile nel senso che si adatta molto a variazioni nei requisiti, ma non e' agile nel senso di adattare le pratiche al variare del progetto. Poi magari le cose scritte da Kent Beck sono sbagliate e mi hanno lasciato un'idea distorta :-)).

Faccio fatica a concludere :-) perche' sarebbe un argomento ampio... ma giusto per dire almeno un'altra cosa: io non amo sposare un singolo approccio, non amo gli "ismi" e di conseguenza sto un po' lontano dagli "isti" :-). Pratico tante cose, ognuna delle quali ha un nome, ma non voglio / posso dare un nome all'insieme [dinamico] delle cose, e nel fare questo "chiuderle" in un unico metodo od approccio.
Provocazione: come puo' una disciplina essere agile una volta che si e' definita e strutturata come disciplina? :-))) [con grande disciplina :-) evito un profluvio di citazioni dal Tao Teh Ching :-)]
 
La società dove lavoro produce software scientifico, abbiamo seguito questo corso tre mesi fa ed è stato utilissimo. Ha cambiato persino il modo in cui parliamo tra noi! Abbiamo ancora tanta strada da fare ma almeno sappiamo dove e come migliorare.
Con noi però ha trattato anche altri argomenti, come la value proposition, che non ho visto nel programma
 
Fabio:
e' vero, con voi ho "divagato" anche su altri argomenti che prima o poi trovero' modo di introdurre in modo armonico nel programma "ufficiale". D'altra parte voi avevate gia' seguito il corso sulla stima, quindi su parte del programma siamo andati piu' veloci. E di quell'argomento c'era un gran bisogno :-) nell'ottica dei cambiamenti in corso...
 
Non so se vale :-). E' un po' come dire che il RUP e' cosi' generale che anche XP e' RUP. Si puo' fare, ma non vale :-).

si con la differenza che RUP e' top-down (parti con tutta questa roba e pian piano, se proprio necessario, toglie cio' che non serve) mentre un approccio agile e' bottom-up (parti con il minimo indispensabile, e magari anche qualcosa meno, e aggiungi pian piano, se proprio necessario, quello che serve). Quindi dal mio punto di vista e' RUP ad essere talmente generale da perdere significato proprio perche' cerca di coprire ogni possibile soluzione :-)

Provo a dirlo in modo piu' netto :-) anche per gli altri che leggono, visto che noi due un pochino ne abbiamo gia' parlato in altre occasioni.

sempre troppo poco!

Ci sono progetti dove a mio avviso e' fondamentale passare una grande quantita' di tempo a capire quello che serve realmente all'utente invece di realizzare le sue > "storie" [pun intended :-)], poi a progettare con grande cura una architettura in grado di reggere gli sviluppi futuri [e quindi pensare per bene anche agli sviluppi futuri, perche' in tanti casi si puo' prevedere un ragionevole futuro], poi dedicare tempo ad una progettazione di dettaglio

ecco, se fino a qualche anno fa pur avendo gia' adottato un apporccio agile avrei concordato con te data la mia attuale esperienza mi sento di dire, IMHO, no :-D
In questo momento sto' "gestendo" un progetto con un team composto da 36 persone, settore bancario (quindi una ventina di mainframe/legacy AIX/DB2 con cui interfacciarsi) in modo assolutamente Agile. Pair programming, TDD, refactoring, iterazioni di 1 settimana, continuous integration (quella vera ad ogni check-in con check-in anche ogni 10 minuti, non quella di Microsoft "una volta al giorno" ;-p), automated acceptance tests, etc, etc con scrittura delle user storie assolutamente just-in-time e con questo intendo dire che le narrative delle storie (qualche dettaglio, acceptance test, happy path, etc, etc) vengono scritte dai business analyst e QA guys insieme al cliente la settimana prima che le storie vengano implementate.
Ok, ho dovuto lasciare l'Italia per avere la liberta' di lavorare in questo modo pero lo stiamo facendo e da i risultati voluti.

Certo questo non significa che OGNI progetto possa essere portato avanti in questo modo ma l'unico vero limite che oggi vedo a questo approccio sta' nella cultura aziendale del cliente e da quanto questo sia disposto ad essere davvero pragmatico. Ci si aspetterebbe che una banca sia uno dei posti + difficili da affrontare in questo modo e invece quando mostri misurazioni e metriche aggiornate settimanalmente in cui il dato che mostri e' il ROI, quindi business piuttosto che SLOC, le banche sono le prime a svegliarsi :-D

tenendoli separati dal codice e tenendoli vivi perche' quello e' il nostro strumento ideale per pensare.

mmmmm ni. Se un modello mi aiuta davvero a pensare/comunicare/discutere allora ben venga (rimanendo nei limiti dei "modelli che parlano" ;-D) ma quando ho finito di usarlo lo butto via, non ci spendo del tempo per mantenerlo vivo se non aggiunge valore.

Cio' che sicuramente e' vero e' che in diversi casi, a fianco di quanto sopra, suggerisco di condurre alcuni esperimenti in ottica skunk, per risolvere alcuni elementi di rischio, ma poi i risultati con ogni probabilita' li uso per migliorare l'architettura, non per fare una early release...

concordiamo: faccio una prova e la butto via perche' l'unico motivo per farla e' acquisire conoscenza, non certo usarla per un'early release. Questo lo chiamo spike e tutto torna

Ma ripeto, questo vale per certi progetti, non certo per tutti.

certo e mi ricollego alla prima mia frase di questo post: dato che non esiste un approccio valido per tutti i progetti non ha senso usare un meta-framework che cerca di comprendere tutti i progetti. Preferisco partire con poco e man mano scalare se e quando scopro che serve, non prima.

A latere: prendendo ad esempio XP (non so se vale dirmi che non e' agile :->, anche se ovviamente agile != XP) a me non sembra cosi' adattativo come dici. Anzi, le sue pratiche sono molto ben definite, e tutto sommato parecchio rigide!! E' agile nel senso che si adatta molto a variazioni nei requisiti, ma non e' agile nel senso di adattare le pratiche al variare del progetto. Poi magari le cose scritte da Kent Beck sono sbagliate e mi hanno lasciato un'idea distorta :-)).

Beck si e' accorto di aver dato quest'idea di XP nella prima edizione del libro ed ha cercato di rimediare con la seconda edizione (anche e soprattutto includendo il feedback di 5 anni di applicazione). Pero' gli ho sentito dire personalmente + volte negli anni che se qualcuno applica XP by the book allora non ha capito il book :-)

io non amo sposare un singolo approccio, non amo gli "ismi" e di conseguenza sto un po' lontano dagli "isti" :-). Pratico tante cose, ognuna delle quali ha un nome, ma non voglio / posso dare un nome all'insieme [dinamico] delle cose, e nel fare questo "chiuderle" in un unico metodo od approccio.

e' il motivo per cui io uso sempre Agili e mai XP, SCRUM, DSDM, etc, etc. Per me e' piu' un attidudine, un modo di approciare le cose che un processo. Oggi le pratiche che conosco e che meglio si avvicinano a questa attitudine sono quelle comunemente conosciute, se domani ne esce una migliore ben venga. Anche se formalmente viene descritta come ultramegaheavyweight :-)

Provocazione: come puo' una disciplina essere agile una volta che si e' definita e strutturata come disciplina? :-))) [con grande disciplina :-) evito un profluvio di citazioni dal Tao Teh Ching :-)]

provocazione corretta e accettata: se parliamo di processo concordo con te, se parliamo di attitudine, valori e principi allora non vedo l'ossimoro. Ok, lo so, ogni tanto sono pedante ma lo ero anche quando lavoravo con RUP :-D

Grazie per aver speso del tempo a rispondermi (e a leggermi)
 
Marco, gioco ancora un po' alla botta e risposta :-)).

Su banche, agilita', ecc:

In realta' l'ambito bancario che citi non e' necessariamente uno di quelli poco adatti ad XP. O meglio, puo' esserlo talvolta l'ambiente culturale, ma non il progetto, che tipicamente ricade nella categoria corporate, che alla fine si presta bene all'approccio a user story incrementali, release frequenti, ecc.
Ti faccio invece qualche esempio concreto di casi che si prestano meno bene, concentrandomi tanto per fare un esempio sulle iterazioni di 1 settimana (ma fossero due sarebbe uguale :-). Posso trovare con altrettanta facilita' esempi in cui ogni pratica piu' o meno agile non regge, o dove non ne reggono N alla volta.
- Software embedded con mass distribution, es. software dei televisori, o dei videoproiettori, ecc ecc. In genere nasce con un forte hardware/software codesign, con l'obiettivo finale di minimizzare il costo di centinaia di migliaia o di milioni di pezzi identici. Non ti puoi permettere di rilasciare sul mercato pezzi diversi ogni settimana. Non ti puoi nemmeno permettere di implementare le varie storie partendo con il minimo che sta in piedi, perche' poi ti troverai a dover cambiare l'hardware sotto, e questo costa molto (tempo e $). Quello che vuoi e' uscire sul mercato con il software definitivo (la gente non applica patch ai televisori), minimizzando i costi globali. Ti serve un tot di pianificazione e progettazione molto accurata per arrivarci. E il mercato intorno non ti sta a guardare, nelle applicazioni corporate l'utente magari si arrabbia ma ha comunque pochissime alternative, qui no.
- Software tecnico / scientifico complesso, che so, per citare un esempio di questa settimana :-), un bel modellatore solido (MCAD 3D). Un prodotto unico da sei milioni di righe C++, belle complicate, un dominio piuttosto complesso di suo, 100 persone sparse tra Italia Francia e India, 24 ore per fare una build, 48 ore per far girare i test automatici su una test farm. I test automatici comunque non coprono che una frazione dei casi, c'e' sempre molto test manuale da fare e che non sappiamo automatizzare (esempi concreti on demand :-). Per come e' scritto il codice esistente, e' normale che una modifica in alcune parti abbia effetti collaterali anche in punti molto distanti funzionalmente. I clienti se non funziona qualcosina si arrabbiano molto :-). Raccontami ancora di continuous integration :-), users story just in time, ecc.
- E cosi' via, ne trovo quanti ne voglio, dove la cultura aziendale c'entra poco / nulla (anche se quando manca quella, ogni speranza e' perduta per ogni approccio :-), ed e' proprio il problema in se' che non si presta...

Partire con niente, sbattere la faccia contro il muro, farsi male, e capire che serve qualcosa di piu' non mi sembra la strategia piu' efficiente. L'idea di classificare i progetti e capire che per progetti diversi e' meglio adottare sin dall'inizio approcci diversi (adattandoli in ogni modo al progetto, ma partendo con una base vicina) e' meglio che partire sempre da un solo punto (niente :-) e aggiungere via via che ci si fa male...

Sui diagrammi ecc:

Vedi, qui c'e' il grosso rischio di finire nella profezia autorealizzante o self-fulfilling expectation che dir si voglia. Ovvero, io credo che i diagrammi possano essere utili sino in fondo, li tratto come utili, e si dimostrano utili. Tu (o un altro a caso :-) pensi che non lo siano, li tratti come inutili [dopo un po'] e si dimostrano inutili [dopo un po'].
Per semplificare molto una storia lunga, se io faccio diagrammi e' perche' certi ragionamenti vengono meglio sui diagrammi. Li faccio astratti, cosi' molte modifiche al codice non hanno impatto sui diagrammi. Ma se ci sono modifiche al codice che impattano il diagramma, e' inefficiente farle nel codice senza pensarle prima sul diagramma, perche' quel tipo di ragionamento viene meglio sul diagramma. Se tu lasci "andare a male" :-)) il diagramma, e' ovvio che poi lo guardi e dici "vedi che non serve piu' a niente".
Purtroppo dire "lo butto via se non aggiunge valore" e' complesso da tradurre in pratica, perche' il valore degli artefatti non e' una costante, e non ha nemmeno derivata costante, durante il progetto: puo' scendere in certi momenti per poi risalire, e se li hai buttati, sei fregato (ovvero: globalmente meno efficiente)
Anche qui, invece di buttare tutto e poi magari rifarlo o semplicemente pagare il costo aggiuntivo di non avere un modello su cui ragionare, io trovo molto piu' sensato cercare di capire su quali progetti i diagrammi servono solo all'inizio, su quali sono utili per sempre, e comportarsi di conseguenza. Non puoi sempre mettere a posto le cose a posteriori.
Io non seguo una corrente fideistica che mi dice che conta solo il codice. Anche perche' proprio non ne condivido i valori, come gia' accennavo...

Vedi perche' non mi piacciono gli "ismi": vogliono convincermi che basta seguire la loro ricetta e tutto andra' bene. Io preferisco avere N ricette, qualche euristica e un po' di guts feeling :-) per capire con quale iniziare, e poi e' ovvio che bisogna essere adattativi, ma in un senso molto diverso da quello che vedo spesso predicato.
Per me e' fondamentale reagire adattando le pratiche al progetto (ed anche alterando il progetto stesso quando serve per aumentare il valore). Troppo di cio' che leggo / sento (anche quando mi spieghi della banca :-) alla fine gira intorno ad alcune idee fisse (requisiti volatili, codice che si cambia facilmente se ha gli unit test, ecc) e quindi pratiche fisse (refactoring, TDD, ecc). Il problema e' che questi valori fissi che mi vengono promulgati non sono veri in senso assoluto. Questa e' la fregatura degli "ismi"...

Calando la provocazione di prima nella pratica, quando mi dici: dato che non esiste un approccio valido per tutti i progetti non ha senso usare un meta-framework che cerca di comprendere tutti i progetti. Preferisco partire con poco e man mano scalare se e quando scopro che serve, non prima.
e' ovvio che anche partire con poco e man mano scalare se e quando scopro che serve, non prima e' un meta-framework che cerca di comprendere tutti i progetti, solo che per me lo fa peggio di uno che ti porta sin dall'inizio vicino a quello che con ottime probabilita' dovrai adottare (dopo esserti fatto molto male :-). E qui siamo di nuovo al clash dei belief: c'e' chi crede troppo alla teoria del chaos universalis :-), che rende inutile ogni tentativo di avvicinarsi sin dall'inizio alla soluzione giusta, io invece credo che esistano sistemi caotici ed altri [tanti] no...

Il lato divertente e' che non credendo agli ismi, finisce che sono piu' agile io :-)))))))))))))))), per una appropriata definizione di agile che pero', come per il tao [stavolta non la scampi :-D] non puo' essere data :-)))).
 
Esatto!
 
Post a Comment

<< Home