consultar o preço de um produto para que eu possa informar ao cliente; Como VENDEDOR, devo selecionar uma forma de pagamento para que eu possa prosseguir com uma venda;
• Responsável por maximizar o valor do produto e do DevTeam; • Responsável por gerenciar o Product Backlog*; • Está ligado à visão de negócio do projeto; • Representa o interesse dos investidores do desenvolvimento do produto. • Responsável por modelar, programar, testar e validar as funcionalidades desenvolvidas; • Transformar o Product Backlog em um produto funcional; • Faz a distribuição de tarefas entre si, sempre de acordo com suas competências; • Desenvolvem as versões incrementais do produto “Pronto” que são entregues ao final de cada Sprint. Product Owner DevTeam
• Ordenar os itens do Product Backlog de acordo com a visão de prioridade do cliente; • Garantir a transparência do Product Backlog; além de: Sobre Gerenciar o Product Backlog* ➔ Aceitar ou rejeitar os resultados dos trabalhos; ➔ Decidir o momento de liberação do produto ou de suas versões funcionais para o cliente.
de "testing/QA" no board não garante qualidade; • O máximo de cobertura de testes de UI, por si só também não garante a qualidade (Assim como apenas testes unitários); • Ter um QA no time atuando apenas no final do processo, por melhor que execute seu trabalho, ainda não garante qualidade. Código Código Código Código Código Código Código Código Teste Feedback dos Testes no Projeto de Classes Feedback dos Testes no Projeto de Classes Desenvolvimento Guiado por Testes Abordagem Tradicional
de executar testes, escrever cenários ou automatizar. O QA é responsável por encontrar mecanismos que viabilizem a estabilização da qualidade como cultura; • Auxilia a promover a melhoria contínua dos processos utilizados ao longo do ciclo de desenvolvimento. To Do | WIP | Block | Test | Done Quality Assurance >> >> >> << <<
o PO e o UX com a visão macro do negócio; • Validar artefatos (requisitos funcionais e não funcionais, layout, teste de usabilidade, entre outros); • Identificar cenários não cobertos pelos critérios de aceite; • Auxiliar o PO a categorizar cenários para automação. Concepção • Auxiliar o time a criar e executar testes unitários, integrados e de UI; • Estabelecer quality gates das pipelines de CI; • Validar as entregas junto a área de negócios; • Agendar testes de regressão no CI. Desenvolvimento
ao time, analisar as métricas geradas em produção, e criar um plano de melhoria no processo para garantir que dado um incidente, o mesmo seja detectado antes de realizar o deploy. Produção
e detalhar percepções de risco, esforço e valor de negócio • Refinamento: Auxiliar em decompor itens do backlog até se tornar itens preparados, com visão crítica em qualidade. • Sprint Planning: Estimar o esforço para cada tarefa, com foco em testes. • Sprint: Automatizar fluxos de testes, visando o atendimento dos critérios de aceite da área de negócios. • Daily: Discutir sobre os impedimentos com os desenvolvedores e acompanhar o desenvolvimento das tarefas. • Review: Inspeção e adaptação do produto visando a qualidade da entrega. • Retrospectiva: Colaborar com a inspeção e adaptação do processo.
base na comunicação entre a área de negócios, os desenvolvedores e testadores; • Usa os testes como ferramenta de análise de requisitos; • O teste de aceitação está voltado ao ponto de vista do usuário, uma visão externa ao sistema. ATDD - Desenvolvimento Orientado a Testes de Aceitação
Revisar ATDD Debater os Requisitos Refinar os Testes Desenvolver o Código com TDD Apresentar os Resultados dos Testes • Prática colaborativa que visa inserir o time na construção dos requisitos da aplicação baseando-se em testes de aceitação.
da Sprint. "Acordo de trabalho" entre o DevTeam e o PO, aplicado a todas as Histórias de Usuário. • A intenção é de que os itens do Product Backlog não cheguem para a reunião de planejamento com granularidade ruim.
Somente aceitaremos um item para o Sprint Backlog se ele estiver: • Compreendido por todos e alinhado entre todos; • Estimado; • Pequeno o suficiente: Estimativa não maior que X story points; • Com critérios de aceitação definidos; • Possuir testes automatizável.
> Escrito como histórias de usuário - INVEST > Possui teste de aceitação automatizável > Análise da tarefa realizada com a área de negócios > DevTeam e PO na mesma página das histórias > Dimensionamento das histórias de usuário feito em pontos > Não restam perguntas pendentes que impeçam a equipe de atuar I N V E S T Independente - Negociável - Valiosa - Estimável - Small - Testável
docarmo
vtryo
whywaita
shinya337
nitya
i35_267
hr01
bengo4com
kou_kita
shift_evolve
hiroramos4
kubell_hr
muit
brad_frost
malarkey
pauljervisheath
tanoku
marcelosomers
stephaniewalter
addyosmani
sugarenia
davidbonilla
maggiecrowley
keavy
shlominoach
