Enfim, chegamos até aqui!
Depois de estimar tarefas, planejar iterações, brincar de Pôquer do planejamento e muito mais, precisamos nos reunir para alinhar o andamento do projeto.
Mas como sempre, nosso tempo é muito curto. Reuniões levam tempo, e esse tempo mais na frente pode deve fazer falta. O que faremos então, já que é preciso manter toda a equipe informada e caminhando junto? Continue lendo
Quando levantamos nossas funcionalidades, utilizamos roteiros de usuários ou histórias do usuário (user stories) para conhecer o nosso provável escopo do projeto. As histórias são representadas com um simples cartão que contém informações como título da funcionalidade, uma breve descrição, um campo para colocarmos nossa estimativa de tempo e um espaço para o cliente dar uma prioridade. No entanto, para começarmos a execução do projeto precisamos de um pouco mais. Continue lendo
No post passado aprendemos como estimar nossas funcionalidades para dar ao cliente um prazo. Somando as estimativas chegamos a um número final. Porém, como levamos em consideração o tempo que 1 desenvolvedor sozinho seria capaz de concluir cada tarefa, devemos agora dividir esse número pela quantidade de programadores na equipe
Finalmente, esse é o nosso prazo! Mas não se anime, o cliente quase nunca concorda.
Suponhamos que ele exija proponha um prazo menor. Teremos então que re-planejar nosso cronograma, ou seja, estabelecer o tempo de nossas iterações. Mas como saber se nossa equipe é capaz de fazer no tempo que ele pediu? Continue lendo…
No post passado começamos a falar sobre princípios de como desenvolver software usando como base a leitura do livro Use a Cabeça: Desenvolvimento de Software. Foi explicado que dividindo o nosso projeto em iterações podemos nos aproximar daquilo que o cliente realmente precisa, obtendo seu feedback e mostrando o andamento do projeto em pequenas partes de Software funcional.
Vimos também que é muito importante que o cliente priorize as funcionalidades a serem desenvolvidas, pois temos um prazo a cumprir e nem sempre tudo caberá no período acordado para entrega do produto.
Para dar ao cliente um prazo, a nossa equipe precisa realizar a estimativa de tempo de cada tarefa a ser construída durante o nosso processo de desenvolvimento. Uma forma de se fazer é Continue lendo
Um software de qualidade necessariamente precisa atingir os 3 princípios básicos de qualquer projeto:
* Requisitos do cliente //afinal esse é o motivo do projeto
* Prazo //sejamos pontuais, like british people
* Custo //pedir mais dinheiro é uma coisa muito feia
Itere sempre!
Clientes são ansiosos e entregar-lhe pedaços de software funcional por mais simples que sejam Continue lendo