Ágil - O que estamos fazendo de errado?

Sou desenvolvedor de uma equipe ágil e tentamos usar o Scrum.

Então, vou colocar aqui um problema hipotético para ilustrar a situação.

Temos um aplicativo muito antigo, usando algum código JQuery confuso e com manutenção ruim. Também temos partes do aplicativo usando o React, e essas partes são muito mais fáceis de atualizar / manter. Além disso, o objetivo da empresa é criar um aplicativo de página única do cliente, no React, para que o uso do JQuery o afaste ainda mais.

Quando fazemos o planejamento, sempre buscamos a solução fácil em termos de tempo de desenvolvimento. Por exemplo, se estamos criando um novo diálogo ou algo assim, usamos o JQuery antigo porque é mais rápido e dizemos que voltamos mais tarde, para arrumar e se transformar em React, mas isso raramente acontece.

Obtemos os requisitos do que precisamos fazer nas histórias de usuários (que são bem feitas na IMO, são pequenas, mas explicam o que estamos fazendo e por que estamos fazendo isso).

Às vezes, os requisitos de novos recursos são muito pequenos, por exemplo, se um requisito diz "criar uma caixa de diálogo que carrega toneladas de conteúdo", mas não diz para implementar um recurso de carregamento, nós, na maioria dos casos, não o implementamos , mesmo sabendo que seria melhor para os clientes, com o motivo de isso comprometer nossa meta de sprint (mesmo que eu pessoalmente acredite que não).

O resultado é que nossa base de código é uma grande bagunça, com péssima capacidade de manutenção e, às vezes, novos recursos são muito pequenos e precisam de uma corrida completa (algo que poderia ser alcançado em um único dia em uma boa base de código) principalmente por causa desse desenvolvimento estratégia, basta ir rápido, fazer o mínimo.

Nesse caso, o que estamos fazendo de errado? Devemos abordar as soluções de uma maneira mais completa, para não escrevermos sempre códigos ruins e reescrevemos códigos que acabamos de escrever na semana passada? Ou devemos continuar fazendo isso apenas para garantir que todo esse código esteja sendo reescrito? Qual seria uma boa abordagem ágil para esse problema?

Isso não tem nada a ver com Agile ou Scrum.

O problema com "fita adesiva agora e vamos consertar mais tarde" é que mais tarde nunca chega e, nesse meio tempo, você está acumulando muita dívida técnica .

O primeiro passo para a recuperação é reconhecer o problema e parar de piorá-lo.

Para cada nova história de usuário, a equipe deve considerar "qual é a maneira correta de codificar isso?", Não "qual é a maneira mais rápida de hackear isso?" e planeje os sprints de acordo.

Para limpar o problema existente, veja as excelentes respostas para eu ter herdado 200 mil linhas de código espaguete - e agora?

O que você tem lá é o que Martin Fowler chama de "scrum flácido".

Se você ler corretamente todos os 12 princípios por trás do manifesto ágil , descobrirá que falha na maioria deles.

Forneça software de trabalho com frequência, de algumas semanas a alguns meses, de preferência à menor escala de tempo.

Você pode dizer que entrega um software realmente funcional? Ou apenas software que mal funciona?

Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente.

Você pode dizer que seu processo é sustentável? Você toma decisões com a sustentabilidade em mente? Ou você escolhe soluções que resolvem o problema atual sem levar em consideração os efeitos a longo prazo?

A atenção contínua à excelência técnica e ao bom design aumenta a agilidade.

O princípio verdadeiramente importante. Acredito que isso deve ser colocado em ENORME LETRAS VERMELHAS na página. É aqui que você falha mais.

A intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, depois ajusta e ajusta seu comportamento de acordo.

E obviamente. Se você descobrir que seu comportamento não está levando aos resultados desejados, altere-o. Se sua equipe não conseguir ver que há problemas, não poderá começar a corrigi-los.

Do seu comentário

Como prever isso em ágil?

Primeiro, aprendendo o que é realmente ágil. Scrum não é ágil. Alguns diriam que o Scrum é o pior dos frameworks ágeis, pois é muito fácil chegar à sua situação exata. Você deve aprender sobre outras estruturas ágeis. O que eu recomendaria é Extreme Programming. O que resolve claramente seus problemas. As soluções não são simples (foco na excelência técnica por meio de testes automatizados robustos, programação em pares e entrega contínua), mas são altamente eficazes. Conforme relatado no relatório State of DevOps .

