La mischia ha qualche merito nei contratti di difesa?

12

Sentito ieri al raffreddatore d'acqua: "Scrum non ha posto nei contratti di difesa".

Tendo a non essere d'accordo, nel senso che credo che Scrum possa essere adattato per funzionare in molti scenari e posso vedere la difesa come uno di loro. Ciò ha scatenato un enorme dibattito tra i miei colleghi (molti di noi lavorano nei contratti di difesa) con una divisione abbastanza / addirittura positiva.

Per rendere questa una domanda corretta: qualcuno ha usato con successo (o ha esperienza di lavoro con) mischia in una situazione contrattuale di difesa? Cosa ha funzionato bene, cosa non ha funzionato bene e quali (se presenti) modifiche alla mischia alla vaniglia hai fatto?

development-process scrum development-methodologies

— Sean Madden
fonte

3

Agile si impegna per rimuovere i rifiuti. Le organizzazioni che cercano di avere successo con l'agile devono essere allineate a tale obiettivo. Le organizzazioni politiche tendono ad avere altre priorità.

— Martin Wickman,

5

"Scrum non ha posto nei contratti di difesa."

Nella mia esperienza, l'impedimento principale è il cliente. Molte agenzie governative hanno il modello a cascata nel loro DNA. Anche i contratti vengono stipulati nelle fasi a cascata: prima finanzeremo i requisiti, quindi la progettazione, quindi l'implementazione. Nella classica teoria delle cascate potrebbero persino pensare di riuscire a convincere diverse aziende a fare diverse fasi.

Ci sono modi per aggirare questo attraverso l'IMO. Esegui un reqs iniziale e progetta come cascata, quindi nell'implementazione suddividere i requisiti in storie utente iterative. Utilizzare test interni / utenti esperti valutano ogni iterazione. A seconda del cliente, potrebbero essere interessati o meno alla partecipazione. Mischia non pura, ma potrebbe essere il meglio che puoi fare.

— Doug T.
fonte

3

Ho lavorato come stagista per tre team presso una struttura del laboratorio di ricerca dell'aeronautica, una volta nello sviluppo di software di produzione, una volta nella prototipazione rapida e una terza volta nella verifica e nella convalida del lavoro a contratto. Entrambe le posizioni di sviluppo erano agili. In effetti, la posizione di produzione era molto vicina a Scrum, con una minore interazione con il cliente (software fornito ogni poche iterazioni, cliente in loco ogni 3-6 mesi), e questo era nel 2006. Concordo sul fatto che l'acquisto e la comprensione del cliente siano i più grandi problema, ma alcune agenzie governative (o almeno squadre) stanno effettivamente adottando metodi Agili.

— Thomas Owens

@Thomas Owens Questo commento sarebbe una buona risposta.

— Hugo,

1

Mentre può essere difficile implementare pienamente Scrum, può essere utile adottare alcune delle pratiche Scrum. Ad esempio, ora importa come stai raccogliendo i requisiti, puoi comunque avere frequenti rilasci e demo. Puoi comunque beneficiare di retrospettive periodiche. Guarda altri processi come Lean o Kanban e vedi se c'è qualcosa che possono aiutare anche il tuo team.

Invece di seguire dogmaticamente ogni singolo processo, pensa a come puoi migliorare il processo specificamente per il tuo team, il tuo progetto e nel tuo settore. Il processo è importante . La metodologia di una squadra ha un impatto notevole sul software fornito.

— epotter
fonte