Come dovrebbero essere introdotti standard e miglioramenti dei processi in un'organizzazione senza di essi?

10

Mi è stato assegnato il compito di migliorare il processo di sviluppo del software attraverso l'implementazione di miglioramenti del processo, di cui molto probabilmente utilizzeremo CMMI per lo sviluppo, Versione 1.3 come linea guida e adottando le migliori pratiche in tutto o in parte. Qual è il modo migliore per introdurre standard e miglioramenti dei processi in modo da ridurre al minimo il grado di respingimento e resistenza da parte degli sviluppatori?

standards cmmi process-improvement

— rjzii
fonte

Solo curioso, hai già idea del perché più bug riescono a superare poi desiderati?

— Chris Pitman,

2

@ S.Lott Puoi fare una richiesta per i bug che non vengono ridotti (dal lato dei consumatori) senza standard? La mia esperienza in un processo e standard riduce notevolmente ciò che il consumatore vede sui bug ... non che non esistano, non vengono mai visti dal cliente.

— Rig

@RobZ: non ti ho chiesto cosa hai attualmente. Sto ancora cercando di capire la domanda. "implementazione dei miglioramenti del processo" sembra essere la descrizione più accurata di ciò che stai chiedendo. Vorrei suggerire che "standard" è un termine confuso, dal momento che ha una definizione formale e non stai usando quella definizione formale.

— S.Lott

@Robz: "Standard di codifica" non è "Standard formali". Ciò chiarirà la domanda. Ancora. Gli "standard formali" sono standard W3C, Posix, ISO, IEEE, ANSI. Redatto e approvato da un'organizzazione riconosciuta per l'allestimento degli stand. Se stai parlando di standard di codifica, aggiorna la domanda per rimuovere la parola "Formale" e usa la parola "Codifica". Con quel cambiamento la tua domanda ha senso. Ed è un duplicato.

— S. Lott,

"Per quanto riguarda le parole" standard "nel titolo insieme ai miglioramenti del processo, le parole standard non si applicano solo al codice che qualcuno scrive"? Che cosa? Ecco un suggerimento. Non utilizzare la parola "standard" senza alcun tipo di qualificatore; è confusionario. Se intendi "standard di codifica", usa quella frase. Se intendi un altro tipo di "standard", qualifica la parola "standard" con una frase qualificante per chiarire di cosa stai parlando. "standard" è vago e confuso.

— S. Lott,

2

Avviare il progetto di miglioramento del processo software (SPI) . Definire portata e obiettivi. Aiuterà sicuramente se la standardizzazione ha i propri obiettivi e misure applicabili alla propria organizzazione.
Assegnare la persona responsabile dell'adozione degli standard . Potrebbe anche essere diverse persone o addirittura dipartimento nel caso di grandi organizzazioni. La cosa importante è che tutti i responsabili della standardizzazione sarebbero:
- abbastanza professionale da vedere l'intera immagine
- abbastanza influente per gestire i team e aiutarli ad adottare / negoziare i cambiamenti
Sviluppa corsi di formazione che coprono sia lo standard che desideri adottare sia i suoi dettagli applicati alla tua organizzazione. Ed è davvero importante finché tutte le persone che non sono state addestrate sono potenzialmente resistenti ai cambiamenti. Ad esempio, quando ho lavorato in una grande azienda, ho istruito tutti i nuovi impiegati sui processi di controllo qualità, CMMI, ISO e Sistema di gestione della qualità. Tale addestramento era obbligatorio. Ha contribuito a migliorare la conoscenza dei processi di gestione della qualità e sensibilizzare i dipendenti sull'importante questione della qualità del software.
Negozia le modifiche e personalizza le pratiche generalmente accettate per le tue esigenze specifiche. Aiuterà a evitare la burocrazia e l'implementazione di processi pesanti di cui nessuno ha davvero bisogno.
Stabilire il monitoraggio di come vengono supportati i miglioramenti dei processi implementati e se sono abbastanza efficaci nella propria organizzazione.

Aiuterà anche se troverai tutte le persone all'interno della tua organizzazione che sono veramente preoccupate per la qualità. Molto probabilmente, quelle sarebbero la risorsa più importante per aiutarti a promuovere i cambiamenti e stabilire pratiche mature.

— Altern
fonte

6

Un paio di pensieri dalla scuola dei duri:

