Eu encontrei esse artigo no blog do Carlos Brando(O Nome do Jogo) e achei muito interessante as dicas de estimativas de prazos.

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.

(mais…)

XP é uma metodologia para desenvolvimento de software que foi desenvolvida ao longe das décadas de 80 e 90, mas que somente a partir de 2001 ganhou impulso e passou a ser mais usado em todo o mundo.

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:

(mais…)

Como colocado no post anterior, vamos falar agora sobre os 12 princípios que foram destacados pelos signatários do Manifesto Ágil.

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.

(mais…)

Desenvolver software é uma das atividades humanas que mais requer criatividade e investimento de inteligência de quem faz. Desde os primeiros softwares que foram feitos que as pessoas ligadas a área vêm pensando em métodos, práticas, que favoreçam o desenvolvimento de software com mais qualidade e observância a prazos e custos. Normalmente fazer software no prazo é uma missão quase impossível.

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

(mais…)