O código de refatoração aleatório é permitido no scrum

fundo

• Minha equipe usa scrum
• No momento, não tenho nenhuma tarefa atribuída
• Não há mais tarefas pendentes no backlog
• Hoje é dia do trabalho para o meu cliente.

Não tendo muitas coisas para fazer hoje, eu queria começar a refatorar algum código que continuo vendo no projeto em que estou trabalhando, mas atualmente não estou designado a nenhuma tarefa de sprint para fazer uma refatoração em grande escala.

Tudo bem no Scrum se eu começar a refatorar aleatoriamente o código que eu tenho e não o escrevi, que sempre me incomoda, mas não tem tempo outros dias para corrigi-lo devido às atribuições de outros dias?

E quanto aos outros dias que tenho tempo livre entre os sprints.

Na verdade, acredito e acredito em refatoração contínua. Eu sempre faço isso nos trechos de código em que estou trabalhando quando atribuída uma história, mas e quanto a outro código que vejo que não está atualmente relacionado ao que estou trabalhando naquele momento?

Realmente não pretendo atacar outras respostas, mas mais ninguém está escrevendo testes automatizados aqui? Aqui está uma leitura divertida de Martin Fowler para quem faz o Scrum sem as práticas adequadas de engenharia de software. Robert C. Martin também diz muito sobre isso aqui .

Então, para a minha resposta ... Resumindo, é assim:

Sim, o código de refatoração "aleatoriamente" é permitido no Scrum , desde que a equipe decida que isso deve ser feito. (Afinal, é auto-organizado)

E agora a resposta longa:

É evidente que deixar cada vez mais dívidas técnicas após cada Sprint é uma receita para o desastre. Em breve, todo mundo diminuirá a velocidade, pois o código fica mais bagunçado; cada mudança será mais difícil de fazer, porque o código é tão confuso e confuso que leva mais tempo para encontrar os pontos a serem alterados do que para fazer a mudança real. Fica ainda pior se você precisar fazer uma alteração em um módulo grande e confuso que você não conhece, torna-se impossível obter / manter a produtividade ao adicionar / alternar pessoas no projeto e assim por diante.

Se uma equipe deseja manter sua velocidade constante, deve poder manter a base de código limpa para incrementar continuamente o software. A refatoração é uma prática obrigatória se você deseja manter sua velocidade ao longo do ciclo de vida do projeto e se deseja reduzir o risco de adicionar / alternar pessoas no projeto e se deseja poder fazer alterações nos módulos, nada sabe. sobre e assim por diante.

No entanto, a refatoração é uma atividade muito perigosa. Repito - é uma atividade muito perigosa . Ou seja, a menos que você tenha cobertura de teste suficiente para poder alterar com segurança e livremente a base de código. Se você apenas pressionar um botão para verificar se nada quebrou, a refatoração se tornará uma atividade muito segura; tão seguro, de fato, que faz parte do ciclo do TDD , que é a prática que permite criar esse conjunto de testes em primeiro lugar.

Mas, como as equipes do Scrum são auto-organizadas, no final, sua equipe deve decidir qual é a coisa certa a fazer. Espero ter apresentado alguns argumentos caso você precise convencer alguém. (Dê atenção especial aos links no primeiro parágrafo e a todos os outros artigos que eles apontam)

O Scrum realmente não diz nada sobre refatoração.

O que o Scrum diz é que, se você não tiver nenhuma tarefa no sprint para trabalhar, deve apoiar o resto da sua equipe para alcançar o objetivo do sprint. Mesmo que isso signifique buscar café para eles.
Se sua equipe concorda que a refatoração do código é a melhor maneira de apoiá-los (e isso inclui ter a infraestrutura instalada para garantir que a refatoração não introduza muitos bugs novos), faça o que for necessário.

Eu diria que não, não é. Isso independentemente do tipo de trabalho (refatoração, etc.).

