Por que preciso de SCRUM vs. um processo menos formal e mais leve para minha equipe?

Gostaria de começar minha pergunta dizendo que entendo que o SCRUM ou algum derivado dele é provavelmente uma boa maneira de gerenciar o desenvolvimento de software. Parece que todas as grandes empresas e meus gerentes o usam ou o usaram, e não posso argumentar com toda essa experiência. No entanto, estou lutando para entender os "porquês" e todas as leituras e até meu treinamento oficial da SCRUM no trabalho não está fazendo o trabalho para mim. É apenas toda retórica. Então eu venho aqui procurando respostas.

Até agora, desenvolvi equipes de 4-5 membros de maneira muito eficaz, completamente auto-organizada e sem a necessidade de treinamento, metodologia ou software especial. Apenas discussões em cubos, reuniões ad hoc e revisões de código individuais. Agora estou em uma posição no trabalho em que nos dizem que o SCRUM é o caminho a seguir e tudo o que vem junto. Quando eles descrevem o SCRUM para mim, leio coisas assim:

• Indivíduos e interações sobre processos e ferramentas
• Software que trabalha sobre uma documentação completa
• Colaboração do cliente sobre negociação de contrato
• Respondendo a mudanças após seguir um plano

Isso é ótimo, mas tudo isso parece senso comum para mim. Por que essa necessidade foi codificada? Me disseram que a metodologia nos ajuda a responder às mudanças. Qual específicoaspectos do SCRUM estão me permitindo ser tão flexível que eu não estava conseguindo com minhas reuniões ad hoc, discussões sobre cubos e reuniões de planejamento de desenvolvedores? Eles explicam a necessidade de ter um produto final a cada duas semanas ou sprint. No meu projeto em particular, não há "cliente", o software não será concluído por um ano ou mais e, enquanto isso, provavelmente estarei demonstrando apenas para a gerência superior todos os meses ou menos. Então, por que a necessidade explícita de uma entrega a cada duas semanas? Eles enfatizam a importância da reunião de planejamento do sprint, na qual toda a equipe apresenta as histórias e tarefas para o próximo sprint. Isso não é diferente das reuniões improvisadas de planejamento que tive no passado. Por que isso deve ocorrer toda segunda-feira, e por que toda a equipe precisa estar envolvida? Entendo o conceito de cada membro que "possui" o produto, mas o fato é que apenas alguns indivíduos podem realmente contribuir para dividir cada história em tarefas, enquanto o restante apenas assiste à toa.

Mais uma vez, entendo que a maioria das pessoas está por trás desse processo e, portanto, ele deve funcionar, e preciso entrar. Eu só gostaria de entender o porquê. O meu problema é que eu já pratico essas coisas e simplesmente não gosto de codificá-las desnecessariamente? Ou talvez ainda não tenha visto as vantagens dessas técnicas porque elas estão sendo feitas de maneira inadequada? Qualquer informação ou conselho pessoal real sobre isso, em oposição ao discurso que estou acostumado a receber, seria extremamente apreciada.

Penso que existem dois aspectos para responder à sua pergunta, mas deixe-me começar por parabenizá-lo por trabalhar com pessoas que parecem ser inteligentes e competentes o suficiente para poder trabalhar praticamente sem um processo fortemente definido e ainda entregar um produto. Infelizmente, esse não é o caso em todas as equipes de software; talvez um dos seus problemas com o Scrum seja que você e seus colegas de trabalho não precisam de um processo despejado em você para torná-lo mais eficaz. Você já pode ser eficaz.

Outras equipes não precisam e precisam de um processo mais estritamente definido e de algumas diretrizes para fazê-las fazer as coisas. Isso não significa que essas equipes sejam mais estúpidas ou menos capazes, apenas significa que talvez tenham problemas de auto-organização ou trabalho com disciplina como equipe. Isso também pode ser uma experiência de aprendizado simples quando proveniente de um local onde as pessoas trabalham principalmente sozinhas para trabalharem juntas como uma equipe. O Scrum pode ajudar a chegar lá, porque oferece algumas diretrizes que são fáceis de entender e seguir, mas eficazes o suficiente para pressionar a equipe a começar a se reunir.

Como o Scrum não diz nada sobre a maneira como o desenvolvimento de software deve ser feito, também deixa a equipe com a liberdade de decidir por si mesma (por exemplo, você ainda pode fazer um sprint aplicando um método cascata bastante conservador, desde que seja feito no final do sprint).

