Refatoração é a melhor amiga do programador para que seu projeto não acumule débitos técnicos com o passar do tempo e chegue um momento em que a cada novo pedido do cliente sejam perdidas várias horas de sono preocupado com a grande dificuldade para alterar o software e os prováveis bugs que surgirão.

O propósito da refatoração é exatamente melhorar a legibilidade do código e aumentar a facilidade de modificá-lo, para que esse tipo de situação não venha a acontecer.

Muitos projetos acumulam tantos débitos técnicos que os patrocinadores acabam decidindo abandonar o código existente e desenvolver um novo sistema, na esperança de que esse novo código possibilite o dinamismo e tenha a confiabilidade que seu negócio exige. Então, para garantir que nossos projetos continuem atendendo as necessidades de nossos clientes no futuro, devemos nos preocupar hoje em desenvolver com qualidade e as refatorações são parte desse caminho.

Uma refatoração é uma alteração no código exclusivamente com o propósito de melhorá-lo, uma refatoração nunca deve alterar o comportamento esperado do software. Kent Beck usa a metáfora dos dois chapéus para ilustrar que o desenvolvedor deve vestir um chapéu e manter o foco naquela função. Quando veste o chapéu da refatoração, nunca devem ser introduzidas novas funcionalidades ao software. Já se estiver adicionando funcionalidades, o código existente nunca deve receber alterações que não estejam diretamente relacionadas à nova funcionalidade.

A maioria dos programadores acaba tendo a impressão de que já utiliza refatoração, apenas não tinha consciência disso, mas o diferencial que eles precisam atentar é a disciplina.

As refatorações quando utilizadas corretamente não geram grandes riscos ao projeto, pois são roteiros de execução bem definidos para cada tipo de alteração. Essas alterações normalmente são necessárias em contextos parecidos e sua necessidade pode ser identificada utilizando o que Kent Beck e Martin Fowler chamam de maus cheiros. Maus cheiros são “certas estruturas no código que sugiram a (às vezes elas gritam pela) possibilidade de refatoração”. Não vou me aprofundar explicando cada um deles, detalhes sobre os maus cheiros podem ser encontrados nos sites wiki.java.net, soberit.hut.fi e c2.com. Para exemplificar, cito alguns maus cheiros muito comuns em softwares:

• Código duplicado
• Métodos longos
• Classes grandes
• Quantidade exagerada de parâmetros
• Baixa coesão
• Alto acoplamento

Outro ponto importante para garantir a tranquilidade ao executar refatoração é a existência de testes unitários. O código deve estar funcionando corretamente antes da refatoração e deverá continuar assim após a mesma. A única coisa que pode lhe garantir que essas situações foram atendidas é um conjunto suficiente de testes unitários sendo executados com sucesso antes e após a refatoração.

Mas chega de papo furado e vamos a algumas refatorações. Cada refatoração tem um nome e descreve uma motivação e os passos a serem executados para chegar ao resultado esperado. Existem inúmeras refatorações além das que abordarei abaixo, um catálogo com muitas delas e explicações mais completas pode ser encontrado no livro “Refatoração – Aperfeiçoando o Projeto de Código Existente” de Martin Fowler e no site sourcemaking.com.

Uma das refatorações mais simples de serem feitas é a introdução de variável explicativa. Ela deve ser utilizada quando há uma expressão complexa no código que dificulta seu entendimento. O procedimento a ser feito é armazenar a expressão complexa ou parte dela em uma variável temporária com um nome que seja explicativo.

Outra refatoração, dessa vez entre as mais utilizadas, é a extração de método, utilizada quando há um método muito longo, necessidade de utilizar parte do código de outro método da mesma classe ou para melhorar a legibilidade de um trecho de código. Você deve criar um novo método com um nome explicativo sobre a utilidade do mesmo, mover o trecho de código para esse método e referenciar esse novo método em todos os lugares onde aquele trecho se repetia. O trabalho contrário também é uma refatoração, se chama internalizar método. Quando um método tem boa legibilidade e não é referenciado em mais de um ponto do código, podemos mover seu corpo para dentro do método que o referencia e apagá-lo.

Como último exemplo, cito a refatoração chamada subir método na hierarquia, utilizada quando há uma hierarquia de classes e duas (ou mais) classes irmãs implementam métodos com mesmo comportamento, nesse caso devemos eleger uma dessas implementações, movê-la para a classe pai e remover as demais.

Existem tantas refatorações que é impossível ter na cabeça detalhes de todas elas, mas entender a importância de utilizá-las e como utilizá-las já é suficiente para aumentar significativamente a qualidade do código produzido e possibilitar uma caminhada sem traumas aos projetos nos quais incentivam essas práticas.

