Plan, Build, Run philosophy philosophy

5

Sto cercando alcune spiegazioni logiche su come lo sviluppo del software si inserisce in un modello Plan, Build, Run di un'organizzazione.

Sto facendo fatica a trovare qualcosa che spieghi in che modo i progetti di sviluppo software si adattano a questa struttura. In effetti il corpo della scrittura sembra essere tutto molto piccolo su PBR.

Quello che vedo è qualcosa chiamato COBIT di isaca che ha 3 fasi internamente chiamate plan build run. È questa la fonte di questa terminologia?

Sto cercando di chiarire dove vanno le cose, perché le cose vanno lì e quale valore ha.

So che questo può sembrare un po 'fuori tema, ma mi sembra il migliore sotto il "ciclo di vita"

    
posta TheNorthWes 22.02.2017 - 17:00
fonte

1 risposta

2

Nei vecchi periodi bui, il software è stato costruito utilizzando il famoso approccio a cascata: pianificare, analizzare i requisiti, progettare il sistema, costruire il sistema, testare il sistema e eseguire il sistema.

Questo risale agli anni Cinquanta, in un'epoca in cui questa separazione dei doveri e la specializzazione dei compiti era una realtà strong in un ambiente tayloristico.

Penso che ci sia l'origine del piano, della build, del concetto di esecuzione, molto prima di COBIT e IASCA. Qualche consulente intelligente ha appena rilasciato le fasi dettagliate, per renderlo facilmente comprensibile a manager e auditor non tecnici.

Al giorno d'oggi, la grande società di consulenza continua a vendere l'idea come un percorso consolidato per il successo.

Tuttavia, chiunque sia coinvolto nello sviluppo di software reale sa che non è possibile pianificare tutti i dettagli da zero e che è necessario un certo grado di flessibilità per far fronte all'incertezza. Questo è il motivo per cui l'agile è così popolare oggi. La pianificazione adattativa e iterativa va di pari passo con lo sviluppo. E la crescente popolarità e successo di DevOps dimostra che è meglio integrare sviluppo (build) e operazioni (esecuzione).

Guarda la gestione del progetto stessa. PMBOK spiega che i progetti complessi richiedono un'elaborazione progressiva. PMBOK e ISO21500 considerano la pianificazione non come una fase (come nel piano / buil / run) ma come un insieme di processi eseguiti durante il progetto.

Con questo in mente, come può essere implementato Plan / build / run? Responsabili di progetto in un dipartimento di piano, perdendo gradualmente la comprensione della tecnologia e delle attività? Developpers in un dipartimento di costruzione che sono tenuti a passare attraverso il piano per organizzare il loro lavoro? E dopo essere andati a vivere, gli stessi sviluppatori non intervengono più (nonostante conoscano il sistema migliore), perché il supporto viene eseguito e non costruito?

Nella mia vita personale ho assistito a tale trasformazione, e il risultato finale è che è difficile portare a termine i progetti e c'è stato un enorme sovraccarico di comunicazione interdipartimentale, quando le stesse persone venivano fornite efficientemente come un team integrato prima del piano / costruzione / Gestisci organizzazione.

    
risposta data 22.02.2017 - 20:22
fonte