Quale metrica / lista dovrebbe essere utilizzata per valutare l'intero team di sviluppo del software?

Inizia ad essere costruttivo e cerca le cose che stanno facendo bene. Se non lo fai, farai dei nemici e il tuo lavoro sarà molto difficile. Fai amicizia, scopri cosa vogliono, cosa motiverà (e demotivi), prima di parlare delle metriche.

Hai mai provato a scoprire perché fanno quello che stanno facendo?

Questo è molto probabilmente un problema di persone - mancanza di lavoro di squadra, mancanza di leadership, messa a fuoco errata (correzione di bug rispetto alla prevenzione di bug) ecc. Ci possono essere carenza di abilità, abilità, addestramento ecc., ma nella mia esperienza è un sintomo, non una causa di percorso.

Una parola di cautela sulle metriche: fai molta attenzione a ciò che misuri. Quello che misuri diventa tutto importante. Ciò che non misurate diventa irrilevante. Se misuri le cose sbagliate, guidi verso i risultati sbagliati.

Modifica - Questa domanda potrebbe essere utile - Anche se chiuso come argomento per programmatori è quasi certamente rilevante per la tua situazione. Leggere in particolare le opere di Steve McConnel.

Sono totalmente d'accordo con i punti che mattnz fa e offrono a parte questo.

Ho visto molto. il modello prototipo diventa il modello di produzione .

Di tanto in tanto una "Prova del concetto" viene montata in delirio per ottenere il buy-in da certe persone e poi ... qualcuno decide di mettere in produzione il "PoC" perché il potenziale cliente l'ha visto offerto di comprarlo oggi. Poi il giorno dopo tre clienti dicono di volerlo e il giorno dopo, sette clienti dicono di volerlo comprare.

Una volta che è stato venduto, devi consegnare e l'attenzione è spostata dalla creazione di un'applicazione scalabile reale a implementare funzionalità che sono molto richieste perché il PoC non le include.

Ottieni un po 'di storia sull'evoluzione del sistema prima di dare consigli.

Non confondere le preoccupazioni sintomatiche in base a pregiudizi personali (preferenza) con problemi di immagine di grandi dimensioni.

• Stanno spedendo software?

Se stanno spedendo software, ci sono alcune cose nel loro processo che stanno funzionando. Se non lo sono, quindi lavora su chi, perché, come e quando possono ottenere un piano di rilascio che possono incontrare.

• Per il software che stanno spedendo, gli sponsor / clienti / utenti sono generalmente soddisfatti? Stanno creando valore reciproco sia per il loro datore di lavoro che per il cliente? Sono le cose che il cliente ha bisogno di essere costruito? È ciò che viene consegnato onestamente rendendo più semplice il lavoro di sponsor / cliente / utente o è un altro livello di complicazioni o difficoltà?

Ogni cosa avrà dei bug. 'Bug Free' è un ideale che si applica solo a software di complessità molto limitata, con un ambiente molto statico. È qualcosa su cui puntare, ma a volte alcuni bug non valgono la pena di investire. Semplicemente perché nessuno ha identificato un bug nel software "bug free" non significa che non sia lì, significa semplicemente che non è emerso o è stato segnalato. Inoltre, è ok dire occasionalmente no al cliente, specialmente quando si tratta di una funzionalità pie-in-the-sky che spinge inutilmente le date di rilascio e spedizione: consegnare le cose che sono fisse, o aggiustabili e rimandare le altre fino a un'altra data di spedizione quando c'è tempo per fare quelle altre cose. Preoccupati più tardi, poiché in seguito potrebbe non arrivare mai: potresti non dover mai risolvere o aggiungere quella funzione.

Diversi anni fa ho sentito una definizione per consulente come:

A guy who can tell you a thousand ways to make love to a woman, but can't get a date.

Penso che tu non debba essere quel ragazzo, a patto che tu abbia le competenze pratiche per andare giù nella lista che hai fatto qui e decidere quale risolvere attraverso una o più volte per il cliente, allenandoti fornisci o acquisti per il personale e per modifiche dello staff che consigli e aiuti ad eseguire.

Forse puoi chiedere di non essere un consulente, ma di essere invece un gestore provvisorio per il software. Avrai bisogno e avrai bisogno dell'autorità decisionale sulla politica, e dovrai agire direttamente, non da una distanza per apportare le modifiche necessarie. Penso che Machiavelli consigliò che quando il Principe conquistasse una città, doveva andare a vivere lì per esercitare il suo potere di governo. Credo che se vuoi apportare cambiamenti duraturi, non c'è altro modo che andare lì e indirizzare il cambiamento che difendi.

La tua lista sembra carina, ma può essere aumentata. Segui i soldi! Inizia con il cliente, scopri come funzioni, prezzi e pagamenti funzionano tra l'azienda ei suoi clienti. Valutare la gestione dei requisiti, la stima, la pianificazione e il tracciamento integrati e la qualità. Come con SEI CMM, è bene iniziare con la gestione in cui si verificheranno le più alte variazioni di leva finanziaria, quindi indirizzarsi verso gli sviluppatori. I metodi Scrum e Agile sono grandiosi, ma c'è un'attività di vendita significativa in ogni fase per mantenere dirigenti, manager e professionisti in attività, apportando le modifiche che risolvono i problemi.