1) La maggior parte delle iniziative di miglioramento dei processi impiega l'80% del proprio tempo nella progettazione dei processi e il 20% nell'istruzione e nella socializzazione. Capovolgi queste percentuali. Uno standard mediocre che segue batte un perfetto che non lo è.

2) Individua i motivi chiari per cui stai chiedendo alle persone di cambiare il loro modo di lavorare. Qual è il caso aziendale? Idealmente, avvantaggia ogni squadra individualmente. A volte è solo un miglioramento sistemico. In entrambi i casi, rendere visibile il caso.

3) Semplificare, quindi standardizzare, non viceversa.

4) Non è possibile delegare completamente questo a un PMO. I direttori diretti devono essere acquistati e il capo dell'unità aziendale dovrà rompere i legami quando arrivano i reclami.

5) Trova i primi utenti amichevoli. La gente si lamenterà di quanto tempo ci vuole. Hai bisogno di qualcuno a cui puoi indicare e dire "ci sono voluti solo 15 minuti"

6) Per le metriche, spingere forte per quantitativo piuttosto che qualitativo. Altrimenti hai progetti che sono verdi fino al giorno prima di Go Live, quando tutto scivola di un mese.

7) Enfatizzare le tecniche rispetto agli strumenti. Una buona pianificazione è più importante di MS Project.

8) Inserire un livello di processo relativo alle esigenze. Ogni ristorante ha bisogno di essere elaborato, ma Nobu e la lavanderia francese hanno bisogno di un tipo diverso rispetto a McDonalds. Lo stesso vale per le società di software.

In bocca al lupo!

— MathAttack
fonte

1

Ottima risposta - Aggiungerò anche molta attenzione al processo che introduci - Assicurati di non cadere nella trappola di fare ciò che è meglio per il processo, non ciò che è meglio per il cliente - cioè il processo deve essere focalizzato sul cliente. Inoltre, fai attenzione a ciò che misuri: per definizione ciò che è misura è importante e ciò che non viene misurato non è importante. Misura le cose sbagliate (SLOC / Day, Bugs / SLOC ecc.) E non otterrai miglioramenti, ma le misurazioni ti diranno che lo sei.

— Mattnz,

1

@mattnz - Non lo so, errore / SLOC può essere una metrica utile se la applichi correttamente. Se qualcuno dice che hanno in media 1 errore / 10 SLOC sarei probabilmente preoccupato. Il trucco è che devi sapere dove sono le barre, che può essere difficile.

— rjzii,

Buon punto. Le persone ottimizzano in base alle loro metriche. Se si producono prima le metriche finanziarie, le persone si ottimizzeranno a questo a spese della funzionalità o del servizio clienti. Si tratta di equilibrio e priorità.

— MathAttack,

1

Misurami con errori / SLOC, SLOC / giorno e rimarrai sorpreso da quanto posso fare il mio codice sorgente senza aggiungere nulla di utile. Ad esempio il posizionamento di parentesi graffe, su una nuova riga, sempre: più righe sono, meno statistiche, migliore è il programmatore che divento, all'istante. Dammi QUALSIASI misura e ti mostrerò come posso fare che la misurazione mi faccia sembrare migliore.

— Mattnz,

1

@mattnz - Ecco a cosa serve la revisione del codice, se qualcuno sta rendendo il suo codice inutilmente dettagliato per nascondere il fatto che è pieno di bug, allora è probabile che non dovrebbero scrivere codice per cominciare. Puoi anche esaminare i difetti per punto di funzione che è estremamente difficile da falsificare quando vedi un'esposizione nel numero di funzioni con il numero che scende (segno negativo), o il numero inizia a scendere quando il codice migliora (buono cartello).

— rjzii,

2

Basare i tuoi sforzi sul CMMI è probabilmente una buona idea, anche se non ti sottoponi alle valutazioni e ti verifichi un controllo e una valutazione formale. C'è molta letteratura disponibile su CMMI , CMMI e altre tecniche di miglioramento dei processi come Lean e Six Sigma , CMMI e sviluppo software agile . Il SEI ha un'intera raccolta di risorse , alcune disponibili gratuitamente, su diversi aspetti di CMMI e indicazioni per diversi tipi di organizzazioni.

