Conteúdo

Por que projetos falham? Comunicação insatisfatória com o cliente, um empurra a culpa para o outro, tempo desperdiçado, falta de testes e retrabalho... Estas são cenas corriqueiras em um time de desenvolvimento de software. E qual a solução?

Neste livro, Daniel Wildt, Dionatan Moura, Guilherme Lacerda e Rafael Helm mostrarão que na verdade não se trata de um único método, mas de um conjunto de práticas que, se bem combinadas, complementam-se em uma sinergia que envolve tanto os membros de dentro do time como o contato destes com o cliente. Conheça práticas de eXtreme Programming e, tendo como base princípios ágeis, desenvolva seus principais valores: comunicação, feedback, simplicidade, coragem e respeito.

Saiba o que você vai aprender

Sumário

• 1 Por que projetos falham?
• 1.1 Cliente distante
• 1.2 A cereja do bolo
• 1.3 Testes no final
• 1.4 Trabalho empurrado
• 1.5 Dívidas técnicas
• 1.6 Conclusão

• 2 Introdução a métodos ágeis
• 2.1 O Manifesto Ágil
• 2.2 Lean Software Development
• 2.3 Scrum
• 2.4 eXtreme Programming (XP)

• 3 Valores do eXtreme Programming
• 3.1 Comunicação
• 3.2 Feedback
• 3.3 Simplicidade
• 3.4 Coragem
• 3.5 Respeito

• 4 Papéis do eXtreme Programming
• 4.1 Desenvolvedor
• 4.2 Cliente
• 4.3 Coach
• 4.4 Testador
• 4.5 Cleaner
• 4.6 Tracker
• 4.7 Gerente
• 4.8 Outros papéis

• 5 Time coeso
• 5.1 Time multidisciplinar
• 5.2 Time auto-organizável
• 5.3 Sentando lado a lado
• 5.4 As reuniões de retrospectiva e a melhoria contínua

• 6 Cliente presente
• 6.1 O que fazer quando o cliente não pode estar presente?

• 7 Histórias de usuário
• 7.1 Modelo 3C
• 7.2 Ciclo de vida
• 7.3 Utilizando um modelo de escrita
• 7.4 Refinando com INVEST
• 7.5 Implementando com tarefas SMART
• 7.6 Personas
• 7.7 Story points
• 7.8 Escrevendo boas histórias
• 7.9 Catálogo de story smells

• 8 Testes de aceitação
• 8.1 Automatização
• 8.2 Validando com critérios de aceitação

• 9 Liberação frequente de pequenas entregas
• 9.1 Foco na qualidade é o ponto-chave
• 9.2 Releases tudo ou nada

• 10 O jogo do planejamento
• 10.1 Definindo o jogo e suas regras
• 10.2 Entendendo regras e comprometimentos
• 10.3 Mantendo o foco
• 10.4 Todo momento é um momento de aprendizado

• 11 Spikes de planejamento
• 11.1 Jogue fora o código gerado no spike

• 12 Projeto simples do início ao fim
• 12.1 MVP: produto mínimo viável

• 13 Metáfora de sistema
• 13.1 Descobrindo uma boa metáfora

• 14 Reunião diária em pé
• 14.1 Time alinhado
• 14.2 Troca de conhecimento
• 14.3 Como começar?
• 14.4 Erros mais comuns de uma reunião em pé

• 15 Posse coletiva
• 15.1 My precious!

• 16 Padrão de codificação
• 16.1 Pequenos projetos também se beneficiam?
• 16.2 Como definir?

• 17 Programação em par
• 17.1 Diversos benefícios
• 17.2 Um desenvolvedor pelo preço de dois?
• 17.3 A pressão do par
• 17.4 Nivelando o conhecimento
• 17.5 Como começar?
• 17.6 Dicas para aprimorar a programação em par
• 17.7 O ambiente de trabalho
• 17.8 Especificar, projetar, trabalhar, tudo em par

• 18 Refatoração de código para alta qualidade
• 18.1 Refatore impiedosamente
• 18.2 Bad smells de código

• 19 TDD: Desenvolvimento Guiado por Testes
• 19.1 Padrões de TDD
• 19.2 Show me the code

• 20 Integração contínua
• 20.1 Como potencializar os benefícios?
• 20.2 Ferramentas

• 21 Ritmo sustentável
• 21.1 Velocidade do time
• 21.2 40 horas semanais

• 22 Indo além do eXtreme programming
• 22.1 Jogos e dinâmicas
• 22.2 Behaviour-Driven Development (BDD)
• 22.3 Domain-Driven Design (DDD)
• 22.4 Kanban
• 22.5 Estimando com planning poker
• 22.6 Resolvendo dívidas técnicas
• 22.7 Refatorando também o banco de dados
• 22.8 Código limpo
• 22.9 Entrega contínua e DevOps
• 22.10 Leituras sobre desenvolvimento de software
• 22.11 Artesanato de Software