Assim como uma refatoração grande, reescrever um software não é algo simples. Após vários anos, adquirimos experiência suficiente para indicar o que você deve considerar ao planejar e executar um processo para reescrever software.

1. As duas plataformas existirão juntas por um determinado período ou não?

Você planeja manter a versão de legado e a nova versão em produção? Caso positivo, por quanto tempo? Você deve evitar manter duas versões em produção por muito tempo devido aos custos operacionais e de oportunidade.

2. Quem trabalhará na reescrita do código e quem trabalhará na versão do legado?

Geralmente, os desenvolvedores preferem trabalhar em projetos greenfield. Você deve considerar isto ao planejar quem trabalhará na versão do legado e quem trabalhará na nova.

3. É inviável reescrever todas as funcionalidades ao mesmo tempo

Mapear cada funcionalidade entre a versão do legado e a nova é inviável. Dito isto, que funcionalidades devem ser as primeiras a serem reescritas?

Leve em consideração como os clientes atuais serão afetados por um produto com menos funcionalidades.

4. Reescrever o software diminuirá ou interromperá o lançamento de novas funcionalidades na versão do legado

É provável que você não lance novos recursos na versão legada durante o processo de reescrita do código. Assim como os usuários finais, os clientes internos (comercial, produtos, financeiro) não terão novas funcionalidades. Seus clientes internos e outras partes interessadas vão pressioná-lo para entregar novas funcionalidades.

Certifique-se que a comunicação antes e durante o processo de reescrita do software seja clara e que cada stakeholder esteja alinhado com as metas.

5. O processo deve ser secreto ou público?

Imagine que você é um cliente potencial de um produto de software. Você planeja comprá-lo, mas descobriu que uma versão completamente nova será lançada em três meses. Você compraria a versão do legado ou esperaria por três meses? Multiplique isso por dezenas ou centenas de potenciais compradores. O fornecedor pode perder muito dinheiro.

Por isso, se você é o fornecedor, deve pensar cuidadosamente sobre como e quando divulgar o lançamento da nova versão.

6. Migração de dados

O processo de reescrever um software não envolve apenas o desenvolvimento de funcionalidades. Você também precisa planejar a migração de dados. As pessoas costumam subestimar a complexidade e o esforço necessários para migrar dados da versão do legado para a nova versão. Essa atividade não deve ser apenas mais uma tarefa em seu quadro, chamado “migração de dados”. É muito maior que isso.

Por exemplo, imagine que você precisa migrar as contas de seus usuários. Se a sua versão de legado é gerenciada por um terceiro, é provável que você não tenha acesso às senhas criptografadas dos usuários, portanto, não será possível migrá-las. Você terá de solicitar a cada usuário para redefinir a senha na nova versão. Isso também faz parte do processo de migração de dados.

7. Prepare-se para uma possível redução nas taxas de conversão

Você lançará uma nova versão com menos recursos. Quem garante que as taxas de conversão permanecerão as mesmas? As taxas de conversão são essenciais em algumas indústrias, como no e-commerce.

Preferencialmente, você deve manter o suporte à versão legada e à nova por um tempo para que, no caso de redução drástica nas taxas de conversão, você tenha um plano de backup.

8. Planeje treinamento para os usuários internos

Este é outro ponto negligenciado. O plano de reescrever o software precisa ter uma fase de treinamento de usuários internos antes de disponibilizar seu novo produto em produção. Não subestime a importância deste item. Pode demorar algum tempo, pois seus usuários internos darão feedback sobre pontos que talvez precisem ser alterados.

Usuários internos podem ser encontrados em várias áreas, como help desk e vendas.

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software
3. 8 pontos-chaves para reescrever um software você está lendo

The post 8 pontos-chave para reescrever um software first appeared on Plataformatec Blog.

Realizar uma refatoração grande¹ de software não é algo simples. Há muitos pontos que você deve considerar, desde o planejamento e priorização até a motivação e execução da equipe. Entender esses pontos de forma estruturada e clara faz parte do processo. A boa notícia é que já passamos por essa situação antes e aprendemos quais os pontos principais com os quais você deve se preocupar.

Aqui estão os pontos principais que você deve considerar ao planejar e executar uma refatoração grande do seu sistema.

1. Defina metas de negócios

Uma refatoração grande de software não deve ser iniciada sem metas de negócios claras, caso contrário, você pode sofrer com a falta de comprometimento das partes interessadas. Aqui estão alguns exemplos de metas:

• O objetivo da refatoração é possibilitar a conexão de vários gateways de pagamento.
• O objetivo da refatoração é melhorar a velocidade de entrega.
• O objetivo da refatoração é viabilizar uma arquitetura multi-tenant para simplificar operações de infraestrutura.