O que você descreve é ​​- pelo menos na minha experiência - um padrão emergente bastante comum de equipes que tentam "ser ágeis". Está aberto a debate se isso é realmente parte do próprio Agile ou uma má implementação comum dele, é contra o manifesto / princípios ágeis ou uma conseqüência inerente dele, e assim por diante. Apenas do ponto de vista empírico e baseado no meu pequeno conjunto de experiências (e nas pessoas com quem converso), se uma equipe é ágil, parece ter uma chance maior que a média de se deparar com esse padrão. Vamos deixar assim e focar no seu exemplo concreto.

Existem dois aspectos separados para o que você descreve:

• Falta de entendimento / visão comum e, portanto, não é eficiente
• Como medir o sucesso / progresso e o custo total

Seguindo o caminho errado ou correndo em círculos

Na minha experiência, o principal motivo para isso acontecer é que, na tentativa de produzir código rapidamente, as equipes afastam ativamente casos de uso ou requisitos que eles já conhecem ou podem facilmente descobrir. Pense dessa maneira: 10 a 20 anos atrás, as pessoas tentaram escrever especificações gigantes e pensar em tudo com antecedência e muitas vezes falharam. Eles demoraram demais ou ignoraram alguma coisa. Uma das aprendizagens do passado é que, no desenvolvimento de software, existem coisas que você não pode saber e que mudam muito, daí a idéia de iterar rapidamente e produzir rapidamente uma saída sensível. Qual é um princípio muito bom. Hoje, porém, estamos no outro extremo: "Eu não ligo para isso porque faz parte do próximo sprint" ou "Eu não arquivo esse bug, lido com ele quando ele aparecer novamente".

1. Reúna todos os casos de uso , requisitos, dependências e restrições de alto nível que você pode encontrar. Coloque-o em algum wiki para que todos os interessados ​​e desenvolvedores possam vê-los. Adicione a eles quando algo novo surgir. Converse com seus acionistas e usuários. Use isso como uma lista de verificação durante o desenvolvimento para impedir a implementação de coisas que não contribuem para o produto final ou são soluções alternativas / hacks que resolvem um problema, mas causam três novos.
2. Formule um conceito de alto nível . Não estou falando sobre o design de interfaces ou classes, mas, em vez disso, esboçar o domínio do problema. Quais são os principais elementos, mecanismo e interações na solução final? No seu caso, isso deve ficar óbvio ao usar a solução alternativa do jquery como uma etapa intermediária e quando causa apenas trabalho adicional.
3. Valide seu conceito usando a lista que você reuniu. Existem problemas óbvios? Isso faz sentido? Existem maneiras mais eficientes de atingir o mesmo valor de usuário sem causar dívidas de longo prazo com a tecnologia?

Não exagere. Você só precisa de algo para que todos na equipe (incluindo não-desenvolvedores) tenham um entendimento comum sobre qual é o melhor caminho para o seu MVP. Todos devem concordar que não há omissões óbvias e que poderia realmente funcionar. Isso, em geral, ajuda a evitar quedas sem saída ou a necessidade de refazer a mesma coisa várias vezes. O Agile pode ajudá-lo a lidar melhor com o inesperado; não há argumento para ignorar o que é conhecido.

Esteja ciente da falácia do custo irrecuperável : se você começar com um tipo de arquitetura ou banco de dados, a maioria das pessoas hesita em alterá-lo no meio do projeto. Portanto, é uma boa ideia investir algum tempo em ter uma "melhor estimativa" antes de começar a implementar as coisas. Os desenvolvedores tendem a querer escrever código rapidamente. Mas, muitas vezes, ter algumas simulações, protótipos ao vivo, capturas de tela, estrutura de arame etc. permite uma iteração ainda mais rápida do que escrever código. Lembre-se de que todas as linhas de código escritas ou mesmo testes de unidade tornam mais difícil mudar seu conceito geral novamente.

Medindo o Sucesso

Um aspecto completamente separado é como você mede o progresso. Digamos que o objetivo do seu projeto é construir uma torre com 1 metro de altura usando coisas por aí. Construir um castelo de cartas pode ser uma solução totalmente válida se, por exemplo, o tempo de colocação no mercado for mais importante que a estabilidade. Se seu objetivo é construir algo que dure, usar o Lego teria sido melhor. A questão é: o que é considerado um hack e que solução elegante depende inteiramente de como o sucesso do projeto é medido .

