Newsgroup: it.lavoro.informatica
Titolo: processo sw per progetti small size..

Ciao a tutti,
Lavoro come libero professionista (in uno studio con un socio) e ci 
occupiamo di progetti di varia natura, anche discretamente complessi ma 
su cui ci troviamo a lavorare sempre in una due o al massimo 3 persone 
(insomma in generale facciamo sia l'analisi che la progettazione che 
l'implementazione in house).
Abbiamo sviluppato internamente alcuni strumenti semplici e veloci per 
la gestione delle commesse (senza scomodare project e bugzilla ad esempio).
A questo punto però sento l'esigenza di definire un vero e proprio 
processo di sviluppo interno che definisca quali documenti e quali 
attività in ogni fase del progetto. Inclusi documenti di testing ecc.
Senza scomodare il Rup et similia esiste qualche processo studiato per 
chi lavora da solo o in piccolissimi team su progetti di breve-media 
durata (max 6 mesi ad esempio) in cui il costo del tempo speso a fare 
documenti è sensibile per cui occorre ottimizzare e fare solo quello che 
serva veramente.
Quello che mi serve è avere uno schema del tipo
-Analisi
Quali documenti fare per se e per il cliente (casi d'uso, diagrammi 
architetturali ecc)
-Progettazione/implementazione
Quali documenti fare per se (schema dei componenti, documentazione 
codice secondo javadoc o simile altro?) ed eventualmente per il cliente 
se ne avesse necessità
-Release e assistenza
Quali documenti fare per il deploy (install/config document, user 
manual) gestire la fase di test presso il cliente (cioè come obbligarli 
a farmi i test o certificare che li hanno fatti) e gestire l'assistenza 
(buglisting e feature listing)
Spero che vorrete darmi suggerimenti, al limite mi sarebbe utile anche 
solo un elenco di possibili documentazioni da prodursi in un progetto 
ove io possa selezionare quel subset minimo adatto al mio ambito di lavoro.
Grazie,
Trini.

 ove io possa selezionare quel subset minimo adatto al mio ambito di lavoro.
E' difficilissimo esprimersi senza sapere che tipo di progetti
realizzate e che tipo di clienti avete.
Un diagramma archietturale può essere fondamentale per un  framework
personalizzabile (cliente software house) ed assolutamente inutile per
un luser qualunque.
L'unico mio consiglio è che bisognerebbe sempre scegliere il minimo
comune linguaggio tra cliente e fornitore  : analisi classica ? Uml ?
Diagrammi ? Disegnini e prototipi ? Dipende...
Per il resto, sinceramente non credo che qualcuno ti fornirà un elenco
di documenti e un processo di sviluppo, quantomeno non uno vincente,
visto che sono un patrimonio fondamentale delle aziende (spesso più
dei sorgenti stessi).
Le norme ISO possono essere una base di partenza, poi ognuno fa come
vuole.

 dei sorgenti stessi).
C'ho provato ;)..
+ che altro mi chiedevo se esisteva un processo diciamo standard o cmq 
open un po' scalato per progetti piccoli. L'idea è che l'avrei studiato 
ed avrei estrapolato quanto utile a me per inserirlo all'interno del mio 
attuale modo di procedere al fine di migliorarlo ove possibile.
Chiaramente in modo flessibile.
Trini.

 per cui occorre ottimizzare e fare solo quello che serva veramente.
[cut]
Scrum o Crystal Clear (parto dall fine e poi argomento, cosi' se non hai voglia
di leggere tutto il messaggio puoi sempre prendermi in parola, anche questo e'
Agile = le attivita' vengono svolte sempre in ordine di valore per il cliente)
Perche' non una metodologia ingegneristica?
- Perche' sono nate per risolvere problemi di comunicazione di grandi team (>
  100 sviluppatori), magari anche territorialmente distribuiti. Mi sembra di
  capire che non sia il tuo caso
