Collegamento: http://metriche-per-il-software-pa.readthedocs.io/it/latest/documento-in-consultazione/coerenza-con-il-piano-triennale.html
Contenuto:
5 Coerenza con il Piano Triennale
Collegamento: http://metriche-per-il-software-pa.readthedocs.io/it/latest/documento-in-consultazione/coerenza-con-il-piano-triennale.html
Contenuto:
5 Coerenza con il Piano Triennale
Nel 4.2 Misure funzionali viene riportato che “l’apprendimento si riduce (il manuale di riferimento, ad esempio, consiste in 81 pagine rispetto alle 546 pagine del manuale IFPUG)”. Questo è alquanto opinabile visto che lo standard ISO sono poco più di 20 pagine se non sbaglio. Il manuale sono oltre 500 pagine per la presenza dei casi di studio e di precise spiegazioni che facilitano la comprensione. L’apprendimento di riduce se non sono chiare le spiegazioni ma non mi sembra questo il caso.
Arrivo tardi, so che la consultazione è chiusa. Tuttavia vorrei comunque segnalare che mi sembra che il documento abbia un rilevante problema nella Tabella 42 (Cap. 5 Coerenza col piano triennale) con riferimento alla possibilità di applicare la misura funzionale dei FP ai metodi agili.
Infatti non si fa assolutamente menzione a metodi di stima alternativi ai FP e ampiamente utilizzati in ambito agile come gli story points o le tecniche di planning poker.
In generale, non mi sembra particolarmente realistica l’applicazione degli FP ad ogni iterazione.
Ancora più in generale, mi sembra che la questione non affrontata nel documento sia quella che sta dietro al problema delle metriche quando si usano metodi agili - prendendoli sul serio. Coi metodi tradizionali infatti siamo in un mondo di project management, dove abbiamo uno scope fisso, un tempo fisso e dobbiamo inizialmente definire un budget sulla base di tali due vincoli. In una logica agile, invece, dovremmo avere un budget ed un tempo fisso, e uno scope variabile (ovviamente non in assoluto: l’obiettivo generale e i macro requisiti - epics - sono certamente ben definiti, ma il contenuto e il modo per ottenerli può variare anche in modo significativo, decidendo in corso d’opera di modificare anche in modo rilevante il prodotto finale.
In conclusione, a mio giudizio sarebbe opportuno trattare in modo approfondito anche metodi alternativi di stima agli FP, suggerendone l’utilizzo da parte delle PA anche allo scopo di diffondere al meglio la cultura agile, che può funzionare meglio se c’è maggiore interazione fra utenti e sviluppatori (cliente e fornitore).