Veja abaixo na íntegra:

Definir quanto tempo será necessário para finalizar uma tarefa ou o desenvolvimento de um software não é (ou pelo menos não deveria ser) algo trivial. Estimar prazos faz parte do nosso dia-a-dia como programadores.

O que muita gente não se dá conta é que a precisão com que um programador prevê a entrega de tarefas e projetos é um poderoso indicador do quão bom ele é.

Para informar de forma precisa o tempo necessário para a realização de algo em desenvolvimento de software é necessário que o programador possua uma certa experiência no assunto, tenha um bom domínio do negócio, seja rápido e produtivo.

Embora muitos de nós não apreciem essa difícil tarefa, estimar prazos é parte do nosso trabalho. Fazer isso bem pode ser a diferença entre um programador profissional e um amador.

Em um dia normal, estamos estimando prazos o tempo todo. Ao colocar a comida no micro-ondas você deve informar quantos minutos serão necessários para esquenta-la. Se você tem um horário fixo para acordar, deve analisar quantas horas de sono serão suficientes e então decidir quando deve ir para a cama.

O segredo não está no tempo, mas em quão precisa deve ser a sua estimativa. Se seu chefe pergunta que horas você entregará o relatório amanhã, ele quer ter uma ideia se será antes ou depois do almoço. Se ele lhe pergunta quanto tempo será necessário para resolver um bug critico e colocar o sistema de volta em produção ele precisa de uma precisão maior.

A escala de tempo é muito importante ao se estimar prazos. Por exemplo, você pode dizer “O projeto será entregue em 25 dias” ou pode dizer “O projeto será entregue em cerca de 5 semanas”. Embora ambas as frases indiquem o mesmo tempo, o efeito sob cada uma delas pode ser diferente. Ao dar a primeira resposta, seu cliente provavelmente anotará na agenda dele o dia exato em que você entregará o projeto. Por outro lado, a segunda resposta fará com que ele lhe procure a qualquer momento daqui a 4 ou 6 semanas.

O livro The Pragmatic Programmer dá uma importante dica que nos ajuda a escolher a escala de tempo apropriada ao estimar prazos. Veja a tabela:

1-15 dias -> dias
3-8 semanas -> semanas
8-30 semanas -> meses
30 + semanas -> pense bem antes de dar uma estimativa

Qual a vantagem disso? O fato é que quanto maior o tempo, mais difícil é a previsão, exigindo que você seja cada vez mais impreciso. Por exemplo, se sua estimativa é que serão necessários 125 dias para terminar um trabalho, é muito mais seguro dizer que precisará de “cerca de 6 meses” para finaliza-lo.

Todas as estimativas que fazemos são baseadas em nossas experiências passadas. Mas, o que fazer quando é necessário estimar algo que você nunca fez ou que não conhece? A resposta é simples: “não estime”. É melhor pedir para que alguém que já tenha feito algo semelhante lhe dê uma ideia do tempo necessário.

Além de considerar o grau de precisão, também é importante entender qual é o problema antes de começar a chutar um tempo. Quase sempre nossas estimativas dependem de outros fatores para darem certo: “Supondo que não haja trânsito dá para chegar aí em 20 minutos”.

Se possível é muito útil testar alguns aspectos do projeto antes de dizer quanto tempo será necessário para cumpri-lo. Se o sistema precisa ser carregado dentro do Facebook, seria muito bom poder gastar um tempo criando alguma coisa bem simples para esta plataforma afim de analisar o grau de complexidade, isto sem dúvida aumentará a precisão da estimativa.

É muito importante levar em consideração que a equipe, sua produtividade e o ambiente afetam diretamente sua estimativa.

Analisando todos estes fatores, a conclusão é que há apenas uma única resposta correta a se dar quando lhe é pedido para estimar um prazo: “Me dê algum tempo para pensar”. Você sempre terá resultados melhores se retardar a resposta e pensar um pouco mais.

Pertencente ao que se convencionou chamar de metodologias ágeis, XP baseia-se em quatro valores:

- Feedback

- Comunicação

- Simplicidade

