“Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.” (Agile Manifest).
Um dos maiores enganos quando se adota uma metodologia ágil é a falsa previsão de velocidade acelerada. Digo falsa porque, quando se fala em entrega incremental, esquece-se da ausência de algumas funcionalidades que não foram desenvolvidas, por isso o projeto dá aquela impressão que andou rápido.
A arte chama-se Simplicidade, mas bem que poderia se chamar economia, fato que ocorre quando o cliente se depara com a chance de escolher o que será desenvolvido primeiramente, ele logo percebe a oportunidade de ouro que tem pela frente: Fazer o que ele realmente irá usar do software.
Alguns projetos utilizando Scrum, e não são poucos, são considerados sucesso, de forma precipitada, visto pelo ponto do prazo que estipulou se inicialmente para realizar tal projeto. Pois bem, segundo um estudo realizado pelo Standish Group em 2011, chamado Chaos Report, em torno de 65% das funcionalidades nunca é utilizada em um sistema. Não acredito que a realidade brasileira seja muito diferente dos EUA. Agora se você é o cliente de um software e tivesse que ordenar os itens a serem feitos, por valor de negócio, sabendo que cada um das funcionalidades tem seu preço para fazer, e sabendo ainda que, aquela que você decidir construir irá para produção tão logo fique pronta. Por onde você iria começar?
Figura 1: Frequência de utilização das funcionalidades do Scrum
Ao adotarmos Scrum para desenvolver software, é vital que esta decisão seja tomada já no inicio do desenvolvimento, isto para que o cliente inicie de fato por aquilo que para seu negócio é mais importante. Sendo assim o cliente tem a oportunidade de avaliar já desde o início do sistema o que foi feito, podendo assim sugerir melhorias, ou at mesmo exclusão de algo que não ficou aderente ao negócio.
Acontece que, quando o cliente percebe que certa porção do software já atende ao negócio dele, ele por si só decide que o restante que ele mesmo elencou, com algum certo grau de prioridade, é dispensável para o seu negócio. Isso ocorre durante o ciclo de desenvolvimento, e muitas vezes dentro do prazo estimado para o desenvolvimento do software como um todo, de acordo com o escopo inicial.
Devido ao fato acima mencionado, é comum que, projetos terminem antes do previsto, o que dá certa conotação de antecipação no prazo final, mas se analisarmos bem, isso pode variar de caso a caso. No geral, o cliente percebeu que ele iniciou pelos 7% do software que o Standish Group diz ser sempre utilizado, partindo posteriormente para as demais funcionalidades.
Dentro deste contexto, não foi o prazo que encurtou, mas a falsa visão da necessidade que se tornou mais clara no desenrolar do projeto, que levou o cliente a tomar a decisão acertada de finalizar o desenvolvimento.
Projetos ágeis são de escopo aberto por motivos simples. Um deles é para dar ao cliente a oportunidade de analisar sempre o andamento, tirar proveito das oportunidades que surgirem e avaliar se compensa ou não prosseguir no caminho que o software está indo.
Quando um cliente decide terminar um projeto mesmo que ele não tenha atingido os 100% inicialmente previstos, devido ao fato que, o que já foi feito atender ao negócio, podemos dizer com certeza que este cliente está praticando a arte da Simplicidade, descrita pelo Manifesto Ágil.
Outro fator que ajuda os projetos ágeis a serem mais rápidos na entrega, é que também de acordo com o Manifesto Ágil, é dado ênfase mais no software funcionando do que naquela vasta documentação, altamente abrangente, que por sua vez, raramente é atualizada quando o software sofre mudança. A documentação em ambientes ágeis é mais leve e de fácil manutenção, muitas vezes em forma de User Story, trazidas para dentro do contexto do desenvolvimento, até mesmo para validação das regras de implementação dos testes de aceitação. Fato é que tais documentações ágeis são de mais claro entendimento e fazem parte da vida do software, seguindo de guia para os códigos fontes que permearão seu desenvolvimento.
Afirmo, em outras palavras, o cliente não jogou o dinheiro dele fora construindo partes do sistema que ele jamais irá utilizar, mas focou os esforços no que ele realmente precisa e, por este motivo, terminou o projeto em um tempo considerado baixo, se compararmos com o tempo que levaria se adotasse uma metodologia tradicional, que tem seu desenvolvimento conduzido pelas fases de Elicitação de requisitos, Projeto, Construção (implementação ou codificação), Integração, Teste e depuração, Instalação e Manutenção de software.