Seu exemplo do "carregamento" é muito bom. Eu tinha coisas assim no passado, onde todos (incluindo vendas, pedidos de compra, usuários) concordavam que era irritante. Mas não teve impacto no sucesso do produto e não causou dívida de longo prazo. Então deixamos de lado porque havia coisas mais valiosas a ver com os recursos de desenvolvimento.

Meu conselho aqui é:

1. Mantenha tudo, até pequenos bugs, como tickets no seu sistema de tickets . Tome uma decisão ativa sobre o que está dentro do escopo do projeto e o que não está. Crie marcos ou filtre sua lista de pendências para ter sempre uma lista "completa" de tudo o que ainda precisa ser feito.
2. Tenha uma ordem estrita de importância e um ponto de corte claro onde o projeto possa ser considerado um sucesso. Qual nível de estabilidade / qualidade do código / documentação o produto final realmente precisa? Tente passar todos os dias do trabalho da melhor maneira possível, escolhendo de cima para baixo. Ao trabalhar em um ticket, tente resolvê-lo completamente sem introduzir novos tickets (a menos que faça sentido adiar as coisas devido à menor prioridade). Todo commit deve levá-lo adiante em direção ao seu objetivo final, não para os lados ou para trás. Mas, para enfatizar novamente: às vezes, um hack que produz trabalho adicional mais tarde ainda pode ser um resultado positivo para o projeto!
3. Use seu PO / usuários para descobrir o valor do usuário, mas também faça com que seus desenvolvedores descubram o custo da tecnologia . Os não-desenvolvedores normalmente não podem julgar qual é o verdadeiro custo de longo prazo (não apenas o custo de implementação!), Então ajude-os. Esteja ciente do problema do sapo fervente: muitos pequenos problemas irrelevantes podem, com o tempo, prender uma equipe. Tente quantificar a eficiência da sua equipe.
4. Fique de olho na meta / custos gerais. Em vez de pensar de sprint em sprint, mantenha uma mentalidade de "podemos, como equipe, fazer tudo o que for necessário até o final do projeto" . Os sprints são apenas uma maneira de quebrar as coisas e ter pontos de verificação.
5. Em vez de querer mostrar algo mais cedo, trace seu caminho no caminho mais rápido para um produto mínimo viável que possa ser dado ao usuário. Ainda assim, sua estratégia geral deve permitir resultados verificáveis ​​no meio.

Portanto, quando alguém fizer algo que não se encaixa no seu objetivo final de implementação, idealmente, não considere a história concluída. Se for benéfico fechar a história (por exemplo, para obter feedback dos clientes), abra imediatamente uma nova história / bug para resolver as deficiências. Torne transparente que a tomada de atalhos não reduz custos, apenas os oculta ou atrasa!

O truque aqui é discutir com o custo total do projeto: se, por exemplo, um pedido de compra forçar atalhos para estabelecer um prazo, quantifique a quantidade de trabalho que deve ser feito posteriormente para considerar o projeto!

Também tenha cuidado com a otimização baseada em critérios : se sua equipe é avaliada pelo número de histórias que podem ser exibidas em uma revisão de sprint, a melhor maneira de obter uma boa "pontuação" é cortar cada história em dez pequenas. Se for medido pelo número de testes de unidade escritos, tenderá a escrever muitos testes desnecessários. Não conte histórias, avalie quanto da funcionalidade necessária do usuário funciona, qual é o tamanho do custo por dívida de tecnologia a ser resolvido no escopo do projeto etc.

Sumário

Para resumir: Ir rápido e mínimo é uma boa abordagem. O problema está na interpretação de "rápido" e "mínimo". Deve-se sempre considerar o custo de longo prazo (a menos que você tenha um projeto onde isso é irrelevante). Usar um atalho que leva apenas 1 dia, mas gera uma dívida técnica de 1 mês após a data de envio, custa à sua empresa mais do que uma solução que levou 1 semana. Imediatamente, começar a escrever testes parece rápido, mas não se o seu conceito for defeituoso e eles consolidarem uma abordagem errada.

E lembre-se do que "longo prazo" significa no seu caso: conheço mais de uma empresa que faliu ao tentar escrever um ótimo código e, portanto, foi enviada muito tarde. Uma boa arquitetura ou código limpo - da perspectiva da empresa - só é valiosa se o custo para alcançá-lo for menor que o custo de não tê-lo.

