Come mappare il debito tecnico? Esploriamo il Mikado Method

Utile. Lo proverò.

Metodo molto Interessante, da provare.

Ho scoperto un metodo interessante per descrivere il debito tecnico in modo meno ambiguo. Il potere della visualizzazione poi aiuta a capire cose come la complessità del task di refactoring e le dipendenze tra i passi di refactoring per rendere l'operazione meno indolore possibile.

Per renderlo ancora migliore, cercherei di trovare una forma espositiva più coinvolgente, e di inserire anche esempi di come viene usata questa tecnica nella vita di tutti i giorni, ad es come vengono prioritizzate le attività di refactoring di questo tipo, se vengono in qualche modo stimate, e come la suite di test aiuta nei passi di refactoring (o diventa magari un ostacolo al cambiamento).

Interessante ed utile. Avrei preferito magari un esempio più personalizzato di utilizzo.

Metodo sicuramente interessante e da provare! Bravo lo speaker!

Molto interessante l'argomento che è stato descritto piuttosto bene. Se si fosse avuto più tempo sarebbe stato bello vedere un esempio più complesso in cui il metodo viene applicato dall'inizio alla fine con un paio di rollback e poi il refactoring con la commit finale).

Mi aspettavo qualcosa di più dal talk dato il titolo. Il metodo non è nulla di stupefacente per chi già affronta problematiche di refactoring complesse tutti i giorni. Non l'ho trovato molto utile.

Relatore comunque bravo, non mi ha mai annoiato.