Como fazer o Scrum funcionar para uma equipe com funções definidas?

Algumas informações básicas

Faço parte de uma equipe interna de desenvolvimento de software. Isso consiste de

• 5 desenvolvedores (com experiências que variam de 2 a 5 anos, eu sou um deles)
• 3 funcionários de implementação (eles fazem a implantação e o treinamento do software)
• e 1 gerente de projeto.

Desenvolvemos muitos projetos de pequeno a médio porte, e seus prazos geralmente se sobrepõem. O desenvolvimento é assim:

1. "Cliente" nos fornece um conjunto de requisitos iniciais
2. Desenvolvemos o sistema para a referida especificação
3. Apresentar o referido sistema ao "cliente"
4. "Cliente" nos fornece requisitos adicionais com base na referida apresentação
5. Repita de 2 a 4 até que o "cliente" fique sem novos requisitos ou a data de destino da implantação esteja próxima
6. Configurar e implantar o sistema

Isso, junto com o fato de ser o "cliente" que lida com os prazos na maioria das vezes (o que é uma bandeira vermelha, pelo que vejo aqui em Programadores e PM.SE) e não seguimos uma metodologia definida de desenvolvimento à codificação de cowboys, código quase impossível de manter e bugs que passam pela produção, entre outras coisas. Por isso, optamos por adotar uma metodologia baseada em Agile como Scrum.

Por que Scrum?

Foi uma iniciativa do nosso gerente, e todos parecem concordar com isso, dada a nossa situação atual.

O problema com o Scrum

Alguns dos elementos do Scrum estão em conflito com a nossa configuração atual que não podemos resolver com facilidade, particularmente a natureza do "pau para toda obra" dos desenvolvedores Agile. A equipe de implantação não sabe como programar e os desenvolvedores têm habilidades de comunicação e treinamento abaixo da média. E essa formação não vai mudar tão cedo.

A questão

Isso afetaria a efetividade do Scrum como metodologia? Outras mudanças precisariam ser feitas para compensar? Ou seria melhor abandonar completamente o pensamento e pensar em uma metodologia diferente?

Na verdade, sua maneira atual de trabalhar não está tão distante do Scrum, como você pode imaginar.

No Scrum, você também obtém um conjunto inicial de requisitos, implementa-os e demonstra o resultado e, com base na demonstração, novos requisitos podem ser dados a você ou as partes interessadas podem decidir que o produto é bom o suficiente para que não seja necessário mais desenvolvimento.
Na sua situação, o "cliente" sobre o qual você falou pode ter o papel de Product Owner no Scrum (eles já parecem preencher esse papel definindo as prioridades em um projeto e decidindo quando ele está pronto para ser lançado).
Uma grande mudança pode ser a duração de uma iteração. No Scrum, uma iteração deve durar entre 1 e 4 semanas.

Quanto à composição da equipe e à falácia do pau para toda obra: Scrum não exige que todos sejam um pau para toda obra. O Scrum exige apenas que a equipe como um todo tenha todas as competências necessárias para obter o produto de uma lista de requisitos para algo que foi / pode ser implantado.
Na sua situação, eu podia ver facilmente uma equipe por projeto composta por um ou mais desenvolvedores (realizando principalmente o trabalho de implementação e teste) e um membro da "equipe de implementação" que se concentra principalmente na criação de manuais e material de treinamento para os recursos que os desenvolvedores estão implementando agora.

Depois que o cliente / Dono do produto der a luz verde para a implantação, o trabalho da equipe scrum será concluído, para que os desenvolvedores possam ir para outro projeto (e estar disponíveis apenas sob demanda para corrigir problemas após a implantação) e a implementação os funcionários podem mudar para realizar o treinamento e apoiar a implementação.

O fato de haver um prazo não é um problema real, desde que haja flexibilidade suficiente em quais funcionalidades precisam estar nessa versão.

Você pede alternativas, então eu vou dizer eXtreme Programming (XP). Penso especificamente que a programação em pares pode ajudá-lo aqui.

