
Autor: Daniel Wildt, Dionatan Moura, Guilherme Lacerda, Rafael Helm
Idioma: Português
Páginas: 161
Ano: 2016
ISBN: 978-85-5519-201-2
Entrega: Quando o pagamento for confirmado o ebook será enviado rapidamente por e-mail.
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.
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