No mínimo, as tarefas devem ser criadas e enviadas para o seu sprint atual. O objetivo do rastreamento de tempo é capturar sua velocidade para poder efetivamente planejar futuros sprints. Se você estiver trabalhando em coisas sem rastreá-las, você afetará a velocidade e ela não melhorará com o tempo, como é planejado com o rastreamento adequado (você provavelmente não terá trabalho suficiente regularmente porque sua velocidade projetada é menor que a velocidade real) )

Quanto ao trabalho de refatoração em si, posso falar sobre isso, mas não vou, pois não acho que seja a pergunta principal que você está tentando responder.

Eu vou dizer não também. A re-fatoração geralmente leva a erros não intencionais, se não for gerenciado da maneira correta.

Como GM, periodicamente eu colocava todo mundo em outro projeto e passava uma semana revisando / re-fatorando / renomeando e aplicando convenções em um projeto. Esses sprints de re-fatoração quase sempre seriam de natureza cosmética. Qualquer re-fatoração funcional seria planejada com antecedência e envolveria o desenvolvedor original.

A re-fatoração funcional deve sempre ser planejada e coordenada como parte do processo de scrum, para que o tempo possa ser rastreado e todos os membros da equipe necessários estejam disponíveis para validar o processo. Um desenvolvedor não deve mudar o código escrito por outro fora da pista, porque provavelmente irá atrapalhar o sprint atual para todos. Especialmente quando se trata de tempo de mesclagem de código.

Se você é o único mantenedor e é o seu próprio tempo livre, pode ser diferente, desde que você tome medidas para garantir que você não cause atrasos desnecessários no seu sprint atual.

Em caso de dúvida, pergunte ao seu gerente.

Edição: Eu também quero mencionar que um determinado pedaço de código que você não gosta pode ter um determinado objetivo de desempenho associado a ele. Você pode não gostar, mas pode ser mais rápido do que qualquer coisa que você possa criar que se adapte à maneira como você deseja usá-lo. Apenas outra razão pela qual a recoforação funcional sempre deve ser um processo gerenciado.

Scrum não diz nada sobre refatoração (veja uma palestra de Robert C. Martin, "A terra que scrum esqueceu").

No Scrum, as tarefas têm como alvo os recursos do seu software especificados pelo cliente, e não as dívidas técnicas a serem pagas pela refatoração. Estes são níveis de abstração totalmente diferentes. O cliente principalmente não é capaz de avaliar a necessidade.

Scrum é gerenciamento estatístico de projetos. Para obter medidas significativas de "quanto tempo leva", você precisa conhecer o desempenho (produção por sprint). Você compara a estimativa e a duração real de um recurso por pelo menos mais de 1 sprint para entrar na estatística. Eu recomendo 5 sprints. Mas isso depende da sua equipe.

O principal é manter as medidas significativas e comparáveis ​​para possibilitar qualquer previsão. Não será esse o caso se o desempenho estiver diminuindo devido a dívidas técnicas.

Se você ainda pensa em refatorar tarefas, tem dois problemas: 1. Um cliente que não entende, por que ele precisa aceitar uma tarefa que não produzirá um novo recurso 2. Você distorce totalmente suas estatísticas e, portanto, sua capacidade de prever de repente, você altera uma variável diferente que não foi considerada nos sprints anteriores

Nos dois casos, você compromete a ideia de scrum ao conversar sobre recursos com o cliente E faz previsões confiáveis ​​para "Quanto tempo leva?" de forma estatística. Para estar seguro, você deve manter sua base de código em uma qualidade constante (talvez alta).

A refatoração é na maioria das vezes uma tarefa subterrânea. Refatorações "grandes" significam que refatorações "pequenas" não foram processadas no passado.

Uma última observação: se você fizer refatorações, verifique se o componente está sendo testado, se está refatorando. Ohh, você não tem testes? Faça uma tarefa para escrever testes. Seu cliente ficará feliz em saber que o software que ele está usando no momento não possui cobertura de teste suficiente ...

Mantenha o material técnico longe do cliente e faça seu trabalho como desenvolvedor profissional.

