O scrum tem algum mérito na contratação de defesa?

12

Ouviu o watercooler ontem: "Scrum não tem lugar na contratação de defesa".

Costumo discordar no sentido de que acredito que o Scrum pode ser adaptado para funcionar em muitos cenários e vejo a defesa como um deles. Isso provocou um grande debate entre meus colegas (muitos de nós trabalhamos na contratação de defesa) com uma divisão bastante equilibrada a favor / contra.

Para fazer disso uma pergunta adequada: alguém usou com sucesso (ou tem experiência em trabalhar com) scrum em uma situação de contratação de defesa? O que funcionou bem, o que não funcionou bem e que modificações (se houver) no vanilla scrum você fez?

development-process scrum development-methodologies

— Sean Madden
fonte

3

O Agile se esforça para remover os resíduos. As organizações que tentam obter sucesso com o Agile devem estar alinhadas com esse objetivo. As organizações políticas tendem a ter outras prioridades.

— Martin Wickman

5

"Scrum não tem lugar na contratação de defesa."

Na minha experiência, o principal impedimento é o cliente. A maioria das agências governamentais possui o modelo de cascata em seu DNA. Até contratos são feitos em fases em cascata - primeiro financiamos os requisitos, depois o design e a implementação. Na teoria clássica da cachoeira, eles podem até pensar que podem conseguir empresas diferentes para realizar fases diferentes.

Existem maneiras de contornar isso através da IMO. Faça um reqs inicial e projete como cascata e, na implementação, divida os requisitos em histórias de usuário iterativas. Use usuários internos de teste / especialista para avaliar cada iteração. Dependendo do cliente, eles podem ou não estar interessados em participar. Não é um scrum puro, mas pode ser o melhor que você pode fazer.

— Doug T.
fonte

3

Trabalhei como estagiário para três equipes em um laboratório de pesquisa da Força Aérea, uma vez no desenvolvimento de software de produção, uma em prototipagem rápida e uma terceira na verificação e validação de contratos de trabalho. Ambas as posições de desenvolvimento foram ágeis. De fato, a posição de produção estava muito próxima do Scrum, com menos interação com o cliente (software entregue a cada poucas iterações, cliente no local a cada 3-6 meses), e isso foi em 2006. Concordo que a compra e o entendimento do cliente são os maiores problema, mas algumas agências governamentais (ou pelo menos equipes) estão de fato adotando métodos ágeis.

— Thomas Owens

@ Thomas Owens Este comentário seria uma boa resposta.

— Hugo

1

Embora possa ser difícil implementar completamente o Scrum, pode ser benéfico adotar algumas das práticas do Scrum. Por exemplo, agora, independentemente de como você está realizando a coleta de requisitos, você ainda pode ter lançamentos e demonstrações frequentes. Você ainda pode se beneficiar de retrospectivas periódicas. Observe outros processos, como o Lean ou o Kanban, e veja se há algo que eles também possam ajudar sua equipe.

Em vez de seguir dogmaticamente qualquer processo, pense em como você pode melhorar o processo especificamente para sua equipe, seu projeto e seu setor. O processo é importante . A metodologia de uma equipe tem um grande impacto no software entregue.

— epotter
fonte