Curso de Extreme Programming - DevMedia
0 - Introdução
Software é feito em ciclos/iterações. O feedback é essencial e as mudanças devem ser abraçadas.
1 - Engenharia de Software
Agile:
- Indivíduos e interações mais que processos e ferramentas
- Software em funcionamento mais que documentação abrangente
- Colaboração com o cliente mais que negociação de contratos
- Responder a mudanças mais que seguir um plano
Objetivos:
- Reduzir o custo de mudanças
- Entregar versões do software funcionando o mais rápido possível
- Enxugar o processo de desenvolvimento e o próprio software em si
2 - Valores
Simplicidade:
- Sempre prezar pela solução mais simples possível para as funcionalidades do sistema
- O sistema deve até omitir certas funcionalidades para garantir a sua Integridade Conceitual
- Evitar generalizações, especulações e otimizações prematuras (OverEngineering)
- Desenvolver funcionalidades apenas a medida que elas se tornam necessárias
- Manter a simplicidade através de refatoração, reusabilidade de código, práticas de orientação à objetos e testes
Feedback:
- O Cliente analisa o sistema para aprovar o que foi feito ou demandar correções
- O Cliente realimenta os desenvolvedores com informações, baseadas em observações sobre o que já foi desenvolvido, que permitam a evolução do software
- O Desenvolvedor deve informar ao Cliente o custo, o prazo e o risco da implementação de determinada funcionalidade (viabilidade técnica do que está sendo pedido)
- Os feedbacks devem ser dados o mais rápido possível, para aumentar as chances de aprendizado
Comunicação:
- Fornece meios para que prioridades, equívocos e detalhes sejam tratados da melhor forma possível
- É essencial que Cliente e Desenvolvedor se comuniquem para tirar dúvidas e alinhar o que deve ser feito
- Deve ser eficiente (rápida) e eficaz (resultado satisfatório)
Coragem e Respeito:
- São essenciais para o sucesso do projeto, em todos os sentidos
- Coragem para praticar as atividades propostas pela XP
3 - Princípios
Auto-semelhança:
- Reúso de soluções/padrões
- Testes, Histórias, Refatoração, Design Patterns
Benefício Mútuo:
- As práticas realizadas devem beneficiar a todos (cooperação)
- Pair Programming, Código Compartilhado, Testes Unitários, Integração Contínua
Diversidade:
- Interdisciplinaridade é fundamental para criar soluções criativas e inovadoras
- Pair Programming, Código Compartilhado, Cliente presente
Economia:
- Foco no Retorno Sobre Investimento
- TDD, Releases frequentes
4 - Práticas
Cliente Participativo:
- Cliente + Equipe = Sucesso
- Menos dúvidas, retrabalho e falhas
- Mais feedback, segurança e confiança
- Entregas no prazo
- Sistema mais simples
- Equipe motivada e cliente satisfeito
Planing Game:
- Elaborar a visão inicial do sistema
- Coletar as User Stories:
- Devem possuir Testes de Aceitação, para validar a solução que foi implementada
- Serão quebradas em tarefas menores, para facilitar a implementação
- Devem ser estimadas, para avaliar quanto tempo/esforço irão demandar
- Planejar as releases:
- Dividir o projeto, para que possa evoluir através da entrega de módulos incrementais com tempos idênticos
- Dividir a primeira release em Iterações
- Selecionar as User Stories que entrarão nas iterações
- Ao final de cada iteração:
- Fazer testes
- Receber feedbacks
- Planejar a próxima iteração, reavaliando user stories, estimativas e prazos
- Ao final de cada release:
- Fazer testes
- Receber feedbacks
- Entregar um produto funcional
- Planejar a próxima release
User Stories:
- Meio onde o Cliente informar o que o sistema:
- Deve e não deve fazer
- Será e o que não será
- Serve também como fonte de informação sobre o negócio e de insumo para testes
Testes de Aceitação:
- Servem para validar as User Stories
- São descritas na visão do Cliente, a nível de interface de uso do sistema
- Podem servir de extensões das User Stories também, por conterem informações e regras de negócio
- Estrutura:
- Cenário => Operação => Verificação
- Podem ser automatizados
Estimativas:
- Juntar Cliente e Desenvolvedores para avaliarem a complexidade de cada US
- Usar pontos (dias ou semanas) como unidade de medida
- US grandes podem ser divididas em tarefas
Metáforas:
- Auxiliam na comunicação entre Negócio e Tecnologia
- Paralelo com o conceito de Linguagem Ubíqua
Releases:
- Cada release é dividida em iterações
- Desenvolvimento incremental e enxuto
- Cada uma entrega parte do software funcionando e testado
Iterações:
- Cada uma é formada por User Stories
- Podem ter 1 ou 2 semanas
- 1 dia para planejar, 1 para entregar, o resto para implementar
Stand Up Meeting:
- Reuniões diárias, curtas e feitas em pé
- Semelhante a daily do Scrum
Pair Programming:
- Redução de bugs
- Discussões levam à implementação de soluções melhores
- Pair pressure, mais produtividade
Design Simples:
- Dúvidas e suposições geram designs complexos e difícies de mudar
- Permite a realização de alterações de forma relativamente fácil
- Decisões podem ser procrastinadas
- Fazer o necessário para o momento
- Só adicionar complexidade se for realmente necessário
- Regras de Kent Back:
- Códigos e Testes devem expressar juntos o que o desenvolvedor deseja comunicar
- Sem duplicação de código nem comentários
- Menor número possível de Classes e Métodos
- Simples, não mal feito
Código Coletivo:
- Todos têm acesso ao código produzido por todos
- Ajuda a manter a qualidade alta
Refatoração:
- Essencial para aumentar a qualidade do código
- Mantém a entropia constante
- Melhora de performace
Código Padronizado:
- Possibilita a expressão de intensões/ideias de forma clara e objetiva
- Agiliza o entendimento do que o código faz
- Code Style automatizado, evitar discussões
Design Patterns:
- Dado um problema, dentro de um contexto específico
- Um Pattern é uma solução para esse problema
- Possui partes boas e ruins (trade-offs)
- Pode servir de base para resolução de problemas similares
Evitar Débitos Técnicos:
- Utilizar conceitos de:
- Arquitetura de Software
- Design Patterns, Orientação à Objetos
- DDD, TDD
- Testar e refatorar é essencial
Integração Contínua:
- Quanto mais demorado o merge, pior
- Integrar o código constantemente
- Build e testes automatizados
- Git, Jenkins, Hudison...
Test Driven Development:
- Escrever os testes que falham
- Escrever código para passar nos testes
- Refatorar
Velocidade Sustentável:
- Semana de 40h
- Horas extras somente em momentos excepcionais
Entrega de Iterações:
- O Cliente deve executar os Testes de Aceitação e validar a correta implementação das US
- É um momento de aprendizado para todos, via feedbacks
Entrega de Releases:
- Deploy do sistema em produção
- Virão feedbacks dos usuários
- Acarreta em diversas atividades para sustentação
5 - Papéis e Responsabilidades
Gerente de Projeto:
- Defende, promove e tem uma visão holística sobre a equipe
- Incentiva a utilização das práticas da XP
- Cuida da logística envolvida no desenvolvimento do projeto
Desenvolvedor:
- Personagem central na XP
- Analisa, modela, projeta, planeja e implementa o sistema
- Testa e faz intergrações
- Refatora e corrige
Analista de Testes:
- Perito em testes
- Garante a qualidade e a corretude do sistema
Redator Técnico:
- Faz e atualiza a documentação do software
- Faz código e documentação refletirem um ao outro
Coach:
- Change your mindset
Narradores:
- Pessoas com conhecimento de negócio
- Escrevem US e Testes de Aceitação
Aprovadores:
- Validam as US, via testes
Planejadores:
- De releases, iterações e US
6 - Outros Aspectos
Ambiente de Trabalho:
- Deve ser propício para facilitar as práticas da XP
Documentação:
- Só o essencial
Contratos:
- De escopo aberto
Métricas:
- Código funcionando, gerando e entregando valor
Projetos que não podem usar XP:
- Aqueles que envolvem licitações
- Software crítico, aviões, reatores...
Quando não tem cliente:
- Alguém deve ter conhecimento de negócio suficiente para fazer o papel do cliente
Cuidados antes e no início do projeto:
- Focar nos fundamentos e nas práticas a longo prazo