Planejando seu projeto com eXtreme Programming – Parte I

Talvez você já tenha lido vários textos sobre XP (eXtreme Programming), talvez também você até diga “legal, mas como eu uso isso?”, portanto, esse artigo, almeja explicar de maneira simples e objetiva como você pode iniciar seu projeto usando as premissas fundamentas do desenvolvimento ágil.

Só para relembrar, XP, é um processo de desenvolvimento de software que é baseado em premissas ágeis como:

• Desenvolvimento incremental;
• Projetos preferencialmente com um escopo orientado a objetos;
• Escopo variável, ou seja, os requisitos são vagos e mudam com freqüência.

Entenda que o termo ágil, não significa que o código do projeto vai ser produzido como um passe de mágica da noite para o dia, na verdade, os processos ágeis como XP, se baseiam na idéia de prover a todas as partes de um projeto, o máximo de produtividade por cada dia de trabalho, gerando dessa forma um maior valor agregado e um alto nível de qualidade ao software desenvolvido.

Essa agilidade, conforme já falei em artigos anteriores, é assegurada por um conjunto de valores como feedback, comunicação, simplicidade, respeito e coragem, através também de uma gama de práticas como:

• O Cliente Presente
• Estórias
• Jogo do Planejamento
• Programação em Par
• Reuniões em Pé (rápidas)
• Desenvolvimento guiado por testes
• Testes de Aceitação
• Refactoring
• Código Coletivo
• Padrões de Código
• Simplicidade de Design
• Metáforas
• Ritmo Sustentável
• Integração Contínua
• Releases Curtos

Como você pode ver o estudo sobre XP apesar de ser bem detalhado, é bem simples de compreender e aplicar, dessa forma, esse artigo terá como foco, a aplicação de alguns “artefatos” que servem como ferramentas fundamentais para o uso de XP.

Por isso, iremos inicialmente estudar nesse artigo as idéias básicas de uma estória e como são estruturados as iterações e os releases, mas nos próximos, iremos estudar o que é um dia perfeito de trabalho? Como funciona o sistema baseado em pontos? Como compor do cartão de estória? E por fim, como elaborar um roteiro para testes de aceitação.

O que é uma estória?

Apesar de que falaremos mais detalhadamente sobre esse tema nos próximos artigos, decidi colocar aqui uma breve introdução sobre o que são estórias, pois é crucial que você tenha esse entendimento básico, para conhecer o funcionamento de XP como um todo.

Estórias são as funcionalidades que o cliente espera receber na aplicação que será construída, que em outras abordagens seriam chamadas de requisitos, casos de usos ou pontos de função.

Quem escreve uma estória?

Normalmente, elas são registradas em cartão de estória, pelo próprio cliente, em uma linguagem simples e comum o suficiente para a compreensão de todos da equipe.

Quem usa uma estória?

Como você pode observar na figura 01, os maiores usuários das estórias, são os desenvolvedores, que o fazem a fim de guiar o que deve ser desenvolvimento na aplicação, porém, costuma-se afirmar que as estórias são um “convite ao diálogo” entre os desenvolvedores e o cliente, ou seja, não é necessário que as estórias sejam bem detalhadas, na verdade é recomendado que o texto contido nelas, seja extremamente simples e objetivo, e principalmente, deixe uma margem para estimular o diálogo entre a equipe e o cliente a fim de dirimir qualquer dúvida sobre a funcionalidade em questão.

É importante observar que é através dessas estórias que podemos estimar qual será o esforço necessário para implementar essa tal funcionalidade através de um sistema baseado em pontos(que vermos no próximo artigo).

Essas estórias, também fazem parte de um conjunto de outras estórias que serão agrupadas em alguma iteração. E só para deixá-lo com bastante curiosidade, no próximo artigo, iremos estudar como compor um cartão de estória.

O que é uma iteração?

Uma iteração de uma maneira bem simples, é o tempo disposto a fim de gerar a implementação de um determinado número de estórias, é importante lembrar que é na iteração que iremos aplicar o conceito de modelo em espiral que veremos mais adiante.

Quanto tempo dura uma iteração?