Consiglierei di approfondire l'approccio continuo all'implementazione di CMMI, piuttosto che l'approccio graduale. Mi sembra un modo molto più efficiente per determinare esattamente dove si trova ora la tua organizzazione e migliorare in aree che aggiungono più valore al business. Ciò consentirà non solo di allineare gli sforzi di miglioramento con gli obiettivi aziendali, ma anche di raggiungere rapidamente traguardi di progresso e dimostrare gli effetti del miglioramento, aumentando il buy-in da tutti i livelli.

Qualcosa da tenere a mente, tuttavia, è che il miglioramento del processo ha generalmente più successo quando si tratta di uno sforzo di base. Quando i cambiamenti di processo sono dettati dall'alto - da persone che gli sviluppatori "nelle trincee" potrebbero vedere come estranei al modo in cui le cose vengono fatte nelle trincee - probabilmente ci sarà un respingimento, anche se l'idea è buona. Preparati per questo.

Anche alcuni tipi di gruppi di processi di ingegneria potrebbero essere utili. Riunire i rappresentanti delle varie componenti organizzative e dei gruppi interessati dal miglioramento in modo che la voce di tutti sia ascoltata. Ciò includerebbe non solo i rappresentanti di ciascun ruolo, ma forse vari team di sviluppo del prodotto. Senza sapere come è strutturata la tua organizzazione, non posso dire esattamente chi potresti voler guardare, ma includo persone di ogni livello dell'organizzazione nel gruppo. Inoltre, rendere le discussioni e le decisioni prese da questo gruppo a disposizione dell'organizzazione per commenti e segnalazioni di eventuali problemi.

— Thomas Owens
fonte

Non sono sicuro di quanto funzionerà bene per gli sforzi di base poiché pochissimi team di progetto hanno formalizzato i processi, motivo per cui questo sarà più un processo dall'alto verso il basso. Detto questo, però, tutti sono preoccupati di rendere le cose il più delicate possibile per evitare che gli sforzi falliscano a causa della mancanza di un'attuazione effettiva.

— rjzii,

@RobZ Per definizione, non puoi spingere per gli sforzi di base - deve naturalmente venire dal basso verso l'alto. A meno che i team di progetto non si rendano conto che esiste un problema reale, la tendenza è quella di non cambiare e di opporsi ai cambiamenti che sono percepiti come cattivi in qualche modo (come rendere il lavoro più complicato o difficile, che è spesso associato al miglioramento del processo, anche se non lo è spesso è il caso).

— Thomas Owens

Esatto ed è per questo che il management sta formalizzando le cose. Ci sono stati dei problemi con alcuni dei software che sono usciti dalla porta e stanno cercando di cambiare anche la cultura aziendale e garantire che i prodotti difettosi non rientrino nel campo.

— rjzii,

@RobZ E quando la direzione interviene e detta le azioni, gli sviluppatori resistono. Non puoi imporre un cambiamento culturale e aspettarti che accada semplicemente e in silenzio. È un processo lungo e doloroso.

— Thomas Owens

Nessuno si aspetta davvero che sia così e abbiamo già incontrato resistenza, a questo punto stiamo cercando modi per minimizzarla.

— rjzii,

0

Per ogni modifica:

Richiama la modifica 1 e come migliorerà lo sviluppo.
Implementa la modifica.
Dimostrare miglioramento
Rimuovi le modifiche che non hanno dimostrato miglioramenti

Ovviamente l'analisi deve avvenire nel tempo, ma nessun cambiamento dovrebbe essere accettato fino a quando non si sarà dimostrato efficace. Questo è anche il motivo per cui non implementerei più di 2-3 modifiche per ciclo, altrimenti spesso non puoi misurare se ci sono stati miglioramenti o meno.

Niente mi irrita più che seguire ciecamente le migliori pratiche senza fare l'analisi per dimostrare che in realtà è una delle migliori pratiche per il tuo ambiente. Una best practice che non dimostra miglioramenti è nella migliore delle ipotesi dispendiosa e nel peggiore dei casi dannosa.

Tutte le fasi del processo e tutte le pratiche metodologiche dovrebbero essere analizzate e dimostrate di essere di beneficio. In caso contrario, dovrebbe essere rimosso. Questa analisi dovrebbe essere eseguita su base continuativa, indipendentemente dall'aggiunta o dalla rimozione di passaggi o pratiche.

— dietbuddha
fonte