- Coragem

Viníucius Teles, um dos grandes evangelizadores de XP no Brasil, afirma que “quando o cliente aprende com o sistema que utiliza e re-avalia as suas necessidades, ele gera feedback para a equipe de desenvolvimento”. Essa característica do feedback está fortemente relacionada à prática do XP  ter sempre junto à  equipe de desenvolvimento pelo menos uma pessoa que será usuária do sistema, bem como ao uso de ciclos de iterações bastante curtos.

A comunicação é entendida, segundo Teles, como o processo que permite que as informações sejam transmitidas dentro da equipe e entre a equipe e o cliente. Este processo tem que ser claro, rápido; não é focado na formalidade e sim na informação de qualidade. Para o XP a melhor forma de repassar uma informação é de forma oral e em reuniões de corpo presente.

No XP a equipe de desenvolvimento de software irá programar sempre o necessário para atender ao requisito do cliente, mas nada mais que isso. Ao propor essa abordagem, o XP se contrapõe a  outras formas de projetar sistemas que procuram antecipar problemas e de formas a obter ganhos.

A coragem como valor no XP pode ser observada em características como:

- Coragem para desenvolver o software de forma incremental

Adotando este paradigma mais uma vez reforça-se a idéia que o desenvolvimento deve ser feito para resolver os problemas existentes e que podem ser identificados. Deve-se abolir a idéia de programar funcionalidades no projeto que sejam baseadas em especulações.

- Manter o sistema simples

Significa preocupar-se em manter todo o projeto de forma geral, simples. Não tentar antecipar problemas e nem desenvolver funcionalidades que o cliente não deseja.

- Permitir que o cliente priorize as funcionalidades

Entregar ao cliente o comando do desenvolvimento pois o mesmo passa a ficar mais comprometido com o resultado.  Outra conseqüência direta desta prática é o aumento da confiança entre equipe de projeto e cliente.

- Programação em pares (pair programming)

A programação em pares é um dos pilares do XP. Significa colocar sempre dois profissionais para executar uma tarefa. A idéia é que ao fazerem a mesma juntos, alternando-se entre quem codifica, estes possam ficar verificando o que está sendo feito. Essa forma de trabalho redunda em uma das grandes vantagens do XP que é o baixo valor de correção de erro. Esse valor cai significativamente, pois os erros são detectados logo no processo de codificação.

- Refactoring

Refactoring pode ser traduzido como uma aplicação do conceito de melhoria contínua na programação de software. A idéia é que ao refazer constantemente sempre parte do software, este ficará cada vez mais organizado, menos sujeito a erros e ainda  mais no domínio da equipe. Segundo Teles (TELES, 2005) “existe um ditado que diz que um dia sem refactoring é como um dia sem sol”.

- Investir tempo em testes automatizados

O desenvolvimento ágil tem como característica marcante a agilidade, a facilidade de receber mudanças. Para suportar essas mudanças é necessário um comprometimento de toda a equipe do projeto com testes. Estes testes são necessários, ocorrem de forma automatizada e o mais cedo possível, exatamente para corrigir eventuais erros e evitar correções de custo elevado mais tarde. E ainda são os testes um importante espaço de participação do cliente, pois nestes o usuário tem papel de destaque. Caso o usuário não possa executar os testes de validação sozinho, uma pessoa da equipe do projeto deve auxiliá-lo. Contudo, a presença do cliente nesta etapa é essencial.

- Estimar as histórias na presença do cliente

O XP utiliza como instrumento principal de documentação os cartões com histórias do cliente. São esses cartões que irão ser a base de todo o projeto. Quando a equipe se reúne para definir os tempos de cada cartão o cliente é a parte imprescindível. Seu papel nessa etapa é validar o conteúdo do cartão e o entendimento da equipe e, principalmente, definir a prioridade da execução. Ao definir que histórias serão executadas o cliente estabelece uma iteração

- Expor o código a todos os membros da equipe