Espero que ajude!

Estritamente da perspectiva do scrum, parece que o que você está fazendo de errado é que não está trabalhando com o cliente. Você precisa trabalhar em conjunto com o cliente para entender o que eles precisam e não apenas o que eles querem . Eles precisam de uma série de soluções rápidas ou precisam de um sistema estável e sustentável que os atenda a longo prazo? Isso pode ser difícil de determinar, mas a qualidade é tão necessária quanto uma cor de plano de fundo ou uma referência de desempenho. O cliente precisa estar ciente de que a estabilidade e a manutenção não são gratuitas e precisam ser projetadas no produto.

Se eles dizem que é o primeiro, você não está fazendo nada errado - supondo que você esteja explicando a eles nas avaliações do sprint que está cortando os cantos da engenharia para atingir os objetivos deles.

Se eles dizem que é o último, o que você está fazendo de errado é que não está dando a eles o que eles querem.

Um dos pilares do Scrum é a transparência. Se você estiver fazendo scrum, deve fazer revisões de sprint com o cliente. Nessas revisões, você está dizendo ao cliente que está cortando os cantos para entregar o software mais rapidamente? Se não, você deveria estar. Você precisa ser 100% claro com seu cliente sobre as ramificações de suas escolhas de design, para que ele possa tomar uma decisão informada sobre se está entregando seu software com um nível de qualidade adequado.

Ewan está certo. O motivo pelo qual o gerenciamento gosta do scrum é porque eles exigem recursos no estilo staccato e obtêm resultados rapidamente. Até que a bagunça resultante seja outro problema.

Agora que tenho sua atenção, por favor, deixe-me explicar. Não é Scrum como tal. É o cenário típico de um gerente de produto forte e de uma equipe de desenvolvimento fraca que é incapaz de fazer estimativas razoáveis ​​e realistas porque sente a pressão. Portanto, eles apresentam estimativas muito otimistas e aprofundam-se em problemas, cortando cantos para entregar a tempo.

No scrum, você (como desenvolvedor) começa a fazer seu próprio planejamento. Ninguém está dizendo para você entregar algum recurso em x dias. Se alguém está lhe dizendo para entregar em x dias, você não está fazendo o Scrum.

Qualquer que seja o problema que precise ser resolvido, solicite seu tempo. Você acha que precisa de tempo para refazer algo primeiro? Incorpore-o em sua estimativa. Você pode se dar ao luxo de fazer isso?

Vamos examinar o que você está fazendo, deixando de lado o Agile por um momento.

Quando fazemos o planejamento, sempre buscamos a solução fácil em termos de tempo de desenvolvimento; por exemplo, se estamos criando um novo diálogo ou algo assim, usamos o velho jquery porque é mais rápido e dizemos que voltaremos mais tarde para arrumar e transformar em reagir, mas isso raramente acontece.

Isso é chamado de "Dívida técnica". Martin Fowler descreveu o "Quadrante da dívida técnica" em um post do seu blog ao longo dos dois eixos: "Imprudente vs. Prudente" e "Deliberado vs. Inadvertente".

Você decide explicitamente usar o conhecido jquery de tecnologia antiga que o afasta ainda mais de uma de suas metas expressas (ou seja, um aplicativo de página única). Você faz isso para entregar "rapidamente". Isso é deliberado.

O que esse cálculo de "rapidamente" não inclui é o tempo necessário para implementar a funcionalidade para reagir posteriormente. Você escolhe uma alternativa que tem apenas desvantagens sobre a alternativa que você sabe ser a correta (ou seja, dedicar um tempo para implementar o recurso em reagir) com base em uma avaliação de que a velocidade é essencial. Isso é imprudente.

Martin Fowler soma esse tipo de dívida em "Não temos tempo para o design". Essa é uma escolha apropriada em um ambiente em que você não espera manter o código ou mesmo espera codificar por mais de alguns dias. Mas seu projeto é de longa duração e envolve explicitamente a manutenção do (s) cliente (s)

O que você está fazendo está errado no nível muito básico. É uma engenharia ruim !

Você assumiu uma dívida técnica, ignorando que essa dívida precisa ser paga e cobra juros. E você continuou fazendo isso até que a taxa de juros de sua dívida começou a se aproximar do trabalho disponível durante o seu sprint.