Sem parecer clichê, o tempo de duração é relativo, pois vai depender do tipo do projeto, tamanho da equipe, capacidade técnica da equipe ou necessidade do cliente.

Convenciona-se apenas que uma iteração deve ter o menor tempo possível, pois é através dela, que conseguiremos medir e corrigir o andamento de um projeto, por isso é comum encontrar iterações que variam de uma a três semanas, mais como eu disse anteriormente, você define isso de acordo com sua necessidade.

Como se inicia uma iteração?

Normalmente dedica-se um dia inteiro, ou boa parte dele, para uma reunião que é chamada de Jogo de Planejamento, onde, programadores, gerentes e clientes definem e estipulam quais as estórias serão priorizadas naquela iteração, como serão seus roteiros de testes, quais serão as combinações iniciais de pares, o que houve de errado na iteração anterior, e que pode ser melhorado naquela iteração atual.

Como se termina uma iteração?

Terminado ora bolas! (eheh brincadeira!) Basicamente ao término de uma iteração, dedica-se também um dia inteiro para a realização de testes de aceitação, verifica-se principalmente, quais estórias foram bem sucedidas e quais passarão para a próxima iteração como uma estória de correção.

O que é um Small Release?

Primeiro é importante que você entenda muito bem, que um release curto é uma pequena versão do sistema, que comumente é funcional o suficiente para que o cliente possa começar a usá-lo a fim de fazer testes mais funcionais, iniciar os cadastros básicos, começar a sentir se o caminho que o projeto está indo, é o correto ou até mesmo liberar aquela pequena versão para o uso por parte dos usuários do sistema.

É importante, notar, que essa idéia possibilita o cliente, ver de maneira mais rápida, o retorno sobre seus investimentos naquele projeto, isso é importante, pois dessa forma, o cliente terá um controle maior sobre a evolução do mesmo e principalmente, poderá implantar o sistema sobre demanda, sem necessariamente, depender do fim do projeto inteiro, para o ver como o sistema funciona e se comporta.

Estrutura baseada em releases e iterações

Ao contrário das metodologias de desenvolvimento tradicionais, que seguem idéias muitos próximas ao modelo em cascata, os processos ágeis como XP, usam um modelo incremental, que se fosse traduzido graficamente, seria semelhante a uma espiral.

Na verdade, o modelo espiral não representa o projeto como um todo, pois, ele é usado várias vezes em pequenas partes durante o mesmo, formando ciclos que se repetem até o final do projeto.

Nesses ciclos que chamamos de iterações vemos claramente são que miniaturas de projetos, onde aplicamos as fases presentes em um desenvolvimento mais tradicional, ou seja, seria como tivéssemos vários pequenos projetos dentro um projeto só.

Cada iteração terá um conjunto de estórias a serem implementadas, que passam por uma análise, por um design, e por testes na mesma iteração vigente.

Veja na figura 02, como é estruturando um projeto seguindo o modelo incremental, observe que em cada iteração, aplicamos o modelo espiral, repetindo as fases de análise, design, implementação e testes.

Esse modelo se apóia na premissa ágil de que por vários motivos o escopo do projeto muda no decorrer de sua execução, portanto, essa estrutura é capaz e absorver de uma forma mais eficaz essas possíveis alterações.

Isso evidencia o fato de que é mais simples alterar ou corrigir pequenos pedaços do projeto, do que faze-los no software inteiro e somente no final do mesmo.

É muito importante que você entenda muito bem esse conceito, pois o mesmo é a base de todo o dinamismo proposto por XP. Para isso veja na figura 03, outro diagrama que mostra outro prisma de uma estrutura de projeto usando XP, observe que teremos a figura dos releases, e que estes por sua vez possuem as iterações que também possuem o conjunto de estórias a serem implementadas.

Conclusões

Bem caro amigo, espero sinceramente que tenha gostado dessa breve introdução sobre um tema tão excitante e útil para o dia-a-dia no desenvolvimento de software, por isso gostaria de agradecer sua atenção, e convidar-lhe a ler os próximos artigos que darão continuidade a esse tema. Portanto até a próxima.

Saiba mais: Planejando seu projeto com Extreme Programming – Parte II