Aqui está uma abordagem: faça as duas coisas!

A refatoração geralmente é propensa a erros ou consome mais tempo do que o estimado originalmente como @misterbiscuit.

Portanto, considere uma tentativa de fazer um rascunho ou um pico. Você não precisa buscar aprovação ou anunciar se estiver nesse estágio.

Em seguida, inclua-o em um dos dois canais:

• um tíquete existente que toque o mesmo código / funcionalidade em que você pode aceitá-lo. Razoavelmente, conforme combinado com os colegas da equipe.
• um ingresso completo para revisão na preparação do próximo ingresso (ou reunião semanal, etc., se houver cascata) Nesse momento, você pode defender isso.

Depois de obter o buy-in real, você pode aplicar ou refazer seu aumento e fazer com que o código seja mesclado na linha principal (mestre, etc.).

Isso terá várias vantagens:

• Todos os seus códigos de código através do mesmo processo, são testados, controle de qualidade, no pipeline de lançamento, etc.
• Você recebe a adesão formal, inclusive do gerente de produto, que a refatoração faz parte do ofício e não algo que precisa ser 'escondido' em um feriado. Pergunte a si mesmo por que você não está 'escondendo' um recurso real pode ajudar na perspectiva.
• Você pode solicitar emparelhamento, revisão de código, qa, devops e todo o outro suporte necessário para a alteração do código de fatoração. Tudo será oficial, de acordo com a Política e Procedimentos e acima da diretoria.
• Se você é uma empresa de capital aberto com conformidade com SOX, provavelmente deseja / precisa executar esse tipo de processo formal (ou seja, documentá-lo e segui-lo).
• Você obtém uma reputação melhor tanto com o gerente de produto (a mudança foi feita rapidamente) quanto com a equipe de desenvolvimento (a base de código foi aprimorada).
• A organização está procurando se preocupar com a qualidade do código, o que é bom para produtividade, moral, retenção de funcionários e muitos outros motivos.
• O efeito na velocidade do projeto pode ser mais facilmente rastreado quando todo o trabalho é incluído. Pode ser bom não nomear nenhum ponto, pois a própria presença pode ser usada para afetar a velocidade.
• É provável que os desenvolvedores vejam ferramentas que incentivam revisões de código mais fáceis, como Fisheye, Github etc.
• É mais provável que os desenvolvedores vejam alguns padrões básicos (às vezes documentados, às vezes não) que facilitam o compartilhamento de código e, portanto, a refatoração. Às vezes, grande parte da refatoração é escolher um estilo e aplicá-lo amplamente (substituindo uma mistura de abordagens por uma).

Um comentário final: evite que o gerente de produto ouça a palavra 'aleatório'. Eles podem responder mais favoravelmente com a atualização de código 'direcionada, estratégica, para melhorar o desempenho'. Ou service pack de aplicativos. Ou qualquer idioma que lhe dê cobertura.

Refatoração aleatória não faz sentido. O que faz sentido é a refatoração de um código que apresentará a maioria dos benefícios. Que significa :

• corrigindo um problema de design ou arquitetura
• melhorando a implementação

Tudo bem no Scrum se eu começar a refatorar aleatoriamente o código que eu tenho e não o escrevi, que sempre me incomoda, mas não tem tempo outros dias para corrigi-lo devido às atribuições de outros dias?

A partir desta resposta :

Manter o código de manutenção precisa ser um item da sua lista de opções (se você usar um Scrum). É tão importante quanto um novo desenvolvimento. Embora possa não parecer algo "visível ao usuário", ignorá-lo aumenta sua dívida técnica. No futuro, quando a dívida técnica se acumular o suficiente para que a falta de manutenção do seu código diminua o desenvolvimento, os atrasos no desenvolvimento de novos recursos serão visíveis para os clientes.

No meu trabalho anterior, tivemos algum tipo de scrum, com sprints maiores (2-3 meses). Como tivemos alguns atrasos entre os sprints (1 mês), usamos esse tempo para analisar o software e refatorar o código.