Desenvolvimento Ágil e seu impacto no desenvolvimento de software

Agile & Project Management

Agile_Scrum_Fotolia_23390746_XSPor motivos óbvios já citados no artigo anterior (O porquê do desenvolvimento Ágil), o impacto do desenvolvimento ágil pode ser algo muito positivo ou negativo, dependendo do método utilizado e sua aplicação. Cada projeto é um organismo vivo que responde de acordo a uma série de parâmetros.

Muito da tecnologia atual se dá devido as necessidades do mercado e devido estas necessidades o próprio desenvolvimento de software vem passando por transformações constantes, como a necessidade de se manter em dia com os requisitos do negócio bem como uma rápida adaptação as mudanças que geralmente ocorrem no dia-a-dia do desenvolvimento de software. É neste cenário que o desenvolvimento ágil surgiu como uma possível solução.]

Analisando os dois lados da moeda, vemos os entusiastas do agile reivindicando aumentos significativos na qualidade dos softwares, enquanto os opositores exibem vários casos em que o desenvolvimento “rápido” com uma estrutura menos “rígida” de desenvolvimento levam a uma diminuição da qualidade. É claro que nem todos os projetos sobre o selo de agile realmente seguem um modelo confiável ou correto. O certo é (e me arrisco a afirmar) que o desenvolvimento ágil vai trazer um grande impacto ao seu projeto se o mesmo for realizado corretamente.

Neste artigo vamos discutir algumas práticas específicas difundidas pela comunidade agile que tem provado oferecer um impacto positivo de qualidade.

Levando em consideração o que já foi dito, fica um dúvida: Como decidir se o desenvolvimento ágil vai ser um bom negócio para sua equipe? É claro que esta não é uma resposta fácil, ainda mais se levarmos em conta que hoje existem muitos métodos vagamente agrupados sob a premissa de ágil (XP, SCRUM, Lean Software Development, etc.).

Neste caso o mais comum é a adoção de de métodos “remendados”. Adicione isso ao fato de que práticas ágeis não são recomendadas a todas as situações sendo mais adequadas a determinados tipos de projetos e filosofias organizacionais do que outros, e vamos ter organizações ou projetos que não se adaptam ao agile com pouca probabilidade de sucesso e qualidade.

 

Falando em ágil…

Quando falamos do desenvolvimento ágil estamos falando em:

    • Software funcionando mais do que uma documentação abrangente
    • Responder as mudanças mais do que seguir o “plano”

O desenvolvimento ágil foi introduzido em meados dos anos 90 quando as grandes corporações sofriam com o ritmo acelerado do desenvolvimento de software causado pelas mudanças culturais e necessidades já citadas anteriormente. A base do agile se fundamenta na premissa que a produtividade e qualidade são oriundas das técnicas e disciplinas usadas e as nossas relações interpessoais. Práticas ágeis focam na simplicidade, no cliente, na responsabilidade compartilhada, colaboração e comunicação frequente e direta.

Métodos mais tradicionais se concentram em produtos bem documentados e revisados em cada fase do ciclo de vida do desenvolvimento de software. Eles exigem que tudo deve ser entendido e concebido antes da codificação inicial. A filosofia ágil assume que as coisas vão mudar antes do lançamento “final” e assim sendo, grande parte do esforço de planejamento inicial é desperdiçado.

A filosofia ágil requer da equipe de desenvolvimento a quebra do projeto de software em pequenos pedaços de funcionais, permitindo a integração contínua e opiniões constantes dos clientes.

Conceitos básicos de agile incluem:

    • Test Driven Development - testes de unidade escritos antes de qualquer coisa apenas com o código necessário para passar no teste;
    • Design descomplicado - fazer a coisa o mais simples possível sem especular sobre futuros recursos;
    • Programação em par - todo o código de produção é escrito em pares com colaboração on-going (em andamento);
    • Refactoring - melhorar o código existente sem alterar a funcionalidade com base nas lições aprendidas através de implementações passadas e boas práticas;
    • Integração Contínua – testes automatizados e integrações constantes;
    • Propriedade coletiva - todos os desenvolvedores são responsáveis pela integridade do código;
    • User Stories - Histórias que descrevem o “pedaço” do sistema a ser implementado, um espaço reservado para uma boa conversa sobre os requisitos durante o curso do desenvolvimento;
    • Iterações curtas - lançamentos frequentes que agregam valor de negócio.

 

Qualidade do Software

Por qualidade de software podemos entender como a medida de quão bem o software é projetado (design de qualidade) e como o software está de acordo com o projeto (qualidade de conformidade). Esta definição implica em dois aspectos de qualidade de software:

    • Construindo a coisa certa
    • Construindo a coisa da maneira certa

Construindo da maneira certa pode ser medido por uma contagem de defeitos por unidade de tamanho (linhas de código fonte, Pontos de Função, Casos de Uso, etc.), o número de testes passados, a taxa de defeito, etc. Determinar se a “coisa certa” está sendo construída é um pouco problemático. Como isto depende da satisfação do cliente, só podemos ter uma medida correta mediante a entrega.  A literatura contém muitos exemplos de estudos e experiências (tanto acadêmica como na indústria) que indicam  a metodologia ágil como sendo a melhor para a qualidade do software e a satisfação do cliente.

 

Práticas ágeis com maior impacto na qualidade de software

Embora seja a combinação de práticas ágeis que levem a melhorias de qualidade, existem várias práticas, que quando implementadas corretamente contribuem para a melhoria da qualidade do software. Abaixo segui algumas destas práticas:

 

Pair Programming (Programação em par)

