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

Question

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

Ho sentito parlare di queste metodologie nella mia scuola e per me sembra che siano pratiche burocratiche.

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

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

Answer 1

ITIL è più focalizzato sull'infrastruttura e sul lato supporto e non sullo sviluppo, quindi la discussione di ITIL è probabilmente più appropriata sulla quotazione &; IT &; versione focalizzata di StackOverflow che si suppone sia in fase di sviluppo. Per inciso, prendo un'eccezione chiamando quell'altro sito & Quot; IT & Quot; focalizzato sul fatto che l'IT comprende infrastrutture, supporto e sviluppo nella maggior parte delle aziende ... probabilmente una buona percentuale di utenti StackOverflow sono sviluppatori nei dipartimenti IT.

Ho lavorato con CMMI e il Team Software Process (TSP), entrambi prodotti di Watts Humphrey e del Carnegie Mellon Software Engineering Institute. Se sei impegnato nel miglioramento continuo e ritieni che la misurazione sia al centro di qualsiasi miglioramento continuo, troverai valore in CMMI.

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

L'attenzione al monitoraggio del tempo (punzonatura dell'orologio), al rilevamento dei difetti (quote di bug), alle linee di codice (molti modi per " gioco " se sei così propenso) e a rendere il tuo processo ripetibile (facendo sembrare uno sviluppatore come un ingranaggio senza libertà di innovare) disattiva molti sviluppatori. < - annota gli argomenti contrapposti tra parentesi.

Resta il fatto che il 90% degli sviluppatori là fuori (alcuni dei quali leggono StackOverflow o qualsiasi blog / sito web tecnico) sparano dall'anca e sono gravemente carenti di autocoscienza di dove risiedono le loro opportunità di miglioramento. Per loro, il rigore del processo e l'opportunità di apportare miglioramenti incrementali alla qualità attraverso l'autocoscienza che la ripetizione e la misurazione facilitano sono componenti preziosi di CMMI.

Fatto bene, ottieni gli stessi benefici dai metodi Agile come Scrum, dove ancora una volta l'attenzione è rivolta alle iterazioni ripetibili, all'apprendimento da ciascuna iterazione e al miglioramento / restringimento del tuo obiettivo. Ci vuole molta maturità ed esperienza per guidare un team nell'adozione dei metodi Agile o CMMI e trarne pieno valore.

Agile è sexy e CMMI è il più lontano che sexy possibile, motivo per cui non ne hai sentito parlare così tanto.

Answer 2

L'adozione agile tende ad essere bottom-up: i tecnici si imbattono in esso e lo raccomandano alla direzione.

ITIL / CMMI tende ad essere dall'alto verso il basso: la gestione si imbatte in esso e lo spinge verso i tecnici.

Ciò non rende l'uno buono e l'altro cattivo; principalmente questo influenza il linguaggio usato per descrivere ogni approccio. E ci sono molte eccezioni: persone con esperienza nelle trincee che sono brave nell'applicazione di CMMI e manager che si agitano agilmente.

Google per " agile CMMI " e otterrai molti successi. Preferisco non raccomandarne uno in particolare, perché è un dibattito in corso (vale a dire che alcune di queste persone hanno semplicemente torto).

A mio avviso, l'idea di processo è certamente un'idea utile da avere quando si analizza il lavoro quotidiano 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 accesso per porre domande che portano al miglioramento. Puoi anche ottenere un certo chilometraggio chiedendo cosa è ripetibile e in quali condizioni le attività possono essere chiamate gestite .

L'errore e gli eccessi iniziano quando il pensiero magico si insinua in: " 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.