The post Débitos técnicos e a Refatoração appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

ROI – Retorno Sobre Investimento – é normalmente definido como um percentual do valor investido e representa a taxa de lucro de um investimento. Essa definição leva em consideração apenas valores monetários devido à sua origem na área financeira.

De modo geral, essa característica dificulta a aplicabilidade da métrica a projetos com naturezas diversas, principalmente quando há dificuldade em converter os resultados esperados em valores financeiros, como a divulgação de uma marca ou a satisfação dos clientes. Sendo assim, antes de decidir por investir em um projeto devem ser definidos os critérios a serem considerados na avaliação de seu desempenho, pois cada projeto tem objetivos e resultados esperados distintos.

Independente dos critérios estabelecidos, um outro aspecto importante a ser observado é o prazo de retorno do investimento e nesse ponto os métodos ágeis são um diferencial.

Enquanto utilizando outras metodologias é necessário um longo prazo para que um projeto comece a dar retorno, com o desenvolvimento ágil os resultados podem ser antecipados liberando para utilização as principais funcionalidades de um software enquanto o restante dele é desenvolvido.

Além disso, há redução de riscos, já que a utilização antecipada do software funciona como uma validação para os impactos esperados no negócio, possibilitando adequações no projeto caso seja identificado um desempenho abaixo do esperado.

Por exemplo, vamos considerar uma empresa hipotética de tecnologia que esteja planejando lançar um serviço na internet e estima que para desenvolvê-lo precisará investir R$10.000,00 durante 24 meses.

Pelo caminho tradicional de desenvolvimento de software, no melhor caso após 2 anos ela terá um custo de 240 mil reais, seu sistema pronto, nenhum cliente e, por consequência, nenhum faturamento, sem contar o risco de má aceitação do serviço pelo mercado.

Caso ela opte por seguir o caminho do desenvolvimento ágil, após algum tempo, digamos 1 ano, ele terá um software em estágio suficiente de desenvolvimento para liberá-lo para uso e durante os próximos 12 meses já validar a aceitação do serviço, assim como acumular clientes e faturamento. Dessa forma, aliviando o fluxo de caixa, antecipando retornos e permitindo fazer adequações ao projeto ou até mesmo suspender o investimento sem tê-lo feito integralmente, caso os resultados sejam muito aquém do esperado.

Em publicações futuras entraremos nos detalhes de como maximizar o ROI utilizando metodologias ágeis para desenvolver seu produto.

The post ROI – Retorno sobre investimento appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Este é o texto do primeiro princípio do Manifesto Ágil e nele fica claro o foco na satisfação do cliente. Essa satisfação é alcançada entregando ao cliente o que ele deseja, ou seja, software que traga soluções ou benefícios para o seu negócio. Entretanto, apenas isso não basta. Esse software deve ser entregue de forma contínua e adiantada, para possibilitar a validação do produto ao longo do desenvolvimento e iniciar o fluxo de retorno do investimento tão logo seja possível.

Ninguém melhor do que o próprio cliente para avaliar se o software em desenvolvimento agregará valor ao negócio e, considerando que o quanto antes isso for feito menores serão os custos de possíveis alterações, não devemos aguardar o fim do desenvolvimento para entregar software funcionando. Planeje o entregas contínuas de partes prontas do software. Essa estratégia permite ao cliente avaliar a qualidade do produto para o seu negócio ao longo do desenvolvimento e até iniciar a sua utilização, mesmo esse não estando com todas as funcionalidades desejadas, mas já contando com um conjunto suficiente para trazer benefícios antecipadamente.

Encontramos na área de software muita gente acreditando que o objetivo do desenvolvimento de software é desenvolver software. Mas, na grande maioria das vezes, softwares são desenvolvidos para resolver problemas complexos, reduzir custos e/ou otimizar lucros. Os clientes estão atrás desses resultados e investem no desenvolvimento de software exclusivamente por causa disso, não porque esperam como resultado uma arquitetura fantástica, a criação de bibliotecas próprias ou preciosismos dos programadores. A qualidade interna do produto deve ser uma preocupação da equipe, mas ela não é um entregável, o cliente não pode tocá-la.

Ou seja, comece a entregar software funcionando o mais breve possível e mantenha um fluxo contínuo de entregas. Assim, a sua chance de ter um cliente satisfeito será muito maior!

The post 1º Princípio do Manifesto Ágil – Entrega Contínua appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Foi lançada uma versão revisada do Scrum Guide, o guia oficial do Scrum escrito pelos seus criadores Ken Schwaber e Jeff Sutherland.

