Ci siamo abbeverati all'ottimo pub Old Fox. L'argomento proposto da Matteo per la serata era: come si gestiscono le storie che sono simili fra di loro? Il problema è che se ho, ad esempio, 5 report da fare, il primo mi forza a creare l'infrastruttura che useranno anche gli altri, e di conseguenza il primo report costerà di più. Come rappresentiamo questa cosa nel planning game?
Ci sono varie scuole di pensiero.
- Introduciamo una dipendenza: diciamo al cliente che la prima storia fra quelle costa 10, e le altre costano 5. Il vantaggio è che spieghiamo bene al cliente com'è la situazione, e il totale (10 + 4*5 = 30) rispecchia quello che noi crediamo sia effettivamente il carico di lavoro. Lo svantaggio è che il planning game si complica, e diventa difficile segnare un numero sulla carta (cosa scrivi: 10 oppure 5?)
- Stimiamo tutte le storie a 10. In questo modo il planning game non subisce modifiche e il cliente semplicemente sceglie il report che gli interessa di più. Il problema è che ora il totale stimato è di 5*10 = 50, mentre noi intimamente siamo convinti che dovrebbe essere 30. Stiamo raccontando palle al cliente? D'altra parte, le nostre stime non sono certe, e tante volte succede che ci sbagliamo. Magari in realtà quello che succede è che scopriamo che la prima storia costa 20 e le altre costano 9. Se poi salta fuori che non è così, tanto meglio, diremo al cliente che abbiamo finito prima del previsto.
- Introduciamo una carta "tecnica" che rappresenta il costo di startup di fare il primo report. Diciamo che la carta tecnica va scelta obbligatoriamente se viene scelto anche una storia di uno dei report.
- Scegliamo noi arbitrariamente: se il cliente ci dice che tutti i report andranno comunque realizzati, decidiamo noi per il cliente quale fare per primo e attacchiamo a quello un costo maggiore.
Non c'è una soluzione che vince...
Altro argomento della serata, Gabriele ci ha raccontato delle differenze tecniche e di principio fra le due librerie JavaScript che vanno per la maggiore. Entrambe implementano delle estensioni agli oggetti predefiniti (gli array o i nodi del DOM, ad esempio) che appianano le differenze fra i vari browser; ma la maniera in cui le implementano sono diverse:
- Prototype, per analogia con il linguaggio Ruby, modifica il prototipo dell'oggetto, mentre
- jQuery crea degli oggetti proxy che delegano all'oggetto originale.
Secondo Gabriele la tecnica di jQuery è superiore, perché la tecnica del prototipo rompe il codice JavaScript che è stato scritto senza prevedere l'uso della libreria Prototype.
Riferimenti segnalati da Piero:
--
Comments (0)
You don't have permission to comment on this page.