Bugs que o sistema apresentou no fim do sprint

Ano passado meu último post foi “Erros que cometi nesse sprint”, tratava-se de alguns erros que tinha cometido em um projeto, principalmente por não ouvir as pessoas. Outra vez vou contar um pouco da experiência que eu tive e que está totalmente relacionada aos princípios ágeis.

A grosso modo, o princípio básico das metodologias ágeis de desenvolvimento de software é: entregar software de qualidade e funcional o mais rápido possível para garantir o ROI (retorno sobre investimento). Esse é um assunto que já se tornou clichê no mundo do desenvolvimento de software, porém no dia a dia de um projeto seguir esse princípio não é tão fácil como parece. Então, seguindo essa linha de pensamento, quando vamos iniciar um sprint devemos priorizar quais tarefas serão executadas primeiro afim de entregar o quanto antes as funcionalidades que tem mais valor (ROI).

Muitas vezes o objetivo principal do projeto não fica claro em um primeiro momento, no caso o projeto tratava-se de um loja virtual de cursos, porém esse conceito só ficou realmente claro para a equipe depois que o projeto foi “finalizado”. Isso foi um grande problema, eu particularmente acabei me concentrando em vários detalhes que não estavam diretamente relacionados com o objetivo principal, ou seja, o usuário poder comprar e se matricular em um curso.

Depois do “fim” do projeto foram encontrados vários bugzinhos no sistema e várias coisas que não tinham sido implementadas ou que poderiam ser melhoradas. Eu fiquei encarregado de arrumar esses bugs para então o site ser finalmente concluído e entrar em produção. No fim da segunda semana que estava arrumando os erros percebemos que o processo de compra de um curso simplesmente não estava funcionando…

É aí que PAGAMOS O PREÇO por NÃO ser ÁGEIS

Não entregamos software funcionando incrementalmente, fizemos incrementalmente, mas não entregamos, dessa forma é muito mais difícil descobrir bugs e possíveis mudanças. Adiar mudanças significa aumentar o custo delas. E o pior é entregar software que não cumpre com seu principal objetivo.

Se o software apresenta muitos bugs e precisa de muitas correções, você estará perdendo dinheiro, afinal o cliente não vai pagar para arrumar erros de desenvolvimento.

Poderíamos ficar procurando N motivos para dizer o porque cometemos erros (acharíamos vários e achamos), principalmente pelo projeto ser de escopo fechado, mas era melhor salvar o projeto, não acha? =p

Salve o projeto, seja ÁGIL

Utilizando três técnicas ágeis, conseguimos em poucos dias, corrigir os bugs e tornar o sistema totalmente funcional.

– Testes Automatizados
– Programação em Par
– Refatoração

O sistema tinha/tem testes automatizados, isso nos proporcionou fazer uma refatoração no código programando em par, com a segurança de que não iríamos quebrar outras partes do sistema. Dessa forma conseguimos rapidamente corrigir os bugs e o processo de compra, tornando o sistema totalmente funcional.

E você? está utilizando desenvolvimento ágil nos seus projetos?

6 thoughts on “Bugs que o sistema apresentou no fim do sprint

  1. Fala Lucas!!

    Já passei por muito disso, quando vou entregar o projeto (já um pouco atrasado algumas vezes) e tem esses bugs.

    Estou tentando melhorar meu processo de desenvolvimento também, mas ainda em prestar mais atenção e testando cada parte concluídas, mas preciso estudar um pouco de ágil, entender melhor.

    Abraço.

  2. Fala Maurício,

    com certeza, esses problemas são bem comuns na vida de qualquer desenvolvedor. Para você eu recomendaria primeiramente a prática dos testes automatizados, deve ter algo para o CakePHP, procure por PHP Unit. Você vai se sentir bem mais seguro para realizar mudanças, e vale lembrar que um do valores da XP é a coragem =)

    abs.

  3. Eai Lukaum. Testes salvam o projeto mesmo. Principalmente quando vc precisa mexer em uma parte crítica do sistema.

    Abraços.

  4. Com certeza, nada como ter testes automatizados pra poder refatorar o sistema com a confiança de não estar quebrando tudo. No meu entendimento é uma parte essencial do desenvolvimento, obrigatória; desenvolver sem testes automatizados é garantia de dores de cabeça grandes quando for necessário modificar o sistema, e qual sistema não precisa ser mexido depois de pronto? No Rails eu uso RSpec, mas acho que toda plataforma tem algum framework de testes automatizados.

    Ah e uma pergunta, não tem um feed desse blog? Gostei muito dos artigos, mas quero ler no meu agregador! =)

    um abraço

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.