Principais características do XP parte 1

A seguir veremos as principais características do XP.

Mais software funcionando, menos documentação

Assim como no Scrum, o XP preconiza que um software funcionando vale mais do que uma documentação extensa. Logo, o código fonte possui um alto valor nesta metodologia.

Portanto, o código finalizado também é uma fonte de feedback, assim como um produto implantado e em pleno funcionamento. Software funcionando agrega bastante para o cliente.

Integração contínua

Consiste na integração do código alterado ou mesmo desenvolvido do projeto que é o principal, porém com muito mais agilidade e de forma mais constante.

O objetivo principal de utilizar a integração contínua é verificar se as alterações ou novas funcionalidades não criaram novos defeitos no projeto já existente.

Esta prática pode ser realizada por meio de processos manuais ou mesmo automatizados.

Adaptação às mudanças

Se muitas mudanças são realizadas todas de uma vez, não se obtém um bom resultado. No XP, as mudanças devem ser incrementais e aos poucos. Os desenvolvedores possuem a liberdade para melhorar constantemente o código do produto.

Entregas pequenas

Cada release deve ser tão pequeno quanto possível, contendo os requisitos mais importantes para o negócio”. Isso possibilita ter releases frequentes, aumentando o feedback dos usuários e o time de desenvolvimento. Lembre-se mínimo útil de forma que agregue valor ao negócio. Não adianta entregar algo que não agregue nada!

Como as releases são constantes, a integração é CONTÍNUA (grave isto). Quando uma funcionalidade é produzida, ela deve ser integrada brevemente. Essa prática diminui a possibilidades de erros.

Histórias de Usuário

Consistem em artefatos com as demandas / requisitos dos usuários. Porém, são escritos de forma mais resumida e em uma linguagem mais próxima do usuário. Representam uma pequena parte da funcionalidade a ser desenvolvida.

Detalhes mais profundos das histórias poderão ser captados com o desenvolvimento da funcionalidade, principalmente nos testes de aceitação do incremento do produto. 

As histórias de usuário podem ser escritas em cartões que serão consultados durante todo o desenvolvimento. Lembrando que o cliente deve participar ativamente dessa escrita.

Tamanho das histórias

Elas devem possuir tamanho ideal para serem desenvolvidas dentro de uma iteração, considerando a capacidade de produção da equipe de desenvolvimento. As histórias de usuário atravessam a arquitetura do produto, não focando em um subsistema específico.

Logo, uma história que não couber dentro da iteração deve ser decomposta em histórias menores. Tenha em mente que as iterações devem produzir produtos utilizáveis para o usuário.

Assim como no Scrum, as histórias de usuário são elaboradas obedecendo as prioridades do cliente (FOCO NO CLIENTE sempre).

Após definidas as histórias, a equipe de desenvolvimento divide os cenários em tarefas menores construção. 

As histórias de usuário possuem algumas características:

Independente — Sempre que possível, as histórias de usuário devem ser independentes umas das outras, a fim de que o Dono do Produto possa ordená-las, planejá-las e implementá-las conforme o valor que cada uma possui para o negócio.

Negociável — Conforme foi dito anteriormente, a história de usuário não contém todos os detalhes de um requisito. Sendo assim, ela deve ser descrita em um nível que permita ao Time Scrum e Stakeholders realizarem conversas a fim negociar o detalhamento desses requisitos. Uma história de usuário não é um contrato a ser seguido, e sim um lembrete a todos que deve ser realizada uma conversa a fim de detalhar os requisitos.

Valorosa — No artigo referente às características de um Backlog do Produto, dissemos que, a fim de evitar desperdício de tempo e de recursos, o Dono do Produto deve priorizar o desenvolvimento dos 20% dos itens do Backlog do Produto que irão agregar o maior valor para o negócio. Os 80% dos itens restantes devem ficar para depois ou, caso não sejam efetivamente necessários, devem ser descartados. Dessa forma, as histórias do usuário devem gerar valor para o negócio.

Estimável — É muito importante que uma história de usuário possa ser estimada pelo Time de Desenvolvimento, mesmo que o nível de precisão não seja alto, uma vez que a estimativa possibilita ao Dono do Produto priorizar o Backlog do Produto, estimar custos, planejar releases, etc. Quando o Time de Desenvolvimento não consegue estimar uma História de Usuário, isso pode significar que o seu tamanho é muito grande, que as informações são insuficientes, que o seu conteúdo está muito ambíguo, ou até mesmo que o Time não possui conhecimento sobre a tecnologia a ser utilizada.

“Small” (Pequena) — As Histórias de Usuário devem ser pequenas, ou seja, necessitam possuir um tamanho máximo que as permitam serem desenvolvidas dentro de uma única Sprint.

Testável — É muito importante que as Histórias de Usuário possam ser testadas, a fim de que seja possível assegurar que o produto obtido ao final do desenvolvimento esteja de acordo com o que foi definido e sem a existência de erros.

Exemplo de um cartão com história de usuário:

Desenvolvimento Incremental – Design incremental

A equipe de desenvolvimento deve investir no design da aplicação todos os dias, buscando oportunidades para remover a duplicação e fazer pequenas melhorias, alcançando o melhor código e produto possíveis. Esses incrementos são curtos.

Os requisitos são registrados em cartões de histórias e as histórias a serem incluídas em um release são determinadas pelo tempo disponível e sua prioridade relativa. Os desenvolvedores dividem essas histórias em tarefas.

Desenvolvimento em pares

Os desenvolvedores trabalham em pares para codificarem as tarefas estabelecidas para o produto. Consiste em um método de programação no qual duas pessoas trabalham juntas em um único programa.

DIRETO DO CONCURSO

Em projetos de desenvolvimento de software, a extreme programming (XP) é um método ágil que usa a prática de

1. projetos com planejamento completo sem incrementos.
2. grandes releases.
3. grande quantidade de horas extras.
4. trabalho em pares de desenvolvedores.
5. integrações após a entrega do software completo.

Comentário

Conforme vimos, uma das práticas do XP é a programação em pares.

Sobre os demais itens:

1. Uma das práticas do XP é a sua forma de desenvolvimento incremental constante. Tão logo o trabalho em uma tarefa é concluído, esta é integrada ao sistema.
2. Seria o contrário: pequenas releases. Em regra, o conjunto mínimo de funcionalidades que agregam valor ao usuário devem ser adicionadas à próxima release.
3. Seria o contrário da afirmação. Horas extras não são bem – vindas no XP. Devem ser evitadas ao máximo. O modelo preconiza o desenvolvimento sustentável com semanas com duração de 40 horas de trabalho.
4. Gabarito correto
5. O código das funcionalidades implementadas pode ser integrado várias vezes ao dia. Compreende na integração contínua.

Gabarito correto é a letra D.