Qual è l'impatto di ITIL o CMMI sullo sviluppo?

Question

Ho letto molti libri su quali pratiche funzionano bene o meno nello sviluppo di software. E non ho mai sentito parlare di metodologie come ITIL o CMMI in nessun webcast o libro o blog nel campo dello sviluppo.

Ho sentito parlare di queste metodologie nella mia scuola, e per me sembra essere una pratica burocratica.

Tuttavia, tutti i libri di sviluppo di cui ho letto parlano di collaborazione o di documentazione. (Sì, molti libri agili)

Quindi la mia domanda è: le metodologie come ITIL o CMMI hanno qualche impatto o relazione con lo sviluppo o la vita quotidiana dello sviluppatore? E hai ottimi libri o blog che parlano di alcune buone idee in queste metodologie che posso utilizzare in un team di sviluppo?

Answer 1

ITIL è più focalizzato sull'infrastruttura e sul supporto e non sullo sviluppo, quindi la discussione su ITIL è probabilmente più appropriata sulla versione focalizzata di "IT" di StackOverflow che è presumibilmente in fase di sviluppo. Per inciso, faccio un'eccezione chiamando l'altro sito "IT" incentrato sul fatto che l'IT comprende infrastruttura, supporto e sviluppo nella maggior parte delle aziende ... probabilmente una buona percentuale di utenti di StackOverflow sono sviluppatori nei reparti IT.

Ho lavorato con CMMI e Team Software Process (TSP), entrambi prodotti di Watts Humphrey e del Carnegie Mellon Software Engineering Institute. Se si è impegnati nel miglioramento continuo e si crede che la misurazione sia al centro di qualsiasi miglioramento continuo, allora si troverà un valore in CMMI.

È molto facile fare CMMI (e TSP) in modo errato o in un modo che allontana gli sviluppatori e alla fine finisce per vestirsi o qualcosa che sembra buono su una pila di certificazioni. Guarda i venditori di sviluppo in India ... sono miracolosamente tutti a livello CMMI 5.Quello che non ti dicono è che è quasi sempre un piccolo progetto o team nella loro organizzazione che ha lavorato duramente per ottenere la certificazione, ma le pratiche ripetibili semplicemente non sono lì per il 95% della loro organizzazione.

L'attenzione al rilevamento del tempo (clock punching), al tracciamento dei difetti (quote bug), linee di codice (molti modi per "giocare" se si è così inclini) e rendere il processo ripetibile (facendo sembrare allo sviluppatore un ingranaggio senza libertà di innovare) disattivare molti sviluppatori. < - nota i contro argomenti argomentati tra parentesi.

Resta il fatto che il 90% degli sviluppatori (alcuni dei quali leggono StackOverflow o blog tecnici/siti Web) sparano alla sprovvista e sono carenti nell'autoconsapevolezza di dove risiedono le loro opportunità di migliorare. Per loro, il rigore del processo e l'opportunità di apportare miglioramenti incrementali della qualità attraverso l'autoconsapevolezza che la ripetizione e la misurazione facilitano sono componenti preziosi di CMMI.

Fatto bene, si ottengono gli stessi benefici dai metodi Agile come Scrum, dove ancora l'attenzione si concentra sulle iterazioni ripetibili, sull'apprendimento di ogni iterazione e sul miglioramento/restringimento del proprio obiettivo. Ci vuole molta maturità ed esperienza per guidare un team nell'adozione dei metodi Agile o CMMI e ottenere il massimo valore da essi.

Agile è sexy e CMMI è più sexy che si possa ottenere, motivo per cui non si sente tanto.

Answer 2

L'adozione agile tende ad essere di tipo bottom-up: i tecnici lo inciampano e lo raccomandano alla direzione.

ITIL/CMMI tende a essere top-down: la gestione inciampa su di essa e la spinge verso il basso verso i tecnici.

Ciò non rende l'uno buono e l'altro cattivo; principalmente ciò influenza il linguaggio usato per descrivere ciascun approccio. E ci sono un sacco di eccezioni - persone con esperienza nelle trincee che sono brave nell'applicare CMMI, e manager che arrancano agile.

Google per "agile CMMI" e otterrete molti successi. Preferisco non raccomandarne uno in particolare, perché è un dibattito in corso (ad esempio alcune di queste persone sono semplicemente sbagliate).

Dal mio punto di vista, la nozione di processo è certamente un'idea utile quando si analizzano le attività quotidiane di sviluppo del software. L'idea che ci siano alcune attività ricorrenti e che queste attività siano spesso organizzate in sequenze simili, è un buon punto di partenza per porre domande che portano a miglioramenti. È anche possibile ottenere un po 'di chilometraggio chiedendo cosa è ripetibile e in quali condizioni le attività possono essere chiamate gestite.

L'errore e gli eccessi iniziano quando il pensiero magico inizia: "Se descriviamo (sulla carta) il processo perfetto e lo documentiamo accuratamente, le persone lo seguiranno e otterremo un software perfetto". Non funziona in questo modo.