AgileZ

A fim de ajudar as pessoas a entenderem melhor o desenvolvimento ágil de software, em 2001 os membros da Agile Alliance refinaram o enunciado do Manifesto Ágil, criando doze princípios que as metodologias ágeis devem seguir. Estes princípios são os seguintes:

1. Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software funcional.
2. Abrace as mudanças de requisitos do projeto, mesmo que ocorram tardiamente. Os processos ágeis apóiam a mudança como uma vantagem competitiva para o cliente.
3. Entregue software funcionando com uma freqüência de duas semanas a dois meses, escolhendo sempre a menor escala de tempo possível.
4. O pessoal de negócio e os desenvolvedores devem trabalhar juntos no projeto diariamente.
5. Construa os projetos com pessoas motivadas. Forneça o ambiente, os equipamentos e as ferramentas de que elas precisam e confie que elas farão o trabalho.
6. Uma conversa cara a cara é a melhor forma de transmitir e receber informação do time de desenvolvimento.
7. Software funcionando é a principal medida de progresso.
8. Processos ágeis promovem um desenvolvimento sustentado. Gerência, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. A atenção contínua à excelência técnica e a um bom design aumentam a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho desnecessária – é essencial.
11. As melhores arquiteturas, designs e requisitos surgem de times auto-gerenciados.
12. A intervalos regulares, o time reflete sobre como se tornar mais eficaz, e então ajusta seu comportamento de acordo com as reflexões.

Pare por um momento e reflita sobre os princípios acima. Serão tão radicais e impossíveis como algumas pessoas acham ou simplesmente seguem o bom senso? Será tão difícil fazer os projetos funcionarem desta forma? Você realmente acredita que seu cliente prefere uma ótima e farta documentação a um sistema funcionando em um curto prazo? Ou que um e-mail substitua um bom bate-papo? E que tal fazer somente o necessário, sem ficar ‘viajando na maionese’?

Estes princípios formam um senso comum e prático, sobre o qual podemos alicerçar nossos esforços para a construção de um software de sucesso.

(Referência: Agile Modelling – Scott Ambler)

Quem trabalha com desenvolvimento de software sabe que um dos nossos maiores desafios é conseguir mensurar o tamanho de cada tarefa com uma boa precisão, e, conseqüentemente, conseguir prever quando determinado recurso deverá ser concluído. A forma como fazemos nossas estimativas tem um grande impacto na confiabilidade de nossos prazos, porém, nem sempre as equipes tomam consciência desse fato, e continuam dando pouco valor ou dedicando menos esforço do que deveriam a essa atividade.

Seja qual for a metodologia de trabalho que sua equipe utiliza (scrum + XP ou outra mais tradicional) você pode utilizar diversas técnicas de estimativas. Neste artigo vou apresentar a que é mais utilizada por equipes que empregam metodologias ágeis: o Planning Poker.

Antes de começar, devo introduzir um conceito que pode não ser conhecido ou aceito por todos: uma estimativa é da equipe e não de um programador ou analista em específico, ou seja, o ato de estimar é uma atividade de TODA a equipe, e esse detalhe é primordial para o sucesso do Planning Poker. Com isso em mente, vamos à definição:

Leia mais…

Como um amigo meu disse certa vez… ‘na internet nada se cria, tudo se copia’. Acabei me rendendo a essa frase, e publicarei uma estorinha já contada em outros blogs. Essa eu peguei do blog do André Dourado (blog muito bom, recomendo). O post original é de Henrik Kniberg, autor do livro ‘Scrum e XP direto das trincheiras’.

É uma historinha bem humorada do dia a dia de negociações com nossos Product Owners. O André fez uma tradução livre para o português. O post original pode ser visto em One Day in Kanban Land.