A ideia principal do framework Scrum é organizar o processo de desenvolvimento para uma execução mais rápida do trabalho em vários estágios do ciclo de vida do projeto. Mas essa abordagem sempre leva os desenvolvedores aos comportamentos certos? Muitos usuários que participaram da discussão da questão acimano Stack Overflow, experimentaram coisas semelhantes quando os desenvolvedores cortaram atalhos, colocaram muita ênfase nas pontuações mais altas atribuídas aos seus tickets ou mesmo fingiram ser funcionários de alto desempenho na frente dos gerentes. Como esses perigos podem ser evitados? A questão em questão mudou de local de trabalho.stackexchange.com para softwareengineering.stackexchange.com . Isso sugere que os programadores veem as considerações em torno do Scrum e sua eficácia como algo sério o suficiente para ir além do gerenciamento do ciclo de desenvolvimento de software. Eles sentem o impacto desse método de gerenciamento de projetos no ambiente geral de trabalho.
Scrum é a causa de más práticas de desenvolvimento ou é apenas uma desculpa para este problema?
Muita controvérsia gerou especulação sobre o impacto do Scrum em equipes e desenvolvedores individuais, e as limitações que o framework impõe a quem o usa. Enquanto muitos culpam o Scrum pelas falhas da equipe, outros acreditam que isso é um erro de atribuição e que as raízes dos problemas nas equipes de desenvolvimento são muito mais profundas.
Os defensores do Scrum veem o mau gerenciamento como a raiz do problema. Aqui está o que o usuário Llewellyn diz, resumindo: “A gestão essencialmente ignora os desenvolvedores. Existem prazos fixos a serem cumpridos a fim de alcançar os resultados pré-determinados. O trabalho não é feito por uma equipe focada em atingir o mesmo objetivo, mas por um grupo de pessoas em que todos se preocupam apenas com si mesmos. É desencorajado planejar com antecedência e pensar fora da caixa. Em tais condições, o programador, por conseguinte, sucumbe às circunstâncias e encontra a salvação na simples execução das tarefas que lhe são atribuídas. Eu trabalhei em tais condições. Mas não culpe o Scrum por isso. "
O usuário DJClayworth expressou o sentimento de muitos dos comentários, dizendo que os programadores que pensam que estão sob pressão terão um desempenho ruim com qualquer metodologia de gerenciamento de desenvolvimento.
A opinião contrária sobre este assunto foi melhor expressa pelo usuário Martin Maat , que chamou a atenção do público para o fato de que o próprio fato de tantas pessoas sentirem a necessidade de falar sobre este assunto fala pela frustração que causa o Scrum.
Quais são os problemas comuns com o uso do Scrum?
Algumas armadilhas comuns do Scrum surgiram nos comentários, seja porque o framework está sendo mal utilizado ou porque são, de fato, problemas inerentes do Scrum. Aqui estão quase uma dúzia de problemas desse tipo que chamaram nossa atenção.
▍1. As reuniões diárias são para gerentes
A primeira crítica ao Scrum está relacionada ao fato de que durante as reuniões diárias (stand-ups) surgem tendências indesejadas. Um dos argumentos a favor desta ideia é que os stand-ups podem degradar-se ao estado dos acontecimentos, cujos participantes apenas fazem o que dizem sobre a sua produtividade. Especialmente se os gerentes estiverem presentes em tais eventos. Portanto, o usuário Matthew Gaiser (ele já escreveu para nós, mas tropeçamos em seu comentário) convocou eventos stand-up que visam informar os gestores sobre a situação atual ( gerenciamento de atualizações) Ele acredita que as apresentações dos desenvolvedores nesses eventos apenas estimulam os gestores a observar no que estão trabalhando, mas não trazem nenhum benefício. Isso é ainda mais verdadeiro para equipes distribuídas, quando cada um dos membros da equipe trabalha em seu próprio modo.
▍2. Concluir tarefas desempenha um papel importante
Outra ideia que surgiu nos comentários é que qualquer metodologia de desenvolvimento que divide grandes tarefas em tarefas menores e monitora o andamento dessas tarefas leva, intencionalmente ou não, a novas abordagens de avaliação do trabalho. Se você apenas começar a aplicar algumas métricas, isso afetará o comportamento das pessoas cujo desempenho é avaliado de acordo com essas métricas.
Muitos comentaristas dizem que isso significa que os desenvolvedores podem “cortar atalhos” para concluir o que precisava ser feito no sprint atual. O problema apontado pelo usuário Gaisere outros usuários, é aquele ticket separado que está sendo trabalhado, e que, durante o sprint, é transferido para a categoria de “pronto”, essa é uma “caixa preta”. O que quer que esteja dentro desta "caixa preta", não afetará o resultado da avaliação da velocidade de trabalho. O usuário Gaiser escreve que a implementação de baixa qualidade que passou pelo departamento de QA e a implementação perfeitamente testada e projetada não são diferentes uma da outra. Como resultado, verifica-se que a contabilização do número de tickets fechados é um indicador não confiável da produtividade do trabalho.
▍3. Desenvolvedores extremamente produtivos que não trabalham em equipe
Outro tópico discutiu a tensão entre grandes programadores solo e grandes equipes. Quando todos seguem a metodologia Scrum, alguns desenvolvedores podem ser extremamente produtivos, mas a "equipe" pode ser esquecida. O usuário Gaiser diz que sem os incentivos certos, a auto-organização é uma meta inatingível: “Os membros da equipe resolverão os problemas como acharem adequado ou conforme as instruções. Se isso não ajudar a construir a equipe, muitas coisas não serão realizadas e os membros da equipe simplesmente seguirão em frente desordenados ”.
Ele continua: "Além disso, permitir que cada desenvolvedor escolha seus próprios métodos para resolver problemas, significa mais difícil depurar o código."
▍4. Tarefas difíceis são adiadas para mais tarde
Gaiser, na mesma linha, continua a criticar a ilusão de produtividade. Ele diz que, ao aplicar Scrum, o foco principal é fazer com que o tíquete fique no estado "Pronto". Pensar profundamente sobre a tarefa ao mesmo tempo não parece particularmente produtivo. Portanto, os desenvolvedores tendem a assumir tarefas fáceis e evitar as mais complexas. Aqui, novamente, as palavras do usuário Gaiser: "Scrum incentiva os desenvolvedores a assumir tarefas fáceis que levam um pouco de tempo para serem resolvidas, o que permite aos desenvolvedores mostrar consistentemente alta velocidade." Como resultado, verifica-se que as escolhas de tarefas diárias e os relatórios de trabalho diários estão forçando a escolha de tarefas que levam um dia para serem concluídas.
▍5. As características do produto são mais importantes do que a qualidade do código
Mesmo assim, Gaiser acredita que o uso do framework Scrum leva a uma queda na qualidade dos produtos: “O quão bom um desenvolvedor é, geralmente é determinado por sua capacidade de desenvolver código confiável. Scrum, a menos que o product owner entenda de programação e revise o código, desvaloriza seriamente essa característica dos projetos. " Ele enfatiza aqui que a "prontidão" de um tíquete é frequentemente determinada não após a verificação da qualidade do código, mas somente após a implementação do recurso correspondente.
▍6. Falta de tempo para discutir questões de trabalho com os colegas
Se a velocidade de desenvolvimento é o único indicador da eficácia da equipe, isso significa que os membros da equipe não têm mais tempo para discutir alguns problemas uns com os outros, para obter a opinião de outros ou para testar suas idéias, alguém falando sobre eles. E é exatamente isso que torna uma equipe uma equipe. Aqui, novamente, as palavras do usuário Gaiser: “Grandes desenvolvedores costumam consultar outros desenvolvedores e procurar alternativas para suas opiniões. Mas essas classes ocupam o tempo que leva para fechar os tickets e isso diminui a velocidade de desenvolvimento.
▍7. Bugs recentemente identificados precisam esperar sua vez
Outro mau comportamento do Scrum é que "bugs são encontrados após o sprint e considerados novas tarefas." Isso pode levar os desenvolvedores a liberar código de baixa qualidade, já que tarefas adicionais não podem ser incluídas no sprint atual.
▍8. Arquitetura baseada em tíquetes
O sistema de tíquetes não se baseia apenas nas tarefas que os desenvolvedores escolhem para si próprios. O usuário Gaiser também diz que usar o Scrum, inadvertidamente, leva a uma arquitetura de projeto confusa, já que os desenvolvedores trabalham nos tickets na ordem em que aparecem e independentemente uns dos outros. Como resultado, "a arquitetura rapidamente se torna um reflexo dos tickets".
▍9. Metodologia de gestão de desenvolvimento que afeta absolutamente tudo
Lendo a discussão, você pode prestar atenção aos comentários, cujos autores observam que a raiz de todos os problemas está na falta de aderência estrita às regras do Scrum. No entanto, talvez a afirmação anti-Scrum mais forte do usuário Gaiser seja que ele domina todo o resto. Isso pode destruir uma equipe forte. "[Scrum] distorce e quebra quaisquer outros mecanismos de gerenciamento de desenvolvimento, esta estrutura se torna um fenômeno generalizado em que nada além de rituais de execução é feito de maneira uniforme, e executar esses rituais cria a ilusão de sucesso."
Discutimos uma lista bastante longa de problemas que podem ser causados pelo uso do Scrum e, talvez, só se tornem mais perceptíveis devido ao uso deste framework. Mas na discussão que estamos pesquisando, você pode encontrar tantas ideias sobre como os desenvolvedores podem viver em paz e harmonia seguindo as regras do Scrum .
Como obter o máximo do Scrum?
Muitas das respostas aos comentários de Gaiser, que receberam muitas avaliações positivas, foram de que o que ele estava falando não era Scrum. Aqui está o que o usuário Stephen Byrne escreveu sobre isso: “Acho que esta é uma boa resposta com alguns insights valiosos, mas tenho que concordar com muitos outros comentaristas que o que é descrito aqui definitivamente não é Scrum, embora e é visto sob o disfarce de Scrum. " Mas muitos odiavam abertamente o Scrum, ou concordavam com o usuário Gaiser que se algo der errado ao usar o Scrum, isso significa que este framework simplesmente não está sendo usado corretamente.
Como usar Scrum corretamente?
▍1. Reuniões diárias não são o mesmo que pegar novos tickets todos os dias
Muitas pessoas disseram que as reuniões diárias forçam os desenvolvedores a fechar os tickets todos os dias. Mas, como observado por DJClayworth , você não pode fazer sem priorizar tarefas. E se as prioridades não forem definidas naturalmente, então esta tarefa deve ser assumida pelo Scrum Master: “Precisamos priorizar as tarefas dentro dos sprints, tarefas maiores precisam ter maior prioridade, então alguém tem que assumir tarefas difíceis no primeiro dia do sprint. Em qualquer caso, se no segundo dia ninguém tiver assumido uma tarefa grande e complexa, o Scrum Master deve dizer algo como: “Vejo que ninguém assumiu a tarefa de compactar o banco de dados. E esta é uma grande tarefa. Se vamos concluir o sprint, precisamos começar a trabalhar nessa tarefa agora. "
▍2. ,
Todas as tarefas resolvidas no sprint devem ser divididas em pequenas partes. Isso é inegável. Mas o framework Scrum não está dizendo que os desenvolvedores devam ser obcecados por métricas que indicam resultados. Scrum não sugere colocar os desenvolvedores uns contra os outros. O usuário Gaiser propõe a abandonar completamente a consideração dos pontos de programadores individuais. Ele também aponta que muitos gerentes podem precisar reaprender as regras do Scrum: “Diga aos gerentes que no momento em que elogiam os desenvolvedores ou dão a eles uma promoção com base em tickets fechados, eles mudam radicalmente o comportamento da equipe. "
Usuário DJClayworthconcorda que ignorar deliberadamente as métricas associadas a tickets individuais deve ser parte da tarefa de um bom Scrum Master: “A atenção deve ser focada em garantir que a equipe atinja seus objetivos como equipe. Um Scrum Master deve seguir esta linha de comportamento e evitar qualquer discussão ou métrica com base em quantas histórias de usuário cada membro da equipe promoveu. "
▍3. Você precisa dar pequenos passos em direção a grandes objetivos, mas com essa abordagem, você não deve se esquecer deles.
Aqui está outra ideia para quebrar grandes problemas em pequenas partes: "Se você está trabalhando em uma pequena peça de um quebra-cabeça, isso não significa que você precisa esquecer o quebra-cabeça inteiro."
O usuário Llewellyn aponta que usar Scrum não é uma desculpa para ignorar completamente os princípios do desenvolvimento de software de qualidade: “Você tem que ter uma boa ideia de para onde o projeto está indo. Esse conhecimento pode ser usado para planejar a arquitetura do projeto, envolvendo-se no planejamento mesmo dentro do sprint atual. "
Scrum não livra os programadores da necessidade de fazer seu trabalho, investindo todo seu conhecimento e toda sua experiência nisso. Portanto, a ligação de Llewellyn vai para os programadores que estão entre os leitores dos comentários: “Vocês estavam na reunião, podem olhar o backlog, sabem qual é a visão geral do projeto na organização. Você se esforça para evitar ter que gastar longos períodos de tempo em algo do futuro distante. Mas não há nada de errado em lançar as bases para um sistema extensível e modular que seja adequado para resolver problemas atuais e permitirá que você crie oportunidades adicionais já planejadas sem problemas no futuro. "
▍4. É necessário decidir o que significa "Concluído"
Um dos tópicos que levantamos na discussão que estávamos discutindo dizia respeito aos critérios de Definição de Pronto (DoD) e como a definição desses critérios ajuda os programadores individuais a aderir a certos padrões de qualidade e a se manter informados sobre o que se espera deles. A questão mais urgente aqui era quem e quando desenvolve esses critérios. Quando se trata de “ quando ”, geralmente se tratava de desenvolver critérios o mais rápido possível ou de como eles deveriam ser desenvolvidos durante o planejamento do sprint.
A resposta para a pergunta de quem produz DoD foi escrita pelo usuário SpoonerNZ na forma de uma resposta a outra perguntano site da Engenharia de Software. “Os critérios de prontidão são criados pela equipe, mas esse processo pode exigir a presença de um Scrum Master. Isso é necessário para estabelecer limites de qualidade, caso a equipe não tenha padrões de desenvolvimento claros. Por exemplo, uma equipe pode não querer mexer com revisões de código ou testes de unidade, o que resultará em todos eles sendo adicionados ao DoD pelo ScrumMaster para garantir um desenvolvimento de alta qualidade. Em uma situação ideal, a equipe, tendo compreendido os pontos fortes do que está sendo oferecido, aceitará com prazer, mas o mundo real nem sempre é ideal. ”
Quem deve trabalhar aderindo ao DoD? Uma meta natural (e desafiadora) é garantir que as disposições descritas no DoD sejam aplicadas em uma equipe e que sejam apoiadas por todos os membros dessa equipe. Mas há bons motivos para estender a influência do DoD a várias equipes. Ou até mesmo toda a organização. Aqui está o que o usuário Alan Larimer escreve sobre isso: “A falta de uma definição do DoD universalmente reconhecida para um produto afeta negativamente a qualidade e a transparência do trabalho. O nível organizacional do DoD deve ser mínimo, técnico e, às vezes, específico da organização, o que pode fornecer uma aplicação universal dos critérios de preparação. A organização pode propor padrões para codificação. Uma organização pode exigir a criação automatizada de montagens, fornecendo os recursos para criar e manter montagens para cada produto. Qualquer parte do DoD, seja criada por uma organização ou por um desenvolvedor individual, deve agregar algo de valor aos critérios de prontidão. "
▍5. Os gerentes devem desempenhar o papel de observadores silenciosos
Embora o que está no título desta seção já esteja consagrado no manual oficial do Scrum, a análise da discussão mostra que essa regra, que é triste, é frequentemente violada em reuniões diárias com a presença de gerentes. Por causa disso, os programadores sentem a necessidade de explicar por que os jobs de ticket estão demorando mais do que o planejado. Se houver apenas programadores participando da reunião, haverá pouca necessidade de tais explicações. Aqui está o que o manual Scrum diz sobre isso: “Daily Scrum é uma reunião interna da equipe de desenvolvimento. Se outra pessoa estiver presente, o Scrum Master garante que ela não interfira na reunião. "
▍6. As pessoas devem ser mais importantes do que os processos
Se você precisar de orientação sobre como aplicar as regras do Scrum, leia as palavras escritas pelo usuário Frank Hopkins para lembrá-lo de um princípio clássico: "As pessoas são mais importantes do que os processos." Aqui ele acrescentou o seguinte: "Uma boa equipe deve definir seus processos, processos rigidamente definidos não contribuem para a formação de uma boa equipe."
Outro usuário, meriton , apontou que o uso do Scrum depende de programadores individuais: “O Scrum não prevê o fato de os desenvolvedores trabalharem independentemente uns dos outros. O Scrum prevê que a equipe de desenvolvimento seja auto-organizada, ou seja, que a equipe tome decisões sobre como seus membros interagem. " Notas de
nvoigt do usuárioque as equipes no Scrum se auto-organizam pelo fato de virem para um projeto com uma missão definida: “O framework Scrum é baseado no fato de que você é uma equipe. Não importa na equipe se o ticket foi fechado ontem por um programador específico. Qualquer pessoa que trabalhe em uma equipe entende a meta (ou seja, DoD) e se esforça para alcançá-la junto com o resto da equipe. "
▍7. Construa equipes para trabalhar como Scrum, mas não espere que o Scrum crie uma equipe
Usuário nvoigtaplicou uma metáfora esportiva: “Imagine que 11 pessoas receberam um manual de futebol impresso. Eles foram informados de que precisavam praticar por volta das 10 da manhã todos os dias na Sala de Conferências 5, gastando 15 minutos cada. Você acha que o resultado será um bom time de futebol? E se essas 11 pessoas fossem bons jogadores de futebol profissionais? O comando não funcionaria de qualquer maneira? Sim, não seria. É que os times de futebol não são criados dessa forma. Como qualquer esporte de equipe, Scrum precisa que aqueles que usam este framework sejam uma equipe. Se for apenas um grupo de pessoas, cada uma das quais quer apenas ganhar pontos para si mesma mostrando quantos pontos na história do usuário cobriram ou quantos objetivos alcançaram, então esse grupo sempre perderá para uma equipe cujos membros jogam juntos e não próximos uns dos outros. amigo,ou um contra o outro. "
Resultado
O usuário nvoigt está disposto a admitir que Scrum "não é adequado para absolutamente todas as pessoas ou equipes." E, como o interesse da comunidade no assunto que estamos discutindo aqui mostrou, a aplicação de um conjunto de regras que o Scrum pode pressionar para desenvolver pode levar a um ambiente de trabalho que está longe do que ela gostaria de construir.
Gostaríamos de resumir este material com as palavras do usuário Seth R... Ele diz que não há necessidade de esperar milagres dos rituais de metodologias ágeis. Demais é desejado por quem busca com sua ajuda, como num passe de mágica, corrigir as deficiências da equipe de desenvolvimento. É assim que ele vê a situação: “É tudo uma questão de acelerar o feedback. Como resultado, a equipe tem a oportunidade de se auto-avaliar e tomar decisões sobre como trabalhar para obter os melhores resultados. Scrum não ajudará você a criar um produto melhor, mas se você levar o autoteste a sério, ele pode ajudá-lo a construir uma equipe melhor. Isso, por sua vez, leva ao desenvolvimento de um produto melhor. "
Muitas pessoas comparam essa estrutura à democracia. Então, talvez Scrum seja a pior forma de gerenciamento de desenvolvimento, além de todos os outros?
Ou talvez seja, como diz o guia oficial , uma estrutura fácil de entender, mas difícil de dominar perfeitamente.
Como você responderia à pergunta do título deste artigo?
