Processo_de_Desenvolvimento.pdf

Transcript

1. Resumindo Metodologias Ágil e tradicional
2. Resumindo Gerenciamento de projetos segundo PMI
3. O que é Projeto? Conjunto de atividades temporárias, realizadas em grupo, destinadas a produzir um produto, serviço ou resultado únicos.
4. Quais suas características? • Temporário • Exclusivo • Incerteza
5. Projeto x Produção contínua Projeto • Temporário • Exclusivo • Grau de Incerteza Produção Contínua • Continuidade • Repetitivo • Zero de Incerteza
6. Quais são os Pilares de um projeto? • Escopo • Tempo • Custo
7. O que é PMI? O PMI é a maior associação sem fins lucrativos do mundo para profissionais de gerenciamento de projetos, com mais de meio milhão de associados e de Profissionais Certificados em 185 países.
9. o que é PMBoK? No PMBoK Guide® 3º Edition (2004), a partir de agora, apenas PMBoK,são abordados quarenta e quatro processos divididos nas nove áreas de conhecimentos, formando um fluxo contínuo de processos.
11. Resumindo Gerenciamento de projetos Ágeis usando Scrum
12. O tal do Manifesto
13. Itens • Os indivíduos e suas interações acima de procedimentos e ferramentas; • O funcionamento do software acima de documentação abrangente; • A colaboração com o cliente acima da negociação e contrato; • Adaptação a mudanças é mais importante do que seguir o plano inicial. http://agilemanifesto.org/
14. Princípios • Garantir a satisfação do cliente, entregando rápida e continuamente software funcional; • Até mesmo mudanças tardias de escopo no projeto são bem-vindas. • Software funcional é entregue frequentemente (semanal ou mensal - o menor intervalo possível); • Cooperação constante entre as pessoas que entendem do 'negócio' e os desenvolvedores; • Projetos surgem por meio de indivíduos motivados, devendo existir uma relação de confiança. • A melhor forma de transmissão de informação entre desenvolvedores é através da conversa 'cara a cara' http://agilemanifesto.org/
15. • Software funcional é a principal medida de progresso do projeto; • Novos recursos de software devem ser entregues constantemente. Clientes e desenvolvedores devem manter um ritmo até a conclusão do projeto. • Design do software deve prezar pela excelência técnica; • Simplicidade; • As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. • Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento. Princípios http://agilemanifesto.org/
16. O tal do SCRUM
17. Um processo para construir software incrementalmente em ambientes complexos, onde os requisitos não são claros ou mudam com muita freqüência O que é?
18. Semelhanças Princípios semelhantes aos de XP (Extreme Programming): • Equipes pequenas • Requisitos pouco estáveis ou desconhecidos • Iterações curtas para promover visibilidade para o desenvolvimento
19. Ciclo de Vida Scrum divide o desenvolvimento em: • Sprints de 30 dias. • Equipes pequenas, de até 7 pessoas, são formadas por: ◦ projetistas ◦ programadores ◦ engenheiros ◦ gerentes de qualidade.
20. Ciclo de vida ◦ Estas equipes trabalham em cima de funcionalidade (os requisitos, em outras palavras) definidas no início de cada Sprint. A equipe toda é responsável pelo desenvolvimento desta funcionalidade
21. Ciclo de vida Daily Meeting Todo dia, é feita uma reunião de 15 minutos onde o time expõe: • O que foi feito ontem • O que será feito hoje • Levantar os fatores de impedimento • Se a tarefa que comecei ontem conseguirei terminar hoje
22. Fases
23. Product Backlog Roadmap Sabemos que temos que fazer mas não sabemos quando
24. Sprint Planning • Planejamento do que vai entrar na sprint. • Conversa para fragmentar as User Stories • Refinamento do Product Backlog
25. Sprint Backlog Conjunto de Stories e seus critério de aceitação
26. Stories User Story ou “história de usuário” é uma descrição concisa de uma necessidade do usuário do produto (ou seja, de um “requisito”) sob o ponto de vista desse usuário. A User Story busca descrever essa necessidade de uma forma simples e leve
27. Stories A User Story possui três aspectos críticos, chamados de “os três C’s”: • Cartão • Conversas • Confirmação.
28. (C1) Cartão Os padrões mais utilizados para se escrever o Cartão da User Story estabelece três parâmetros da necessidade do usuário: “QUEM”, “O QUÊ” e “POR QUÊ”.
29. Forma ERRADA “Eu, enquanto Comprador de Livros, quero buscar livros por nome para escolher o que vou comprar.” buscar livros por nome é um problema ou uma solução?
30. Forma MAIS INDICADA “Eu, enquanto Comprador de Livros, quero encontrar um livro cujo nome sei para escolher e comprá-lo.”
31. Expressar a User Story a partir do problema e não de uma solução
32. (C2) Conversa São conversas sobre a User Story, por onde a solução de negócios e os detalhes dessa solução são discutidos, negociados, definidos e então documentados na forma de Critérios e Testes de Aceitação.
33. (C3) Confirmação São critérios e testes deles derivados que documentam os detalhes da User Story
34. Ou seja, são regras que estabelecem como a funcionalidade deve se comportar uma vez implementada.
35. Esses critérios são chamados de Critérios de Aceitação
36. Cada User Story possui seu próprio conjunto de Critérios e Testes de Aceitação.
37. Características desse tal de critério de aceitação? • Critérios de Aceitação são expressos por enunciados pequenos e de fácil entendimento. • São utilizados para determinar quando a funcionalidade produzida pelo Time de Desenvolvimento está completa • A partir desses critérios, o Time de Desenvolvimento gera os Testes Unitários Automatizados .
38. Os Critérios de Aceitação são negociados e definidos antes do desenvolvimento da funcionalidade, geralmente em sessões de Refinamento do Product Backlog.
39. Um exemplo
40. User Story “Eu, enquanto Comprador de Livros, quero utilizar meu cartão de crédito no pagamento dos livros escolhidos, para ter praticidade e segurança no pagamento.”
41. Critérios Critério #1: somente podemos aceitar cartões de crédito com bandeiras com que temos convênio. Critério #2: somente podemos aceitar cartões de crédito com data de expiração no futuro.
42. Testes Unitário Critério #1: somente podemos aceitar cartões de crédito com bandeiras com que temos convênio. • Comprador de Livros utiliza cartão de crédito Visa ◦ Aceitou = correto. ◦ Recusou = errado, deve ser corrigido! • Comprador de Livros utiliza cartão de crédito MasterCard ◦ Aceitou = correto. ◦ Recusou = errado, deve ser corrigido! • Comprador de Livros utiliza cartão de crédito Amex ◦ Recusou = correto. ◦ Aceitou = errado, deve ser corrigido!
43. Testes Unitário Critério #2: somente podemos aceitar cartões de crédito com data de expiração no futuro. • Comprador de Livros utiliza cartão de crédito com expiração em 01/01/2020 ◦ Aceitou = correto. ◦ Recusou = errado, deve ser corrigido! • Comprador de Livros utilizou cartão de crédito com expiração em 01/01/2000 ◦ Recusou = correto. ◦ Aceitou = errado, deve ser corrigido!
44. Outras metodologias • Crystal • Feature Driven Development • Adaptive Software Development