E sai perché per me è particolarmente importante questa capacità di fare pagare poco un prodotto piccolo? Perché sul prodotto piccolo ci sono poche possibilità di alzare una cortina di fumo. Il successo o il fallimento sono molto più evidenti. Su un progetto di un anno non c’è lo stesso livello di attenzione, non c’è lo stesso feedback rapido fra l’azione e il risultato.

Es. è entrato un lavoro da 1000 euro che ci viene a costare 2000 euro: risultato, dobbiamo capirci meglio; o impariamo a farlo costare di meno o impariamo a farlo pagare di più.

Se entra un lavoro da 100.000 euro che ci viene a costare 130.000 euro, il risultato è molto più grave ma le possibilità di ignorare la realtà e dare la colpa al commerciale, al dirigente, al cliente, alla tecnologia, al maltempo, al governo, a Steve Jobs o a Bill Gates sono infinite. Risultato –> non si impara e non si migliora.

Per questo i progetti piccoli sono interessanti :-)

-> Ma e’ ovvio che se chiedo ad un’azienda di fare una cavolatina i costi vanno alle stelle. Come chiedere ad un’impresa di attaccarmi le tende alle finestre.
Ma quello che diceva Francesco era che 10k non erano il preventivo dell’azienda ma i loro costi interni (ma come fa a saperli?). A questo punto se quella azienda e’ ancora in commercio significa che evidentemente riesce a rivendere a 20k l’applicazioncina (40k per l’azienda agile), quindi o ha degli ottimi commerciali oppure ci sono altri fattori che non sappiamo.
Pero’ sarebbe interessante sapere come sono arrivati ai 10k… hanno stimato 3 mesi uomo? strapagano i loro dev (improbabile)? boh detta cosi’ e’ un’informazione che mi e’ poco utile.

Un’azienda non si scomoda nemmeno per 1.000 euro, non prende proprio il lavoro.

Ammesso che sia comunque interessata al lavoro ha due possibilità:
a) prende una persona nuova a tempo determinato per sviluppare l’app e quindi sopporta il costo una tantum della persona e dell’infrastruttura che gli mette a disposizione. Non credo che 1000 euro siano sufficienti (magari l’azienda non possiede un iphone e quindi come minimo deve comprare quello). Il costo da sopportare secondo me si avvicina facilmente ai 5.000 euro.
b) L’alternativa è utilizzare personale interno, ma il personale interno non è che sta lì ad aspettare mentre prende un caffè. Sicuramente è impegnato in altre cose, quindi oltre al costo del personale interno (pro quota per il tempo necessario) ci sarà anche il costo dovuto al distogliere tale personale da altri progetti.

Quello che voglio dire è che sviluppare un prodotto anche piccolo come il Pomodoro ha comunque uno zoccolo di costi e questo zoccolo non è che necessariamente si abbassa al diminuire della complessità del prodotto.
Quindi l’esempio di Cirillo secondo me non è particolarmente rilevante.

Molto più rilevante sarebbe chiedere: quanto mi costa sviluppare questo prodotto complesso? Quanto mi costa aggiungere o modificare una feature a prodotto finito?
Probabilmente è in questi casi che il team agile vince, ed è in questi casi che il team anziano e competente vince sul team giovane ed inesperto.

Per quanto riguarda le illusioni dell’Agile mi ricordo perfettamente di aver letto su un libro (cercherò quale perché non mi viene in mente.., ma sicuramente è di un autore importante, perché ho solo quelli di libri….) una frase del tipo “il tdd funziona anche perché non richiede sviluppatori particolarmente bravi, mette in grado tutti di scrivere codice decente”.

Sul fatto che un medio Agile è meglio di un medio Waterfall non mi sembra ci siano particolari dubbi, il problema che Cirillo pone è: fare Agile a livello medio non è particolarmente difficile, farlo ad alti livelli, con continuità e migliorando costantemente è molto difficile. Rimane la domanda: come si fa a sapere su che strada si è? Come si imbocca quella giusta? Come ci si rimane?

Sulla terza invece Chapeau! Ma in fondo e’ la prefazione e il povero Ron Jeffreys vorra’ vendere qualche copia del libro. :)

Pero’ nessuno (neanche Ron) ha mai detto che “usando i Metodi Agili si diventa più bravi.”