O código de todo projeto executado usando XP é coletivo. Isso significa que qualquer membro da equipe pode ver o código que o outro escreveu e, mais que isso, deve oferecer comentários, observações e fazer refactoring desse código. O XP necessita do trabalho coletivo não sendo compatível com sua metodologia a idéia de profissionais que não compartilhem.

- Integrar o sistema diversas vezes ao dia

Seguindo o conceito de desenvolver e testar de forma muito próxima, no XP o projeto é integrado continuamente. Podem-se corrigir problemas de integração que somente seriam corrigidos em etapas posteriores do projeto.

- Adotar um ritmo sustentável

Trabalhar com metas realistas é outra característica importante do XP. Ao discutir a precedência das ações com o cliente de forma transparente, a equipe também apresenta a este qual seu ritmo de execução.

- Abrir mão de documentação que vale como defesa

O envolvimento e a confiança que o cliente adquira na equipe que utilize XP tornam possível que a equipe utilize a mínima documentação apenas necessária. Não existe no XP a documentação que é feita apenas para o cliente saber o que está sendo feito, como uma prestação de contas. A participação e a transparência com o cliente, o cumprimento dos prazos e a entrega do software funcionando, isso satisfaz o cliente, não papéis com diagramas e modelos.

- Propor contratos de escopo variável

No XP entende-se ser mais vantajoso utilizar o tripé: qualidade, tempo e custo. O escopo é determinado, mas de forma a apenas ser uma orientação inicial. Este formato é colocado como mais adequado para o desenvolvimento de software, pois fundamentalmente o cliente não sabe dizer tudo o que o software terá que ter tudo o que irá compor seu escopo. Este irá sendo determinado ao longo do desenvolvimento. A idéia em XP então é utilizar-se um modelo de contrato no qual o cliente contrata horas e estas são utilizadas de acordo com a implementação das histórias de usuário. Desta forma promove-se o alinhamento de interesses do cliente com o fornecedor conforme verificado no quadro abaixo.

- Propor a adoção de um processo novo

Adotar um modelo novo, diferente do qual as pessoas estão habituadas a trabalhar requer coragem. Romper com as resistências é uma das tarefas mais importantes ao se implantar um projeto que vai utilizar XP.

1 – Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software usual.

Esse princípio coloca de forma muito clara a importância que o Manifesto Ágil dá as entregas rápidas. Por conta desse princípio os agilistas têm que trabalhar de forma muito focada no que importa para o cliente. Releases curtas e software funcionando são melhores que releases longas e de software que por vezes não é funcional.

2 – As mudanças são bem vindas. Os processos ágeis tiram proveito da mudança, não se colocam contra ele.

Os agilistas tem que aceitar que as mudanças são oportunidades para encontrar novas vantagens competitivas no software que estão desenvolvendo. Dado que a realidade do mercado é cada vez mais de mudanças, que o mercado se move cada vez mais velozmente, adotar uma postura enrijecida diante da necessidade de mudanças pode ser um erro fatal. No mínimo ao final do projeto vai-se entregar para o cliente um software inútil.

3 – Trabalhar para entregar software funcionando  em intervalos de tempo cada vez menores.

Releases em intervalos curtos de tempo ajudam na colaboração cliente pois dessa forma ele poderá interferir no trabalho para correções mais cedo, diminuindo o risco de grandes mudanças ao final.

4 – Simplicidade

Seja simples, procure soluções diretas aos problemas em vez de ficar elaborando por um longo tempo uma solução para um problema genérico demais. Normalmente esse código “a mais” não é percebido pelo cliente.

5 – Trabalha sempre com equipes altamentes motivadas.

Dote as pessoas de sua equipe do melhor ambiente possível, das ferramentas e informações necessárias e remova quaisquer obstáculos a conclusão do seu trabalho. Mantenha-as sempre super motivadas.

6 – Valoriza a comunicação face a face

A melhor forma de transmitir informações é face a face, pessoalmente. Quando não for possível utilize as tecnologias que lhe permitam fazer essa comunicação da forma mais rica possível. Nada de só utilizar apenas um e-mail ou uma ligação rápida.

7 – Software funcionando é a medida da execução do projeto

