Requisitos ageis paulofurtado_2014

1.217 visualizações

Publicada em

Apresentação usada para o Workshop de Requisitos Ágeis da Empresa AboutTI. Por Paulo Furtado.

Publicada em: Educação
0 comentários
4 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.217
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
38
Comentários
0
Gostaram
4
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Requisitos ageis paulofurtado_2014

  1. 1. About Thinking Innovation Workshop de Requisitos Ágeis Paulo Furtado 2014
  2. 2. Dinâmica (30 min) About Thinking Innovation
  3. 3. Onde tudo começou 100%   Média  de  uso  de  funcionalidades   de  sistemas   80%   7%   60%   Falhou   40%   Desafiado   13%   16%   Sucesso   2000   2002   2004   2007   2009   20%   0%   45%   19%   About Thinking Innovation
  4. 4. O Manifesto Ágil – Valores “Estamos descobrindo melhores maneiras de desenvolver software, fazendo software e ajudando outros a fazê-lo. Através deste trabalho passamos a valorizar: Indivíduos e interações Processos e ferramentas Software que funciona Documentação abrangente Colaboração do cliente Resposta à mudanças mais que Negociação de contrato Seguir um plano Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do lado esquerdo.” Fonte: http://www.agilemanifesto.org About Thinking Innovation
  5. 5. 12 princípios do Manifesto Ágil 1.  Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. 2.  Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas 3.  Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos 4.  Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto 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 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. 7.  Software funcional é a medida primária de progresso 8.  Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes 9.  Contínua atenção à excelência técnica e bom design, aumenta a agilidade 10.  Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. 11.  As melhores arquiteturas, requisitos e designs emergem de times autoorganizáveis. 12.  Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento. About Thinking Innovation
  6. 6. Antes de começar Conceitos Iniciais About Thinking Innovation
  7. 7. O que é um requisito? Segundo o dicionário: 1.  Coisa necessária e indispensável. 2.  Condição indispensável; exigência. 3.  Requerido; requisitado. Pergunta Tudo que um usuário/cliente nos pede é indispensável? About Thinking Innovation
  8. 8. O que é Análise de Requisitos? Análise ou levantamento de requisitos é a ação de identificar necessidades de usuários/clientes. About Thinking Innovation
  9. 9. ATENÇÃO!!! Análise ou levantamento de requisitos não é documentar e/ou especificar requisitos, mas identificar o que realmente são os requisitos. About Thinking Innovation
  10. 10. O que significa “ser ágil”? •  Segundo James Shore & Shane Warden “A resposta é mais complicada do que se pode pensar. O Desenvolvimento ágil não é um processo específico que pode ser seguido. Nenhuma equipe pratica o método Ágil.” “O desenvolvimento ágil é uma filosofia. É uma maneira de pensar sobre desenvolvimento de software. Isso pode ser visto no Manifesto Ágil.” About Thinking Innovation
  11. 11. 1º passo Foco no Usuário/Cliente About Thinking Innovation
  12. 12. Problema “Nós temos a tendência de NÃO tratar o cliente de software como uma pessoa que gasta dinheiro.” About Thinking Innovation
  13. 13. Problema pior… “O cliente, muitas vezes, também não percebe que está gastando dinheiro” About Thinking Innovation
  14. 14. O Cliente é responsável, mas como dizer isso a ele? R$ 500.000,00 Quinhentos mil reais About Thinking Innovation
  15. 15. Lição #1 Um Team Guider valoriza o dinheiro gasto para fazer um software About Thinking Innovation
  16. 16. O valor dos requisitos é RELATIVO Contexto é importante About Thinking Innovation
  17. 17. Lição #2 Um Team Guider o conhece o contexto do produto About Thinking Innovation
  18. 18. O Requisito fácil e simples pode ser ESSENCIAL. About Thinking Innovation
  19. 19. Lição #3 Um Team Guider sabe a diferença entre um par de brincos e uma escova de dentes About Thinking Innovation
  20. 20. Quality is personal! Jim  Highsmith   Agile  Consultant   About Thinking Innovation
  21. 21. Lição #4 Um Team Guider define, para o seu time, o conceito de qualidade About Thinking Innovation
  22. 22. Escolha um cenário... O Time O PO + + ? = ? = About Thinking Innovation
  23. 23. Lição #5 Um Team Guider sabe onde quer chegar About Thinking Innovation
  24. 24. Delegando poderes About Thinking Innovation
  25. 25. Lição #6 Um Team Guider deve ter poderes de decisão e isso deve ficar claro para TODOS About Thinking Innovation
  26. 26. O Cliente é tratado como Cliente! About Thinking Innovation
  27. 27. Lição #7 Um Team Guider faz TEST DRIVE o tempo inteiro. About Thinking Innovation
  28. 28. Pergunta: E qual a diferença entre um Team Guider e um Owner ? About Thinking Innovation
  29. 29. Resposta: Um Product Owner banca o produto e, eventualmente, guia o time Um Team Guider guia o time e, eventualmente, banca o produto. About Thinking Innovation
  30. 30. Administrando Expectativas Fonte: Software Requirement 3 (Karl Wiegers, Joy Beatty) About Thinking Innovation
  31. 31. Interseção de Responsabilidades Pessoas de Negócio Equipe de Desenvolv. Facilitadores About Thinking Innovation
  32. 32. Definindo uma visão About Thinking Innovation
  33. 33. Visão de Produto •  Define as fronteiras do projeto deixando bem claro o objetivo macro do produto a ser desenvolvido; •  Tem o objetivo de estabelecer um acordo inicial entre os participantes do projeto sobre as funcionalidades que devem ser implementadas; •  Ela ajuda a guiar as mudanças que vão ocorrer no projeto para identificar se existem grandes distorções em relação ao que foi acordado inicialmente; About Thinking Innovation
  34. 34. About Thinking Innovation
  35. 35. About Thinking Innovation
  36. 36. Business Model Canvas •  Usado para realizar planejamento estratégico e melhorar modelos de negócio (novos ou não); •  Mapa que contém 9 (nove) blocos para um modelo de negócio •  Criado por Alexander Osterwalder Um Business Model é um mapa dos principais itens que constituem uma empresa. O Mapa é um resumo dos pontos chave de um plano de negócio. About Thinking Innovation
  37. 37. 8 Principais Parceiros Alianças de negócios que contemplam os outros aspectos do modelo de negócio 7 4 2 Relac. com Cliente Principais Atividades Atividades necessárias para executar o Modelo de Negócio 6 Principais Recursos Recursos necessários para criar valor para o cliente Proposição de Valor Proposições a serem atendidas. Que necessidades, do público-alvo a que se destina meu negócio, precisam ser atendidas? 9 Ligação entre a empresa e seus clientes 3 Canais Meio pelo qual uma empresa fornece produtos e serviços Estrutura de Custos Consequência monetária dos meios utilizados no modelo de negócio. (Despesas) 1 Segmentos de Clientes O Públicoalvo para os produtos e serviços de uma empresa Fluxos de Receita 5 A forma como a empresa ganha dinheiro através de uma variedade de fluxos de receita. About Thinking Innovation
  38. 38. User Stories Hi Paulo-I'm glad you've enjoyed those books. Many others teach classes based on those materials and doing so is perfectly fine. Please note that I do own the copyright on the titles of those courses so you'll need to call your classes something slightly different. Thank you for including references to my work. Good luck with your classes. Mike Cohn Regards, Mike Authorized About Thinking Innovation
  39. 39. Software: O Filme About Thinking Innovation
  40. 40. ard onversation onfirmation About Thinking Innovation
  41. 41. Requisitos Abstratos e Concretos Abstrato Concreto Verbo Substantivo About Thinking Innovation
  42. 42. Estrutura de uma User Story Como um <PAPEL> eu posso/gostaria/devo <FUNÇÃO> para <VALOR DE NEGÓCIO> About Thinking Innovation
  43. 43. Pagamento via Cartão de Crédito Como um cliente, Eu gostaria de pagar usando meu cartão de crédito para poder parcelar minhas compras. Observações: - Aceitar Master Card, Visa e Amex Restrições: - Parcelar, no máximo, em 10x - Cliente não pode estar no SPC About Thinking Innovation
  44. 44. Estórias devem ser... I ndepent N egociable V aluable E stimable S mall T estable Sempre que possível, preocupe-se em evitar criação de dependências entre as estórias Estórias são negociáveis. Elas não são contratos requisitos que um software deve implementar. As estórias devem ter um valor visível para quem está comprando/pagando pelo produto Os desenvolvedores devem ter condições suficientes para estimar uma estória Uma estória muito grande é difícil de estimar complexa de desenvolver As estórias devem ser testáveis About Thinking Innovation
  45. 45. I ndepent •  Dependência entre estórias levam a problemas na priorização e na estimativa; •  Por exemplo: O cliente selecionou uma estória de alta prioridade que tem uma outra estória de baixa prioridade como dependente; •  Outros exemplo: –  Suponha que você tenha uma loja virtual e possui as seguintes estórias no seu backlog: 1.  O cliente pode pagar usando cartão VISA; 2.  O cliente pode pagar usando cartão MasterCard; 3.  O cliente pode pagar usando cartão America Express; –  Os desenvolvedores estimaram que a implementação do primeiro cartão demoraria 3 dias; About Thinking Innovation
  46. 46. N egociable •  Cartões de estórias são descrições pequenas da funcionalidade, bem como alguns detalhes que precisam ser negociados em conversa entre desenvolvedores e cliente; •  Exemplo: O cliente pode efetuar pagamento com cartão de crédito Nota: Aceitar VISA, MarterCard e America Express About Thinking Innovation
  47. 47. V aluable •  Tenha em mente a diferença entre usuário (alguém que usa o software) e comprador (alguém que compra o software) •  Muitos projetos possuem estórias que não são valiosas para os usuários; –  Ex: Toda a informação de configuração deve ser lida de um servidor central; •  Evite estórias que aparentam ter valor apenas para os desenvolvedores: Todos os erros e controle de log devem ser tratados por um conjunto comum de classes Todos os erros devem ser apresentados aos usuários de uma maneira consistente About Thinking Innovation
  48. 48. E stimable •  É importante que os desenvolvedores sintam-se aptos a estimar a estória (pelo menos um “chute”) •  Existem pelo menos 3 razões que levam uma estória a não ser estimada –  O time não conhece o domínio de negócio; •  Uma conversa é necessária com o cliente para sanar dúvidas. Vale salientar que não é preciso entrar em detalhes de implementação, mas os desenvolvedores precisam ter uma ideia do que vão fazer; –  O time não conhece a tecnologia a ser utilizada; •  Tarefas “spike” podem ser criadas para pesquisar a tecnologia; –  A estória é muito grande para ser estimada; •  Neste caso, é importante que a estória seja “quebrada” em outras estórias até que os desenvolvedores se sintam à vontade para dar um chute; About Thinking Innovation
  49. 49. S mall •  O tamanho da estória é muito importante, pois as estórias podem atrapalhar um planejamento caso sejam grande ou pequenas demais; •  Um grande indício para saber se a estória está em um tamanho razoável é observar o time, suas capacidades e a tecnologia em uso; •  Estórias grandes são muito difíceis de serem priorizadas; •  Uma dica é definir fronteiras nas estivativas. Por exemplo: Se você usa Planning Poker, pode definir que uma estória ½ é muito pequena e uma estória acima de 13 é muito grande; ½ - 1 – 2 – 3 – 5 – 8 – 13 – 21 – 34 ... About Thinking Innovation
  50. 50. T estable •  Estórias devem ser escritas de forma que possam ser testadas; •  Se uma estória não pode ser testada, como os desenvolvedores podem saber quando terminaram? •  É comum estórias que implementam requisitos “não funcionais” sejam escritas de forma que não podem ser testadas: –  Ex: “O usuário não deve esperar muito para a tela de cadastro aparecer” •  O melhor seria escrevê-la assim: –  “A tela de cadastro deve aparecer em menos de 2 segundos em 95% dos casos” About Thinking Innovation
  51. 51. About Thinking Innovation
  52. 52. TEMA Gerenciamento de Emails Gerenciamento de Contatos Épico Épico Estórias com uma estimativa (Story Points) alta Ex: Estórias com um tamanho 21, 34, ...
  53. 53. Épico vs Tema História História Épico História História História História História História História Tema História História História História História História História História About Thinking Innovation
  54. 54. Mapeamento de estórias About Thinking Innovation
  55. 55. About Thinking Innovation Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
  56. 56. BENEFÍCIOS OU SERVIÇOS OFERECIDOS BACKBONE FUNCIONALIDADES APLICAÇÃO ESQUELETO DA DO SOFTWARE DETALHAMENTO DAS FUNCIONALIDADES About Thinking Innovation Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
  57. 57. O MAPA •  Backbone: –  Lista de atividades essenciais que dão suporte à aplicação –  Benefícios do produto •  Esqueleto –  É o software em construção que atende a um número mínimo de tarefas necessárias para abranger a todo o ciclo de atividades do usuário About Thinking Innovation
  58. 58. TEMPO IMPORTÂNCIA MAIS IMPORTANTES OU ESSENCIAIS MENOS IMPORTANTES OU DESCARTÁVEIS About Thinking Innovation Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
  59. 59. Business Value, Story Point e ROI About Thinking Innovation
  60. 60. # Item BV %BV Size 1 F1 1000 20% 13 76,92 7% 2 F2 500 10% 8 62,50 6% 3 F3 600 12% 5 4 F4 400 8% 21 5 F5 800 16% 3 266,67 24% 6 F6 500 10% 5 100,00 7 F7 900 18% 5 180,00 16% 8 F8 300 6% 1 300,00 27% TOTAL 5000 61 ROI %ROI 120,00 11% 19,05 2% 9% About Thinking Innovation
  61. 61. Linha de corte do Backlog A (13) B (8) C (5) D (21) E (3) F (5) G (5) H (1) I (3) F (34) F (21) F (13) About Thinking Innovation
  62. 62. Personas About Thinking Innovation
  63. 63. Atores Cadastrar   Clientes   Ator Iteração Caso de Uso About Thinking Innovation
  64. 64. Personas —  A criação de personas é uma técnica utilizada para especificar usuários com um determinado perfil; —  Esta técnicas personaliza o software, fazendo com que pessoas de perfis diferentes fiquem satisfeitas com o produto; About Thinking Innovation
  65. 65. Exemplo de Persona Teovaldo é professor de História com mais de 20 anos de experiência. Sempre fez todas as suas atividades de forma manual e, apesar de não gostar de computadores, fica fascinado com a possibilidade de ganhar tempo com tarefas automatizadas por ferramentas de software. About Thinking Innovation
  66. 66. Contato Paulo Furtado paulofurtado.ti@gmail.com @paulofurtadoti www.aboutti.com.br About Thinking Innovation
  67. 67. OBRIGADO! About Thinking Innovation

×