Sì, questo è solo un termine che viene gettato in giro dai tipi di gestione ma se togli il linguaggio di gestione ciò che sta dicendo è che vuole un dipartimento che viene visto come usando e incarnando le migliori pratiche del settore in un modo che gli altri aspirano e stanno facendo così per offrire grandi soluzioni alla gente.
(Quest'ultimo bit è importante - se non stai effettivamente consegnando, non importa quanto sia bello tutto il resto e il tuo manager non sarà in giro a lungo).
La complessità si presenta in due modi principali:
1) Lo vuole perché capisce che è il modo giusto di sviluppare software e che è così che produci ottimi prodotti, o lo vuole perché vuole essere in grado di vantarsene?
2) Accetterà i costi iniziali (tempo, denaro, credibilità e rischio) associati all'implementazione delle migliori pratiche? Va bene dire "andiamo agili", ma sta mettendo la sua reputazione sulla linea che migliorerà le cose e dovrà passare molto tempo a venderlo nell'organizzazione. Quasi sempre i benefici sono a lungo termine, i costi sono a breve termine e questo è un aspetto difficile. In definitiva, è davvero serio?
In termini di come sarebbe, dipende da cosa stai facendo, ma devi pensare in termini di quali sono i tuoi processi di sviluppo e gestione del progetto, quali strumenti stai usando, quali kit hanno le persone e così via . Il test Joel è sempre un buon punto di partenza e in particolare vorrei vedere un processo di controllo della versione davvero solido, un tracciamento dei bug davvero buono e processi di compilazione davvero buoni.
Vorrei anche verificare se le metodologie agili sono giuste per te (SCRUM in particolare), in che misura i test automatizzati potrebbero aiutare (senza iniziare una guerra religiosa ci sono convinzioni diverse sul punto in cui la complessità dei test supera i benefici che hanno fornire) se hai gli strumenti e il kit necessari per svolgere il lavoro. Generalmente suggerirei che desideri che gli strumenti siano all'avanguardia ma non sanguinanti. Vale la pena sottolineare che non si tratta di avere giocattoli, ma di dare a tutti i membri del team gli strumenti per essere il più produttivi possibile per la maggior parte della giornata lavorativa possibile. L'esempio più ovvio sono i PC danneggiati: è davvero eccellente pagare agli sviluppatori di guardare un cursore mentre il loro progetto impiega 5 minuti per essere costruito quando lo costruiscono mezza dozzina di volte al giorno?
Alcune altre cose che probabilmente saranno visibili in un centro di eccellenza: suggerirei che un centro di software di eccellenza abbia probabilmente un programma di formazione piuttosto buono - forse non corsi formali ma certamente budget di libri, tempo di studio, tutoraggio e piace.
E suggerirei che probabilmente sta facendo anche una piccola quantità (almeno) di ricerca e sviluppo. Con ciò non intendo cose completamente a cielo azzurro, ma dare agli sviluppatori spazio per provare nuove cose e valutare nuovi strumenti e linguaggi senza la continua pressione della consegna al cliente. Ecco come andare avanti e rimanere bene l'anno prossimo, l'anno successivo e così via.
Come puoi misurarlo? Ah, la domanda secolare. Misurare in definitiva lo sviluppo del software è difficile, se non impossibile, e misurare l'eccellenza nello sviluppo del software è altrettanto difficile.
L'unica cosa che posso davvero suggerire di ritenere utile che sia ampiamente adottata da molte aziende è la soddisfazione del cliente e del personale. È una misurazione indiretta, ma la mia opinione sarebbe che se non sei eccellente, è improbabile che otterrai livelli davvero grandi di soddisfazione del cliente e livelli davvero grandi di soddisfazione del personale.