Portanto, a equipe é uma questão. A outra questão é gerenciamento e confiança de gerenciamento. Aqui, o Scrum pode ser bom porque é transparente e permite que todos os interessados ​​vejam o progresso que a equipe faz em ciclos definidos. Portanto, não é "estamos progredindo, infelizmente não podemos mostrar nada agora, mas acredite, terminaremos a tempo". Isso pode até ser verdade, mas pode ser reconfortante para qualquer gerente ter uma demonstração regular, na qual eles podem ver que o progresso realmente aconteceu.

Scrum não é uma bala de prata. Pode não funcionar para algumas equipes por várias razões, talvez para algumas equipes a auto-organização não funcione. Talvez para você seja o contrário e pareça um processo despejado em uma equipe já produtiva e organizada.

Em caso de dúvida, sugiro que tente e veja. Se não funcionar e a maior parte da equipe não gostar de trabalhar dessa maneira, não faça. No entanto, verifique-o por alguns meses (digo alguns meses, porque os primeiros sprints serão difíceis de qualquer maneira e você precisará de tempo para ajustar os detalhes) e depois reavalie.

Pode ser controverso, mas o Scrum é melhor para diminuir os medos gerenciais do Agile, ou para usar com uma equipe que já está com desempenho insuficiente. Se sua equipe está indo muito bem, cumprindo metas, ganhando dinheiro e feliz, o Scrum não comprará nada para você, porque tudo o que fará será perturbar o bom equilíbrio de atividades que você realiza (e tornar sua equipe bem-sucedida). Scrum não é uma bala de prata. Na minha experiência com isso, ajuda apenas as equipes que tiveram pouca estimativa e comunicação para começar. Uma equipe que trabalha com estimativas realistas em um ambiente de comunicação eficaz é prejudicada apenas pela sobrecarga do processo do Scrum.

Acredite ou não, boas equipes de software existiam antes do Scrum aparecer. O Scrum ajuda os ruins a melhorar.

A maioria das respostas aqui já enumerou o motivo, embora um pouco indireto. A resposta de Anne é especialmente esclarecedora quando ela toca na transparência. Ou seja, permitindo que os gerentes vejam o que está acontecendo. E a resposta de Schultz também toca nisso quando ele fala sobre as pessoas não serem capazes de esconder o fato de que elas estão diminuindo.

Então, eu gostaria de dizer o que os outros já estão dizendo, mas em uma linguagem mais direta: o principal objetivo do SCRUM não é gerenciar o desenvolvimento de software, o principal objetivo do SCRUM é medir o desenvolvimento de software.

Outros sistemas já tentaram antes e as pessoas propuseram inúmeras métricas para tentar medir o desenvolvimento de software, mas falharam. O SCRUM vira o problema de cabeça para baixo e transfere o ônus da medição dos gerentes e dos próprios desenvolvedores. A lógica é simples: quem melhor estimar quanto tempo leva para fazer alguma coisa do que quem faz o trabalho?

Agora, o problema é que os programadores são bem conhecidos por serem otimistas demais. Pergunte a um programador quanto tempo leva para fazer algo e ele normalmente subestimará a dificuldade da tarefa. O SCRUM fornece as ferramentas para controlar isso:

• reuniões diárias para avaliar o progresso e obter uma visão geral do projeto
• as estimativas são feitas em "pontos" em vez de horas / dias para abstrair o tempo ausente
• gráficos de queima e gráficos de tortura / lebre para visualizar a velocidade dos pontos
• histórias e tarefas em um quadro para obter uma visão geral da carga de trabalho
• sprints e iterações para agir como prazos para que possamos medir o progresso
• funções específicas para o scrum master, proprietário e membro da equipe para evitar a tentação de trapacear

etc.

Você pode perceber que todas as opções acima fazem principalmente duas coisas:

1. Eles medem o trabalho. Trabalho a ser feito ou trabalho a ser realizado ou trabalho concluído.
2. Eles tentam muito evitar o problema do programador super otimista para obter uma estimativa melhor e mais realista.

Quanto mais tempo você implementar o SCRUM, mais precisa será sua estimativa. Na verdade, eu pessoalmente acredito que rodar sprints + um backlog + um gráfico de burn-down por si só é suficiente para curar a maioria dos programadores de fazer estimativas ruins sobre quanto tempo leva para fazer alguma coisa.

