Quindi stai correggendo i bug, quindi ne hai incontrato uno che potrebbe interessare altri moduli del prodotto software. I tuoi dati non sono sufficienti per supportare il tuo reclamo sugli effetti della correzione e ti è stato chiesto di creare un documento di analisi dell'impatto.
I modelli che ho visto per l'analisi di impatto dove sono stati realizzati all'interno dell'azienda per cui lavoro. Lo usiamo per valutare le Richieste di modifica e prima di lavorarci (e possibilmente di rifiutarne alcune). Aveva sezioni come questa:
Per coprire tutti i possibili impatti devi attraversare le dipendenze. Se possiedi una matrice di tracciabilità bidirezionale, sarà più semplice.
Abbiamo utilizzato l'ordine di cui sopra perché il progettista dovrà conoscere l'impatto dal punto di vista dell'analista per ottenere una migliore comprensione del cambiamento e così anche il tester deve conoscere l'opinione dell'analista e dell'architetto. Allo stesso modo, il PM ha bisogno di tutte le informazioni per conoscere il costo e il programma.
Lo abbiamo usato con CR ma puoi usarlo con bug allo stesso modo. Inoltre, se è necessario effettuare questa operazione per scegliere tra diverse soluzioni di correzione per risolvere il bug, sarà necessario ripetere l'analisi di impatto per ogni possibile soluzione e consolidare tutti i dati in un modulo di analisi e risoluzione (DAR) di decisione per sapere quale soluzione è il migliore. Nel modulo DAR è necessario aggiungere alcuni fattori di valutazione come la manutenibilità futura o altri fattori che non sono inclusi implicitamente nell'analisi dell'impatto. Quindi attribuisci il peso di ogni fattore e assegna il punteggio di ogni soluzione in ciascun fattore. Infine moltiplicare e sommare il punteggio * peso e scegliere il migliore. Nota che il costo può essere incluso nei fattori o il PM può avere un'altra opinione.
Credo con qualsiasi documentazione che l'approccio agile sia buono. Ora, ci sono alcune idee sbagliate là fuori che agile significa "nessuna documentazione o analisi", ma non è questo il caso. Le cose che ho letto sull'agile dicono "usa ciò che funziona". Prendo questo per dire che il documento dovrebbe essere di lunghezza e dettaglio commisurato al compito.
I modelli possono essere utili come elenco di controllo, ma non richiederei che ogni sezione venga compilata per modifiche a rischio ridotto o a rischio ridotto. Per un cambio di una riga, forse non hai affatto bisogno di un documento. Non ho mai utilizzato un modello per un documento di analisi dell'impatto, ma mi occupo regolarmente dei requisiti aziendali o delle specifiche tecniche. Un modello può essere troppo restrittivo; una buona guida è invece quella di considerare chi sarà il pubblico. Se è per i manager che non sono tecnici, concentrati sulla giustificazione aziendale del cambiamento. Se è per le persone tecniche, fornisci un po 'di retroscena in modo che una nuova persona nel team non vada persa e dia loro abbastanza per andare avanti se devono sostenere il cambiamento. Inoltre, se vuoi qualcosa di ancora più attrito e leggero, non usare affatto un documento, mettilo su un wiki.
Informazioni da includere:
Questo è un minimo accettabile. L'altro post ha messo in evidenza alcune cose CMMi piuttosto pesanti da IBM; è fantastico se hai tempo e risorse per farlo (e quando stai costruendo sistemi per la NASA in cui è in gioco la vita umana, allora le persone dovrebbero essere seri in proposito) ma per le piccole squadre probabilmente non hai bisogno di essere così pesanti . Fai attenzione alla stima, come sempre. I manager sono inclini ad assumere che una stima sia effettiva.
Si noti che ci sono pericoli nell'approccio agile. Alcuni sviluppatori pensano che significhi "nessun documento necessario, basta iniziare a distruggere" (che potrebbe andare bene in alcune situazioni). Inoltre, altri prenderanno la latitudine data l'attività e semplicemente scrivono documenti davvero schifosi che non aiutano veramente (non necessariamente OK nella maggior parte delle situazioni). Parte del problema è che scrivere bene richiede un po 'di sforzo, abilità e tempo; la maggior parte di noi ha almeno due di queste cose;)
Sono sempre stato grande sulla documentazione perché ti dimostra almeno di aver riflettuto abbastanza per qualificarti come se avessi un piano. Ma nella mia vecchiaia ho anche capito che troppa documentazione può diventare di per sé una seccatura di manutenzione, e che non ci sono abbastanza persone che si preoccupano abbastanza per mantenere aggiornata la documentazione.
Il documento Impact Analysis è effettivamente richiesto in progetti su larga scala, specialmente dove i programmatori stanno lavorando geograficamente in luoghi diversi.
Il documento di analisi dell'impatto dovrebbe essere approvato dal lead per assicurarsi che la modifica non influenzi l'altro componente che sta funzionando bene nella produzione.
L'analisi dell'impatto è necessaria per garantire che il requisito sia completamente compreso e tutti i componenti da modificare siano identificati per evitare rielaborazioni
L'analisi dell'impatto è richiesta anche per la responsabilità delle parti interessate del cliente. Altrimenti, quando si verifica un problema dopo la distribuzione lo sviluppatore diventa il capro espiatorio.
L'analisi dell'impatto è la base per la stima. Senza di ciò la stima non ha alcun valore. Potrebbe essere troppo alto o potrebbe essere troppo basso. Con Impact Analysis se lo sforzo effettivo supera, è facile da spiegare.
Leggi altre domande sui tag project-management documentation