c'è un modo elegante per analizzare il processo di un ingegnere?

Non sono sicuro che lo considereresti elegante, ma Watts Humphrey ha scritto un intero libro intitolato Personal Software Process che era tutto incentrato sulla misurazione della tua produttività. Ha delineato le metriche per gli input come il tempo alla scrivania vs. le interruzioni, il tempo trascorso a lavorare su vari tipi di attività del ciclo di vita del software, i difetti per quantità di codice. C'è un rapporto tecnico che fornisce la versione breve su:

link

Se si vuole guardare qualcosa come la qualità di un codice sviluppatori, Chidamber & Kemerer ha proposto diverse metriche per il codice orientato agli oggetti.

Metriche per codice orientato agli oggetti

• depth of inheritance tree,
• numero ponderato di metodi,
• numero di funzioni membro,
• numero di bambini e
• accoppiamento tra oggetti.

Usando una base di codice, hanno provato a correlare queste metriche alla densità dei difetti e allo sforzo di manutenzione usando l'analisi covariante. Studi successivi hanno effettuato analisi simili su centinaia di progetti Source Forge Java per determinare le loro caratteristiche relative a CK Metrics e alcuni parametri aggiuntivi proposti successivamente.

Metriche derivanti dal contesto delle recensioni di codice

I difetti possono essere classificati in base a diversi criteri:

• severità: (maggiore, minore, cosmetico, investigare / sconosciuto),
• tipo (logica, errore di battitura, ortografia, violazione standard di codifica, ecc.),
• contenimento origine / fase (requisiti, design, codice, ecc.).

Esistono anche i tassi di preparazione e ispezione (tempo per recensore, tempo per riga di codice) e densità dei difetti (per KLOC (migliaia di righe di codice), al minuto di tempo dell'ispettore / revisore).

Plotting these values against control charts can show us whether we are within bounds for the process (for example, a team that inspects 200 lines of code that finds no defects in a group that averages twenty-five defects per KLOC might be malfunctioning).

Altre metriche

Altre metriche che potrebbero aiutare a includere quelle per

• valore ottenuto per aiutare a calibrare la stima
• velocità per coloro che utilizzano Scrum o Kanban .
• Il lavoro di Pareto , Juran , Demming , Ishikawa , e altri di qualità e ingegneria industriale sono in qualche modo portabili allo sviluppo di software con un po 'di immaginazione.

Limiti di analisi

Ci sono enormi limiti sul valore delle metriche. I bug corretti per sviluppatore possono significare quasi tutto, e quando inizi a punire o premiare su quella misurazione, scommetto che i bug diventeranno più numerosi e granulari, e il mix di bug difficili da risolvere cambierà anche quando il team selezionerà correre per avere il massimo

C'è anche una certa distrazione e potenzialmente una perdita di concentrazione e divertimento che può arrivare con misurazioni intrusive. Non puoi diventare molto più elegante (ed emotivamente appesantito) di un poeta del lago come Wordsworth che ha detto,

      Sweet is the lore which Nature brings;
      Our meddling intellect
      Mis-shapes the beauteous forms of things:--
      We murder to dissect.

Mentre il software non è esattamente di natura, datemi un po 'di spazio perché pensavo che non avrei mai usato nulla della lezione di letteratura inglese delle scuole superiori.

Agile potrebbe essere considerato una reazione a un processo centralizzato e di grandi dimensioni. A volte quella modalità di lavoro potrebbe richiedere un così grande sforzo analitico che la capacità di raggiungere flusso durante la creazione di software è tutto tranne scomparso.

Voglio aggiungere una risposta alternativa che rimandi alla pratica dell'ingegneria del software standard verso un altro campo con l'obiettivo di rubare dagli strumenti di base che possiamo adattare secondo necessità. Gli addetti all'assicurazione della qualità si occupano della produzione, del rendimento e del rilevamento e della prevenzione dei difetti, proprio come gli sviluppatori di software.

link

Mi piace il grafico di controllo.

link

Esegui un'attività, traccia una metrica, fai un'altra, traccia la sua metrica e così via. Ad esempio, il plot si impegna al giorno. Il grafico scatterà i dati che vanno da un minimo ad un massimo. Forse in seguito è possibile caratterizzare i risultati per determinare che quando il valore è basso, qualcosa sta impedendo il progresso e quando è troppo alto, il lavoro inizia in modo rapido ma trascurato. Il modo in cui incoraggia i lavoratori ad accelerare o rallentare è lasciato a te.

Le metriche personali potrebbero essere qualcosa che puoi correlare a te stesso a partire da una domanda del tipo "Mi sento più produttivo quando ..."

• Scrivi un caso di utilizzo completo prima di iniziare a codificare.
• Scrivi i miei test di unità prima del mio codice.
• Controlla spesso con le parti interessate per assicurare che i requisiti non cambino e crei una massiccia rilavorazione sul lavoro svolto verso un piano obsoleto.
• Modifica il maggior numero possibile di codice.
• Delegare le modifiche ben definite ai membri del team che sono i più esperti con le parti che ho chiesto loro di cambiare.
  • Fornisci alla mia squadra una panoramica completa, ma con le priorità possiamo finire nello sprint attuale.
  • Inizia il mio passaggio di refactoring con un elenco gerarchico di directory, file, classi, metodi, equazioni, variabili, documentazione, ecc. che cambierò.
  • Ricercare un problema di alto livello per trovare soluzioni della tecnica nota, stimare l'ambito e i miglioramenti chiave necessari per ottenere una soluzione migliore.

Il vecchio ha visto ciò che misuriamo è ciò che viene fatto potrebbe portare ad attaccare il problema sulla base di ciò che si determina essere il fattore limitante

o più fattori in ordine di priorità in base a un diagramma di Pareto.

link