2. Faça a medição do progresso

Em sua essência, o processo de refatoração de software é um esforço técnico, razão pela qual é comum não medir o progresso de forma estruturada, como é medido o progresso do desenvolvimento de novas features. Não caia nessa armadilha.

Assim como cada tarefa em um projeto, uma refatoração deve sempre ser planejada e medida.

3. Preste atenção à motivação da sua equipe

Trabalhar em base de código legado pode desmotivar os desenvolvedores, especialmente se não conseguem visualizar o progresso de suas atividades, ou se não sabem quando vão acabar. Ao passar por um processo de refatoração, você deve ter isso em mente.

Mostre à sua equipe que estão avançando. Planeje pequenas entregas, para viabilizar liberações contínuas e celebrar o bom trabalho feito. Além disso, pense em rotacionar os desenvolvedores para essa tarefa de refatoração, pois pode ajudar a manter a motivação.

4. Defina sua abordagem: puxada ou empurrada?

Você vai melhorar a base de código apenas quando encontrar um problema, ou escolherá de forma proativa as partes a melhorar?

Clique aqui para assistir o webinar Migração de Plataforma Tecnológica. É grátis!

5. Priorização

Se você tem uma meta de negócios clara, é mais fácil escolher proativamente as partes que precisam ser melhoradas para alcançar a meta. Com as partes listadas, você pode priorizar, como de costume.

Por outro lado, se você imagina que a base de código inteira deve ser refatorada, priorizar torna-se complicado, porque não há uma ou duas partes principais que precisam de melhorias, há muitas. É difícil saber por onde começar.

Uma solução é pedir ao time para avaliar a complexidade e churn do código para apontar as partes a refatorar. Para chegar numa conclusão se o código deve ou não ser refatorado, eles tem de se perguntar:

• A complexidade dessa classe é muito alta comparada às outras?
• Precisamos fazer mudanças constantes nesse arquivo?

Se ambas as respostas forem sim, essa parte do código parece um bom candidato para refatoração. Trace um gráfico de “complexidade de classe X churn”, priorize as partes que são mais complexas e que passam por alterações com frequência.

As partes do código que tem complexidade alta e que sofrem poucas modificações não são boas candidatas para serem refatoradas. Isso porque apesar de feias, funcionam. E também tem pouco impacto no desenvolvimento, já que a os desenvolvedores precisam modificá-las pouco no seu dia a dia.

6. Defina o “pronto”

O processo de refatoração de software pode se transformar em esforço infinito se você não planejar, priorizar e medir o progresso. Você deve tratá-lo como um projeto. Deve ter começo, meio e fim.

7. Cobertura da suíte de testes

A refatoração deve melhorar o que já está funcionando, sem quebrar nada. Certifique-se que a cobertura de testes está adequada, caso contrário, o processo pode gerar mais bugs do que melhorias de qualidade.

8. Desempenho da suíte de testes

Se a suíte de testes é lenta, refatorar também se tornará um processo lento, visto que a refatoração de software é fortemente baseada na execução contínua dos testes. Assegure que o desempenho da suíte de testes não seja um gargalo.

9. Compromisso dos patrocinadores

O processo de refatoração pode levar muito tempo: semanas, meses. Durante esse período, a velocidade das entregas de novas features será comprometida.

Certifique-se que stakeholders das áreas de negócio entendam os objetivos e a natureza desse tipo de trabalho para evitar que eles desistam no meio do caminho.

E você tem alguma dica além dessas para grande refatoração de software? Compartilhe conosco!

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software você está lendo
3. 8 pontos-chaves para reescrever um software

The post 9 Pontos-chaves ao se fazer uma refatoração grande de software first appeared on Plataformatec Blog.

Um dos desafios mais comuns que você vai encarar na sua carreira, ou até mesmo em sua vida, é escolher entre uma coisa e outra. Pode ser a decisão entre ir ao restaurante japonês ou pizzaria, um projeto de 2 meses que custe $1M ou um projeto de 10 dias que custe $10k. O fato é: nós gastamos muito tempo decidindo o melhor caminho a ser seguido.