Pessoalmente, acho que o objetivo do SCRUM é satisfazer as organizações mais antigas, onde a alta gerência não pode ou não ficará atrás de um processo mais enxuto. Trabalho como arquiteto (Chicken) há cerca de um ano em um departamento que utiliza fortemente o SCRUM. Meu histórico anterior é de startups do Vale do Silício, a maioria das quais usava um processo focado em recursos muito mais enxuto, ad hoc e altamente iterativo (às vezes semanalmente ou até mesmo diariamente). Acho o SCRUM, pelo menos da maneira como o implementamos, para exagerar em termos de processo (e, de certa forma, mais pesado que a cascata (pelo menos do ponto de vista do desenvolvedor). O desvio é que nossos proprietários de produtos são realmente mais parecidos com os analistas de requisitos na organização de TI. Como resultado, eles tendem a embotar as informações provenientes dos negócios e, pior ainda, deixam os negócios irresponsáveis ​​pela equipe de desenvolvimento (o que requer infusões sucessivas regulares de histórias de usuários). No entanto, na minha futura inicialização, eu não usaria um SCRUM. Eu provavelmente o usaria apenas na situação em que o gerenciamento requer a sobrecarga adicional.

Não vou falar da perspectiva de um purista. Eu sinto que você é capaz de executá-lo de forma semelhante ao que Scrum diz. No entanto, o ponto principal é que você pode executar o programa. O que acontecerá se você estiver de férias por um mês?

Eu vejo o scrum como um mecanismo para otimizar tudo o que você tem feito e colocar alguns aspectos definidos nisso. Para que na sua ausência, alguém também possa replicá-lo e também para outros projetos. No entanto, o scrum não é uma bala de prata. Eu já vi muitas pessoas que começaram a usar o Scrum (porque estão na moda) e foram espancadas porque não entenderam a essência dele.

PS: O Scrum não exige que o seu sprint tenha a duração de duas semanas. Pode demorar um mês (o seu caso).

Por favor, veja meus comentários à pergunta primeiro.

SCRUM é um paradigma de desenvolvimento ágil de software. Como tal, é ágil. Não supõe que você deva seguir seu modelo clássico. E duvido que alguém faça realmente. Eu trabalhava em várias organizações e todas as equipes o adaptavam às suas necessidades. Não é incomum que não haja cliente / consumidor quando se trata de liberar algum produto / biblioteca / API pública. Eu nunca tive um. No meu caso, nosso GM agiu como um, que a IMO era como não ter.

Ter duas semanas de corrida é difícil. Muito difícil. 3 semanas é melhor, mas é realmente experiente e familiarizado com a equipe do processo. Tivemos 4 semanas ou um mês. Isso nos deu tempo suficiente para "resolver", por assim dizer, no começo e ter mais confiança no final devido a mais durante os testes. Eu gostava disso e ficaria com pelo menos três semanas.

A outra equipe com a qual eu estava colaborando não tinha nada além de pendências. Eles se reuniam, informavam sobre o status e o que vem a seguir e é isso. Depois que tudo estivesse pronto, eles apresentariam outra lista de pendências. Eles sabiam que não era o SCRUM, mas funcionou para eles e é isso que importa.

É mais leve? Definitivamente é. Mas não é SCRUM. O que eu gosto no SCRUM é que ele promove disciplina. As pessoas sentem a pressão de entregar algo todos os dias. Todo mundo sabe o que os outros fazem e ele falha, todo mundo sabe disso. Mesmo que se tente encobrir isso (leia a mentira), torna-se óbvio muito mais cedo do que com outros processos. Portanto, quando você diverge e simplifica como com essa equipe, precisa ter certeza de que faz isso com as pessoas certas. Caso contrário, isso pode desmoronar rapidamente, degradando-se em reuniões de status sem sentido, onde todos ficam e pensam "o que eu faço aqui? Eu sei o que preciso fazer, e que diabos?"

Esses são meus dois centavos. Eu faço meu próprio SCRUM como desenvolvimento: planejo o trabalho, divido em tarefas, calculo-as, observo o progresso. Isso realmente me ajuda a estar no topo das coisas. Apliquei algumas coisas da SCRUM em projetos que terceirizei e funcionou muito bem para mim.

Apenas ... fique ágil ;-)

Eu recomendo que você ignore o scrum. Daqui a alguns anos surgirá uma nova moda, e você será menos cínico e ainda poderá adotá-la de todo o coração. Na verdade, você pode rapidamente se tornar um especialista. Depois, você pode ganhar muito dinheiro escrevendo um livro e falando em conferências.