A programação em pares é frequentemente citada como uma razão para a melhor qualidade de software. Com a programação em pares dois programadores são colocados juntos para completar uma tarefa de programação única. Eles têm um computador entre eles e colaborar para determinar o melhor design e melhor aplicação para esse projeto. A programação em pares aplica aquele velho ditado em que "duas cabeças pensam melhor que uma". 

 

Test Driven Development (TDD)

Desenvolvimento orientado a testes prega que nenhum código deve ser escrito para um recurso até que os testes para que o recurso em questão tenham sido escritos e que estes testes primeiramente falhem. Se este é seu primeiro contato com TDD não se assuste, é isso mesmo o que você leu. Antes do desenvolvedor começar o código para um determinado recurso ele precisa entender os requisitos, intenções e exceções do recurso de maneira que possa escrever testes para isso. O processo para cada novo recurso começa com um estudo da história do usuário, a fim de avaliar as necessidades de se escrever ou não um teste automatizado para este recurso. Este teste é então executado para assegurar que ele vai falhar (uma vez que a característica ainda tem de ser escrita). Uma vez que o teste tenha falhado, o desenvolvedor escreve o que ele “acredita” ser a quantidade mínima de código para fazer o teste passar. Após o código ser escrito e o teste passe, o desenvolvedor, em seguida, de forma incremental refatora a solução para a tornar mais simples e mais limpa. Porque cada incremento inclui a reexecução do teste, o desenvolvedor pode refatorar com a confiança de que o recurso não vai “quebrar” com as alterações posteriores.

Testes realizados pela Microsoft em dois ambientes distintos com projetos semelhantes mostrou que a taxa de erros diminuiu significativamente entre o projeto que utilizou TDD em relação ao projeto que não usou. Os testes também indicaram que o aumento no tempo de desenvolvimento não é tão significativo quando o ganho na qualidade de software. O teste pode ser lido em detalhes no artigo Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies

 

Integração Contínua

Integração Contínua é uma prática ágil que exige que as mudanças na base de código sejam continuamente integradas em um sistema operacional. Geralmente este processo é automatizado e integrado com um conjunto de testes automatizados, a fim de dar feedback em tempo real quando um desenvolvedor faz uma alteração que causa mau comportamento em lugares inesperados no sistema. Durante o processo, os desenvolvedores individualmente fazem o famoso 'check out' em uma cópia do código a fim de fazer alterações para corrigir um bug ou adicionar um recurso. Logo após ele testa (ou deveria testar) essa mudança e, em seguida, faz o 'check-in' do código alterado. Durante este tempo, os outros desenvolvedores fizeram mudanças em outras partes do código. Um problema comum surge quando o tempo do 'check out' é muito longo, isso porque cada desenvolvedor consegui passar a suíte de testes com o seu código local, a combinação deste código local com as alterações dos outros desenvolvedores é propenso a falhas.

Quanto maior o período entre as integrações é mais provável que a equipe passe pela problemática da infinda de determinar qual das muitas alterações de código é responsável por falhas nos testes.

 

Iterações curtas 

Geralmente entendemos por iterações curtas uma 'release' com valor agregado a cada duas semanas. Estes lançamentos podem nunca ver a luz do dia fora do grupo de desenvolvimento, mas a equipe trabalha neste sentido, como se a entrega estivesse destinado ao cliente. Se um lançamento é construído a cada poucas semanas com implementações incrementais de funcionalidades, o cliente tem a oportunidade de ver como a equipe de desenvolvimento está interpretando suas necessidades e tem a chance de redirecionar os esforços quando  estes se desviam de suas expectativas. Se um projeto de software se mete em problemas e atrasa, o cliente tem a oportunidade de priorizar os requisitos para que o melhor conjunto de funcionalidades chegue ao mercado em tempo hábil. Outra vantagem é que o cliente tem a oportunidade de fazer testes funcionais nos recursos a medida que eles surgem. Com isso a equipe ganha tempo para se concentrar nos recursos à medida que surgem, aumentando a chance de que os defeitos sejam detectados e tratados no sem impactar futuros recursos.

Certamente visibilidade precoce e frequente das funcionalidades implementadas dá para o cliente o poder de observação e crítica o que aumenta a probabilidade do software implementado "fazer a coisa certa" e deixar os clientes satisfeitos. 

 

 

Conclusão

Desenvolvimento ágil em todas as facetas tem sido utilizado em muitos casos, para diminuir os defeitos e aumentar a satisfação do cliente. Há também pesquisas (e opiniões) para apoiar uma conclusão oposta. Esta disparidade decorre do fato de que diferentes organizações adotam diferentes formas de agile e muitas vezes adotam diferentes conjuntos de práticas ágeis dentro da metodologia agile adotada. Algumas práticas ágeis, ou combinação de práticas ágeis, quando implementadas corretamente, são mais propensas a resultar em melhoria da qualidade de software do que outras. Práticas como a programação em pares, desenvolvimento orientado a testes, integração contínua e iterações curtas foram todas citadas como componentes de um conjunto de iniciativas para melhoria de qualidade de software. A melhor maneira de garantir que o software seja entregue e atenda as necessidades do cliente fazendo a “coisa certa” é ter comunicação constante entre os clientes e os desenvolvedores.

 

Bom estudo a todos!

Me Azul

Twitter: @vitormeriat

vitormeriat@gmail.com

vitor.pereira@studentpartner.com


Author's profile picture

Vitor is a computer scientist who is passionate about creating software that will positively change the world we live in.

MVP Azure - Cloud Architect - Data science enthusiast


10 minutes to read