È comune per gli sviluppatori occuparsi di estese procedure di controllo delle modifiche? [chiuso]

In realtà è ESTREMAMENTE comune nei settori governativo / aerospaziale / della salute.

Questo è in realtà un meccanismo di sicurezza che previene lo spreco di energie e riduce i cambiamenti che alcuni ragazzi decidono che sarebbe meglio se rompessero qualcos'altro che era molto più importante. Dovresti dare un'occhiata a CMMI per avere qualche informazione su cosa sono questi processi e perché (in teoria) aiutano a minimizzare cambiare e rischiare. Quando anche un piccolo cambiamento ha il potenziale di rischiare la vita di una persona o causare una massiccia perdita di denaro, questi processi vengono messi in atto. Il più delle volte sono un ostacolo all'innovazione e alla capacità di adattarsi e cambiare rapidamente, tuttavia in alcuni casi è accettabile se si evita un singolo cambiamento che potrebbe mettere in ginocchio un'azienda, uccidere qualcuno o causare un enorme e costoso querela.

Per quanto riguarda la giustificazione per la gestione degli sviluppatori vs:

La gestione dovrebbe giustificare il passaggio da una prospettiva aziendale. Dovrebbero giustificare e passare il cambiamento attraverso il comitato prima che lo sviluppatore veda il cambiamento. Tuttavia, lo sviluppatore dovrebbe essere coinvolto nel senso che sono gli unici qualificati a fornire un'analisi dei rischi accurata a distanza. Gli sviluppatori non dovrebbero fare da soli la giustificazione aziendale, ma dovrebbero essere parte del processo per fornire analisi di benefici / rischi da un punto di vista tecnico. La direzione dovrebbe chiarire per decidere se è addirittura necessario prima. Secondo, dovresti chiarirlo come (questo può essere fatto, questo non può essere fatto, questo può essere fatto ma ci metterà 4 mesi indietro, questo può essere fatto ma i gattini moriranno nello space shuttle al rientro) .

L'ho incontrato in grandi aziende (settore finanziario, nella mia esperienza). Quando ho iniziato, il processo era ben consolidato e tutti erano abituati. Un po 'di tempo per trattare con il Comitato delle modifiche è stato iscritto nel progetto. E 'stato fastidioso trattare, ma in qualche modo necessario e quando ero un membro del comitato ho visto accadere più di una volta che i cambiamenti portati avanti si sarebbero scontrati in qualche modo - i sistemi interessati o la pianificazione richiesta. In un'azienda così grande, era impossibile per ogni team di sviluppo sapere cosa stavano facendo gli altri, quindi questo processo ha assicurato che c'era un punto in cui tutte le modifiche venivano gestite e pianificate.

Per giustificare le modifiche, di solito chiedevamo che lo sviluppatore principale incaricato E il loro manager presentasse il cambiamento. Il manager perché conosceva il lato business ed era responsabile del cambiamento, lo sviluppatore perché spesso conosceva molto meglio i requisiti tecnici.

Sembra che la tua azienda stia ancora attraversando alcuni dolori in crescita per questo processo, e lo strumento suona anche un po 'imbarazzante (non abbiamo dovuto digitare manualmente i dati, potremmo allegare documenti esistenti). Abbiamo anche avuto un processo semplificato per modifiche minori. Potrebbero decidere di rivedere il loro processo dopo un paio di mesi di esperienza con esso, o forse potresti suggerire che lo esaminino.

Ho lavorato per alcune aziende Fortune 500 e questo è abbastanza comune. Nella maggior parte dei casi ho visto l'intero team del progetto responsabile della documentazione della modifica, il che significa che alcuni dettagli tecnici sono forniti dallo sviluppatore, ma la giustificazione commerciale è fornita dal PM o BA. Tutta la documentazione delle modifiche viene quindi compilata da uno dei membri del team e inviata nel suo complesso.

Il processo di modifica riguarda molto più che l'approvazione della modifica.

Idealmente, i principali proprietari di processi sono coinvolti e coinvolti. Quando viene proposto un cambiamento, discutono i processi attuali, eventuali brevi cadute e cercano di prendere una decisione sull'ambito del progetto. La modifica è necessaria solo per un piccolo gruppo, ubicazione o dovrebbe essere modificata a livello aziendale. Questo può sembrare stupido per trascorrere questo tipo di tempo, ma è molto più facile supportare i sistemi che sono comuni in tutta l'azienda.

Questo gruppo si assicura anche che più gruppi non stiano cercando di apportare le stesse modifiche o modifiche allo stesso sistema che potrebbero entrare in conflitto. E se vogliono provare a coordinare queste modifiche per assicurarti che lavorino insieme.

E hanno una responsabilità di gestione per assicurarsi che le modifiche siano davvero necessarie. Potrebbe essere necessario attendere 5 ore per correggere un errore di battitura su una pagina web. Ma perché non è stato catturato prima del rilascio? È davvero importante ripararlo? Ci sono dei rischi nel fare il cambiamento? Ho corretto un errore di battitura una volta e ho cancellato per errore l'intero contenuto della nostra directory INETPUB. Per 3 ore, tutte le app su quel server sono state disattivate durante il ripristino. Il controllo del cambiamento considera cose come questa. È la correzione di un errore tipografico che vale il rischio di perdere 3 ore di ordini online?

So che è doloroso. Una volta ho passato circa 80 ore a fare documentazione e richieste e ho coinvolto la mia gestione per ottenere un server virtuale con un costo reale di circa $ 20 al mese. Il processo è stato doloroso ma ci sono ragioni di lavoro che hanno fatto sì che avessimo bisogno di quel server. Costa solo $ 20 al mese perché il processo per ottenerne uno è controllato e standardizzato. Se il data center aumentasse, i costi aumenterebbero costando a tutti.