Se você puder se dar ao luxo de adiar a refatoração, sugiro que concentre as próximas iterações na adição de testes unitários e testes de integração automatizados ao ponto de refazer a base de código confortavelmente e refatorar em um único sprint.
Eu trabalho com uma base de código com mais de 500 mil linhas de código. Está em grande necessidade de refatoração. Houve esforços de refatoração identificados que levarão mais tempo do que o sprint normal de duas semanas. Estes não podem ser divididos em tarefas menores, como tenho visto sugerido em outras respostas neste site. O produto precisa funcionar no final da iteração e a refatoração parcial deixará o sistema em um estado inutilizável, pois a dependência entre os itens é horrível. Então, qual seria a melhor maneira de abordar esse obstáculo? Novamente eu mencionei, dividi-lo em pedaços menores não é uma opção, isso já foi feito.
Atualização: As pessoas parecem precisar de uma explicação de por que isso não pode caber em um sprint de duas semanas. Há mais envolvidos em um sprint do que apenas escrever código. Nós temos uma política de não usar código sem testes. Essa política nem sempre existia e uma grande parte da base de código não as possui. Além disso, alguns dos nossos testes de integração ainda são testes manuais. A questão não é que a refatoração em si é tão grande. É com o fato de que pequenas mudanças afetam muitas partes do sistema, e precisamos garantir que essas partes ainda funcionem corretamente.
Não podemos adiar ou ampliar um sprint porque temos os hotfixes mensais. Portanto, essa alteração que se estende além de um sprint não pode impedir que o outro trabalho seja adicionado ao hotfix.
Refatoração versus novo design: Só porque nosso processo de desenvolvimento não é eficiente o suficiente para lidar com essa refatoração em um ciclo de duas semanas, não é necessário renomeá-lo para um novo design. Eu gostaria de acreditar que, no futuro, poderíamos realizar exatamente a mesma tarefa dentro de um ciclo de duas semanas, à medida que nosso processo melhorasse. O código em questão aqui não teve que mudar em muito tempo, e é bastante estável. Agora, como a direção da empresa está se tornando mais adaptável à mudança, queremos que essa parte da base de código seja tão adaptável quanto o restante. Que requer refatoração. Com base nas respostas aqui, está se tornando aparente que faltam os scaffolding necessários para fazer com que esse trabalho de refatoração ocorra no período de sprints normais.
Resposta:
Vou fazer a abordagem de ramificação e mesclagem que Corbin March sugeriu na primeira vez, para que possamos aprender mais sobre essas áreas problemáticas e como identificar os testes ausentes. Acho que seguindo em frente, devemos adotar a abordagem que Buhb sugeriu de identificar as áreas que estão faltando testes e implementá-las primeiro, depois fazer a refatoração. Isso nos permitirá manter nosso ciclo normal de duas semanas, assim como muitos vêm dizendo que deve ser sempre o caso da refatoração.
Se você puder se dar ao luxo de adiar a refatoração, sugiro que concentre as próximas iterações na adição de testes unitários e testes de integração automatizados ao ponto de refazer a base de código confortavelmente e refatorar em um único sprint.
Minha sugestão:
Não há como fugir do fato de que provavelmente ficará feio. Eu não te invejo. Na minha experiência, quando você muda drasticamente um projeto, é mais fácil mesclar o desenvolvimento contínuo com o novo paradigma do que com a fusão do novo paradigma em um tronco que agora mudou, depois que tudo estiver terminado. Ainda assim, vai doer.
Nem todas as tarefas podem ser feitas em um sprint (artificial) de 2 semanas, portanto é recomendável o bom senso. Se não puder mais ser quebrado, e isso deve ser feito, apenas siga em frente e faça. O processo não é mais importante do que o resultado final e deve ser visto como uma diretriz, e não como uma lei que nunca será violada.
Basta fazer um sprint de 3, 4 ou 5 semanas. Quem se importa? Você está obviamente convencido de que nada pode ser feito em menos tempo, então pare de lutar contra isso.
Apenas não conte aos seus companheiros na Royal Society of Blind Agile Adherance.
Recomendo começar com o livro Trabalhando efetivamente com o código herdado , de Michael Feathers. Ele cobre uma variedade de técnicas para reduzir o escopo das mudanças no estilo de refatoração.
Em nossa loja, quando temos grandes tarefas de refatoração ou reescrita que não podem ser concluídas em uma janela de lançamento, deixamos a funcionalidade como está no sistema. Mas começamos com as novas funções lego-block refatoradas, conforme o tempo permitir. Eventualmente, chegamos a um estado em que temos lego-blocks suficientes, que um sprint fornece tempo suficiente para conectar os blocos lego ao aplicativo e ativá-lo para os usuários.
Mais concisamente, dividimos ou refazemos grandes funções usando novos nomes. Então, no final, usamos nosso trabalho refatorado e renomeado, em vez do código antigo desagradável.
Dedique um sprint para descobrir como manter o código funcionando corretamente no mid-refactor. Isso pode assumir a forma de métodos e classes obsoletos, wrappers, adaptadores e semelhantes. Sua refatoração pode tornar o código mais sujo por um curto período de tempo, a fim de ser mais limpo a longo prazo; isso está ok. Agora você está dizendo que não pode ser feito. Eu não acho isso certo - pense em como seria o seu processo, se pudesse ser feito, pense nos passos que você pode dar para que isso aconteça. Então mergulhe.
+1 na resposta de Corbin March, isso é exatamente o que eu estava pensando.
Parece que o seu código-base é um pouco feio e vai demorar mais do que um único ciclo de sprint para limpá-lo.
Então, assim como Corbin disse,
Tenho certeza de que você não teria nenhum problema em vender isso para seu gerente de desenvolvimento, se seus gerentes de ponto estiverem tendo dificuldades para ver isso, então explique a eles que Roma não foi construída em um dia e limpando todo o lixo jogado nas ruas de Roma não vai ser feito em um dia também. A refatoração demorará um pouco, mas valerá a pena no final em termos de manutenção mais fácil, lançamentos de aprimoramento mais rápidos, menos tickets de produção e um SLA mais completo.
Embora o novo design que você realmente quer fazer seja uma grande tarefa, seria possível refatorar peças menores para dividir / desvincular dependências individuais? Você sabe - quando em dúvida, adicione indireção. Cada um desses desacoplamentos deve ser uma tarefa menor que a do mamute que você não pode completar.
Depois que as dependências forem removidas, você poderá separar as tarefas de refatoração remanescentes a serem obtidas em sprints.
No projeto em que estou trabalhando no momento, estamos usando sprints de 4 semanas. E às vezes não podemos concluir uma história de usuário e apenas a reiniciamos durante o sprint a seguir.
No entanto, IMHO, deve ser possível dividir uma refatoração em histórias menores que se encaixam em um sprint de 4 semanas. Se você não puder colocar o código em um estado consistente dentro de 4 semanas, tenho a sensação de que você está reescrevendo seu aplicativo em vez de refatorá-lo.
Recomendo que, quando determinadas tarefas demorem mais que o ciclo de sprint de duas semanas, a tarefa seja programada para outra ocasião. Sua equipe identificou a necessidade de refatoração e isso é importante. Às vezes, não há outra opção ... e, sim, isso é uma droga.
Quando chegar a hora de começar a refatoração, você simplesmente suspenderá os sprints normais. Você não tem escolha. Use o controle de versão inteligente - ramificar, refatorar, testar e mesclar. Há sempre um momento em que a refatoração de alguns projetos grandes tem prioridade sobre os recursos. Se possível, eu também tentaria separar as preocupações de uma melhor flexibilidade.
Tendo passado recentemente pelo mesmo problema com uma parte da nossa base de código (que também é um pouco maior), espero poder compartilhar algumas ideias com você. Na minha situação, o codebase foi desenvolvido por outra equipe, então ninguém dos desenvolvedores originais estava envolvido nessa refatoração. Minha experiência com a base de código foi de cerca de 1 ano e outro desenvolvedor precisou de 2 anos.
Permitam-me duas notas pequenas sobre as outras respostas aqui:
Ir aparentemente "fora de reserva" por duas semanas ou mais não passará despercebido. Você precisa garantir que você tenha o apoio do gerenciamento de projetos e, ainda mais importante, da equipe. Se a equipe não estiver comprometida com essa refatoração (e isso significa, faça isso agora, não no futuro distante), você terá problemas.
Não faça isso sozinho, use programação em pares. Isso não significa estritamente que você precisa se sentar em frente ao mesmo teclado o tempo todo, mas pode lidar com tarefas pequenas e estreitas (por exemplo, testes de gravação que capturam o comportamento dessa classe) individualmente.
Faça uma refatoração de riscos e trate-a como tal. (Uma espécie de refatoração de protótipos "fora de casa", o bit "descartável" é importante!) Honestamente, é improvável que você saiba todas as implicações que sua refatoração terá. Uma nova refatoração ajudará você em certos aspectos:
Quando você tiver feito sua refatoração, espero que você descubra que não pode simplesmente mudar tudo. Você vai se sentir mal, é apenas uma grande bagunça e você não pode simplesmente apertar um botão e fazer funcionar. Isso é o que aconteceu comigo, pode ser diferente na sua situação.
No entanto, meu parceiro e eu tivemos uma compreensão muito melhor do nosso sistema. Agora fomos capazes de identificar refatorações / redesenhos individuais, menores (embora ainda grandes). Capturamos nossa visão do sistema em um diagrama e o compartilhamos com a equipe, juntamente com os itens do backlog que criamos para implementar essa visão. Fortalecidos pelo consenso comum, decidimos quais itens implementaríamos ao longo da próxima iteração.
Uma última coisa que nos ajudou foi usar um grande quadro branco. Há muitas coisas para manter em sua cabeça. É extremamente importante que você mantenha anotações. Escreva uma nota informativa no final do dia, capturando o que você fez hoje e quer fazer amanhã. Isso ajuda a relaxar grandes momentos, e você precisa de um tempo descontraído se quiser acompanhar a tarefa. Boa sorte!
Inicie uma janela de manutenção durante a qual nenhum desenvolvimento adicional é realizado. Realize o novo design e, em seguida, retome os sprints de desenvolvimento.
Temos dois tipos de trabalhos à nossa disposição:
A refatoração geralmente consiste no primeiro tipo de trabalho, já que muitos métodos já são conhecidos de desenvolvedores como DRY , SRP , OCP , DI , etc. Assim, quando um projeto leva dois meses para ser refatorado, ele simplesmente leva dois meses , não há maneira de contornar isso. Assim, minha sugestão seria não refatorar o projeto original e deixá-lo trabalhar em sua situação atual. Pare de receber novas solicitações e requisitos das partes interessadas e do proprietário do produto . Em seguida, deixe a equipe trabalhar no projeto até que ela seja refatorada e pronta para ser usada.
Uma sugestão que pode ajudar: Se você tiver código não testado de tal forma que você não tenha tempo suficiente para refatorar e testar novamente dentro do sprint de duas semanas, considere primeiro fazer outra pequena alteração não relacionada ( s) ao código para que você possa se concentrar em escrever testes para o primeiro sprint ou dois. Talvez você possa identificar vários clientes não testados do código que deseja refatorar; escolha um cliente e faça algumas outras alterações de algum uso para o negócio que forçará você a escrever testes para esse cliente. Uma vez que você esteja mais familiarizado com o código, trabalhe com ele e tenha mais testes, e possivelmente tenha conseguido algumas refatorações menores, você estará em uma posição muito melhor para realizar a refatoração e a (agora mais fácil ) testando ambos em uma iteração.
Outra abordagem é fazer uma cópia do código incorreto, refatorá-lo e, em seguida, mover os clientes, um de cada vez, para o novo código. Este trabalho pode ser dividido entre iterações.
E não desista: não aceite apenas que uma grande refatoração não pode ser dividida em etapas menores. A abordagem mais fácil / rápida / melhor pode demorar mais do que uma iteração. Mas isso não significa que não há como fazer trechos do tamanho de uma iteração.
Tags refactoring sprint