1. LSD
1.1. Fundação teórica
1.1.1. Produção toyota sistemas
1.1.2. Eliminar desperdícios
1.1.3. Entrega rápida
1.2. Papéis
1.2.1. Product owner
1.2.2. Menbros
1.2.3. Stalkeholder
1.3. Práticas
1.3.1. Não tem
1.4. Ciclo de vida
1.4.1. Planejamento do projeto
1.4.2. Plano de interação
1.4.3. Processos de teste
1.4.4. Eliminação de resíduos
1.5. Relação com outras metodologias
1.5.1. Scrum
1.5.2. Kanban
1.6. Ferramentas
1.6.1. Os 5s (sao os cinco passos para obter um bom resultado)
1.6.2. Just-in-Time (produção de peças)
1.6.3. Kaizen ( trabalho de forma pró ativa para melhorias)
1.7. Vantagens
1.7.1. .Não possui documentação
1.7.2. Baixo custo do produto final
1.7.3. Maior velocidade e precisão no desenvolvimento
1.7.4. Entrega do sistema em um período curto de tempo
1.8. Desvantagens
1.8.1. Não é feito desenvolvimento para futuras implementações
1.8.2. Levantamento de requisitos desnecessários
1.8.3. Comunicação interna ineficiente
2. XP
2.1. Fundação teórica
2.1.1. Feedback Rapido
2.1.2. Assumir simplicidade
2.1.3. Fazer trabalho com qualidade
2.1.4. Abraçar mudanças
2.2. Papéis
2.2.1. Programadores (que são os membros)
2.2.2. Coach (Programador mais experiente da equipe)
2.2.3. Tracker
2.2.4. Cliente
2.3. Práticas
2.3.1. Padronizações de codificação
2.3.2. Integração continua
2.3.3. Propriedades coletivas
2.3.4. Testes
2.3.5. Design simples
2.3.6. Cliente Sempre Presente
2.4. Ciclo de Vida
2.4.1. Exploração
2.4.2. Fase de planejamento
2.4.3. Fase de iterações
2.4.4. Produção
2.4.5. Manutenção
2.5. Relação com outras metodologias
2.5.1. Scrum
2.6. Ferramentas
2.6.1. Hard Tools (gráficos de apoio)
2.6.2. Soft Tools (Software que apoiam as práticas)
2.7. Vantagens
2.7.1. -Tornar o processo ágil e mais flexível. As praticas do XP foram criadas para funcionarem juntas. - Fornecem mais valor do que cada uma poderia fornecer individualmente. - Analise prévia dos acontecimentos dentro do projeto, o que oferece qualidade, confiança, datas de entrega e custos promissores. - O XP é ideal para projetos em que o cliente não sabe exatamente o que quer, pois os feedbacks constantes tornam possível as mudanças para atender os requisitos de forma rápida.
2.8. Desvantagens
2.8.1. - O cliente deve disponibilizar uma equipe para participar de todo o processo de desenvolvimento do software. - Existe uma perda de produtividade adotando programação em pares. - Todos os envolvidos no projeto devem conhecer as técnicas e regras.
3. TDD
3.1. Fundação teórica
3.1.1. Guiado por testes
3.1.2. Ciclo curto
3.1.3. Validação e verificação
3.2. Papéis
3.2.1. Desenvolvedores
3.3. Práticas
3.3.1. Teste confiáveis
3.3.2. Teste legíveis
3.3.3. Testes de formas simples
3.4. Ciclo de vida
3.4.1. executar o teste
3.4.2. implementação de novas funcionalidades
3.4.3. testes automatizados
3.4.4. refatoração
3.5. Relação com outras metodologias
3.5.1. XP
3.6. Ferramentas
3.6.1. testes unitários
3.6.2. teste de integração
3.6.3. teste de aceitação
3.7. Vantagens
3.7.1. -Cobertura do código com testes Prevenção a introdução de bugs -Assegura que a lógica funcione como esperado -Facilita manutenção -Refatoração pode ser feito com confiança -Clean Code
3.8. Desvantagens
3.8.1. -Mais código a ser desenvolvido
3.8.2. Muita integração externa
3.8.3. Alta Administração
4. ASD
4.1. Fundação teórica
4.1.1. atuação em problemas complexos
4.1.2. desenvolvimento com repetições
4.1.3. constante prototipação
4.2. Papéis
4.2.1. executivo responsavel
4.2.2. workshops
4.2.3. Facilitador
4.2.4. Developers
4.2.5. Escrivão
4.2.6. Cliente
4.2.7. Gerente de Projectos
4.3. Práticas
4.3.1. colaboração
4.3.2. comunicação
4.3.3. feedback
4.4. Ciclo de vida
4.4.1. especulação
4.4.2. colaboração
4.4.3. aprendizagem
4.5. Relação com outras metodologias
4.5.1. scrum
4.6. Ferramentas
4.6.1. não encontrado
4.7. Vantagens
4.7.1. Produz resultado com rapidez
4.7.2. Pode ser utilizado em projetos que necessitem de avaliação constante dos clientes
4.7.3. O planejamento pode ser adaptado em qualquer fase do projeto
4.8. Desvantagens
4.8.1. Ambos os desenvolvedores e clientes devem estar comprometidos com o passo rápido do projeto.
4.8.2. Projetos grandes exigem grandes equipes
4.8.3. Quando os riscos de projeto são altos, o Adaptive Software Development não pode ser adaptado
5. DSDM
5.1. Fundação teórica
5.1.1. aplicações com qualidade desejado
5.1.2. envolvimento constante com o usuário
5.1.3. Integração de funcionalidades
5.2. Papéis
5.2.1. progamador
5.2.2. Designers
5.2.3. analista
5.3. Práticas
5.3.1. Timeboxing
5.3.2. MoSCoW
5.3.3. Prototipagem
5.3.4. Workshop
5.3.5. Testes
5.4. Ciclo de vida
5.4.1. Estudo de Viabilidade
5.4.2. Estudo do Negócio
5.5. Relação com outras metodologias
5.5.1. nao tem
5.6. Ferramentas
5.7. Vantagens
5.7.1. Produz resultados com rapidez
5.7.2. Pode ser utilizado em projetos que necessitem de avaliação constante dos clientes
5.7.3. Criação e reutilização de componentes
5.7.4. O planejamento pode ser adaptado em qualquer fase do projeto
5.8. Desvantagens
5.8.1. O envolvimento com o usuário tem que ser ativo
5.8.2. Funções desnecessárias (reuso de componentes)
5.8.3. Sucessos anteriores são difíceis de se reproduzir
6. SCRUM
6.1. Fundação teórica
6.1.1. Sprints (requesitos do cliente)
6.1.2. backlog (backlog)
6.1.3. Product backlog (todo projeto reunido através do cliente)
6.2. Papéis
6.2.1. Product Owner
6.2.2. Membros da equipe
6.2.3. Scrum Master
6.2.4. Stake holders
6.3. Práticas
6.3.1. Quadro de tarefas
6.3.2. Gráfico Burndown (utilizado para que se possa acompanhar o desempenho do time ao longo da sprint.)
6.3.3. Estimativas (maneira como os requisitos devem ser estimados.)
6.3.4. Histórias de Usuário (descreve uma necessidade de um usuário do sistema)
6.3.5. Planning Poker
6.4. Ciclo de vida
6.4.1. Sprint Planning Meeting (se alinhar em tudo que será feito)
6.4.2. Prints
6.4.3. Reuniões
6.4.4. reinício do ciclo
6.5. Relação com outras metodologias
6.5.1. xp
6.6. Ferramentas
6.6.1. Jira Software
6.6.2. Basecamp
6.6.3. Slack (usado para feedbacks informais e para otimizar a comunicação)
6.6.4. Trello
6.6.5. IceScrum
6.6.6. Scrumhalf
6.6.7. PangoScrum
6.7. Vantagens
6.7.1. Complementa práticas existentes
6.7.2. Participação e direção do cliente
6.7.3. Prioridades baseadas no valor para o cliente
6.7.4. Times auto-organizados e com feedback
6.8. Desvantagem
6.8.1. Suporte apenas para gerenciamento de projetos
6.8.2. Não especifica técnicas práticas
7. BDD
7.1. Fundação teórica
7.1.1. Cria testes e integra regras de negócios com a linguagem de programação, focando no comportamento do software.
7.1.2. Comunicação entre equipes
7.1.3. Compartilhamento de conhecimento
7.1.4. Documentação dinâmica
7.1.5. Visão do todo
7.2. Papéis
7.2.1. Analista de negócios
7.2.2. Funcionários não-desenvolvedores
7.2.3. Líder de controle de qualidade (Quality Assurance, QA).
7.2.4. Dublês de teste
7.3. Práticas
7.3.1. Usar simuladores de teste
7.3.2. Usar "deve" ( para ajudar esclarecer responsabilidades e permitir que funcionalidades do software sejam questionadas)
7.3.3. Exemplos para descrever o comportamento de uma aplicação ou unidades de código
7.3.4. Automatizar os exemplos para prover um feedback rápido e testes de regressão
7.3.5. Envolver as partes interessadas no processo através de Outside-in Development (Desenvolvimento de Fora para Dentro)
7.4. Ciclo de vida
7.4.1. Documentação
7.4.2. Arquitetura
7.4.3. Desinvolvimento
7.4.4. Criar teste
7.4.5. Testes
7.4.6. Entregas
7.5. Relação com outras metodologias
7.5.1. Scrum
7.6. Ferramentas
7.6.1. Cucumber (automatizar testes)
7.6.2. Cucumber (ruby)
7.6.3. Behat (Php)
7.6.4. JBehave (java)
7.6.5. Jasmine (JS)
7.7. Vantagens
7.7.1. Facilita a escrita de testes
7.7.2. Aumenta o entendimento do negócio por parte do time
7.7.3. Aumenta a qualidade do software
7.7.4. Favorece o desenvolvimento de forma evolutiva.
7.8. Desvantagens
7.8.1. Iterações não são tão bem definidas
7.8.2. Dificuldade no seu desenvolvimento, manutenção e gerenciamento;
7.8.3. Dificuldade em evitar que erros ocorridos nas máquinas ou na rede atrapalhem o sistema
8. FDD
8.1. Fundação teórica
8.1.1. Entregar uma peça de software tangível e funcional para o cliente em espaços de tempo regulares
8.1.2. Apresentar para o cliente as funcionalidades em um período fixo de tempo
8.1.3. Entregar dentro de duas semanas o projeto desenvolvido
8.2. Papéis
8.2.1. Gerente do projeto
8.2.2. Gerente de desinvolvimento
8.2.3. Arquiteto chefe
8.2.4. Programadores chefes
8.2.5. Especialista de domínio
8.2.6. Proprietários de classe
8.3. Práticas
8.3.1. Modelagem em objetos de domínio
8.3.2. Desenvolvimento por características
8.3.3. Autoria individual
8.3.4. Times da característica
8.3.5. Inspeções
8.3.6. Integração (build) regular
8.3.7. Gerência de configuração
8.3.8. Reportar/Visibilidade dos resultados
8.4. Ciclo de vida
8.4.1. Desenvolver um modelo abrangente
8.4.2. Detalhar por funcionalidade
8.4.3. Construir listas de funcionalidades
8.4.4. Construir listas de funcionalidades
8.4.5. Planejar por funcionalidade
8.5. Relação com outras metodologias
8.5.1. Xp
8.5.2. Scrum
8.6. Ferramentas
8.6.1. FDDTools
8.7. Vantagens
8.7.1. Vários times podem trabalhar em paralelo
8.7.2. Todos os aspectos do projeto são rastreados por funcionalidade
8.7.3. Escalável para times e projetos grandes
8.7.4. Modelagem e desenvolvimento por funcionalidade são fáceis de entender e de adotar
8.8. Desvantagens
8.8.1. Iterações não são tão bem definidas
8.8.2. promove "donos" do codigo