Qual è (sono) la tecnica / visualizzazione più utile per lo stato generale del progetto? [chiuso]

Per avere successo in questo compito, vorrei procedere come segue: (1) Specificare KPI da presentare per ciascun tipo di livello di gestione (suppongo che nel tuo caso, avrai 1)

(2) Distillare KPI (ad es. LOC deve essere evitato come indicato dal post bethlakshmi ). Inoltre, devi assicurarti che i dati riportati siano qualcosa che puoi produrre o calcolare con precisione usando gli strumenti che hai.

(3) Determina in che modo prevedi di raccogliere, calcolare e accumulare i dati aggiornati e assicurati che questo processo venga conteggiato nel tuo piano di progetto (sembra un lavoro di data mart)

(4) Specificare la migliore rappresentazione da utilizzare per presentare le informazioni (questa è la domanda) e fare un prototipo degli sguardi che devono essere approvati dai gestori.

Raccomando una presentazione in stile dashboard (vedi l'immagine di esempio qui sotto - So che non è elegante!)

Puoitrovarneunomiglioreall'indirizzo Strumento Telerik-TeamPlus

Ora come per (4), hai già identificato alcuni KPI. La prossima cosa è categorizzare gli indicatori KPI in gruppi (ad esempio Stato generale, Stato finanziario, Stato del personale, Stato attività) Ogni gruppo può essere rappresentato da una schermata / pagina / scheda Excel, ecc.

Oltre ai grafici di Burndown menzionati da altri responder, potresti utilizzare 1 o più diagrammi di Gantt per mostrare: 1 - Dipendenza complessiva del progetto di altissimo livello 2 - Pietre miliari per il periodo di riferimento in corso e il suo vicinato (ad esempio il mese corrente e 1 mese prima e dopo)

Le funzionalità di utilizzo e visualizzazione del software dipendono molto da cosa hai, da cosa ti puoi permettere, da dove sono i tuoi dati attuali, come prevedi di pubblicare le informazioni, ecc.

L'elenco da cui scegliere è lungo ( prodotto Telerik-TeamPlus , MS-Project, Rapporti Zoho , Zoho Progetti , Project Dashboard , tra gli altri ovviamente)

Direi che una parte di questo si riferisce alla tua cultura aziendale e agli aspetti dello sviluppo che devi misurare maggiormente. Nessuno può misurare tutto, quindi devi trovare e monitorare i punti più delicati che possono favorire la tua attività.

Ecco alcuni che ho trovato utili in vari momenti:

• I grafici di burndown, in particolare per il progetto Agile, richiedono che gli sviluppatori valutino e riportino costantemente il loro stato, la durata delle attività da completare e l'intera attività in un breve ciclo. Se si sta eseguendo un processo di sviluppo a cascata, il burndown di una fase può essere ancora utile, ma solo se i report di stato sono veramente accurati - spesso i progetti a cascata sono così carichi di documenti che ottenere una risposta diretta correlata allo stato è dolorosa e persino impossibile, che riduce notevolmente il valore di questo tipo di grafico.

• Bug trovati / corretti per unità di tempo - utile soprattutto in situazioni in cui è richiesta un'alta qualità - in genere un grafico con # bug sull'accesso orizzontale e il tempo in unità (come settimane) da sinistra a destra. Ci sono due linee: # di bug trovati ogni settimana, # di bug risolti ogni settimana. In un tipico processo a cascata, questo mostrerà - un costante e quindi un brusco aumento dei bug rilevati a settimana, che alla fine si assottigliano mentre i tester iniziano a colpire rendimenti decrescenti (in altre parole, devono diventare sempre più creativi per trovare quelli ultimi pochi bug). Quindi il numero di bug della linea fissa manterrà un po 'indietro rispetto ai # bug trovati. Alla fine sarà ritardato quando si accumulerà un arretrato e i riparatori saranno sbalzati dal lavoro. Mentre i tester rallentano, i fissatori si riprendono e i due iniziano ad avvicinarsi asintoticamente al punto finale. Da qualche parte intorno a questo appiattimento è quando il prodotto può essere rilasciato - diverse aziende hanno metriche diverse per quale livello di questo è alpha, beta, ecc. Funziona bene in una cascata, processo basato sulla tradizione, dove le aspettative di qualità sono elevate e i requisiti sono considerati sacro. Diventa più difficile negli sprint, dove cambi ogni volta i requisiti.

• Metriche del tipo SLA: quanto velocemente il team risponde ai problemi? Conosco meno questo tipo di monitoraggio, ma in un QA di un sistema live con utenti effettivi, questo è il re - indipendentemente dal processo di sviluppo, la natura del supporto ai clienti definirà la percezione della qualità del prodotto, quindi rispondere, comunicare e risolvere i problemi per i clienti in modo tempestivo con un minimo di costi è un grosso problema.

Come anti-raccomandazione - se avessi i miei druthers, eviterei qualsiasi cosa che abbia a che fare con "linee di codice" (LOC) - come SLOC (source LOC), ELOC (stimato LOC) e altri acronimi orribili . Alcune aziende si sono attenute a questa forma di metrica, perché 20 anni fa, era il modo in cui è stato fatto e hanno un enorme archivio storico. In questi giorni, il significato di 1 LOC e il lavoro richiesto per svilupparlo e sostenerlo possono cambiare radicalmente e costantemente, non solo con l'evolversi dei linguaggi di programmazione, ma anche con la modifica delle API, la creazione e il mantenimento del codice generato automaticamente e altri aspetti della programmazione lavoro. Ogni volta che vedo un sistema di metriche con LOC alla sua base, rabbrividisco, perché non vedo mai che produca risultati accurati e vedo una quantità insopportabile di tempo spesa cercando di giustificare questa mancanza di accuratezza. La maggior parte dei sistemi relativi alla LOC si concentra sul passaggio tra l'accuratezza delle previsioni (quanto grande? Quanto difficile da fare?) Rispetto al risultato effettivo. Penso che ci siano modi migliori, meno formali, per farlo - come i punti della storia - che daranno buoni risultati. La chiave per qualsiasi sistema di tracciabilità della previsione è che le persone che fanno le previsioni devono avere un modo palpabile di sperimentare l'accuratezza di tali previsioni se devono essere stimatori migliori in futuro. Per me, la stima nelle settimane uomo o nei punti della storia è stata altrettanto utile ...

Nota - Non sono in disaccordo con le metriche sull'accuratezza della previsione - penso che queste possano essere incredibilmente utili - specialmente in un ambiente di costruzione in cui la previsione e l'impostazione delle aspettative dei clienti sono una parte importante del successo del progetto.

Personalmente ritengo che il diverso tipo di grafici di burn-down utilizzati in progetti agili siano incredibilmente potenti in quanto rispondono alle domanda su "se il progetto continua a funzionare come è, quando abbiamo finito?". Nei progetti di solito utilizzo i burn-down per lo sprint corrente e per l'intera release. Le stime utilizzate per produrre il burn-down del release sono ovviamente meno precise ma, tutto sommato, tendono a prevedere abbastanza bene la consegna.