9.0 Waterfall vs. Project Management ciclico (Parte 2) – Stima di tempo e risorse

La tecnica della cascata è suddivisa in fasi. I leader di progetto devono includere stime per la quantità di tempo (e quindi denaro) necessaria per ogni fase nei loro piani di progetto. Abbiamo precedentemente stabilito che le stime dei tempi sono intrinsecamente problematiche per qualsiasi progetto, tanto più quando devono essere impostate all’inizio della vita del progetto. Non è fattibile per i progetti software. Considerare la possibilità che durante la fase di definizione possa essere compilato un elenco di capacità qualitativamente accettabile. In linea di principio, ciò dovrebbe consentire al team di progetto di fornire una stima realistica del tempo necessario per sviluppare ciascuna funzionalità. Tuttavia, in realtà, ci sono troppe incertezze per fornire una buona approssimazione:

Tuttavia, in realtà, ci sono troppe incertezze per fornire una buona approssimazione:

  • Spesso, dopo che una funzionalità è stata sviluppata, si scopre che il client non ne ha bisogno. Pertanto, le ore trascorse a sviluppare questa funzionalità possono essere considerate vane.
  • Nel corso del progetto, i requisiti possono cambiare.
  • La capacità deve essere fornita a un costo elevato oa un costo basso? Esistono molte tecniche di implementazione e realizzazione.
  • Come sarà progettata tecnicamente la funzionalità? Il design influenza notevolmente la quantità di tempo necessaria per crearlo.
  • Fino a che punto il funzionamento deve essere di alto livello? Ad esempio, un’applicazione Web dovrebbe essere completamente accessibile in ogni momento o dovrebbe essere inattiva per alcune ore all’anno?
  • Il tempo necessario per rilevare e correggere i problemi del software varia da minuti a settimane.
  • Quanto tempo impiegherà il nuovo software per l’installazione e l’integrazione con i sistemi attuali del cliente?
  • La mancanza di informazioni sulle potenziali soluzioni influisce ulteriormente sulle stime dei tempi. Inoltre, stimare il tempo necessario per acquisire le competenze richieste è impegnativo.

L’elenco di cui sopra dimostra che una varietà di variabili può influenzare il tempo necessario per sviluppare un nuovo software. Le stime del tempo necessario per sviluppare una funzionalità all’inizio di un progetto sono spesso quattro volte troppo basse o quattro volte troppo alte. Ciò implica che il tempo richiesto può essere quattro volte più o quattro volte meno di una stima errata. Man mano che il progetto si sviluppa, queste stime diventano più precise. Dopo aver completato il design funzionale, il margine viene ridotto del 25% in più o in troppo poco. Solo quando la funzionalità è stata sviluppata è possibile fornire una stima con un alto grado di confidenza.

Rischi software #

Software di gestione del progetto non sarà mai completamente esente da errori. Anche per i programmi noti e ampiamente utilizzati (ad es. Word, Excel, Explorer, OS X, PHP e Flash), Internet ha elenchi di difetti noti. Sul mercato vengono regolarmente rese disponibili nuove versioni che risolvono i bug del software. I clienti a volte richiedono che il software sia privo di errori. In realtà, però, un simile obiettivo renderebbe impossibile completare un pezzo di software. Inoltre, gli errori del software spesso non sono inerenti al programma.

Flash è stato utilizzato per creare un gioco didattico. Il cliente ha accettato di ottenere il gioco come file e installarlo sul proprio server. Nel corso del progetto, il cliente ha chiesto che fosse aggiunta al gioco una funzione di punteggio elevato per migliorare la competitività dei giocatori. Ciò richiederebbe un codice di script PHP. Gli sviluppatori del gioco hanno sviluppato e testato il codice dello script sul proprio server con Linux. Ha avuto successo. Il client ha ricevuto il codice del gioco e dello script. Tuttavia, il client utilizzava un server Windows e, per qualche motivo, lo script ha smesso di funzionare correttamente. I voti migliori non sono stati mantenuti. Il programmatore ha bisogno di una settimana per risolvere il problema. A quanto pare, PHP e Windows non funzionano sempre bene insieme. La sceneggiatura nella sua interezza non ha avuto alcun errore! È stato in grado di farlo funzionare tramite l’uso di un hack, e tutti erano contenti, ma chi dovrebbe pagare per quella settimana aggiuntiva di lavoro?

Un altro progetto di sviluppo software ha incluso anche la creazione di applicazioni didattiche. Il problema era che il software funzionava benissimo per gli sviluppatori ma non per il cliente. Dopo aver esaurito tutte le altre possibilità, il programmatore decise di fare una visita al cliente. Come si è scoperto, il cliente utilizzava una macchina Pentium III dei primi anni ’90. La lentezza del computer ha contribuito alle scarse prestazioni del software. Inoltre, i programmatori hanno provato il software su un Pentium III e ha funzionato bene. Un ulteriore esame ha mostrato che il PC del cliente funzionava lentamente a causa di un’infezione da virus e spyware.

Gestire le incertezze nello sviluppo del progetto #

L’incertezza mostrata dalle istanze di cui sopra complica il processo di sviluppare piani di progetto . Inoltre, complica le negoziazioni tra le parti. Qualcuno deve sopportare i rischi associati al lavoro aggiuntivo che deve essere eseguito. Se il pagamento viene effettuato ogni ora, il cliente si assume tutti i rischi. Quando viene concordata una tariffa fissa (come nel caso dei progetti finanziati da sovvenzioni), lo sviluppatore del software si assume il rischio. Quando sono coinvolte più di due persone, la situazione si complica. In questo scenario, chi dovrebbe sostenere il costo delle ore aggiuntive lavorate sul progetto?

Spesso emergono controversie su chi debba essere ritenuto responsabile per i ritardi. Spesso, la persona responsabile è difficile da identificare. È del tutto ipotizzabile che nessuna delle parti coinvolte sia responsabile, poiché il “ritardo” è stato causato da un’errata stima iniziale del numero di ore necessarie. Ore di progetto eccessive e la questione di chi dovrebbe pagare sono cause comuni di contesa nel settore della tecnologia dell’informazione.