Nel disegno si fanno emergere varie alternative possibili che vengono analizzate e esplorate in un processo iterativo fatto di prove e tentativi che migliorano via via la comprensione del problema e della soluzione sino alla definizione del disegno prescelto (vedi ad esempio Modificare metodi interminabili: strategia).
Il primo passo per l'efficenza è distinguere le (re)iterazioni di disegno che in questo modo generano valore dalle (re)iterazioni di produzione che invece sono un "rework" cioè rifare il lavoro che è uno spreco (l'esempio in questo commento)
Il secondo passo per l'efficenza è riuscire a distinguere anche tra le (re)iterazioni di disegno "positive" perché danno valore e le (re)iterazioni di disegno "negative" si possono evitare. Riporto le indicazioni da POSITIVE VS NEGATIVE ITERATION IN DESIGN, G Ballard
- tenere presenti le esperienze precedenti, le scelte fatte in precedenza e i loro esiti, le prove e le prototipazioni già tentate, gli esiti che hanno prodotto e il loro risultato una volta in produzione: questo evita lo spreco di esplorare con prototipi e prove di cui si conosce già la risposta
- condividere subito le informazioni parziali riguardo la applicazione da disegnare e i valori accettabili entro cui il disegno deve muoversi (per esempio numero di utenti che il sistema deve supportare, vincoli di sicurezza, facilità di evoluzione/estensione, costi entro cui resta economicamente sostenibile/vantaggioso) in un team cross-funzionale (es. dal DBA al Sistemista allo Sviluppatore all'Amministratore al Responsabile di Sicurezza) & affrontare il disegno adottando insieme un approccio di tipo problem solving
- evitare la sovraproduzione di caratteristiche/funzionalità non immediatamente necessarie/usabili (vedi YAGNI)
- affrontare il disegno in piccoli blocchi, occuparsi del disegno delle parti che devono essere implementate e rilasciate immediatamente e rilasciarle frequentemente
- esprimi le scelte di disegno come un intervallo o un insieme (un ventaglio di possibilità) invece di esprimerlo come un unica scelta tutto o niente - questo viene chiamato Set Based Design quando applicato al sw e "set-based concurrent engineering" altrove
- posticipare ogni decisione irreversibile di disegno all'ultimo momento responsabile ossia il momento superato il quale non decidere pregiudica comunque ogni alternativa disponibile :
- mantieni aperte contemporaneamente le diverse opzioni di disegno disponibili sino a quando il tempo disponibile si avvicina a quello necessario a implementare quel disegno, in quel momento fai la scelta (è importante che tu abbia la sensibilità del tem,po necessario a implementare le varie alternative) avendo avuto a disposizione più tempo e quindi più informazioni per fare la scelta migliore
- quando il tempo di decidere manca e serve una decisione rapida usa un disegno ridondante (ad esempio non c'è tempo di stimare l'esatto carico di connessioni client che una funzione Server deve sostenere, disegnala perché sostenga il caso peggiore - a patto che i tempi di questo disego e implementazione non superino i tempi necessari a stimare il valore esatto e implementare quello)
- verifica la fattibilità e fai le stime prima di impegnarti per realizzare un dato disegno
Tags : Team Work | Agile | Pratiche | Progettazione Software |
Print | posted @ martedì 16 settembre 2008 04:54