Come spiegare che è difficile stimare il tempo richiesto per un progetto software più grande?

Potresti chiedergli di stimare quanto tempo ci vorrà per accedere ad una località lontana in un angolo disabitato del mondo. Come esempio estremo, scegliamo un picco meno conosciuto dell'Himalaya, dove poche persone (se ce ne sono) sono mai salite. Avrebbe avuto bisogno di un sacco di preparazione e di pratica prima di iniziare il viaggio, oltre a un mucchio di permessi, ognuno dei quali può ritardare il viaggio per mesi o anni ... e una buona squadra di supporto ... poi una volta in cima alla collina pendenza, avrebbe bisogno di aspettare e pregare per il bel tempo per iniziare a salire verso il picco ... ecc. ecc. La maggior parte di questi sono difficili da stimare, anche con precedenti esperienze.

E il punto è: ogni progetto software è un po 'come scalare una nuova montagna, dove nessuno è mai stato prima, quindi nessuno ha una precedente esperienza diretta. Gli sviluppatori stagionati possono aver accumulato esperienza su più o meno progetti simili , ma ci saranno sempre nuovi elementi e sorprese - altrimenti, se un progetto software fosse esattamente come alcuni quello precedente, non avrebbe assolutamente senso farlo .

L'hai spiegato alla persona? Tu sei l'ingegnere del software professionale, quindi la persona per cui crei software dovrebbe considerare le tue conoscenze e feedback quando si tratta della progettazione e dell'implementazione dei sistemi software.

Il Cono di incertezza è probabilmente un buon punto di partenza. I progetti software sono difficili da stimare fino a quando non si conosceranno altri dettagli, cosa che succederà più avanti nel progetto. Inoltre, il cambiamento dei requisiti cambierà anche le stime. Le tue stime iniziali all'inizio di un progetto avranno una grande quantità di variabilità.

Potresti essere interessato anche ad altre tecniche di stima. Hai detto che sei solo uno sviluppatore junior. Generalmente, gli sviluppatori più esperti hanno una migliore capacità di stimare dal momento che hanno visto più problemi, risolti e (si spera) tengono traccia della stima rispetto al tempo effettivo. Puoi trarre vantaggio da questo utilizzando tecniche di stima come delta banda larga o pianificazione del poker .

Come sviluppatore junior, inizia a monitorare le stime e il tempo effettivo ora. Potresti essere interessato a leggere del processo di personal software sviluppato presso il Software Engineering Institute. I libri di base su PSP sono Una disciplina per l'ingegneria del software , PSP: un processo di auto-miglioramento per gli sviluppatori software e Introduzione al Processo software personale . Credo che l'introduzione al processo del software personale riguarderebbe gli argomenti che troveresti più utili. Penso che sia generalmente eccessivo per la maggior parte degli sviluppatori, ma ha alcune buone idee e buone pratiche che possono essere estratte e utilizzate al fine di migliorare la produttività personale e affinare le varie abilità (compresa la stima) che userete continuamente durante la vostra carriera.

Se farai molto più lavoro di stima, ti consiglio vivamente due dei libri di Steve McConnell: Stima del software: Demistificare la Black Art (si concentra sulla stima come arte e scienza) e Rapid Development: Taming Wild Software Schedules (processo generale di ingegneria del software e argomenti di gestione del progetto).

Fare riferimento alla letteratura. C'è un mucchio enorme di materiale complesso e spesso contraddittorio, che, come dimostrato dalla pratica (esperimenti), non funziona come previsto. Almeno gli accademici sono influenzati da una pila di libri.

Must-read: link

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks, whose central theme is that "adding manpower to a late software project makes it later". This idea is known as Brooks' law, and is presented along with the second-system effect and advocacy of prototyping.

Brooks' observations are based on his experiences at IBM while managing the development of OS/360. He had added more programmers to a project falling behind schedule, a decision that he would later counter-intuitively conclude to have delayed the project even further. He also made the mistake of asserting that one project — writing an ALGOL compiler — would require six months, regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it." The book is widely regarded as a classic on the human elements of software engineering...

Scopri cosa pensano di fare con questa stima. Nella loro mente vogliono sapere se ci vorranno mesi o anni e stai cercando di ottenere le ore esatte (Tipico Ingegnere).

Vedi se riesci a lavorare su un pezzo del progetto e poi a mettere insieme una stima migliore se necessario.

Se continuano a spingere, sarai costretto a dettagliare il maggior numero di compiti possibile applicando un intervallo di tempo. Dì loro che li farai sapere non appena vedrai qualcosa che potrebbe influenzare la stima e apportare modifiche. Le persone di solito cercano di evitare sorprese.

Ho incontrato persone che sostengono di poter stimare il software, ma non so come lo fanno. Nessuno dei due è stato in grado di spiegare come lo fanno.

In qualità di consulente, i miei clienti mi richiedono spesso di lavorare su una base di offerta fissa. Quindi ho bisogno di stimare in modo da poter preparare un'offerta realistica. Non ci sono mai riuscito. Si potrebbe pensare che avrei sovraffollato tutte le volte che mi sono sottostimato, ma non è mai così. Il risultato è che spesso perdo molti soldi sui miei contratti e finisco per guadagnare molto meno di quanto avrei fatto se lavorassi per un'azienda come dipendente regolare.

Ho cercato per molti anni un libro che mi insegnasse come stimare il software, ma devo ancora trovarne uno.

Per spiegarlo a qualcuno che non è un programmatore. Potresti sottolineare che nessuno nel settore è costantemente in grado di soddisfare le loro stime. Succede sempre che i nuovi prodotti software siano preannunciati, solo per spedire mesi o anni dopo la data originariamente annunciata.

Se una grande azienda come Microsoft non riesce a capire come stimare il tempo necessario per produrre i propri prodotti, come posso?

Sia che venga pagato a ore o per lavoro, i miei clienti si aspettano sempre che fornisca queste stime. Non so come si aspettano che io li produca quando tale stima non è insegnata da nessuna parte, e non ho basi razionali per le mie stime.

La stima dell'intero tempo del progetto viene solitamente eseguita dal project manager e non dal programmatore.

È possibile creare un argomento basato sul fatto che il project manager ha l'elenco completo delle attività richieste. Senza questo elenco, qualsiasi stima sarà una "cattiva" ipotesi.

Inoltre, il tempo dipende da molti fattori come il numero di persone disponibili e l'ambito dei requisiti, che non hai detto di avere. L'architettura da sola non è sufficiente.

Un altro punto che potresti fare è che l'ingegneria del software è ancora agli albori rispetto ad altri campi dell'ingegneria, e non è maturata a sufficienza perché siano apparse tecniche di sviluppo stimabili.

Anche l'ingegneria del software è in continua evoluzione. Quando una tecnologia è stata abbastanza avanzata da essere considerata matura, viene spesso abbandonata a favore di alcune nuove tecnologie. Ciò impedisce a chiunque di acquisire un'esperienza sufficiente con una qualsiasi tecnologia per essere in grado di produrre stime affidabili.

Confrontalo con la stima della costruzione. Questo è un problema molto ben compreso, non solo perché gli appalti vengono assegnati in base alle offerte, ma perché l'umanità ha costruito cose sin dagli albori della civiltà.