Se dovessi dire delle cose che mi aiutano a velocizzare i progetti:
1. stendere subito la lista delle features e dei casi d’uso utilizzando un wiki
2. condividere subito il wiki con il cliente e con il team di sviluppo
3. arrivare il prima possibile ad un prototipo e poi iterare a go-go
4. sentire spesso il cliente, almeno 2-3 volte alla settimana
5. registrare sempre tutto sul wiki, obbligare il team e il cliente a farlo
Alberto Mucignat
random thoughts around web stuffs (è tutto un equilibrio sopra la follia…)
-
Socialize
8 commenti ↓
e io che speravo di leggere consigli su come tacchinare durante le lezioni di spinning in palestra…
sapefo che saresti caduten nella trappolen!
una curiosità, come usi il wiki (e quale usi)?
io attualmente, per i progetti che non necessitano di phpCollab, o che necessitano di un manuale di fine lavoro ho una macchiavellica struttura del genere
= PROGETTO
1. LAVORO (descrizione del lavoro)
2. TODO (cose da fare)
3. CONSIDERAZIONI (dubbi e perplessità)
4. DONE (cose fatte)
dove 2,3,4 non sono mai editati ma includono tutti i relativi TODO, CONSIDERAZIONI, DONE dei tasks
= TASKS
1. TASK (descrizione)
2. TODO
3. CONSIDERAZIONI
4. DONE
5. ALTRO (ie, link alle img delle template)
= CODE
1. CODE SNIPPLET (pezzetti di codice usati spesso x facilitare copia/incolla)
2. CODE TEMPLATE (template per funzioni simili, contiene + snipplet)
3. CODE FAQ (link ai manuali di riferimento sulle classi usate nello sviluppo)
4. PATTERN (casi d’uso e pattern tipici di utilizzo di qualcosa)
CODE può appartenere, ovviamente, a più progetti (ie funzione di login che ha un suo pattern di funzionamento, una sua classe php, una lista di funzioncine già pronte all’uso).
quindi che succede:
ho una template di progetto dove vedo ad occhio tutto quello che c’è da fare/fatto e poi mi posso interessare ai singoli task di volta in volta, modificando le pagine dei task automaticamente si aggiorna lo stato del progetto.
altro che “macchiavellico”…
cmq io ho un approccio diverso e, soprattutto, esigenze diverse. il mio lavoro è project management, non sviluppatore. quindi mi relaziono anche con persone diverse.
ad ogni modo, per rispondere:
- uso [url="http://www.pmwiki.org"]pmwiki[/url]
- solitamente non ho una scaletta prefissata, ma faccio crescere il wiki “così come viene”
- avendo in mente una gestione agile dei progetti, solitamente lavoro ad iterazioni e quindi individuo task che vanno fatti per ogni iterazione
- di solito la mia struttura è più descrittiva del progetto, utilizzo strumenti tipo: feature list, sitemap, wireframe, page description diagrams, casi d’uso, glossario, ecc..
- non mi interessa sapere esattamente come sono implementate le cose, ma come deve essere il risultato finale. soprattutto, questo deve essere chiaro a tutti (cliente, team, ecc)
discorso a parte per la documentazione:
- esistono delle convenzioni quindi gli sviluppatori e i grafici le devono seguire
- il codice deve essere commentato
- solitamente utilizziamo dei cms che impongono una loro struttura che quindi è già documentata
- infine: la documentazione è già di fatto il wiki, per tutto quello che ci viene scritto. ogni volta che il cliente mi chiede una spiegazione o che lo sviluppatore mi chiede una delucidazione, metto tutto nel wiki: in questo modo la documentazione viene da se.
sono cose che ho scoperto spesso a posteriori, dopo aver usato il wiki “a tentoni”.
tempo fa ho messo nel mio wiki anche [url="http://www.mucignat.com/wiki/index.php/LiveDoc/WikiTool"]altre considerazioni[/url] più generali
ovviamente avendo io uno stampo + “dev” (e la sfortuna di non riuscire a dedicarmi mai al solo pm) relaziono tutto a quello…
cmq sia all’interno dell’entità progetto bene o male includo tutto quello che aggiungi anche tu.. con alcune differenze, se scopro che un “caso d’uso” è molto generico lo considero come “pattern” e lo sposto li (una cosa tipo http://www.welie.com/patterns/ )
nel mio caso i task sono raramente decisi a priori (a parte quelli indispensabili come la stesura della prima bozza delle specifiche funzionali), poi man mano crescono (e si evolvono) col progetto
altra differenza è che a me interessa sapere come e perchè sono state fatte le cose, per alcuni motivi come il fatto che il gruppo di lavoro può essere composto solo da me, ma anche da individui che poi scompaiono (ed in entrambi i casi ho bisogno di info sul codice, portare avanti una decina di piccoli progetti di sviluppo all’anno frigge la mente), o per il fatto che il cliente dopo n-mesi/anni vuole aggiungere LA nuova features indispensabile (che spesso richiede una riscrittura delle api.. === devo sapere come sono state definite/scritte)
poter avere sott’occhio tali informazioni per me è sempre di vitale importanza..
ho dato un occhio a pmwiki, caruccio
io per ora uso dokuwiki e mediawiki, il secondo però mi sta deludendo sempre di più troppo macchinoso da personalizzare e poche estensioni veramente utili 
creiamo una ml o un wiki a riguardo (del pm)?
[quote=fullo]se scopro che un “caso d’uso” è molto generico lo considero come “pattern” e lo sposto li (una cosa tipo http://www.welie.com/patterns/ )[/quote]
grazie del link, l’ho subito FURLato. spesso i casi d’uso tipo “login” o altro si possono infatti ricondurre ad un pattern…
[quote=fullo]a me interessa sapere come e perchè sono state fatte le cose[/quote]
non concordo. il perchè non è mai un problema. il come potrebbe essere un’informazione necessaria in molti casi. ad ogni modo, tendo a prevenire (almeno mentalmente) questi problemi, dicendo: la struttura dell’applicazione non può essere decisa da un singolo, ma deve sottostare a delle regole, così come il codice. se uno segue le regole, le risorse sono sostituibili. altrimenti… sono fatte male le regole!
-> pmwiki è veloce da customizzare e puoi proteggere facilmente qualche pagina. per un progetto è ottimo. per scalare forse è meglio mediawiki, ma so che è un po’ più complesso. dokuwiki mai provato… al limite la cosa più interessante potrebbe essere se uno di loro ha un editor wysiwyg, che per un cliente fa la differenza (voglio dire: se non hanno un editor wysiwyg si trovano un po’ spaesati…).
[quote=fullo]creiamo una ml o un wiki a riguardo (del pm)?[/quote]
ci sto pensando… cmq ml no: meglio un wiki o un forum tipo phpbb. in italia c’è qualche “gruppo” che tu sappia?
[quote]il perchè non è mai un problema[/quote]
falso se il perchè è dipendente da una precisa scelta del cliente, nel tal caso documentare la motivazione riduce rischi sul lungo termine
[quote]al limite la cosa più interessante potrebbe essere se uno di loro ha un editor wysiwyg, che per un cliente fa la differenza (voglio dire: se non hanno un editor wysiwyg si trovano un po’ spaesati…).[/quote]
niente wysiwyg inclusi nel prezzo, pero’ c’è sempre: http://www.fullo.net/blog/archives/2005/08/22/wikiwyg/
[quote]in italia c’è qualche “gruppo” che tu sappia?[/quote]
per ora in italia ho trovato solo gran gruppi di discussione su webdesign, usabilità, accessibilità ma nulla sul pm.. ripensandoci credo che siamo gli unici 2 che ne discutono…
1. credo che il “perchè si fa una cosa” faccia parte dei requisiti, non della documentazione. documentando i requisiti e le scelte su un wiki non c’è necessità di aggiungere lavoro allo sviluppatore. ma forse stiamo guardando un po’ troppo alle sfumature.
2. non so cosa intendi tu per project management, poichè è una materia vasta. quello che intendo è “realizzare progetti web focalizzandosi sulle cose che devono essere realizzate e sulla comunicazione tra team e cliente”. perlomeno questo è quello che cerco di fare io. quindi non intendo solo la gestione della parte dello sviluppo, ma anche la costruzione dei servizi.
ps: il fatto che ci sono solo 2 persone in italia che parlano di pm spiega molte cose
cmq dai io non penso che ci siamo solo noi…