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 segunda opinião, executar um conceito por alguém — todas as coisas que fazem de uma equipe uma equipe. Nas palavras de Gaiser: "Grandes desenvolvedores são frequentemente procurados por conselhos e por segundas opiniões. Mas qualquer tempo que faz isso é menos tempo gasto produzindo bilhetes, então sua velocidade cai."

Novos bugs têm que esperar

Outro dos maus comportamentos do scrum é que "os bugs são encontrados após o sprint e, portanto, contados como um novo trabalho". Ele incentiva o comportamento onde os desenvolvedores podem liberar código falho, porque esse novo trabalho não pode ser incluído no sprint atual.

Arquitetura orientada por bilhetes

Não só os devs fazem escolhas sobre o que trabalhar com base no sistema de bilhetes, Gaiser também sugere que o scrum involuntariamente cria arquitetura bagunçada, com os desenvolvedores trabalhando através de bilhetes sequencialmente e independentemente uns dos outros como "a arquitetura rapidamente começa a espelhar os bilhetes".

Um processo para governar todos eles

Lendo a discussão você encontrará aqueles argumentando que não seguir as regras de scrum corretamente é a causa principal de todos os problemas. No entanto, talvez o ponto mais forte de Gaiser contra o processo de scrum seja sobre ele se tornar o processo que substitui todo o resto, e com isso pode quebrar uma equipe vencedora: "[Scrum] dobra e quebra todos os outros processos para ele e se torna esse processo abrangente onde você não faz nada consistentemente, exceto rituais de scrum e fazendo esses rituais de scrum parecerem bem sucedidos."

Essa é uma longa lista de problemas, sejam eles ou não estritamente causados ou apenas trazidos à tona por scrum. No entanto, igualmente numerosas foram as sugestões de como permitir que os desenvolvedores para fazer jus à grandeza sob as regras scrum.  

Como tirar o máximo do scrum?

Muitas das respostas à resposta de Gaiser — atualmente os mais votados — foram sobre como seu processo não foi scrum. Stephen Byrne escreveu: "Eu acho que esta é uma boa resposta com algumas grandes ideias, mas devo concordar com a maioria dos outros comentaristas, o processo que está sendo descrito aqui definitivamente não é scrum como deveria ser." Mas pessoas suficientes detestam scrum ou ressoaram com a resposta de Gaiser de que algo deve ser quebrado com a forma como scrum é implementado.

Então, como você pode fazer scrum certo?

Standup diário ≠ novos ingressos todos os dias

Muitos dos debates sugeridos em standups diários criam pressão para entregar um bilhete fechado todos os dias. Mas a priorização das tarefas ainda deve acontecer Como o usuário DJClayworth aponta, se isso não acontecer naturalmente, é o trabalho do mestre do scrum: "Você deve priorizar as tarefas dentro do sprint, e você deve priorizar as grandes tarefas mais altas, então alguém deve pegar as grandes tarefas difíceis no primeiro dia. De qualquer forma, se no segundo dia do sprint, ninguém pegou a tarefa complexa, então o mestre do scrum deve dizer 'Vejo que ninguém começou a tarefa de compactação do banco de dados – essa é uma tarefa grande e precisa ser iniciada imediatamente se vamos terminá-la neste sprint'."

Pare de perseguir os melhores pessoais não rastreando-os

Sim, você deve quebrar tudo em um sprint em pequenos pedaços, mas scrum não diz que você deve ficar obcecado com o progresso — certamente não colocando devs uns contra os outros. Gaiser sugere parar de rastrear pontuações para indivíduos completamente. Ele também ressalta que muitos gestores podem precisar reaprender seu processo. "Diga à gerência que no segundo em que eles elogiam um dev ou dão-lhes um aumento com base no volume de bilhetes, eles mudam radicalmente o comportamento."

O usuário DJClayworth concorda que ignorar ativamente as métricas individuais de bilhetes deve ser um bom trabalho do mestre scrum: "O foco deve ser se a equipe completou seus compromissos como uma equipe. O mestre scrum deve enfatizar isso e evitar qualquer discussão ou medição de quantas histórias cada pessoa moveu."

Quebre os grandes objetivos, mas não se esqueça deles.

Outra nota sobre a quebra de tarefas em pedaços: Pegar uma pequena peça do quebra-cabeça não significa ignorar o quebra-cabeça. Llewellyn enfatiza que o processo de scrum não pode ser desculpa para esquecer completamente o bom desenvolvimento de software.

"Você deve ter uma boa ideia de onde o projeto está indo, e você pode usar esse conhecimento quando você planeja a arquitetura mesmo para o sprint atual." Scrum não absolve as pessoas de fazer seu trabalho como desenvolvedores de software experientes, então o apelo de Llewellyn é para seus pares entre os leitores. "Você esteve nas reuniões de planejamento, você pode verificar o atraso, você sabe qual é a visão geral. Você vai querer evitar investir muito tempo em algo muito à frente no futuro, mas não há nada de errado em estabelecer as bases para um sistema modular extensível que funcione bem para o que você precisa agora e também apoiará as adições futuras planejadas."

Concorde com sua 'definição de feito'