O que você deve fazer é reduzir o nível da dívida . Converse com seu chefe, converse com seu cliente. Você precisa trabalhar na manutenção ontem.

Pare de usar o Agile ...

Ou melhor, pare de tentar fazer algo de uma certa maneira puramente porque é isso que (sua compreensão de) ágil (ou scrum etc ...) dita. Tentar aplicar uma (des) interpretação de um desses termos a um projeto no estágio errado pode rapidamente se tornar o pior curso de ação. Use sua razão.

A razão pela qual seu projeto, e quase todos os outros projetos no mundo, é uma bagunça de código e abordagens divergentes, é devido à falta de um projeto arquitetônico onisciente e centralizado (foi o que eu disse).

Os motivos pelos quais isso pode estar faltando são:

• O arquiteto não possui a experiência (como seus dez primeiros projetos de hobby)
• O arquiteto não tem tempo
• O arquiteto não tem poder (o gerente diz que não ou sim, mas apenas para algumas partes)
• A equipe acredita em alguma metodologia de vodu que os salvará (tudo será resolvido porque estamos usando o Agile)

A solução simples é descartar todas essas palavras mágicas e examinar a realidade da situação, que pode ser resumida como:

1. O estado do código está impedindo a capacidade da equipe de entregar a tempo e sem erros.
2. Quanto mais recursos adicionarmos, pior será.
3. Portanto, faz sentido pausar, reavaliar e (talvez drasticamente) redesenhar as peças.

Você naturalmente perguntará por que chegou a esse estado em primeiro lugar, com o dedo da culpa girando e girando. A resposta é que isso é inevitável: à medida que seu design amadurece, você percebe que deveria ter feito de maneira diferente, mas não poderia ter previsto. Além disso, essa não é uma realização única por projeto, acontecerá várias vezes e é necessário planejar.

Dito isto, há muitas coisas que os gerentes podem fazer para exacerbar as coisas:

1. Deathmarching seus devs aos prazos.
2. Afirmar que os desenvolvedores podem registrar apenas o tempo em relação aos tickets, sem que haja tickets para "reflexão, consolidação e refatoração de qualidade" e um tempo generoso para eles.
3. Não dar a ninguém uma propriedade da arquitetura por tempo suficiente para controlá-la
4. Não permitir que essa pessoa faça as mudanças que acha necessárias

Olhando dessa maneira, é fácil ver como algumas interpretações do ágil e do scrum realmente o levarão por esse caminho ainda mais rápido!

Uma abordagem é criar tickets para cada parte da refatoração. O problema é que, muitas vezes, você não percebe que precisa de um grande refatorador até começar a trabalhar em um ticket menor, o que atrasa os prazos e o ticket passa por ciclos de aprovação, o que reduz a velocidade.

Outra abordagem é planejar sprints para usar apenas 25-50% da capacidade da sua equipe. Os desenvolvedores registram seu tempo nos tickets reais (registram o tempo que deveria levar sem refatorar) e o tempo de refatoração (um ticket grande para a semana, sem loops de aprovação, apenas discussão entre desenvolvedores). Se não houver refatoração, você poderá retirar os ingressos do sprint da próxima semana. Você ajusta o controle deslizante de porcentagem para as próximas semanas, à medida que o código subjacente do projeto melhora.

Então, para responder "o que estamos fazendo de errado", eu diria que você está confiando em uma metodologia sobre o senso comum. Você até pede uma "abordagem ágil para esse problema" . Eu diria que largue as palavras e pense sobre o problema real. Se você realmente deseja separar vários manifestos tentando decifrar se sua abordagem final de bom senso realmente cai sob o disfarce de "ágil" ou "scrum", faça o que for necessário :-)

Você não está fazendo nada de errado. Esse tipo de metodologia é projetado para fornecer recursos às especificações e o mais rápido possível.

Se você tem objetivos secundários para os quais está trabalhando, é melhor expressá-los como 'requisitos não funcionais' ou 'definição de pronto'.

por exemplo, você pode ter um requisito não funcional:

"Todos os novos recursos devem ser escritos em React"

e

"Todas as chamadas assíncronas devem implementar um controle giratório de carregamento e tratamento de erros"

Você só precisa pedir ao Dono do Produto (ou equivalente) que concorde que essas são coisas que valem a pena ser feitas, em vez de escondê-las porque os desenvolvedores gostam delas.