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 ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 ScrumHalf Blog - Agile and Scrum Software - Brazil.

Stories are the needs or requirements raised, possibly to be developed throughout the project, and the product backlog stores all the stories that have not yet been executed, according to their priority, which is set by the product owner. These stories should have an estimate of how much effort is needed to complete them. This estimate is done by the team before the first planning meeting, so when the sprint backlog is made, it is taking into account the estimated effort for the stories and the average speed of the team in previous sprints.

After that, the team will have the second planning meeting. In this meeting, the stories which were previously selected for the sprint backlog should be analyzed and discussed among the team (and, if necessary, with the product owner), and than the tasks needed for each story to be finished should also be defined. If the team decides that they cannot complete all stories in the sprint backlog in time, a reduction of the sprint backlog should be negotiated with the PO.

After defining all the stories in the sprint backlog, the team should work on each story according to their “priority”, which was set by the PO.

The team should be self-organized in order to perform the tasks during the Daily Scrum. In it, each member should inform the other members of their progress in their work from the day before, what they are planning for the current day and if they are having any problems that prevents them from proceeding with any tasks. These daily meetings and the use of the burndown chart allows the monitoring of progress of the stories during the sprint.

Reaching the end of the sprint, it is time for the Review meeting. The team presents the results of their work, which was made during that sprint to the Product Owner to get his approval. If the product owner is not satisfied with a story, the story is rejected and it should return the product backlog, to be prioritized again and eventually selected for another sprint backlog.

The last step of a Sprint is the Retrospective meeting. It is vital to the continuous improvement of the development process. This is the time the team has to reflect on the problems that hindered the progress of the sprint, which aspects of the process can be improved and how to improve them in next sprint. And then everything repeats itself …

Did you already know about Scrum? What did you think? If you already knew about it, share your experience in the comments below!

The post Scrum in 5 minutes… or less… :) appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.