Como muitas coisas são cíclicas, provavelmente essa nova moda será um processo pesado, semelhante ao RUP. O que aconteceu, como você vê, é que todos seguirão processos ágeis leves, e eles serão responsabilizados por suas falhas no projeto. Portanto, é claro que a solução lógica é que sejam necessários mais planejamento e design iniciais!

Sério, acho que você não precisa do Scrum. Não há nada no scrum que seja melhor do que outros processos ágeis concorrentes. Também tem muitos nomes estúpidos para as coisas.

Isso é ótimo, mas tudo isso parece senso comum para mim. Por que essa necessidade foi codificada?

O Scrum é geralmente comparado a metodologias mais antigas e mais pesadas. As metodologias tentaram fazer com que a cascata sem feedback funcionasse, impondo mais documentos, mais assinaturas e mais planejamento antecipado. O manifesto Agile (que você está citando) foi uma reversão dessas idéias.

Me disseram que a metodologia nos ajuda a responder às mudanças. Quais aspectos específicos do SCRUM estão me permitindo ser tão flexível que eu não estava conseguindo com minhas reuniões ad hoc, discussões sobre cubos e reuniões de planejamento de desenvolvedores?

Parece que você já tem uma estrutura ágil. Se você já está respondendo bem às mudanças, obviamente não precisa de ajuda. Alguns processos tornam-se tão ocultos com o procedimento que a correção de um bug requer uma fase completa de análise e design funcional, e não pode entrar no projeto até o próximo ano, no mínimo.

Eles explicam a necessidade de ter um produto final a cada duas semanas ou sprint. No meu projeto em particular, não há "cliente", o software não será concluído por um ano ou mais e, enquanto isso, provavelmente estarei demonstrando apenas para a gerência superior todos os meses ou menos. Então, por que a necessidade explícita de uma entrega a cada duas semanas?

O Scrum Original prescreve sprints de um mês. Há uma tendência desagradável para o machismo ágil na redução de sprints. ("Sim, bem, nossos sprints são apenas um dia ...") O Cliente / Cliente é quem tem autoridade para dizer que o projeto está pronto ou precisa de mais trabalho. Se você está demonstrando para a gerência superior todos os meses, provavelmente é seu cliente e provavelmente já está muito próximo do Scrum.

Com base na sua descrição do que sua equipe está fazendo, o Scrum provavelmente não é muito diferente. Você pode obter algum valor com a padronização, porque será mais fácil explicar aos estrangeiros o que está acontecendo se você usar os termos do Scrum. Além disso, Scrum pode ser usado como escudo; por exemplo, Scrum prescreve que decisões técnicas devem ser tomadas pela equipe - apontar esse princípio pode ser uma boa maneira de obter um valor técnico que, de outra forma, é difícil de vender (programação em pares, por exemplo).

O Scrum é basicamente uma interface que sua equipe pode implementar. Se o fizer, terá uma boa idéia sobre como se comunicar com pessoas de fora da equipe e eles terão uma boa idéia sobre como se comunicar com você. Somente você pode saber se sua equipe precisa disso.

Nós não usamos Scrum no trabalho. Utilizamos uma metodologia fundada em Agile e Lean que é semelhante em muitos aspectos. Eu usei esse processo em equipes que variam em tamanho entre 3 a 5 pessoas, incluindo o líder. Embora haja diferenças, acho que você poderá ajudá-lo a descobrir se o Scrum é útil para sua situação.

Fazendo a Metodologia Explícita

Tornamos nosso processo explícito porque revisamos nosso processo a cada finalização / revisão do sprint. Parte do resumo / revisão é identificar práticas que não estão funcionando para nós. Também discutimos práticas que acreditamos que funcionem para nós e, se houver acordo suficiente, tentaremos. Não poderíamos fazer isso sem codificar nossa metodologia.

Cancelar assinar

Este é o cavalo de batalha do nosso processo. Isso garante o que escrevemos é o que é necessário. Quando obtemos um recurso específico, procuramos nosso cliente. O cliente é quem vai usar o que está escrevendo. Em alguns casos, é necessário fazer proxy do cliente com alguém que o represente (como gerenciamento de produtos). Essas são nossas etapas e, até a última etapa ser concluída, o recurso não será concluído.

• Obtenha o recurso do quadro, rastreador etc.
• Vá conversar com o cliente e entender o que ele está procurando antes de escrever qualquer coisa.
• Implemente o recurso.
• Mostrar ao cliente o recurso de trabalho em sua forma final Faça com que o cliente assine o recurso sendo concluído.

Fatias verticais

Fazemos todo o nosso desenvolvimento em fatias verticais. Isso suporta a capacidade de assinar com um recurso concluído, além de outros motivos.

