Quanto sono agili i punti funzione?

Molte organizzazioni hanno imparato che possono ottenere una migliore presa sui loro progetti software stimandoli con punti funzione. Allo stesso tempo, vediamo che sempre più organizzazioni hanno un modo di lavorare Agile, solitamente applicando Scrum. La grande domanda è se i punti funzione rimangono in piedi. Scrum li getta in mare? Oppure i Function Point hanno ancora valore in un mondo Agile? In questo blog Jolijn Onvlee e Rini van Solingen mostrano quali attriti e somiglianze ci sono.

Agile / Scrum

Agile (con Scrum come l'approccio più utilizzato) viene accolto da un numero crescente di organizzazioni come soluzione al fallimento di grandi progetti IT. Iniziando a fornire direttamente il software, ogni due settimane un cliente riceve informazioni dirette sui progressi e sul valore aggiunto. Gli utenti non devono più attendere la funzionalità con il valore aziendale più elevato. Inoltre, il flusso continuo di feedback porta a sistemi preziosi che funzionano, più veloce. Infatti, con l'uso di Scrum, un grande progetto IT viene suddiviso in tanti piccoli progetti. Ciò rende più facile rispondere a nuove intuizioni e riduce enormemente la complessità dell'intero progetto.

Scrum gestisce le specifiche del sistema in un modo drasticamente diverso. Il prodotto è descritto solo in termini generali (chiamato il Backlog di prodotto).Poi, All'inizio vengono elaborate in dettaglio solo quelle parti che hanno il valore aziendale più elevato e le tesi vengono consegnate rapidamente. Dopo questa consegna viene determinato nuovamente il valore aziendale più elevato, sviluppato e consegnato, e così via. In questo modo è possibile una regolazione costante. Questo sostituisce l'idea originale di un progetto che fornisce un risultato predefinito. La stima dell'intero volume di consegna non ha più senso, semplicemente perché l'intero ambito non è più elaborato in dettaglio. Il punto all'orizzonte può cambiare in qualsiasi momento.

Attrito

Scrum gestisce la stima e il budget in modo diverso da un approccio più tradizionale e sistematico. L'approccio tradizionale utilizza spesso Function Point Analysis (FPA) per la quantificazione. L'FPA viene utilizzato per stimare quanto costerà la realizzazione del software e quanto tempo ci vorrà per consegnarlo. Un punto funzione viene utilizzato come metrica per determinare la dimensione del sistema. Questo dimensionamento viene effettuato sulla base delle specifiche funzionali. Un certo grado di dettaglio di ciò che farai è necessario per FPA.

Quindi sembra che Function Point e Scrum non combacino. Dopotutto, il primo vuole una specifica completa in anticipo e l'altro vuole mettere in discussione e aggiornare la specifica in qualsiasi momento e non entra troppo nei dettagli. Gli sprint all'interno dell'approccio Scrum sono troppo brevi e troppo vari per essere stimati in base ai punti funzione. Allo stesso tempo, anche all'interno delle organizzazioni Agile, è necessario controllare i costi. 'Vedremo alla fine quanto è costato' è inaccettabile per la maggior parte delle organizzazioni. Ciò significherebbe che Agile crea anarchia nella spesa IT, che non ha senso. Anche con Scrum un cliente ha bisogno di controllo. Il proprietario del prodotto desidera mantenere una panoramica dei risultati di tutti questi sforzi (obbiettivo) e quanto tempo e denaro è costato alla fine (budget). Ed è proprio qui che l'FPA tradizionale offre una soluzione.

Analogie

Se guardi in dettaglio la combinazione di FPA e Scrum, vedi che si rafforzano invece di indebolirsi a vicenda. Dopotutto, L'FPA aiuta a stabilire l'ambito generale (il punto all'orizzonte) e il budget appropriato. Scrum aiuta a realizzare prima le funzioni con il più alto valore aziendale all'interno di quel budget. Non appena possibile, il feedback viene inserito nel processo di consegna. Feedback su due fronti: primo, se l'ambito generale è corretto e, secondo, se l'intero problema può essere risolto entro il budget.

In pratica ciò significa che il backlog del progetto è determinato a livello globale. All'interno di Scrum è pratica comune che la parte del prodotto con il valore aziendale più elevato abbia già una quantità significativa di dettagli. Questo livello di dettaglio (preferibilmente per un numero di sprint) di solito è sufficiente per eseguire un'analisi dei punti funzione. È quindi possibile utilizzare tale analisi per determinare il numero totale di punti funzione per l'intero backlog estrapolando. All'interno del metodo FPA, questo sarà permesso.

Scrum e FPA sono amici

In breve, Scrum e FPA possono aiutarsi e rafforzarsi a vicenda in modo eccellente. I punti funzione ti aiutano a tenere sotto controllo le spese totali. Utilizzando Scrum rimani flessibile sulla base di intuizioni. In definitiva spetta a te risolvere il problema generale. Veloce come, il più buono ed economico possibile. In quella zona, i punti funzione e Scrum hanno un obiettivo comune.
Quindi Scrum e FPA sono amici. La perdita di controllo e il superamento del budget è il (Comune) nemico!

Vittorie veloci

Vittorie veloci nella combinazione Scrum e Function Points

  1. Più rapida concretizzazione del Product Backlog
    Il Product Backlog è la descrizione di tutti i requisiti non implementati che devono essere realizzati. Nella parte superiore del Product Backlog ci sono gli elementi più importanti per l'azienda e solo questi elementi vengono elaborati in dettaglio. La dimensione del Product Backlog può essere concretizzata utilizzando FPA. Spettacoli FPA che cosa è richiesta la funzionalità. FPA fornisce quindi una sintesi del Product Backlog in termini funzionali.
  2. Obiettivo misurabile
    Un Product Backlog dettagliato per i primi sei sprint è sufficiente per fare un FPA stimato (ISO / IEC 24570 Metodo di misurazione delle dimensioni funzionali Nesma). Il numero di punti funzione può quindi essere estrapolato al totale. Così, l'ultimo goal (il punto all'orizzonte) può essere quantificato, e il risultato finale diventa tangibile, senza la necessità di specifiche dettagliate per l'intero prodotto.
  3. Misurazione più semplice del "valore aggiunto"’
    La velocità con cui un team fornisce il software è misurata in story point. Queste sono stime relative della dimensione del lavoro. Questi story point non devono essere confusi con i function points. Non si assomigliano nemmeno (tranne nel nome, ovviamente). I punti funzionali sono rivolti verso l'esterno e considerano il progetto complessivo. Gli Story Point sono rivolti verso l'interno e aiutano a evitare che un team Scrum morda più di quanto possa masticare. In Scrum comunque, è difficile esprimere il valore fornito. tuttavia, questo può essere fatto in modo eccellente in termini di: Punti funzione!
  4. Aiuta a dare priorità alle funzionalità
    Un aspetto importante di Scrum è determinare la funzionalità desiderata con il più alto valore di business, che verrà poi ripreso nel prossimo sprint. Con l'Estimated FPA la lista dei desideri totale – e all'interno di quello, i prossimi sprint – può essere misurato in modo semplice, anche per quanto riguarda il raggruppamento di funzionalità. Il quadro generale è mantenuto e i turni sono tracciabili.
  5. Assistenza nell'effettuazione di preventivi
    La stima è il compito del team. Fare un preventivo è sempre (e rimane) una faccenda complicata. Dopotutto, una squadra non ha la sfera di cristallo e prima che tu lo sappia, le stime vengono utilizzate come se fossero garanzie. Stime di Scrum con story point, ma questi sono relativamente: paragonabile alla squadra ma non oltre. Punti funzione, però, sono assolutamente e confrontabili. I punti di funzione sono confrontabili tra i progetti e non possono essere misurati solo in anticipo, ma anche durante e dopo un progetto. Così, il team riceve un aiuto extra per fare stime.
  6. Rilevamento dei miglioramenti
    Poiché la FPA fornisce una misura oggettiva, può essere utilizzata nella retrospettiva del processo Scrum per mostrare miglioramenti. Così puoi aiutare le squadre ad imparare gli uni dagli altri ea rilevare i principali fattori inibitori.
  7. Conferma del business case per Scrum
    Mentre molte organizzazioni sono entusiaste di Scrum, Si può sentire rumorosamente che i processi di Scrum includono più rielaborazioni (avanzando intuizione) il che li renderà più costosi. È possibile determinare il numero di punti funzionali della funzionalità nuova e migliorata e quindi stabilire la produttività sia dell'adattamento che dell'intero processo. Quindi il business case può essere determinato oggettivamente.

Questo blog è stato originariamente pubblicato come articolo di opinione in Guida all'automazione (in olandese).

 

Riguardo agli Autori

Jolijn Onvlee (jolijn@onvlee.com) è uno specialista e consulente FPA indipendente, revisore e docente in materia di qualità, gestione del budget e della produttività. Jolijn ha anche lavorato per molti anni come presidente e membro del consiglio di Nesma.

Rini van Solingen è CTO presso Prowareness (rini@scrum.nl) e professore presso l'Università Tecnica di Delft. Rini è l'autore del libro “Il potere di Scrum”; ora pubblicato anche in francese, Tedesco e inglese.

Condividi questo post su:

4 Commenti

Lascia un commento
  1. Ian Alyss dice:

    Ciao Jolijn e Rini,

    Bell'articolo, ma c'è ancora molta resistenza all'interno della comunità degli sviluppatori contro l'uso dei punti funzione. C'è un bell'articolo di Jean-Pierre Fayolle che lo spiega: http://qualilogy.com/en/do-developers-dream-of-automated-function-points-1/ Come pensi a questo proposito.

    Ian

  2. Ciao Ian, sì, riconosco la resistenza degli sviluppatori quando FPA viene introdotto nell'organizzazione. Hanno paura che il loro (individuale) la produttività verrà misurata e mantenuta rispetto ad altri sviluppatori. Ma…. L'FPA non può essere utilizzato per misurare la produttività di un individuo. È sempre lo sforzo di squadra che stai misurando. FPA è uno strumento per il proprietario del prodotto! E ci sono diversi modi per implementare FPA nel tuo progetto srum!
    Sfido che l'FPA sia un metodo molto difficile, in particolare l'Estimated FPA come menzionato nel blog.

lascia un commento