Calcolo delle pietre miliari / Elenco delle attività

5

Il mio project manager mi ha assegnato un compito per stimare il tempo di sviluppo per un'applicazione iPad. Supponiamo che abbia dato una stima di 15 giorni lavorativi. Pensava che il numero di giorni in cui troppi e client richiedevano urgentemente le modifiche all'applicazione (come nella maggior parte dei casi).

Quindi, mi ha detto: "Assegnerò lo sviluppatore due che include te e, secondo le mie comprensioni ed esperienza, non impiegherà più di sette giorni lavorativi ".

Chiarimenti

Mi è stato assegnato il compito di stimare il tempo di sviluppo per un individuo. Come potrei essere sicuro che 2 sviluppatori lo finiranno entro 7 giorni? (Sono nuovo per la squadra e conosco a malapena le altre abilità)

Domande

  • Perché la maggior parte dei project manager / team leader ha intese come:
    • Se uno sviluppatore richiede N giorni,
    • Quindi due sviluppatori richiederebbero N / 2 giorni,
  • Pensano qualcosa come developer = s/w production machines ?
  • Se un membro del team (sviluppatore, non team lead o post superiore) stimano gli altri sviluppatori a lavorare?

Non ho negato nulla nella riunione e non ho detto, ma quale dovrebbe essere la risposta appropriata per convincerli che la formula N / 2 che seguono non è corretta?

    
posta Sagar R. Kothari 25.11.2011 - 08:28
fonte

2 risposte

5

Solo gli sviluppatori con esperienza reale sono in grado di stimare correttamente. Il motivo è che il confronto ripetitivo tra le sue stime e ciò che è realmente accaduto (errori) gli insegna intuitivamente ad aumentare le sue capacità.

Pochissimi sviluppatori o manager esperti sono in grado di stimare per gli altri. Stimare per un'intera squadra è ancora più complicato e personalmente credo che sia impossibile senza strumenti adeguati.

Ecco perché la stima collettiva come la pianificazione del poker accoppiata al tracciamento della velocità è la strada da percorrere.

Pianificazione del poker aiuta il team ad evitare di essere influenzato da pregiudizio cognitivo (i pensieri sono influenzati da credenze, ambiente, ecc.), mentre il tracciamento della velocità , successivamente utilizzato nella pianificazione, aiuta il gestore a convertire le stime soggettive in stime realistiche.

    
risposta data 25.11.2011 - 09:19
fonte
3

Questa è una trappola di stima standard che la maggior parte delle persone incontra quando le autorità superiori non hanno una visione più approfondita del problema. Il nodo del problema non è una stima. Nemmeno i dettagli, ma in genere tutto si riduce a percezioni (o in alcuni casi, citazioni competitive che i ragazzi di marketing devono corrispondere).

La maggior parte dei project manager tende a stimare pad ; e la maggior parte delle persone che gestisce i PM, lo sa, e un circolo vizioso o la contrattazione per le stime continua. Non ho visto un PM che avrebbe vinto un simile affare!

In generale, quando ritieni che sia difficile superare gli argomenti di stima, è ora di implementare Agile o iterativo. In poche parole, prova prima a fare la cosa più importante e invita il cliente (oi rappresentanti) a convalidare.

Come regola generale, proverei a convincerli con solo una prima versione definitiva che tutti confermano come la più importante e una pietra miliare dopo quella - molte volte sul terreno che l'equilibrio dipende dalla comprensione fino a questo punto. Più si ottiene iterativo, migliore è la visibilità del progetto e le persone tendono ad apprezzare meglio i problemi.

In secondo luogo, identificare le aree di rischio chiave in precedenza. Individuare quali sono gli obiettivi chiave e le tappe fondamentali che hanno svolto un ruolo chiave nel successo o nel fallimento del progetto. E assicurati qual è il tempo minimo che puoi impiegare per arrivarci. Essere chiari e valutare chiunque quando potenziali problemi (in particolare i requisiti sono ancora aperti) alla luce del quale il caso peggiore nel caso migliore può ancora oscillare molto. Identificare ed evidenziare le sfide tecnologiche chiave. Uno potrebbe non sapere o potrebbe presumere che le cose potrebbero essere facili da fare.

Ultimo ma importante: evitare di ottenere più risorse per ridurre i tempi.

Leggi questo articolo 1. articolo Come fornire applicazioni di qualità nei tempi e nel budget e
2. prenota Rapido sviluppo .

Gli insegnamenti essenziali sono che mentre molte persone richiedono una pianificazione fast , hanno davvero bisogno (e vogliono) di un programma affidabile . Portare un modo prevedibile, stabile e più visibile di gestione del progetto porta tutta la sicurezza desiderata con cui la parte perché delle stime diventa ampiamente più accettabile.

Nel tempo, quando le persone si fidano di più, vedrai che le trappole di stima lentamente scompaiono.

    
risposta data 25.11.2011 - 09:10
fonte

Leggi altre domande sui tag