Tenho usado SCRUM em três projetos diferentes nos últimos quatro anos. Uma das vantagens do SCRUM parece ser sua flexibilidade e adaptabilidade, por exemplo, em relação às mudanças nos requisitos do cliente. Outra vantagem é que o gerenciamento pode rastrear facilmente o andamento de um projeto.
A flexibilidade do SCRUM pode ser uma vantagem por exemplo ao implementar um aplicativo da web, onde os requisitos mudam muito rapidamente e os clientes realmente entendem o que querem depois de ver um protótipo.
Por outro lado, existem outros tipos de projetos de software (por exemplo, na indústria aeroespacial indústria), onde os requisitos são bastante fixos: você obtém um documento de especificação de requisitos e tem que voltar seis meses depois com o software em funcionamento e a documentação completa. Para este tipo de projeto, duvido que a flexibilidade oferecida pelo SCRUM seja necessária (no sentido que você não precisa construir protótipos e mostrá-los ao cliente para obter feedback sobre os requisitos): você precisa de uma abordagem muito estruturada e sistemática, que provavelmente se repete continuamente para cada projeto, com pouco espaço para surpresas.
Então o SCRUM é considerado por seus proponentes uma metodologia de desenvolvimento de software de propósito geral ou é considerado especialmente adequado para certas categorias de projetos ou áreas de aplicação?
Para Por exemplo, recentemente olhei o site de uma empresa que produz software para a indústria aeroespacial e percebi que eles estão usando o modelo V. Um proponente do SCRUM diria que o SCRUM é menos adequado para este tipo de projetos ou sugeriria que esta empresa deveria tentar mudar para o SCRUM?
Observação que não estou pedindo a opinião dos leitores deste fórum, mas quero saber qual é a opinião estabelecida entre os proponentes do SCRUM: o SCRUM é considerado de uso geral ou adequado para certas classes de projetos apenas? Nos últimos casos, para quais tipos de projetos?
Comentários
- Consulte stackoverflow.com / questions / 596916 / when-should-you-not-scrum e eweek.com/c/a/IT-Management/…
- Que ” obtenha um documento de especificação de requisitos e você tenha que voltar seis meses depois com o software funcional ” é um mito. Mesmo quando você constrói algo como um compilador para uma linguagem formalmente definida (onde os requisitos funcionais parecem ser realmente claros e fixos), você tem que decidir e priorizar as coisas a serem implementadas, existem requisitos não funcionais a serem discutidos com o usuário , e você tem vários graus de liberdade para decidir como resolver as coisas. Portanto, uma abordagem ágil faz sentido até mesmo para esses tipos de projetos.
- ” Portanto, uma abordagem ágil faz até mesmo sentido para esses tipos de projetos. “: Embora o ágil possa ser mais flexível, outros métodos também são flexíveis. Pode ser que outros métodos sejam flexíveis o suficiente e o Agile seja muito flexível para certos projetos. Apenas brainstorming aqui.
- ” Que ” obtenha um documento de especificação de requisitos e você tenha que voltar seis meses depois com software funcional ” coisa é um mito. “: Eu não ‘ não penso assim . Embora você possa alterar rapidamente o rótulo de um botão em uma página da web porque os clientes mudaram de ideia depois de olhar para ele, você não pode alterar tão facilmente uma parte crítica de um software aviônico que controla uma parte móvel de um avião. Talvez sejam necessárias mudanças tardias, mas eu me pergunto se um método ágil é a maneira certa de gerenciá-los, ou se você precisa de uma iteração mais complexa de outro método (por exemplo, o modelo V).
Resposta
SCRUM é uma metodologia de propósito geral que pode funcionar bem para a maioria dos projetos e tamanhos de equipe, mas é menos útil para equipes grandes que trabalham muito grandes projetos. O grande número de pessoas envolvidas em alguns projetos torna qualquer metodologia ágil extremamente difícil ou quase impossível, porque uma estrutura mais rígida é necessária para manter a ordem. A indústria aeroespacial é um bom exemplo de uma indústria que tende a ter grandes projetos onde abordagens ágeis nem sempre são viáveis.
Comentários
- Existe alguma informação sobre quando um projeto é considerado muito grande para ser feito com SCRUM? Considere, por exemplo, um projeto de 18 meses para uma equipe de 15 pessoas: essa equipe lucraria com SCRUM ou outro modelo como o modelo V também seria adequado A razão pela qual estou perguntando é que ao longo de 18 meses os requisitos e implementação tenham tempo suficiente para amadurecer e se estabilizar e talvez a flexibilidade fornecida pelo SCRUM não seja realmente necessária.Em vez disso, uma abordagem mais de médio a longo prazo é adequada aqui. Existe alguma literatura sobre isso?
- @Giorgio tempo do projeto não ‘ realmente importa, mas 15 pessoas é o suficiente para que você se beneficie de fazer vários scrum grupos, mas ainda está na faixa gerenciável para SCRUM. quando a gestão da comunicação começa a se tornar um trabalho de tempo integral para sua equipe, é hora de começar a olhar para um modelo V
- Você está falando sério? Estávamos usando um modelo V antes e mudamos para SCRUM. Na verdade, temos a sensação de que ‘ ficamos mais lentos exatamente por este motivo: muita contabilidade.
- @Giorgio isso seria verdadeiro para qualquer switch, você é vai parecer mais lento no início porque é novo, como Pierre 303 disse, você tem uma ideia melhor depois de alguns sprints.
- @Giorgio – que ‘ é verdade, muitas ” agile ” metodologias são mais pesadas do que os processos pesados que elas ‘ supõem para substituir! Obviamente, isso significa que eles ‘ estão errados – o ágil deve ser leve e livre, e parece caótico para quem está de fora. Isso significa que sua equipe deve ser muito organizada e disciplinada, mas isso ‘ geralmente é uma vantagem. Tente o Crystal de Alistair Cockburn (um dos fundadores do Agile).
Resposta
Qualquer tipo de projeto ! Ele funciona bem para projetos grandes e pequenos.
As pessoas o usam para planejar casamentos, mudanças de casa, etc. Portanto, nem mesmo apenas em projetos de software.
Acredito piamente que existem muitas operações de negócios que poderiam se beneficiar de uma abordagem semelhante ao Scrum.
Comentários
- Sua opinião é compartilhada por proponentes do SCRUM, isto é, por autores que codificaram e promoveram o SCRUM?
- Sim – foi dito recentemente por Cheryl Hammond ( blog.bsktcase.com ), uma consultora de ALM da Northwest Cadence em uma palestra intitulada ” Um dia do Scrum Masters na vida: o novo Visual Studio “. Você pode assistí-lo aqui: msevents.microsoft.com/CUI/…
Resposta
Observe que Scrum não é uma metodologia, mas um framework.
Scrum funcionará melhor em um c equipe de funcional de 5 a 9 desenvolvedores trabalhando em um médio a grande projeto de tamanho (de 4 meses a vários anos). Se o seu projeto for maior, você pode escalar com Scrum of Scrums .
Não discutirei a questão multifuncional aqui, mas aqui são o que o Guia oficial do Scrum está dizendo para o tamanho da equipe:
Desenvolvimento ideal O tamanho da equipe é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo. Menos de três membros da Equipe de Desenvolvimento diminui a interação e resulta em menores ganhos de produtividade. Equipes de desenvolvimento menores podem encontrar restrições de habilidade durante a Sprint, fazendo com que a equipe de desenvolvimento seja incapaz de entregar um incremento potencialmente liberável. Ter mais de nove membros requer muita coordenação. Grandes equipes de desenvolvimento geram muita complexidade para um processo empírico gerenciar. As funções de Product Owner e Scrum Master não estão incluídas nesta contagem, a menos que também estejam executando o trabalho do Sprint Backlog
Um sprint dura cerca de um mês.
Os sprints são limitados a um mês. Quando o horizonte de um Sprint é muito longo, a definição do que está sendo construído pode mudar, a complexidade pode aumentar e o risco pode aumentar. Sprints permitem previsibilidade, garantindo a inspeção e adaptação do progresso em direção a uma meta pelo menos a cada mês. Sprints também limitam o risco a um mês de calendário de custo.
Acho que não faz sentido usar um framework baseado em um processo iterativo com projetos menores de 4 meses. 4 meses = 4 sprints. Você também deve considerar que obtém uma velocidade mais precisa após 3 sprints.
Dito isso , Eu pessoalmente uso uma versão limitada do Scrum para projetos menores. Mas você não pode realmente chamá-lo de Scrum então. Nesse caso específico, você está usando alguns princípios básicos do Scrum em sua própria implementação do framework.
Resposta
para iniciantes , pense no SCRUM como apenas um conjunto de diretrizes para a implementação de práticas ágeis. Nunca pense nisso como um “livro sagrado” de como fazer projetos. Para muitos projetos onde um fluxo constante de tarefas é necessário, o Kanbam é mais apropriado, por exemplo.
Os projetos Agile tendem a cair quando você está fazendo projetos que exigem uma data de término fixa ou um custo fixo. Embora você ainda possa fazer esses projetos usando métodos Agile, a necessidade de planejar tudo antecipadamente determinar se é provável que você acerte o alvo não é a maneira ágil usual – no ágil, você tende a continuar fazendo o trabalho até ficar sem coisas para fazer ou sem tempo para fazê-lo. Para a maioria dos projetos, isso está ok já que os requisitos mudam de qualquer maneira durante o projeto.
Comentários
- A maneira como agilizamos nossa equipe é deixando o cliente definir uma prioridade nas histórias (do mais ao menos importante), estimamos as histórias de usuários usando cartas de pôquer e planejamos quantas histórias pudermos implementar até o fim do prazo. Se ficarmos mais rápidos, agendamos mais histórias, de acordo com o que vem a seguir na lista de prioridades.
- Li sua resposta novamente depois de alguns meses e é realmente muito esclarecedora. +1