source: [xkcd](http://xkcd.com/1445/)

O que é Custo de Atraso

Custo de Atraso (Cost of Delay ou CoD em inglês) é o impacto econômico do atraso de um projeto. Em outras palavras, é quanto você deixa de ganhar se o produto, ou feature, não estiver pronto em uma certa data. O benefício do cálculo é proporcionar mais informações para tomada de decisão, do ponto de vista econômico-financeiro.

Como calcular CoD?

Para calcular o CoD você pode simplesmente estimar quanto de lucro seria esperado do projeto depois de um certo período de tempo.

Digamos que você espera que o projeto que está desenvolvendo, quando terminado, dê de retorno à empresa algo em torno de $10.000 por semana. Nesse contexto, o CoD é $10.000 / semana. Isto é, cada semana que o projeto atrasa a empresa “perde” $10.000. Não parece bom, né?

Outra métrica relacionada ao CoD é o CD3 (Custo de Atraso dividido pela duração, do inglês Cost of Delay Divided by Duration). A diferença entre ambos é que o CD3 é o CoD dividido pela duração do projeto. Essa é uma boa métrica para priorização. Você pode calculá-la da seguinte maneira:

• Calcule o lucro semanal (ou mensal) esperado do projeto (CoD);
• Calcule, aproximadamente, quanto tempo demorará para implementá-lo;
• Divida o lucro pelo tempo estimado de duração do projeto.

Quanto maior o CD3, mais importante o projeto é, já que o retorno sobre o investimento seria mais rápido.

Planilha para calcular probabilidade de data de término de projetos
BAIXAR PLANILHA GRÁTIS

Tipos de CoD

Curva Padrão

Em curvas padrões, o CoD do projeto aumenta quase linearmente com o tempo. Este é o jeito mais simples de calcular o CoD, já que não muda com o tempo.

Curva Urgente

Em curvas urgentes, o projeto precisa ser entregue rápido para gerar valor para empresa, caso contrário perde-se muito. Isso acontece, por exemplo, quando um competidor lança um produto similar e não há tempo suficiente para reagir e competir no mercado. Provavelmente, o CoD será muito alto, começando na semana da entrega do projeto, aumentando pouco com o tempo.

Curva de Data Fixa

Curvas de data fixa são o clássico exemplo de projetos com deadlines imutáveis. Nesses casos, o CoD está altamente ligado à uma data específica. O exemplo mencionado na curva urgente também é válido aqui. Outro exemplo seria um comercial de TV marcado para uma certa data, ou uma nova lei que afetará o projeto. O CoD será um pouco mais complexo. Nas primeiras semanas o CoD cresceria em ritmo moderado. Após certa semana, o custo receberia um grande impulso, depois retornaria ao crescimento moderado.

Curva Intangível

A curva intangível cobre os projetos que têm baixo CoD. Geralmente, os projetos têm baixa prioridade dentro da empresa, pois causam pouco ou nenhum impacto nos resultados. O CoD é quase estático, já que não existe muito risco em atrasar o projeto.

Como usar?

Além do conhecimento de quanto a empresa perde semanalmente caso o projeto seja atrasado, é possível utilizar o CoD como ferramenta de tomada de decisão ao priorizar projetos.

Exemplo

Digamos que você tenha dois projetos: A e B. Ambos com CoD de curvas padrão.

Baseado nos detalhes do projeto, alguém poderia pensar que o projeto A é mais importante que o projeto B. No entanto, se você calcular o CD3, você verá que CD3_A = 138.8; enquanto o CD3_B = 200.

Mas o que isso significa? Significa que caso você trabalhe no projeto B primeiro, você vai antecipar a geração de renda quando comparado com começar o projeto A. Ainda não acredita? Aqui está uma simulação de 75 semanas:

Ponto de atenção

É importante notar que a curva de CoD de um projeto pode mudar com o tempo. Para ilustrar, digamos que um produto nunca antes visto no mercado está sendo desenvolvido. Como não há competidores, ele segue a curva padrão. Depois de um ano de desenvolvimento, chegam notícias de que um competidor está desenvolvendo algo similar, e vão lançar o produto no dia X. A curva do projeto provavelmente seguirá a curva de data fixa, com a reta íngreme começando no dia X.

Conclusão

Você pode, e deveria, calcular o CoD toda vez que houver dúvida de qual projeto priorizar. É uma método fácil de ser calculado e, pensar em todos esses detalhes, pode proporcionar intuições sobre os projetos.

E você? O que acha de usar Custo de Atraso na priorização de projetos? Deixe seus comentários abaixo!

The post Quanto a empresa perde financeiramente quando o projeto atrasa? first appeared on Plataformatec Blog.

Não só bens físicos se deterioram, isso também ocorre com software.

Todos sabem que bens físicos se deterioram. As pessoas aceitam este fato e sempre lidaram com isso. O que as pessoas não aceitam tão facilmente é que software “se deteriora” também. Ao contrário dos bens físicos, isso não acontece devido a algum fenômeno físico ou químico. Essa deterioração ocorre geralmente devido a mudanças de negócios ou de profissionais. Vou dar um exemplo.

Imagine que você é o líder de uma equipe de produto ou tecnologia em uma startup; você é o CTO. Você já lançou a primeira versão do seu produto e foi um sucesso. Seu modelo de negócio foi validado e agora você está em fase de crescimento. Isso é fantástico! Mas tem seus custos, além de novos desafios.

A primeira versão do seu produto está funcionando, mas a base de código não está como você precisa a partir de agora. Talvez sua equipe não seja tão veloz quanto antes. Sua equipe reclama continuamente da qualidade do código. O CEO e o diretor de produto querem novas features e suas estimativas atuais não atenderão às necessidades do negócio.

Não raro, baixa qualidade da base de código está entre as principais origens de todos problemas. Talvez você precise refatorar (refactor) ou reescrever (rewrite) o software.

Quando a base de código não está em boas condições, todos podem ficar frustrados.

Sua equipe inteira, incluindo os desenvolvedores, se sentirão frustrados porque gostariam de liberar features com maior velocidade, porém a qualidade do código e a arquitetura atual não ajudam.

Os departamentos de TI, produto e software sofrem por não atenderem às expectativas das outras áreas.

O cliente também sofre devido aos bugs frequentes, o tempo gasto para que sejam corrigidos, além da demora para lançar novas features.

Você conseguiu entender.

Identifique os sintomas

É papel do líder (por exemplo, o CTO) identificar quando é necessário refatorar ou reescrever o software. Para isso, ele(a) pode fazer uma análise em busca de alguns sintomas, como os listados abaixo:

• Tudo é difícil: Quase todas features novas ou correções de bugs que sua equipe precisa fazer são difíceis. Nem sempre foi assim. Você se lembra dos bons tempos em que sua equipe era rápida e a execução era perfeita.
• Velocidade lenta: a velocidade de sua equipe diminuiu ou está diminuindo. Quando vocês desenvolveram a primeira versão do produto, era rápido desenvolver uma nova feature. Sua equipe conseguia desenvolver um monte delas a cada iteração. Agora é diferente.
• Suíte de testes lenta: Sua suíte de testes apresenta tempo de execução 10x, 20x, 30x maior que antes.
• Bugs que não desaparecem: Sua equipe corrige um bug e em algumas semanas ele reaparece. É comum sua equipe corrigir bugs em testes de regressão.
• Sua equipe está desmotivada: Sua equipe reclama continuamente que trabalhar no projeto já não é tão produtivo como era no antes. Uma pessoa não consegue construir uma feature sozinha; há muitas partes em movimento.
• Conhecimento isolado: Existem algumas partes do software que apenas um desenvolvedor conhece bem o suficiente para mantê-las. O resto da equipe tem dificuldades em trabalhar com esse código específico.
• O período de adaptação de um novo desenvolvedor é muito longo: Quando novos desenvolvedores se juntam à equipe, demora demais para que eles se tornem totalmente produtivos.

A razão pela qual você está em uma dessas situações provavelmente não é técnica. Talvez você precisasse entregar muitas features muito rápido, enquanto ainda estava desenvolvendo a primeira versão de seu produto. Talvez sua equipe não tinha maturidade e experiência que possuem agora. Analisar a causa raiz também é importante, mas você precisa fazer mais. Você precisa resolver o seu problema.

Se você está enfrentando os sintomas acima, provavelmente você tem problema de baixa qualidade interna de software. Reconhecer os sintomas já é um grande passo. O próximo passo é pensar em soluções. Algumas soluções que você pode considerar incluem o processo de refatorar ou reescrever o software.

Refatorar ou reescrever?

Não existe um guia definitivo que aponte quando você deve refatorar ou reescrever o software, pois depende muito do seu contexto. Dito isto, existem algumas regras básicas que você deve considerar ao avaliar qual a melhor solução para sua situação:

Quando reescrever

• Se a tecnologia que você usa está desatualizada e não possui mais manutenção;
• Se seu software é muito lento e mudar a arquitetura não é suficiente ou viável;
• Se a disponibilidade de desenvolvedores de software que conhecem a tecnologia que você usa é baixa e está diminuindo;
• Se existem novas tecnologias que oferecem vantagem significativa em relação a que você utiliza.

Quando refatorar

• Se a tecnologia que você usa ainda possui manutenção e é relevante;
• Se é viável melhorar seu aplicativo gradualmente;
• Se o problema que você está resolvendo é apenas técnico, e não de negócio.

Não é fácil decidir qual opção escolher. Ao optar por uma delas, você enfrentará um monte de novas preocupações. Fique atento, em nossos próximos posts vamos discutir o que levar em consideração antes de optar por refatoração ou reescrita do software.

Agora eu gostaria de saber sobre suas experiências. Você já esteve nessa situação? Como você identificou que o problema era baixa qualidade interna de software? Compartilhe sua história conosco!

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software você está lendo
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software
3. 8 pontos-chaves para reescrever um software

The post Sintomas da Baixa Qualidade Interna de Software first appeared on Plataformatec Blog.