Uma das coisas que aparece é a Definição de Done ou DoD e como isso ajuda a manter os padrões e expectativas para o indivíduo claros. As perguntas mais urgentes são quem a cria e quando? Quanto ao 'quando?': O mais rápido possível ou durante o planejamento de sprint parecem ser sugestões comuns.

Para o "quem?" SpoonerNZ escreve como resposta para outra pergunta sobre engenharia de software. "A Definição de Done é criada pela equipe, mas pode exigir que o scrum master imponha restrições de qualidade se a equipe não tiver padrões claros de desenvolvimento. Por exemplo, uma equipe pode não querer revisões de código ou testes de unidade, mas um mestre de scrum pode precisar aplicá-los para garantir que a qualidade seja mantida. Na situação ideal, a equipe vê os benefícios e quer tais restrições de qualidade, mas o mundo real nem sempre é o ideal."

Quem precisa compartilhar o DoD? Bem, naturalmente o objetivo (difícil) é ter todos na mesma equipe para concordar com isso. Há boas razões, porém, para estendê-lo a várias equipes. Ou até mesmo uma organização. Alan Larimer sobre isso: "Sem uma definição comum de 'Done' para um produto, a qualidade e sua transparência serão impactadas negativamente. Os níveis organizacionais de Definição de Feito devem ser mínimos, técnicos e, por vezes, fornecidos pela organização para que possam ser aplicados universalmente. A organização pode fornecer padrões de codificação. A organização pode exigir construções automatizadas, fornecendo os recursos para criá-lo e mantê-lo para cada produto. Qualquer parte da definição de 'Feito' seja criado pela organização ou por uma equipe de desenvolvimento individual deve trazer valor."

Gerentes como observadores silenciosos

Embora já faça parte do guia scrum, a discussão parecia sugerir que muitos, infelizmente, vivenciam standups diários onde os gestores estão presentes. Por causa disso, eles sentem que precisam explicar por que os ingressos estão demorando mais do que eles teriam em uma reunião com apenas seus pares. Então, para reiterar: um standup é uma reunião de equipe. Como afirmado no guia original: "O scrum diário é uma reunião interna para a equipe de desenvolvimento. Se outros estiverem presentes, o mestre do scrum garante que eles não interrompam a reunião."

Pessoas sobre o processo

Se você quer uma regra sobre como aplicar o conjunto de regras no quadro scrum, Frank Hopkins comenta com a máxima clássica, "Pessoas sobre processos", e elabora: "Uma boa equipe deve definir seus processos, processos rígidos não fazem uma boa equipe".

Outro usuário, meriton,aponta que o scrum depende dos indivíduos. "Scrum não diz que os desenvolvedores trabalham de forma independente. Ele diz que a equipe de desenvolvimento se organiza, o que significa que a equipe pode decidir como seus membros colaboram."

nvoigt observa que as equipes do scrum se auto-organizam porque chegam a um projeto com uma missão já estabelecida. "Scrum se baseia no fato de que você é uma equipe. Em uma equipe, não importa se você tem "um bilhete feito" ontem. Em uma equipe, você concorda sobre qual é o seu objetivo (ou seja, Definição de Feito) e, em seguida, se esforça para alcançá-lo. Juntos.

Construa uma equipe para fazer scrum, não espere scrum para construir sua equipe.

O usuário nvoigt vai para a metáfora esportiva: "Imagine 11 pessoas recebendo um manual de futebol e sendo dito que a prática é todos os dias durante quinze minutos por volta das 10 da manhã na sala de conferência #5. Você acha que é isso que faz um bom time de futebol? Mas e se essas 11 pessoas fossem realmente bons, jogadores profissionais? Ainda sem equipe? Não. Não é como se constrói uma equipe. Assim como esportes em equipe, scrum precisa que os participantes sejam uma equipe. Se eles são apenas participantes que procuram aumentar sua própria posição mostrando quantos pontos de história eles fizeram ou quantos gols eles marcaram, eles sempre perderão o dia para uma equipe que trabalha em conjunto em vez de um ao outro ou um contra o outro."

Pensamentos de despedida

nvoigt está pronto para admitir que scrumdoe "não funciona com cada pessoa e não funciona em todas as constelações" e como a participação em torno da questão mostrou, o conjunto de regras que é scrum pode levar a realidades que estão muito longe da intenção.

Há muitas vozes na linha saltando para a defesa de Scrum e reiterando-a como elevar equipes à grandeza e capacitar uma equipe a crescer além de seus indivíduos.

Um pensamento de despedida vem de Seth R. Ele diz que não há milagre a ser esperado de rituais ágeis em geral. E exigi-los magicamente consertar uma equipe é pedir demais. Em vez disso, sua interpretação é: "Trata-se de apertar o ciclo de feedback para que a equipe possa se autoexaminar e descobrir por si mesma como melhorar. Scrum não vai ajudá-lo a construir um produto melhor, mas se você levar o passo de autoexame a sério, pode ajudá-lo a construir uma equipe melhor. Isso, por sua vez, leva a um produto melhor."

Mais de uma pessoa comparou o quadro à democracia. Então, scrum, talvez, a pior forma de processo de desenvolvimento, exceto para todos os outros?

Ou é, como o guia scrum afirma, uma estrutura que é simples de entender, mas difícil de dominar?

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.