- Focalizzate su correttezza e prevedibilita', bene dirai, non tanto dico io.
  La correttezza riguarda l'implementazione di un sistema rispetto alle
  specifiche, ma chi dice che le specifiche una volta implementate raggiungano
  gli obiettivi del cliente? Secondo te i tuoi clienti sarebbero piu' propensi a
  pagarti perche' hai implementato correttamente delle specifiche o perche' hai
  raggiunto gli obiettivi di progetto? La prevedibilita' puo' andar bene per
  situazioni in cui i requisiti sono stabili, ma quando l'interesse del cliente
  e' quello di massimizare il ROI, dubito fortemente che lo siano
- Focalizzate su forma e burocrazia, meglio un manuale utente impeccabile (che
  nessuno leggera') per un'applicazione sbagliata o un'applicazione corretta ed
  usabile al punto da non aver bisogno di un manuale utente
- Potrei andare avanti a lungo :-)
Perche' Scrum? Se cio' che ti manca e' una *gestione* piu' controllata del
processo produttivo al fine di ottimizzarlo, allora Scrum e' una buona scelta
http://video.google.it/videoplay?docid=-7230144396191025011&q=scrum
Se pensi che *anche* le pratiche di implementazione che attualmente utilizzi
possano essere migliorate, puoi sicuramente attingere dalle pratiche
dell'eXtreme Programming, vedi anche due ottimi libri dei Pragmatic Programmers
http://www.pragmaticprogrammer.com/titles/pad/index.html
http://www.pragmaticprogrammer.com/titles/prj/index.html
Nonche' lo starter kit sempre loro
http://www.pragmaticprogrammer.com/starter_kit/index.html
Perche' Crystal Clear? E' una metodologia molto leggera (che attualmente sto
utilizzando con un team di cui sono mentore) distillata dallo studio dei
processi adottati da team vincenti (= prodotti di successo, in time, on budget).
A me piace molto per la sua natura introspettiva, ovvero il fatto che considera
le retrospettive di processo[*] come parte fondamentale del processo stesso, ed
e' nata come linea guida per team di ridotte dimensioni. Il libro di Cockburn fa
da riferimento 
http://www.amazon.com/o/ASIN/0201699478
Aggiungo che se sei di Milano, il mio gruppo (Milano eXtreme Programming User
Group) 
http://milano-xpug.pbwiki.com/
 si riunisce due volte alla settimana per
trattare argomenti di questo tipo, altrimenti prova a vedere se nella tua zona
esiste un xpug
[*] quello che stiamo facendo ci aiuta a raggiungere i
nostri obiettivi? Cosa facciamo bene? Cosa facciamo male? Possiamo eliminare
degli sprechi di risorse? In cosa dobbiamo migliorare per raggiungere gli
obiettivi del cliente?
-- 
Gabriele Lana
contact me at info at gabrielelana dot it
http://www.gabrielelana.it
 - Agile methodologies and Programming
http://www.xpug.it
 - italian eXtreme Programming User Groups

 Chiaramente in modo flessibile.
Ti consiglio di stare molto attento su questo punto. La "customizzazione" delle
metodologie e' molto pericolosa [*], la liberta' di adattare un metodo di
sviluppo in un ambiente non constrollato/misurato, e' meglio non farlo. Per
quanto riguarda le metodologie tradizionali/ingegneristiche, non lo puoi fare e
basta, sono metodologie "studiate" per essere corrette e complete, non puoi
scegliere i pezzi che ti "piacciono" scartando gli altri, alcune ti permettono
di farlo (ex. RUP) ma lo fanno attraverso un processo controllato e abbastanza
complesso.  Le metodologie agili in questo si prestano meglio, ma mettono in
campo tutta una serie di strumenti per guidarti nell'adattamento del processo
produttivo alle esigenze del progetto specifico
[*] Se vogliamo e' una delle ragionioni per le quali nell'80% dei casi in Italia
non viene applicata nessuna metodologia


 [cut]
Anche se in ritardo grazie per l'ottima e interessante risposta.
Trini.