Ken Schwaber e Jeff Sutherland resolveram simplificar o Scrum Guide para conter apenas o que eles consideram as regras do Scrum. Ou seja, foram retiradas do documento todas as coisas que não são obrigatórias à prática do Scrum, como dicas, práticas e técnicas opcionais. Essa mudança foi justificada como uma tentativa de diminuir os erros de interpretação acerca do que é ou não Scrum.

Como essa versão 2011 está disponível apenas em inglês, até que sejam feitas traduções para as outras línguas, explicaremos neste artigo as principais mudanças feitas e quais os possíveis impactos para a sua equipe.

• O termo time definido até então no Scrum para referir-se à equipe de desenvolvedores, aqueles que executam o trabalho de criação do incremento de produto, gerava confusão com o time de scrum, usado para referenciar todos os comprometidos de um projeto. Para solucionar tal confusão, definiu-se que a partir de agora os desenvolvedores serão chamados de equipe de desenvolvimento (do inglês, development team), independente das atividades executadas por cada um deles.
  

• Nessa nova versão do guia foi dada mais atenção ao papel do Scrum Master, detalhando melhor as atividades desempenhadas por ele e em especial a sua influência no ambiente da organização.
  

• O acompanhamento diário do andamento da sprint deve ser feito, mas não é obrigatório o uso do gráfico de burndown. O importante é ter conhecimento diário do trabalho que ainda resta ser feito e acompanhá-lo ao longo da sprint.
  

• Apesar do planejamento de releases ser uma prática aconselhada, também não é obrigatório no Scrum.
  

• As equipes de desenvolvimento não se comprometem com a conclusão do trabalho planejado durante a reunião de planejamento da Sprint. A equipe de desenvolvimento cria uma previsão de trabalho que acredita que será feito, mas essa previsão pode mudar à medida que o conhecimento relacionado às histórias aumenta ao longo da Sprint.
  

• O Product Backlog é “ordenado” ao invés de “priorizado” provendo flexibilidade ao Product Owner para otimizar valor de acordo com as circunstâncias existentes. Ou seja, o P.O. indica a sequência em que deseja que as histórias sejam tratadas.
  

Futuramente discutiremos aqui essas mudanças com mais detalhes. Enquanto isso, dê a sua opinião. O que você achou das modificações? Vamos por em discussão?

The post Scrum Guide 2011 – O que mudou? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Histórias são as necessidades ou requisitos levantados, para possivelmente serem desenvolvidos ao longo do projeto, e o product backlog armazena todas as histórias que ainda não foram executadas, de acordo com a prioridade atribuída pelo product owner. Essas histórias devem ter seus esforços estimados pela equipe antes da reunião de Planejamento 1, de forma que o sprint backlog seja definido levando em consideração o esforço estimado para as histórias e a velocidade média da equipe nas sprints anteriores. Um aspecto importante a ser observado para uma boa estimativa de esforço e, conseqüente, regularidade no cumprimento das metas das sprints é a qualidade das descrições das histórias.

Em seguida vem a reunião de Planejamento 2. Nessa, as histórias previamente selecionadas para o sprint backlog devem ser analisadas e discutidas entre a equipe (e, se necessário, com o product owner), para posteriormente serem definidas as tarefas necessárias para as suas execuções. Se a equipe concluir que não será possível realizar as histórias da sprint, deve ser negociada uma redução do sprint backlog com o product owner.

Após ter definida a composição do sprint backlog, a equipe deve desenvolver as histórias na ordem de prioridade definida pelo product owner.

A equipe se auto-organiza, para a execução das tarefas, durante a Reunião Diária. Nela, cada um deve informar aos demais membros sobre o andamento de seu trabalho no dia anterior, seu planejamento para o dia e se está tendo algum problema que o impeça de prosseguir com alguma tarefa. Essas reuniões diárias e o uso do gráfico de burndown permitem o acompanhamento do andamento das histórias durante a sprint.

Chegando o término da sprint, deve ser feita a reunião de Revisão. A equipe apresenta ao product owner o resultado do trabalho realizado ao longo daquela sprint para que ele aprove as histórias. Caso o product owner não fique satisfeito com alguma história, essa é reprovada e deve voltar ao product backlog para ser priorizada novamente e futuramente selecionada para outra sprint.

Por último numa sprint, é feita a reunião de Retrospectiva, fundamental para a melhoria contínua do processo de desenvolvimento. É considerada por alguns o momento de “lavar a roupa suja”, mas, mais importante do que isso, é o momento para refletir sobre os problemas que atrapalharam o andamento da sprint, quais pontos do processo podem ser melhorados e como melhorá-los na próxima sprint. E aí, tudo se repete…

Você não conhecia o Scrum? O que achou? Se já o conhece, compartilhe a sua experiência. As reuniões funcionam na sua equipe?

The post Scrum em 5 minutos… ou menos… rsrs appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.