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

Sono uno sviluppatore junior e trovo difficile stimare quanto tempo ci vuole per completare un progetto software più grande. So strutturare l'architettura in generale, ma è difficile per me sapere quali dettagli devo fare e quali problemi devo risolvere. Quindi è difficile stimare quanto tempo ci vorrà per finire un progetto più grande, perché non so quali problemi devo risolvere e quanto tempo ci vuole per risolverli.

Come posso spiegarlo a una persona che non è uno sviluppatore di software ?

Potresti chiedergli di stimare quanto tempo impiegherà ad accedere a una posizione lontana in un angolo disabitato del mondo. A titolo di esempio estremo, scegliamo qualche picco meno conosciuto in Himalaya, dove poche persone (se ce ne sono) sono mai salite. Avrebbe bisogno di un sacco di preparazione e pratica prima ancora di iniziare il viaggio, oltre a un mucchio di permessi, ognuno dei quali può ritardare il viaggio da mesi a anni ... e una buona squadra di supporto ... poi una volta in salita pendenza, avrebbe bisogno di aspettare e pregare per il bel tempo per iniziare a salire verso il picco ... ecc. ecc. Molti di questi sono difficili da stimare, anche con esperienza precedente.

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

L'hai spiegato alla persona? Sei un ingegnere software professionista, quindi la persona per cui stai creando software dovrebbe considerare le tue conoscenze e il tuo feedback quando si tratta di progettare e implementare sistemi software.

Il cono di incertezza è probabilmente un buon punto di partenza. I progetti software sono difficili da stimare fino a quando non si conoscono più dettagli, cosa che accade più avanti nel progetto. Inoltre, cambiando i requisiti cambieranno anche le stime. Le tue stime iniziali all'inizio di un progetto avranno una grande 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 stima poiché hanno visto più problemi, risolti e (si spera) hanno tenuto traccia della stima rispetto al tempo reale. Puoi trarne vantaggio usando tecniche di stima come delphi a banda larga o poker di pianificazione .

Come sviluppatore junior, inizia a monitorare le stime e l'ora reale ora. Potresti essere interessato a leggere sul processo di software personale sviluppato presso il Software Engineering Institute. I libri di base di PSP sono Una disciplina per l'ingegneria del software , PSP: un processo di auto-miglioramento per gli ingegneri del software e Introduzione al processo del software personale . Credo che l'introduzione al processo del software personale riguarderebbe gli argomenti che potresti trovare 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 varie abilità (compresa la stima) che userete continuamente durante la vostra carriera.

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

Fare riferimento alla letteratura. C'è un enorme mucchio 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.

Da leggere: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

The Mythical Man-Month: Essays on Software Engineering è un libro di ingegneria del software e project management di Fred Brooks, il cui tema centrale è che "l'aggiunta di manodopera a un progetto software tardivo lo rende in seguito". Questa idea è nota come legge di Brooks e viene presentata insieme all'effetto del secondo sistema e alla difesa della prototipazione.

Le osservazioni di Brooks si basano sulle sue esperienze in IBM durante la gestione dello sviluppo di OS / 360. Aveva aggiunto più programmatori a un progetto in ritardo sui tempi previsti, una decisione che avrebbe in seguito controintuitivamente concluso per aver ritardato ulteriormente il progetto. Ha anche commesso l'errore di affermare che un progetto - la scrittura di un compilatore ALGOL - avrebbe richiesto sei mesi, indipendentemente dal numero di lavoratori coinvolti (richiedeva più tempo). La tendenza dei manager a ripetere tali errori nello sviluppo del progetto ha portato Brooks a dire che il suo libro si chiama "La Bibbia dell'ingegneria del software", perché "tutti lo citano, alcune persone lo leggono e alcune persone lo seguono". Il libro è ampiamente considerato un classico sugli elementi umani dell'ingegneria del software ...

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

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

Se continuano a spingere, sarai costretto a elencare il maggior numero di attività possibile per applicare un lasso di tempo. Di 'loro che lo farai sapere non appena vedrai qualcosa che potrebbe influenzare il preventivo e apportare modifiche. Le persone di solito cercano di evitare sorprese.

Ho incontrato persone che affermano di poter stimare il software, ma non so come lo facciano. Né nessuno di loro è stato in grado di spiegare come lo fanno.

Come consulente, i miei clienti spesso mi richiedono di lavorare con un'offerta fissa. Quindi devo fare una stima in modo da poter preparare un'offerta realistica. Non ci sono mai riuscito una volta. Si potrebbe pensare che esagererei tutte le volte che lo sottopongo, ma non è mai così. Il risultato è che spesso perdo molti soldi con i miei contratti e finisco per guadagnare molto meno di quanto farei 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.

Quanto a spiegare questo a qualcuno che non è un programmatore. Si potrebbe sottolineare che nessuno nel settore è costantemente in grado di soddisfare le proprie stime. Accade continuamente che vengano preannunciati nuovi prodotti software, solo per la spedizione mesi o anni dopo la data originariamente annunciata.

Se una grande azienda come Microsoft non riesce a capire come stimare il tempo impiegato per la produzione dei propri prodotti, come posso fare?

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

La stima dell'intero tempo del progetto viene generalmente 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 supposizione "negativa".

Inoltre, il tempo dipende da molti fattori come quante persone sono disponibili e la portata dei requisiti, che non hai detto di avere. L'architettura da sola non è abbastanza.

Un altro punto che potresti sottolineare è che l'ingegneria del software è ancora agli inizi rispetto ad altri campi dell'ingegneria e non è maturata abbastanza da far apparire tecniche di sviluppo stimabili.

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

In contrasto con la stima della costruzione. Questo è un problema ben compreso, non solo perché i contratti vengono aggiudicati in base alle offerte, ma perché l'umanità ha costruito le cose dagli albori della civiltà.