1. A filosofia ágil de desenvolvimento
1.1. Princípios ágeis
1.1.1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
1.1.2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adapta a mudanças, para que o cliente possa tirar vantagens competitivas.
1.1.3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
1.1.4. Pessoas relacionadas á negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o projeto.
1.1.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.
1.1.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.
1.1.7. Software funcional é a medida primária de progresso.
1.1.8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
1.1.9. Contínua atenção á excelência técnica e bom design, aumenta a agilidade.
1.1.10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
1.1.11. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
1.1.12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
1.2. MVP
1.2.1. Produto Mínimo Viável
1.2.2. Participa das primeiras fases do projeto. Para lançar um novo produto ou serviço com pouco custo.
1.3. Feedback
1.3.1. Quando o cliente aprende com o produto reavalia as suas necessidades. É gerado um feedback para a equipe.
1.3.2. É fundamental, permite o cliente conduzir o projeto diariamente.
1.3.3. Garante que a equipe direcione as suas atenções para aquilo que irá gerar mais valor.
1.4. Manifesto ágil
1.4.1. Pessoas
1.4.2. Valor
1.4.3. Confiança
1.4.4. Complexidade
1.5. Métodos Ágeis
1.5.1. Envolvimento do cliente
1.5.1.1. Clientes devem ser profundamente envolvidos no processo de desenvolvimento. Seu papel é fornecer e priorizar novos requisitos do sistema e avaliar as iterações ou sistema.
1.5.2. Entrega incremental
1.5.2.1. O software é desenvolvido em incrementos e o cliente especifica os requisitos a serem incluídos em cada incremento.
1.5.3. Pessoa, não processo
1.5.3.1. As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas. Os membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos.
1.5.4. Aceite as mudanças
1.5.4.1. Projete o sistema para acomodar mudanças.
1.5.5. Mantenha a simplicidade
1.5.5.1. Evite complexidade do sistema.
1.6. Princípios ágeis
1.6.1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
1.6.2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adapta a mudanças, para que o cliente possa tirar vantagens competitivas.
1.6.3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
1.6.4. Pessoas relacionadas á negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o projeto.
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.
1.6.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.
1.6.7. Software funcional é a medida primária de progresso.
1.6.8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
1.6.9. Contínua atenção á excelência técnica e bom design, aumenta a agilidade.
1.6.10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
1.6.11. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
1.6.12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
2. eXtremme Programming
2.1. Práticas do XP
2.1.1. Possui 12 práticas
2.1.1.1. Jogo do planejamento
2.1.1.1.1. Cartões de histórias dos usuários
2.1.1.2. Cliente Presente
2.1.1.2.1. O cliente deve esclarecer dúvidas sobre os requisitos do sistema, ajudar na confecção dos casos de testes funcionais.
2.1.1.2.2. Deve ser incluído alguém da parte do cliente ou que o represente junto a equipe.
2.1.1.3. Stand Up Meeting
2.1.1.3.1. Reunião rápida que a equipe de desenvolvimento faz a cada manhã e prioriza aquilo que será implementado no dia.
2.1.1.3.2. Três perguntas devem ser respondidas por cada desenvolvedor: O que foi feito no dia anterior? O que vai ser feito hoje? Tem algo atrapalhando ou necessário para o trabalho a ser realizado?
2.1.1.3.3. Os problemas relatados devem ser tratados fora da reunião!
2.1.1.4. Programação por pares
2.1.1.4.1. Todo código desenvolvido em XP é escrito por um par de desenvolvedores, que possuem papéis distintos, sentados lado-a-lado e olhando para o computador.
2.1.1.4.2. As duplas devem ser constantemente trocadas, assim como os papéis e as funcionalidades implementadas.
2.1.1.4.3. Polêmicas: Por que usar 2 pessoas para fazer o trabalho de 1? Usando 2 pessoas dobrará o custo de desenvolvimento e não tenho mesas suficientes...
2.1.1.4.4. Argumentos: Menos erros, velocidade na codificação, transferência de conhecimento, conhecimento global do sistema, mais produtividade(sem e-mail, e etc..) e promove maior integração entre a equipe.
2.1.1.5. Desenvolvimento guiado por testes
2.1.1.5.1. Os desenvolvedores escrevem testes para cada funcionalidade antes de implementá-las: Melhoram o entendimento sobre as necessidades do cliente; Projetam melhor as interfaces externas dos métodos e classes e limitam até onde codificar cada funcionalidade.
2.1.1.6. Refatoração
2.1.1.6.1. São melhorias sugeridas para o projeto do código sem alterar sua funcionalidade. Minimizam problemas que poderiam advir da prática de projeto simples visto que se mudanças devem ser incorporadas e o código é bem estruturado, então isso não será um problema.
2.1.1.7. Código Coletivo
2.1.1.7.1. Evita "ilhas de conhecimento": Quando só uma pessoa conhece uma solução, pode ser um gargalho no desenvolvimento.
2.1.1.8. Código Padronizado
2.1.1.8.1. A equipe estabelece padrões de implementação que devem ser seguidos por todos.
2.1.1.9. Design Simples
2.1.1.9.1. O código deve ser suficiente para atender as necessiddades atuais do cliente.
2.1.1.10. Ritmo Sustentável
2.1.1.10.1. Os desenvolvedores devem trabalhar apenas 8hrs por dia.
2.1.1.10.2. Horas extras devem ser evitadas.
2.1.1.10.3. Isso permiti que os desenvolvedores se mantenham atentos, criativos e dispostos a solucionar problemas.
2.1.1.11. Integração Contínua
2.1.1.11.1. Consiste da equipe integrarem seus códigos com o restante do sistema várias vezes ao dia.
2.1.1.12. Releases Curtos
2.1.1.12.1. A equipe deve produzir um conjunto pequeno de funcionalidades.
2.1.1.12.2. Colocar a release em produção rapidamente para que o cliente possa fazer uso das funcionalidades o mais cedo possível.
2.2. O XP é um método que tem o mérito de passar as pessoas um outro ponto de vista e forma de desenvolver software.
3. Try MeisterTask!
4. SCRUM
4.1. Framework SCRUM
4.1.1. 3 Papéis
4.1.2. 3 Artefatos
4.1.3. 4 Cerimônias
4.2. Time
4.2.1. A equipe de desenvolvimento compõe esse time. Não possui apenas analistas, programadores e designers. Mas todos interagem para desenvolver o produto.
4.2.2. São recomendadas equipe de 5 a 10 pessoas.
4.2.3. Velocidade do time
4.2.3.1. É a quantidade de pontos que um time consegue entregar durante uma Sprint.
4.3. Product Owner
4.3.1. Seu papel é predominante nas metodologias ágeis. Toma todas as decisões sobre o negócio (o que vai ser implementado, o que vai ficar fora...)
4.4. Scrum Master
4.4.1. Garante que o processo Scrum seja seguido!
4.4.2. Soft Skills: Facilitador, motivador, conciliador, bom ouvinte(ouve as ideias, sem interrupção e sem pré-julgamento) e possui iniciativa(vontade de fazer o que é preciso).
4.5. Backlog do produto
4.5.1. As funcionalidades ou características a serem implementadas ou produzidas em cada projeto (requisitos, casos de uso ou histórias do usuário) são mantidas em uma lista chamada Backlog do produto.
4.5.2. Cada funcionalidade é classificada genericamente como um item de backlog.
4.6. Sprint
4.6.1. Planejamento da Sprint
4.6.1.1. A equipe se compromete a desenvolver as tarefas e o Product Owner se compromete a não trazer novas tarefas durante o mesmo Sprint.
4.6.1.2. Se novas tarefas ou requisitos forem descobertas, serão abordadas em Sprints posteriores.
4.6.2. É um ciclo de desenvolvimento de poucas semanas de duração sobre o qual se estrutura o Scrum.
4.6.3. Dura de 2 a 4 semanas.
4.6.4. No inicio de cada Sprint é feito uma reunião de planejamento da Sprint, no qual a equipe prioriza os itens de backlog de produtos a serem implementados, e transfere estes elementos do backlog do produto para o backlog da sprint, implementando no ciclo que se inicia.
4.7. Time Box
4.7.1. É um aplicado as reuniões e as Sprints.
4.7.2. É utilizado para ressaltar a importância que existe um tempo limitado para executar algum tipo de trabalho.
4.8. Reunião diária
4.8.1. É feita diariamente para avaliar o trabalho do dia anterior e priorizar aquilo que serå implementado no dia.
4.9. Trabalho em pares
4.9.1. Um pilota o computador e a outra acompanha e verifica o que está sendo feito.
4.9.2. Trabalhando em conjunto para executar uma tarefa no computador.
4.9.3. As duplas devem ser trocadas constantemente.
4.10. Revisão da Sprint
4.10.1. Na reunião de revisão, ocorre a demonstração e avaliação do produto desenvolvido na Sprint pelo Product Owner.
4.10.2. É verificado o que foi feito e, a partir daí, vai para a próxima Sprint.
4.10.3. Itens reprovados
4.10.3.1. Se algum item for reprovado pelo Product Owner, mesmo que parte dele esteja entregável, todo oitem deve voltar ao Backlog de Produto e nenhum ponto será considerado na velocidade do time.
4.10.4. Itens inacabados
4.10.4.1. Se ao final da Sprint, ainda possuir itens inacabados, mesmo que sejam por muito pouco, a Sprint deve ser finalizada e nunca estendida por mais 1 ou 2 dias para que o item seja terminado.
4.10.5. Realimentação
4.10.5.1. Novas histórias de usuários podem surgir durante a execução de uma iteração e serão incorporadas no projeto.
4.11. Revisão da Sprint
4.11.1. A reunião de retrospectiva da Sprint tem como objetivo avaliar a equipe e os processos (impedimentos, problemas, dificuldades, ideias novas e etc...)