Ele tenta chegar a um acordo com o impacto do scrum na capacidade dos desenvolvedores de fazer um grande trabalho. A afirmação é ousada: scrum está transformando bons desenvolvedores em desenvolvedores médios. Isso pode ser verdade?

A ideia do scrum framework é organizar um processo de desenvolvimento para passar rapidamente pelos diferentes ciclos de projetos. Mas isso sempre incentiva os comportamentos certos a fazê-lo? Muitos dos usuários que se juntaram ao debate em torno da pergunta sobre assunto têm histórias semelhantes de como os desenvolvedores pegam atalhos, se distraem com sua pontuação alta de bilhetes ou até fingem produtividade para os gerentes. Como evitar essas armadilhas?

Que a questão foi migrada da nossa troca de local de trabalho para a engenharia de software, mostra que os desenvolvedores consideram preocupações com o scrum e sua eficácia maiores do que o ciclo de vida padrão de desenvolvimento de software; eles sentem seu efeito em seu local de trabalho como um todo. O usuário Qiulang faz uma afirmação ousada em sua pergunta: Scrum está transformando bons desenvolvedores em desenvolvedores médios.

 

Isso pode ser verdade?

 

Scrum é a causa de más práticas de desenvolvimento ou apenas uma desculpa para isso?

Muito do debate tentou lidar com o impacto e limitações do scrum em qualquer equipe ou indivíduo. Enquanto muitos veem o scrum como a causa das falhas da equipe, outros acreditam que ser um erro de atribuição e dizem que a disfunção nas equipes de dev é muito mais profunda.

Os defensores do scrum vêem a má gestão como a causa. Llewellyn escreve em suas observações finais: “Se a gestão está essencialmente ignorando os desenvolvedores, há prazos fixos a serem alcançados com um escopo predefinido, ou é um ambiente de cão-come-cão em vez de uma equipe focada em alcançar o mesmo objetivo, se planejar com antecedência e pensar fora da caixa não são apreciados, então sim, eventualmente você vai desistir e recorrer apenas a fazer as tarefas atribuídas. Já passei por isso. Mas não culpe isso no scrum.

O usuário DJClayworth ecoa o sentimento de muitos comentários dizendo que “desenvolvedores que pensam que estão sob pressão) farão um trabalho ruim em qualquer metodologia de desenvolvimento”.

A oposição é melhor resumida pelo usuário Martin Maat, que aponta: “O simples fato de tantas pessoas sentirem a necessidade de dizer algo sobre isso é um indicador da frustração que o scrum causa”.

Vamos desempacotar alguns pontos da discussão. Independentemente de você ser pró ou contra, podemos dar uma olhada na discussão para ver onde o scrum falha com os desenvolvedores e onde ele os ajuda a se destacar.

 

O que são armadilhas típicas de scrum?

 

Se as pessoas estão fazendo errado ou se é um bug assado na estrutura scrum, algumas armadilhas comuns de desenvolvedor aparecem nos comentários. Aqui estão dez que nos destacaram:

 

Standups são para gerentes

 

Uma primeira crítica é sobre como dinâmicas não intencionais acontecem durante os standups. Um argumento é que eles podem se degenerar para ser apenas uma demonstração de produtividade, especialmente quando os gestores estão presentes. Esta é a razão pela qual o usuário Matthew Gaiser em sua resposta rebels standups como “gerenciamento de atualizações”. Em sua mente, o check-in só convida os gerentes a acompanhar o que está sendo trabalhado de maneira inútil. Isso é ainda mais verdadeiro para equipes distribuídas que trabalham assincronicamente. (Divulgação completa: Matthew já escreveu para nós antes. Mas nós tropeçamos na pergunta scrum por acaso)

 

Priorizando ‘feito’

 

Outro ponto levantado é que qualquer processo que divida o trabalho e rastreie o progresso leva a uma nova medida para o progresso (deliberada ou não). Apenas introduzindo métricas, isso influencia o comportamento das pessoas que contribuem para elas.

Muitos comentaristas sugerem que isso significa que os desenvolvedores podem cortar os cantos para completar o que estava comprometido em terminar no sprint atual. O problema que Gaiser e outros apontam é que um bilhete individual que está sendo trabalhado e movido para ‘feito’ durante um sprint é uma caixa preta. Conta o mesmo para o indicador de velocidade. “Uma implementação ruim”, gaiser wirtes “que passa qa e uma implementação bem testada, bem arquitetado são equivalentes.” É um falso indicador de produtividade.

 

Indivíduos muito produtivos que não trabalham em equipe

 

Outro tópico provocou a discrepância entre grandes indivíduos vs. grandes equipes. Com todos seguindo a metodologia scrum, você pode ter alguns desenvolvedores altamente eficientes, mas você não tem uma equipe. Gaiser argumenta que, sem os incentivos certos, a auto-organização é um objetivo não cumprido:

 

“Os membros da equipe vão fazer as coisas da maneira que preferirem/são incentivados a fazer e, a menos que isso se soma a uma equipe útil, muitas coisas não são feitas e os membros da equipe continuam marchando sobre a bagunça.”

Além disso, deixar cada desenvolvedor escolher seu método para resolver um problema, disse Gaiser, cria mais trabalho durante a depuração.

 

Tarefas complicadas são despriorizadas

 

Em uma veia semelhante, Gaiser ainda critica a ilusão de produtividade — há um foco em fazer qualquer bilhete para “fazer”, enquanto o pensamento profundo não parece muito produtivo. Assim, os desenvolvedores podem pegar frutas baixas e pular os problemas difíceis de resolver. Gaiser novamente: “Scrum incentiva a escolha de trabalho que pode ser facilmente feito e rapidamente agitado em um ritmo constante.” O resultado: Catch-ups diários e check-ins incentivam a escolha de tarefas que podem ser feitas em um dia.

 

Recursos sobre código robusto

 

A qualidade, acredita Gaiser, sofrerá. “Grandes desenvolvedores geralmente são definidos por sua capacidade de desenvolver código robusto. A menos que o proprietário do produto seja técnico, o scrum desvaloriza massivamente que, como o proprietário do produto, não está avaliando o código.” A este ponto, ele ressalta que um “bilhete feito” muitas vezes é uma decisão de recurso e não uma verificação do código que está sendo escrito.

 

Não há tempo para polinização cruzada ou troca com pares

 

Quando a velocidade é a única medida, a equipe não tem mais tempo para consultar, dar uma