• Amortiza problemas de integração, integrando-os a cada recurso. Ajuda a eliminar o tempo de trituração no final de um projeto.
• Permite cortar recursos facilmente porque eliminamos muitas dependências cruzadas.
• Permite interromper o desenvolvimento se precisarmos mudar de direção.
• Podemos fazer lançamentos iterativos , fornecendo ao cliente funcionalidades antecipadamente.

Aceitação TDD

Utilizamos estruturas de teste de unidade para aceitação de tdd. Isso nos dá muitos benefícios.

• A grande reestruturação não custa muito tempo para refazer o teste.
• Garantimos a funcionalidade do cliente.
• Abordamos a integração de código.
• Suporte à prática de desenvolvimento de fatia vertical.

A compilação é sempre liberável

Após cada push, o código deve ser liberado. Mesmo se o recurso estiver incompleto, nada deve ser quebrado. Todos os testes devem ser executados e todas as funcionalidades anteriores devem estar presentes. Esta é realmente uma extensão do nosso desenvolvimento de fatia vertical. Como tal, ele compartilha muitos dos mesmos benefícios.

• Permite cortar recursos facilmente porque eliminamos muitas dependências cruzadas.
• Permite interromper o desenvolvimento se precisarmos mudar de direção.
• Podemos fazer lançamentos iterativos , fornecendo ao cliente funcionalidades antecipadamente.

Integração contínua

Cada push gera uma compilação por meio do servidor de compilação de IC. O servidor de compilação verifica o código, executa todo o conjunto de testes, identifica o código e o empacota para implantação. Reforça nossa política de que a construção é sempre liberável.

Estimativa de pontos para cartões

Todo bug, recurso e tarefa se torna "cartão". Um cartão é a menor unidade lógica de trabalho que possui algum benefício para o cliente. Nós apontamos isso de acordo com nossa escala. Qualquer que exceda o nosso valor máximo em pontos ou seja discriminado ainda mais. Descobrimos que quanto maior o valor do ponto, maior o desvio possível no tempo para a conclusão, quebrando ainda mais os cartões grandes. Se a carta tiver ambiguidade suficiente, ela é arredondada para o próximo valor de ponto na escala. Cada cartão deve ser assinado antes que possa ser considerado completo. A estimativa adequada suporta nossa capacidade de calcular a velocidade.

Velocidade

Temos uma semana de corrida. Toda sexta-feira, planejamos o trabalho e priorizamos o trabalho para a próxima semana. Com base em nossa velocidade, temos uma boa idéia de quanto "trabalho" podemos realizar dentro de uma semana. Nossa velocidade é a média e a mediana do total de pontos completados dentro de uma semana. Os aumentos no desvio padrão são analisados ​​em busca de estimativas ruins (que estão sempre tentando melhorar) ou interrupções aumentadas (sobre as quais falo com o gerente). A velocidade também pode ser usada para estimar uma data precisa da conclusão de um projeto, mas apenas se for o único projeto em desenvolvimento.

Melhoria e Design Incrementais

Também temos uma política para deixar o código pelo menos um pouco melhor do que o que você encontrou. Refatorar / redesenhar o código no início de um cartão. O objetivo é levar em conta o crescimento orgânico que pode prevalecer com o desenvolvimento incremental. Também refatoramos no final por normal.

Na maioria das vezes, essas são as regras que seguimos e por que as seguimos.

Parece-me que você está em uma equipe muito experiente e de alto funcionamento. Parabéns, Scrum / Agile está basicamente formalizando o que sua equipe intuiu todo esse tempo.

Eu acho que o que pode ser uma vantagem para toda a sua empresa é adotar o Scrum como um "terreno comum", não entre os membros da sua equipe de desenvolvimento, mas entre a equipe de desenvolvimento e o departamento de negócios em geral .

Enquanto o Scrum Sprints é timebox, as equipes podem selecionar entre as recomendações que variam de duas semanas a 1 mês. Qualquer menor e haveria muitas Revisões e Retrospectivas e mais poderia prejudicar a capacidade da empresa de mudar de direção dentro de um ano. Parece que você encontrou seu ponto ideal de 1 mês, então empurre para isso.

Há muita margem de manobra para você ajustar os parâmetros do Scrum e tenho certeza de que pode explicar aos seus negócios que você ainda está fazendo o Scrum da maneira certa. Uma vantagem é que, se você conhecer a empresa no meio do caminho, o envolvimento deles poderá render apoio positivo.