Receber software funcionando é o objetivo do cliente. E pronto. É por esse ponto de vista que o cliente irá julgar a equipe do projeto e deve ser portanto por este ponto de vista que a equipe deve também ser avaliar.

8 – Procure manter um ritmo sustentável

Métodos ágeis devem produzir uma velocidade sustentável de desenvolvimento. Exatamente por não trabalhar com sobre cargas, com jornadas que exijam dedicação fora do nornal, os métodos ágeis devem produzir uma condição de trabalho e de relacionamento entre equipe e cliente que permita um ritmo perene.

9 – Excelência técnica e design são pré-condição para Agile

Os agilistas necessitam de boa técnica e de um bons designs de aplicação para que conceitos como releases curtos, integração contínua, programação orientada a testes possam ser praticados.

10 – A melhore arquitetura e o melhor design nascem do time

Simples, dentro de um projeto ágil as melhores idéias nascem do time e não de um líder “inspirado”.

11 – De tempos em tempos o time se auto avalia

Regularmente o time é chamado e refletir sobre sua produção, seu comportamento, enfim, sobre sua atuação dentro do projeto e de que forma ele pode ser ajustar para melhorar sua performance.

12 – Equipe, executivos e clientes devem trabalhar bem próximos

Em todos os métodos é colocado que o desenvolvimento deve ser feito de forma muito próxima ao cliente. Da mesma forma os executivos, gerentes, também deve estar bem alinhados com esse desenvolvimento afim de que no final todos estejam solidários com os produtos entregues.

Bem, esses foram alguns tópicos sobre Agilidade numa perspectiva mais geral. No próxima post vamos passar para descrever algumas metodologias.

Por acreditar que o desenvolvimento de software poderia ser algo mais prazeroso e mais simples, com resultados melhores, foi que vários especialistas em desenvolvimento criaram o que hoje é conhecimento como Manifesto Ágil.

O Manifesto Ágil traduziu a agilidade em 4 valores principais:

- Os indivíduos e as interações são mais importantes que os processos e as ferramentas

Uma das principais características da Agilidade é a valorização das pessoas, equipe e cliente, colocando-os em primeiríssimo lugar. A valorização da comunicação entre estes, suas interações, fica muito evidente quando vê-se que no desenvolvimento ágil quem “guia” o projeto é o cliente através do acompanhamento da produção do software.

- Software funcional ao invés de documentação abrangente

A entrega do software é o objetivo principal do projeto. No pensamento Ágil diz-se claramente que a documentação está a serviço dessa entrega e não o contrário. Ou seja, em termos de prioridade a entrega do software vêm antes e geralmente valoriza-se bastante o próprio código como principal documentação do projeto.

- Colaboração do cliente ao invés da negociação de contrato

Esse é um dos pontos mais complicados, principalmente no Brasil quando consideramos a realidade da Lei de Licitações que amarra bastante a forma de contratação dos órgãos públicos. Basicamente esse valor  traduz a vontade do movimento de colocar o cliente no comando do projeto, deixando portanto que o mesmo possa fazer mudanças ao logo de sua execução. No Desenvolvimento Ágil o cliente está efetivamente no comando do projeto.

- Respostas as mudanças ao invés de seguir um plano

Reconhecer que o desenvolvimento de software é um projeto que é muito afeito as mudanças é uma das mudanças que o movimento Ágil prega. Esse valor traduz essa mudança da paradigma ao valorizar mais a facilidade, a abertura as mudanças, que o apego a um plano que foi traçado inicialmente. Nesses termos existe uma inversão do modelo tradicional que diz que as mudanças podem ocorrer mas impõem tantas condições que na verdade as limitam bastante. Na verdade, dentro da perspectiva Ágil a mudança é a regra.

Importante: Nenhum desses valores diz que os valores “antigos” estão errados ou não devam ser considerados. Por exemplo, continua sendo importante ter processo, continua sendo necessário ter documentação. O que o movimento Ágil faz é uma valorização maior dos “novos” valores.

No próximo post vamos tratar dos 12 princípios do Desenvolvimento Ágil.