Essere agli vuol dire adattarsi velocemente ai cambiamenti che il mondo esterno ci impone.
Scrum ti consente di cambiare velocemente le priorit, modificare velocemente i tuoi requisiti di business e migliorare i tuoi processi, ma il sw che stai scrivendo 竪 altrettanto adattivo e in grado di accogliere i cambiamenti?
Se cos狸 non fosse presto la tua agilit verr ostacolata dalla flaccidit del tuo codice e dovrai porvi rimedio.
Vedremo insieme come accorgersene il prima possibile e quali misure adottare.
1 of 34
Download to read offline
More Related Content
Il tuo team "agile" scrive codice "flaccido"? Forse scrum non basta
4. Perch竪Scrum?
E semplice
Consente di rilasciare valore per lutente
molto presto
Implementa cicli di feedback sul prodotto
che consentono di rilasciare valore con
continuit
Implementa cicli di feedback sul processo
consentendo di aumentare la produttivit
del team tramite collaborazione e
miglioramento continuo.
6. Scrum 竪
sufficiente?
6
Dove spendete pi湛 tempo?
Correggendo bug Aggiungendo
funzionalit
Che dite quando vi
chiedono una modifica?
Acciderbolina! Si
romper tutto!
束Tuttapposto損,
devo solo
cambiare un
po il design
Quanto 竪 complicata la
vostra codebase attuale?
Non ne ho la minima
idea
E ampia ma facile
da capire e
cambiarla non 竪 un
problema
11. Spenderepoconon
vuoldirespendere
poconellosviluppo
.They piled story on story as
quickly as possible with the least
possible investment in design.
Without daily attention to design,
the cost of changes does
skyrocket. The result is poorly
designed, brittle, hard-to-change
systems.
Kent Beck, Extreme Programming
Explained: Embrace Change
12. Scrum non 竪
sufficiente
Se il nostro team 竪 Agileanche
il nostro codice lo deve essere!
Talvolta invece scriviamo codice
13. Come 竪fatto un codice Flaccido
Ha molti difetti
(anche noti) rilasciati
in produzione
1
Non 竪 manutenibile: E
difficile individuare
lorigine di un difetto
perch竪 il codice non 竪
leggibile o non se ne
capisce lintent.Spesso
risolvere un difetto vuol
dire crearne un altro.
2
Non 竪 estensibile: E
difficile estendere le
funzionalit di
unapplicazione se non
竪 modulare, flessibile
e utilizza design
pattern riconoscilbili.
3
15. Sintomi tipici di
un codice
flaccido
Rigidit
Fragilit
Immobilit
Viscosit
Inutile complessit
Inutili ripetizioni
Opacit
Robert C. Martin
束Design principles and Design Patterns損
17. Legge della
complessit
crescente di
Lehman
La struttura di un sistema che
evolve si deteriora man mano
che cambia, e devono essere
spese risorse aggiuntive per
preservarne la funzione e
semplificarne la struttura
18. CostodelcambiamentodelSWtradizionale
Equazione di Lehman e Belady:
M= p+ K c-d
M= sforzo di manutenzione, p= sforzo di sviluppo totale, c = complessit
causata dalla mancanza di strutturazione (leggi: debito tecnico), d
= grado di familiarit del team di manutenzione col software. K 竪 una
costante da individuare confrontando il modello con i dati reali,
21. Come?
Adottando pratiche che consentono
di:
Realizzare e mantenere nel
tempo un buon Design
Individuare i bug molto presto nel
ciclo di vita del SW