1. SCRUM
1.1. Framework Scrum
1.1.1. é um conjunto de valores, princípios e práticas que fornecem a base para que a sua organização adicione suas práticas particulares de engenharia e gestão e que sejam relevantes para a realidade da sua empresa. O resultado será uma versão de Scrum que é exclusivamente sua.
1.2. Caracaterísticas
1.2.1. Método Ágil
1.2.2. Embasado em empirismo, é Iterativo e Incremental
1.3. Papéis
1.3.1. Product Owner (PO)
1.3.1.1. Cliente ou um representante. Toma toda as decisões sobre o negócio, especificando os requisitos, o objetivo do software, o que será implementado e o que ficará de fora.
1.3.1.2. Indica os requisitos mais importantes para cada sprint.
1.3.2. Scrum Master
1.3.2.1. É um facilitador, alguém responsável por garantir que o processo está seguindo, por motivar o time, remover os impedimentos, garantir a conclusão do processo.
1.3.3. Time
1.3.3.1. É a equipe de desenvolvimento, tendo a participação de todos para o desenvolvimento do produto. Usualmente de 5 a 10 pessoas.
1.3.3.2. Velocidade do Time
1.3.3.2.1. Quantidade de pontos entregue durante uma sprint. Ex: 8 pontos em 2 semanas
1.4. Backlog do Produto
1.4.1. é uma lista de funcionalidades ou características a serem implementados ou produzidos em cada projeto (Requisitos, casos de suso, histórias de usurários)
1.5. Sprint Backlog
1.5.1. é a lista de funcionalidades a serem implementadas no ciclo que se inicia.
1.6. Cerimonias
1.6.1. Planejamento da Sprint
1.6.1.1. É o ciclo de desenvolvimento de poucas semanas de duração ( 2 a 4 semanas), onde é feita a priorização de itens do backlog, e são transferidos do backlog do produto para sprint backlog.
1.6.1.1.1. Time
1.6.1.1.2. PO
1.6.1.1.3. Scrum Master
1.6.1.2. Time in box
1.6.1.2.1. Estipula o tempo de execução do trabalho definido.
1.6.1.3. Estimativas
1.6.1.3.1. A equipe estima o esforço gasto para implementar cada história.
1.6.1.3.2. Story points
1.6.1.3.3. Dias Ideais
1.6.1.3.4. Planning Poker
1.6.2. Reunião Diária
1.6.2.1. Reunião rápida feita todos os dias para avaliar o trabalho do dia anterior e priorizar aquilo será implantado no dia.
1.6.2.1.1. Scrum Master
1.6.2.1.2. Time
1.6.3. Revisão da Sprint
1.6.3.1. Ocorre a demonstração e avaliação, do produto desenvolvido na sprint, para PO
1.6.3.1.1. PO
1.6.3.1.2. Scrum Master
1.6.3.1.3. Time
1.6.3.2. Aprovação ou não das histórias pelo PO. Caso um história não seja aprovada, tola toda para p backlog do produto.
1.6.3.3. O que será feito em uma nova sprint.
1.6.4. Retrospectiva da Sprint
1.6.4.1. Objetivo de avaliar o time e os processos (impedimentos, problemas, etc.)
1.6.4.1.1. Scrum Master
1.6.4.1.2. Time
1.6.4.1.3. Convidado: PO
1.6.4.2. Retrospectiva Starfish
1.6.4.2.1. Continuar a fazer?
1.6.4.2.2. Parar de Fazer?
1.6.4.2.3. Mais de...
1.6.4.2.4. Menos de...
1.6.4.2.5. Começar a fazer...
1.6.4.3. Happiness Board
1.6.4.3.1. É a prática que mede o nível de satisfação, felicidade de cada membro da equipe.
1.6.4.4. Retrospectiva do Barco
1.7. Trabalho em par
1.7.1. Duas pessoas para a execução de uma tarefas, com a toca constante das duplas.
2. Métodos Ágeis
2.1. Princípios Ágeis
2.1.1. 1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
2.1.2. 2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos
2.1.3. ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
2.1.4. 3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
2.1.5. 4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
2.1.6. 5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
2.1.7. 6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
2.1.8. 7. Software funcional é a medida primária de progresso.
2.1.9. 8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
2.1.10. 9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
2.1.11. 10.Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
2.1.12. 11.As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
2.1.13. 12.Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo
2.2. Manifesto Ágil
2.2.1. É uma declaração de valores e princípios essenciais para o desenvolvimento de software.
2.2.2. Valores
2.2.2.1. Indivíduos e interação entre eles mais que processos e ferramentas;
2.2.2.2. Software em funcionamento mais que documentação abrangente;
2.2.2.3. Colaboração com o cliente mais que negociação de contratos;
2.2.2.4. Responder a mudanças mais que seguir um plano.
2.3. Feedback
2.3.1. É o mecanismo fundamental que permite que o cliente conduza o desenvolvimento do projeto diariamente.
2.4. MVP
2.4.1. É a versão Mínima do produto, ou seja, possui apenas as funcionalidades necessárias para que o software cumpra o seu objetivo.
2.5. Resumo Ágil
2.5.1. Envolvimento do Cliente
2.5.2. Entrega Incremental
2.5.3. Pessoas, não processos
2.5.4. Aceite as mudanças
2.5.5. Manter a simplicidade
3. Extreme Programming XP
3.1. Práticas
3.1.1. 1. Jogo do Planejamento
3.1.1.1. Planejamento da release, geralmente de 2 a 3 meses, tendo uma release diversas iterações curtas (1 a 3 semanas).
3.1.1.2. 1º Etapa: Histórias de Usuários
3.1.1.3. 2º Etapa: Estimativas
3.1.1.3.1. Story points
3.1.1.3.2. Dias Ideais
3.1.1.3.3. Planning Poker
3.1.1.4. 3º Etapa: Priorização do Cliente e Definição do conteúdo da Iteração
3.1.1.5. 4º Etapa: Avaliação de Iteração
3.1.2. 2. Cliente Presente
3.1.2.1. Deve ser incluído alguém da parte do cliente ou que o represente junto à equipe XP para esclarecer dúvidas sobre os requisitos do sistema, ajudar na confecção dos casos de teste funcionais, auxiliar na escrita das histórias e priorização delas.
3.1.3. 3. Reuniões de Pé (Stand Up Meeting)
3.1.3.1. Reunião rápida que a equipe de desenvolvimento faz a cada manhã para avaliar o trabalho do dia anterior e priorizar aquilo que será implementado no dia.
3.1.4. 4. Programação por Pares
3.1.4.1. Duas pessoas, com papéis distintos, para a execução de uma tarefas, com a toca constante das duplas.
3.1.5. 5. Desenvolvimento guiado pelos Testes
3.1.5.1. Os desenvolvedores escrevem testes para cada funcionalidade antes de implementá-los.
3.1.6. 6.Refatoração
3.1.6.1. Constantes melhorias sugeridas para o projeto do código sem alterar sua funcionalidade.
3.1.7. 7. Código Coletivo
3.1.7.1. Cada membro da equipe pode trabalhar em qualquer parte do sistema a qualquer hora do dia.
3.1.8. 8. Código Padronizado
3.1.8.1. A equipe estabelece padrões de implementações que devem ser seguidos por todos.
3.1.9. 9. Design Simples
3.1.9.1. Para ser ágil a equipe deve optar por um código que seja suficiente para atender as necessidades atuais do cliente.
3.1.10. 10.Ritmo Sustentável
3.1.10.1. Os desenvolvedores devem trabalhar apenas 8h por dia.
3.1.11. 11.Integração Contínua
3.1.11.1. A equipe integrarem seus códigos com o restante do sistema várias vezes ao dia.
3.1.12. 12.Releases Curtos
3.1.12.1. A equipe deve produzir um conjunto pequeno de funcionalidades (release) e colocar em produção rapidamente para que o cliente possa usar o mais cedo possível.