Ao emparelhar pessoas com habilidades diferentes, não importa qual habilidade: fazer café, testar, treinar etc., você pode espalhar as habilidades pela equipe.

Mas, para ser sincero, não parece que o SCRUM está muito longe para você. Parte do SCRUM é ser flexível e encontrar o melhor para sua equipe. Parte do XP é respeitar sua equipe e se adaptar. Talvez daqui a 100 anos possamos ter uma profissão mais desenvolvida, com regras rígidas (embora eu duvide), mas por enquanto, fazer o que funciona para você é tudo o que temos. O importante é ter loops de feedback. Se algo não estiver funcionando, a equipe precisará discutir isso e experimentar coisas novas até encontrar algo que funcione.

Como fazer o Scrum funcionar para uma equipe com funções definidas?

Apenas faça. De acordo com o guia do scrum, todos são desenvolvedores, mas aqui no planeta Terra, pessoas diferentes trarão coisas diferentes para a mesa. Eu quase fui linchado quando sugeri que algumas pessoas são realmente testadores enquanto outros escrevem o software.

Algumas coisas que você pode querer resolver:

Corrida

Parece que você tem uma fase inicial de desenvolvimento seguida por uma série do que são ostensivamente sprints. Considere terminar isso. O cliente não apenas verá algo cedo, como também terá uma ideia melhor dos marcos de desenvolvimento à medida que eles ocorrem.

Prazos fixos

Isso surge uma e outra vez e, de fato, é um espinho persistente no lado dos desenvolvedores onde atualmente trabalho. O Scrum define estimativas para o sprint - nada mais. Sim, você pode atingir o alvo após uma série de sprints, mas uma vez que o cliente está de olho nas versões anteriores, o escopo provavelmente aumentará significativamente. Isso não é um problema em si, mas o cliente deve estar ciente de que mais trabalho ocorrerá em sprints posteriores e ultrapassará os requisitos conhecidos.

Sua situação pode ser uma melhor correspondência para o Kanban, pois você pode começar com o iterar e iterar a partir daí. Isso significa que você não terá uma introdução do big bang que atrapalhe seus projetos atuais - comece visualizando tarefas em um quadro e adotando algumas das práticas, como retrospectivas e reuniões diárias.

Você precisa ser um pouco mais cuidadoso do que com o Scrum, porque não é tão prescritivo: por isso, tende a voltar ao que foi antes, em vez de inculcar uma mentalidade ágil adequada.

O Scrum não funciona bem com projetos separados que se sobrepõem, pois você não tem um conjunto estável de pessoas trabalhando em um projeto para o sprint completo. Por isso, conceitos como verbosidade etc. provavelmente só o deprimirão.

Mas primeiro pegue a história que oferece o melhor custo / benefício para o cliente e implemente-a, incluindo testes automatizados completos, com uma qualidade suficientemente boa para ser implantada, antes de trabalhar na próxima história é um conceito útil. Da mesma forma, exige que todo o código escrito para uma história seja revisado por outro desenvolvedor antes que a história seja considerada "concluída".

Presumo que sua equipe de implementação tenha que escrever documentos de treinamento e referência, eles podem ser escritos (primeiro rascunho) para cada história antes que o código seja escrito, tornando-se, assim, os testes de aceitação.

Espero que você descubra que, no início de cada projeto, onde a contribuição da equipe de implementação seria de grande ajuda para os desenvolvedores, eles estão 100% comprometidos com a implantação do projeto anterior. Portanto, considere se a equipe de implementação pode estar trabalhando para escrever as histórias e a documentação do usuário para o próximo projeto, enquanto os desenvolvedores estão escrevendo o código para o projeto atual.

“Desenvolvimento orientado a comportamento”, com a equipe de implementação escrevendo o exemplo usado nos testes, pode funcionar.

Portanto, há um pouco de Scrum que irá ajudá-lo, mas tente usar o Scrum em vez de usá-lo.