Stima dei tempi nello sviluppo software

Una guida su come effettuare stime efficaci in maniera efficiente.

La stima dei tempi e la pianificazione sono attività critiche, spesso complicate e prone ad errori. Tuttavia non ci possiamo esimere da queste solo perché sono difficili. La stima ottenuta nelle prime fasi del progetto sarà sicuramente meno accurata di quella in corso d’opera; tale stima andrà via via affinandosi, come mostrato dal cono di incertezza (Figura 3.6).

 

 Cono di incertezza per la stima delle attività nello sviluppo software
Fig. 3.6: il cono di incertezza nella stima di un progetto

 

L’obiettivo della pianificazione consiste nel trovare una risposta ottimale per l’intero processo di sviluppo rispetto alla domanda “cosa dobbiamo fare”. La risposta ingloba funzionalità, risorse, e le tempistiche. Per dare una risposta a tale domanda occorre seguire un processo di pianificazione atto a:

  • ridurre il rischio,
  • ridurre l’incertezza,
  • dare un supporto efficace alle decisioni,
  • dare fiducia,
  • convogliare l’informazione.

 

La giusta pianificazione è quella che è sufficientemente affidabile per essere usata come base per prendere decisioni in merito al progetto.

I tradizionali approcci si focalizzano sulle attività da fare, distogliendo l’attenzione dalle funzionalità da realizzare, che in realtà sono l’unica e vera unità di misura del valore percepito dal cliente. All’interno di una pianificazione per attività, l’ipotesi di non rispettare una scadenza porta ad una serie di conseguenze negative. Nonostante le buone intenzioni, i membri del progetto possono interpretare il multitasking (ovvero lavorare su più attività contemporaneamente) come soluzione per velocizzare il completamento delle attività; talvolta si instaurano condizioni per cui lo sviluppatore si trova ad avere assegnate più attività entro scadenze analoghe, magari a causa della sua partecipazione a più progetti, o per attività su progetti già congegnati. In realtà lavorare su più attività ha costi nascosti, spesso ignorati da chi gestisce il progetto, spesso inevitabili, ad esempio nel caso in cui si presentino criticità su altri progetti già consegnati o in fase di consegna. Durante gli sviluppi, le funzionalità implementate tramite le attività pianificate sono quelle ritenute più convenienti dagli sviluppatori, così che nel caso in cui si arrivi alla scadenza con il progetto ad uno stato parziale, le funzionalità non ancora implementate non necessariamente sono quelle ritenute meno importanti dall’utente finale. Ignorare l’incertezza, che riguarda cosa esattamente vuole l’utente, può portare a completare il progetto entro le scadenze senza includere importanti funzionalità richieste dall’utente e che erano state definite al momento della creazione del progetto. Quando si ignora l’incertezza in merito a come il prodotto sarà sviluppato, la situazione si traduce in attività mancanti all’interno del project plan. Questo aumenta la probabilità che il progetto sarà in ritardo, che alcune funzionalità saranno eliminate alla fine del progetto, o che alla fine si giunga ad un compromesso tra cliente e fornitore, che spesso risulta appropriato solo per quanto riguarda la situazione economica tra i due soggetti, mantenendo il progetto consegnato in uno stato subottimo rispetto alle necessità.

Il principio di base che sottende l’Agile planning è concentrarsi sulla pianificazione piuttosto che sulla creazione del piano stesso, incoraggiando il cambiamento. Questo principio si traduce in pianificazioni facilmente modificabili e che seguono il progetto per tutto il corso della sua vita.

Il proposito dell’Agile planning è scoprire in maniera iterativa la soluzione ottima per il problema, per determinare quali funzionalità verranno implementate da quali risorse e in quali tempi. L’approccio agile ha successo poiché tali pianificazioni:

 

  • sono effettuate a più livelli e aggiornate frequentemente,
  • si basano sulle funzionalità da realizzare piuttosto che sulle attività,
  • vengono stimate prima in termini di volume di lavoro, poi convertite in tempi,
  • misurano il progresso a livello di team, non di individuo,
  • prevedono e gestiscono l’incertezza.

 

I team di lavoro Agili lavorano insieme come una squadra, ma includono ruoli associati a specifici individui:

 

  • product owner: colui che è responsabile per la visione del prodotto e per la prioritarizzazione delle funzionalità su cui lavorerà il team; nel caso il progetto sia su commissione il product owner è generalmente lo stakeholder che ha la responsabilità del progetto.
  • customer: colui che pagherà per acquistare il prodotto, o nel caso in cui il progetto sia su commissione, colui che ha commissionato il progetto.
  • User: chi utilizzerà il software.
  • Developer, Menagers, etc.

 

I team agili lavorano in brevi iterazioni temporalmente circoscritte, così che al termine di ciascuna iterazione sia consegnato un prodotto funzionante. Le funzionalità implementate durante un’iterazione sono selezionate sulle necessità di business, ovvero in base alla priorità percepita dal cliente. Questo garantisce che le funzionalità più importanti siano sviluppate prima, e che il concetto di importanza non sia definito dal team di sviluppo bensì dal cliente stesso, assicurando che siano soddisfate le sue aspettative.

danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres

Lascia un commento