EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito de Software em Gestão Ágil
•Transferir como PPT, PDF•
0 gostou•483 visualizações
Fabiano Milani apresenta suas credenciais e experiência em gestão ágil de projetos de software. Ele discute os problemas causados quando clientes e fornecedores não compartilham as mesmas expectativas sobre requisitos e mudanças. A gestão ágil visa entregar valor ao cliente de forma incremental através de feedback contínuo e priorização dinâmica dos requisitos.
![Fabiano Milani, CSP [email_address] Aprenda, ensine e melhore os resultados com seu cliente : Requisitos de Software em Gestão Ágil](https://image.slidesharecdn.com/aprendaensinemelhoresresultadosclientes-100920131100-phpapp02/85/EDTED-Aprenda-ensine-e-melhores-os-resultados-com-seus-clientes-Requisito-de-Software-em-Gestao-Agil-1-320.jpg)
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Sobre mim @fabianomilani](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito de Software em Gestão Ágil
Semelhante a EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito de Software em Gestão Ágil (20)
EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito de Software em Gestão Ágil
- 1. Fabiano Milani, CSP [email_address] Aprenda, ensine e melhore os resultados com seu cliente : Requisitos de Software em Gestão Ágil
- 8. O Standish Group vem, há mais de uma década, realizando estudos em volta dos resultados dos projetos de software ao redor do mundo. O resultado destes estudos é um relatório batizado de Chaos Report; Chaos Report
- 11. Titanic (o filme) Orçamento inicial: US$ 200 mi Total gasto: US$ 400 mi Data da entrega: 1 ano depois do previsto Ganhador de 11 Oscars Receitas financeiras > US$ 1.8 bi
- 12. Orçamento inicial: US$ 200 mi Total gasto: US$ 400 mi Data da entrega: 1 ano depois do previsto Ganhador de 11 Oscars Receitas financeiras > US$ 1.8 bi Titanic (o filme) O projeto se daría como desafiado pelo CHAOS REPORT, apesar do seu sucesso financeiro.
- 13. Standish Group, 2002 Média de uso de funcionalidades
- 14. Estrutura de trabalho Analista de Negócio Arquitetos Designer Desenv. Teste Gerente de Projetos Cliente
- 17. A solução do cliente #TecnicaChicoChavier
- 20. A solução do fornecedor #SindromedoEstudante #SindromedeNostraDamos
- 21. O que tudo isto gera?
- 22. Quem mais perde? A EMPRESA
- 23. A verdade Gestão Ágil
- 24. Processos ágeis e Scrum
- 25. Fluxo do Scrum ScrumMaster Product Owner Time
- 27. A verdade Ferramentas de auxílio
- 28. Âncoras
- 29. Valores
- 30. Crença Limitante
- 31. Coaching
- 32. A verdade Visão
- 34. Visão Controle de Caixa Controle de Estoque Folha de Pagamento Ordens de Serviço Venda de Passagem Loja Virtual
- 35. A verdade Lista de desejos
- 36. Lista de Desejos Product Owner
- 38. Priorização O que tem MAIOR VALOR para seu cliente T écnicas de priorização Kano Theme Screening Priorization Poker
- 39. A verdade User Stories
- 40. User Stories
- 42. User Stories I N V E S T ndependente egociável aliosa stimável mall ( pequena ) estável Emissão do relatório de comissões por período Emissão do relatório de comissão por vendedor Um usu ário podera emitir somente os relatórios de seu departamento com o cuidado de não permitir que o mesmo emita mais de uma vez o relatório de controle de fechamento para não prejudicar o depto financeiro no fechamento das vendas diárias … bla bla bla Parametrizar emiss ão de relatório por usuário O software ira suportar no máximo 150 conexões simultaneas com o Banco de Dados 150 usuários podem fazer compras na loja virtual simultaneamente Integração com o SAP Integrar o módulo do CPG com o SAP No momento da compra o sistema deve validar o cartão de credito e seu limite Caso a operadora não autorize a compra, enviar e-mail informando ao usuário Emissão do relatório de comissão por per íodo e vendedor
- 43. User Stories Story-Writing Workshop
- 44. User Stories
- 45. User Stories Home Page Pesquisa Produto Comprar Produto Pagar Produto Cartão de Crédito Planos de Venda Divulgação de Produto Pessoa Física Pessoa Jur ídica
- 46. User Stories Quem ? O que ? Como um <perfil> eu posso / gostaria / devo <FUNCTION> Como um PALESTRANTE eu devo SER CLARO NAS MINHAS APRESENTAÇÕES
- 47. User Stories Por que ? Como um <perfil> eu posso / gostaria / devo <FUNCTION> para <VALOR AO NEGÓCIO> Como um PALESTRANTE eu devo SER CLARO NAS MINHAS APRESENTAÇÕES para que os congressistas me compreendam
- 48. User Stories Quem ? O que ? Por que ?
- 49. User Stories Como um Cliente eu posso pesquisar produtos para agilizar as minhas compras Como um Gerente de Contas eu devo oferecer Planos de Vendas para fidelizar meus clientes Como um Gerente Comercial eu devo dar opções de pagamento para facilitar a compra dos meus clientes Como um Cliente de Negócios eu posso pesquisar recursos de divulgação de produto para aumentar as minhas vendas.
- 52. Entregando o que é importante para o cliente Alta Prioridade Baixa Prioridade Cada Sprint implementa os requisitos de prioridade mais alta Cada novo requisito é priorizado e inserido no Product Backlog pelo Product Owner a qualquer momento Requisitos podem ser repriorizados pelo Product Owner a qualquer momento Requisitos podem ser removidos do Product Backlog pelo Product Owner a qualquer momento Copyright Scott Ambler, 2004
- 53. Entregando o que é importante para o cliente ROIx 2 + ROIx + ROI = 0 Ax 2 + Bx + C = 0
- 54. ??????????
- 55. Obrigado! [email_address] fabianomilani http://blog.adaptworks.com.br/ fabianomilani [email_address]
Notas do Editor
- ScrumMaster - Garantir o funcionamento do Scrum - Priorizar impedimentos e combate-los - Facilitador das cerimônias - Combater o comando-controle => Não distribui tarefas - Lider facilitador - Não é o responsável por montar um plano Time - auto-organizados - multi-disciplinares - comprometidos - responsáveis - comunicativos Product Owner - Definir a visão do produto - Gerenciar requisitos ( Elaboração, priorização, manutenção ) - Priorizar os requisitos de acordo com o seu valor de negócio para o cliente - Apresentar ao time os requisitos - Planejar as entregas de releases
- O Product Owner define a Visão do Produto. Esta Visão é o que representa sua necessidade, é o que deve ser satisfeito ao fim do projeto. - Para definir esta Visão o PO colhe informações junto a clientes, usuários final, time, gerentes, stakeholders, executivos, etc.;
- Uma visão é uma clara imagem que gera uma atração emocional entre pessoas e produto; O Product Owner é o responsável pela criação da visão; Ele compartilha essa visão com o time; - Ele refina essa visão com o time;
- Product Owner Backlog De acordo com o valor que representam para o cliente e negócio Existir por todo o ciclo de vida do projeto Mudanças e necessidades do cliente, mudanças estratégicas ou tecnológicas, novas idéias - Composto : funcionalidades, requisitos de desenvolvimento, exploração técnica, estudo, documentação, bugs, etc.
- - Caixa de bombom - Jogo de Futebol ou DR ? Cinuca ou mercado ? Fazer cabelo, pé e mão ou lavar a louça ? Kano : Theme Screening : Priorization Poker :
- - Descreve funcionalidades que deve fornecer valor para usuários ou cliente de um projeto de software
- Uma descrição da story para ser usada nas sessões de planejamento e mesmo como uma lembrança do desejo do cliente. Conversas sobre a Storie que servirão como flash sobre a mesma Testes que documentam os detalhes da Story e que podem ser usados para determinar qdo ela está completa.
- Independente : Podem gerar problemas no momento em que o time for estimar essas estórias, ambas provavelmente utilizam a mesma infra-estrutura da aplicação e com isso uma tera uma estimativa o que ira prejudicar o seu planejamento e desenvolvimento das sprints Negoci ável : Sem muito detalhes, para que assim possa haver uma negocição, debate, sobre aquela US com time e PO, uma US não é uma especificação de requisitos mas uma lembrança para uma conversa futura com P.O e Time, assim passa a impressão para o time que eles não precisam conversar sobre aquela US pq já tem tudo que o cliente precisas, ou até mesmo a idéia de um EPIC
- Participantes : desenvolvedores, usuários, cliente, product owner e qualquer pessoa que possa contribuir no processo de descoberta de stories Escrever quantidade de stories que conseguirem Nesse momento não nos preocupamos com priorização Brainstorming e prototipação de desenho
- Não significa que cada post-it desse gera uma Storie; Provavelmente a união de dois ou mais post-its gera um Storie Por exemplo Pagar Produto + Cartão de Crédito = User Storie => Como um cliente eu gostaria de poder escolher formas de pagamento para ver o que melhor se adapta a minha necessidade.
- - Muitos documentos de requisitos que possuem páginas e mais páginas não respondem estas 3 perguntas...daí o poder das User Stories.
- Expresssar detalhes discutidos entre cliente ( Product Owner e Especialistas de Negócio ) – Teste de aceitação Cliente quem escreve e antes da codificação Testes devem fazer parte do processo Automatização Fitnesse e Selenium Teste de engenharia para garantir a qualidade dos entregáveis
- - Notação (simbologia) utilizada por Bhaskara para a equação