Perché il ciclo di vita dello sviluppo di un software è così inefficiente?

Question

Perché il ciclo di vita dello sviluppo di un software è così inefficiente?

Naviga le tue risposte

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)

0

Attualmente il ciclo di vita dello sviluppo del software seguito nella società IT a cui lavoro è:

Il "Business" funziona con un solution manager per creare un documento sui requisiti aziendali
Il gestore soluzioni lavora con il Program manager per creare una specifica funzionale
Il PM collabora con il responsabile dell'ingegneria per sviluppare un piano di rilascio e con il team di ingegneri per lo sviluppo di specifiche tecniche
Se ci sono dei chiarimenti richiesti, gli sviluppatori contattano il PM che contatta il solution manager che contatta l'azienda e al contrario introduce una latenza di quasi 24 ore e enormi catene di e-mail per qualsiasi chiarimento
Quando vengono fatte le specifiche tecniche, è passato quasi un mese avanti e indietro
Ora, 2 settimane passano allo sviluppo mentre il test scrive i casi di test
Il codice viene abbandonato formalmente per il test, il test inizia a generare errori. Anche se esiste una causa principale per 10 problemi diversi, ed è facilmente risolvibile, gli sviluppatori non sono autorizzati a fornire codice nuovo da testare per la prossima settimana. Dopo 2-3 gocce per testare il codice viene dato al team ops come una "goccia d'oro"

(2 mesi passati dall'inizio)

Il team operativo ora distribuirà il codice in un ambiente di staging. Se è stabile per una settimana, sarà promosso a UAT e dopo 2 settimane sarà promosso a prod. Se ci sono errori trovati qui, bene, la richiesta di un visto richiede meno documenti

Questo intero processo viene seguito anche se un singolo report SSRS deve essere rilasciato.

In che modo altre aziende elaborano tali requisiti? Mi chiedo il motivo per cui l'azienda non può semplicemente abbandonare i requisiti agli sviluppatori, creare e implementare gli sviluppatori in UAT, esporli al business che solleva bug funzionali e dopo averli risolti a promuovere. (anche per cose più complesse)

sdlc

posta user87166 10.06.2014 - 18:36

fonte

3 risposte

0

•The "Business" works with a solution manager to build a Business Requirement document

Il tuo team deve essere pronto, disponibile e in grado di lavorare con il "Business" e creare requisiti. Potrebbero voler mantenere gli stessi formati di documento e probabilmente interpretarli come un tipo di accordo o contratto tra loro e gli sviluppatori. Se il tuo team di sviluppo preferisce un altro tipo di documentazione (le note adesive su una bacheca sono ancora documentazione, ma non tradizionali), potresti essere in grado di convincere l'azienda ad accettarlo. Idealmente è qualcosa che tutti capiscono e concordano.

Ora tutto ciò che devi fare è decidere cosa faranno tutte queste altre persone. Che te ne accorga o meno; non hai solo dichiarato guerra, ma hai sparato il primo colpo.

risposta data 10.06.2014 - 22:07

fonte

0

Risposta breve: le altre società che non utilizzano l'approccio a cascata che stai descrivendo per creare soluzioni IT utilizzano spesso un approccio Agile, ad esempio, Scrum o eXtreme Programming.

risposta data 11.06.2014 - 01:17

fonte

Leggi altre domande sui tag sdlc

Esiste un termine di programmazione comune per i problemi legati all'aggiunta di funzionalità a un programma già ricco di funzionalità? Previsione algoritmica e riconoscimento di pattern

score 3 · Accepted Answer

How do other companies process such requirements?

A differenza.

Aziende diverse hanno processi diversi perché hanno esigenze diverse, tolleranza al rischio diversa, risorse diverse ...

I'm wondering why, the business cannot just drop the requirements to developers

Spesso, perché è difficile / impossibile / costoso trovare sviluppatori che siano bravi a essere sviluppatori e anche bravi a parlare agli uomini d'affari. Ovviamente, anche il contrario è un problema: trovare uomini d'affari che siano bravi negli affari e possano parlare con gli sviluppatori.

developers build and deploy to UAT themselves

Spesso, perché lasciare che gli Op lo faccia, gli sviluppatori si concentrano sul codice. Inoltre, le persone operative apprendono come funziona il sistema e lo mantengono / supportano. Quel supporto può creare o distruggere un prodotto.

Ma tutto questo è (principalmente) l'avvocato del diavolo da parte mia. Troppo spesso il processo viene implementato da manager che non si fidano dei propri dipendenti a svolgere il proprio lavoro anziché essere documentati (e continuamente rivalutati) dai manager in modo che i nuovi dipendenti possano più facilmente impara come fare ciò che fanno gli altri .