O documento discute o Product Backlog no Scrum, incluindo sua criação e manutenção, características-chave, requisitos funcionais e não funcionais, critérios para inclusão no backlog, e priorização de itens.
Treinamento de Scrum que aplico em empresas que desejam adotar métodos ágeis no desenvolvimento de software. Mais informações em http://www.luiztools.com.br
As três frases resumem os principais padrões para quebra de histórias: 1) Quebra histórias com múltiplos itens ou fluxos de trabalho em histórias individuais; 2) Identifica passos específicos em um fluxo de trabalho e cria histórias para cada um; 3) Similar ao padrão anterior, histórias representam caminhos felizes e alternativos de interação do usuário.
Scrum - As Regras do Jogo segundo o Guia do ScrumAndré Borgonovo
Este documento resume os principais conceitos e regras do framework Scrum de acordo com o Guia do Scrum. Ele define Scrum, seus pilares, papéis, eventos e artefatos. Destaca que Scrum é leve, simples, mas difícil de dominar e deve ser aplicado em sua totalidade para obter resultados.
[Product Starter] Fábio Aguiar - Lean Inception e Product Backlog BuildingProduct Camp Brasil
O documento descreve o processo de Lean Inception e Product Backlog Building (PBB) para o desenvolvimento de produtos de forma ágil. O PBB é apresentado como o passo seguinte após a Lean Inception para efetivamente identificar funcionalidades do produto com base nos usuários e seus objetivos. O documento fornece detalhes sobre como conduzir workshops de PBB utilizando ferramentas como Personas, Jornadas do Usuário e o Canvas PBB.
O documento apresenta os princípios ágeis de desenvolvimento de software, como o Manifesto Ágil e Scrum. Inclui os papéis de Scrum e exemplos de como aplicar conceitos como fluxo de valor, melhoria contínua e eliminação de desperdícios nas empresas. O objetivo é introduzir estas técnicas para tornar processos e times mais ágeis e eficientes.
Como usar o Learning Canvas para descobrir Features para o Product BacklogFábio Aguiar
O Learning Canvas é uma ferramenta para a promoção da aprendizagem emergente. Foi criada com o propósito de organizar ideias e experiências sobre um tema problematizado durante uma discussão facilitada. Nesta palestra mostro como podemos aplica-lo para descobrir features para o backlog do produto com base na problematização do cliente.
Lean inception: como alinhar pessoas e construir o produto certoPaulo Caroli
Lean Inception é a combinação eficaz do Design Thinking e do Lean StartUp para decidir o Produto Mínimo Viável, em Inglês Minimum Viable Product (MVP). É um workshop dividido em várias etapas e atividades que irão direcionar a equipe na construção do produto ideal. A construção de qualquer projeto sempre começa com uma Lean Inception.
O documento fornece uma introdução ao desenvolvimento ágil e Scrum. Resume os principais pontos da seguinte maneira:
1) Explica como o desenvolvimento ágil surgiu da necessidade de melhorar a forma de desenvolvimento de software com foco no cliente.
2) Apresenta os princípios e valores ágeis como entrega contínua de valor, aceitação de mudanças, entregas frequentes e colaboração entre times.
3) Descreve os papéis, eventos e artefatos do framework Scrum como Product Owner, Dev
Treinamento de Scrum que aplico em empresas que desejam adotar métodos ágeis no desenvolvimento de software. Mais informações em http://www.luiztools.com.br
As três frases resumem os principais padrões para quebra de histórias: 1) Quebra histórias com múltiplos itens ou fluxos de trabalho em histórias individuais; 2) Identifica passos específicos em um fluxo de trabalho e cria histórias para cada um; 3) Similar ao padrão anterior, histórias representam caminhos felizes e alternativos de interação do usuário.
Scrum - As Regras do Jogo segundo o Guia do ScrumAndré Borgonovo
Este documento resume os principais conceitos e regras do framework Scrum de acordo com o Guia do Scrum. Ele define Scrum, seus pilares, papéis, eventos e artefatos. Destaca que Scrum é leve, simples, mas difícil de dominar e deve ser aplicado em sua totalidade para obter resultados.
[Product Starter] Fábio Aguiar - Lean Inception e Product Backlog BuildingProduct Camp Brasil
O documento descreve o processo de Lean Inception e Product Backlog Building (PBB) para o desenvolvimento de produtos de forma ágil. O PBB é apresentado como o passo seguinte após a Lean Inception para efetivamente identificar funcionalidades do produto com base nos usuários e seus objetivos. O documento fornece detalhes sobre como conduzir workshops de PBB utilizando ferramentas como Personas, Jornadas do Usuário e o Canvas PBB.
O documento apresenta os princípios ágeis de desenvolvimento de software, como o Manifesto Ágil e Scrum. Inclui os papéis de Scrum e exemplos de como aplicar conceitos como fluxo de valor, melhoria contínua e eliminação de desperdícios nas empresas. O objetivo é introduzir estas técnicas para tornar processos e times mais ágeis e eficientes.
Como usar o Learning Canvas para descobrir Features para o Product BacklogFábio Aguiar
O Learning Canvas é uma ferramenta para a promoção da aprendizagem emergente. Foi criada com o propósito de organizar ideias e experiências sobre um tema problematizado durante uma discussão facilitada. Nesta palestra mostro como podemos aplica-lo para descobrir features para o backlog do produto com base na problematização do cliente.
Lean inception: como alinhar pessoas e construir o produto certoPaulo Caroli
Lean Inception é a combinação eficaz do Design Thinking e do Lean StartUp para decidir o Produto Mínimo Viável, em Inglês Minimum Viable Product (MVP). É um workshop dividido em várias etapas e atividades que irão direcionar a equipe na construção do produto ideal. A construção de qualquer projeto sempre começa com uma Lean Inception.
O documento fornece uma introdução ao desenvolvimento ágil e Scrum. Resume os principais pontos da seguinte maneira:
1) Explica como o desenvolvimento ágil surgiu da necessidade de melhorar a forma de desenvolvimento de software com foco no cliente.
2) Apresenta os princípios e valores ágeis como entrega contínua de valor, aceitação de mudanças, entregas frequentes e colaboração entre times.
3) Descreve os papéis, eventos e artefatos do framework Scrum como Product Owner, Dev
Lean Inception & PBB: Cómo integrar ambas técnicas para construir el Backlog ...Luis Buchelli
Lean Inception es una técnica ampliamente utilizada que ayuda a generar alineación entre todas las personas involucradas en la creación del Producto correcto, además de identificar correctamente su MVP (Producto Mínimo Viable), considerando que ofrezca valor, sea utilizable y factible. La Técnica PBB (Product Backlog Building), a su vez, permite de forma colaborativa la elaboración y refinamiento de un Product Backlog efectivo a través de la utilización del PBB Canvas como herramienta. Durante esta sesión, vamos a aprender cómo integrar ambas técnicas para llegar desde la definición del producto y su MVP hasta obtener el Product Backlog refinado y priorizado, ¡completamente listo para empezar con el desarrollo de su producto!
O documento descreve o método Kanban para gerenciamento de fluxo de trabalho. Kanban usa cartões visuais para limitar o trabalho em progresso e medir o fluxo através do mapeamento do valor, definindo tipos de itens de trabalho e estabelecendo limites de WIP em cada etapa. O método é adaptativo, visualizando o fluxo de trabalho para melhorar o lead time e throughput.
La ilusión de Agilidad - Scrum Day Colombia 2019Johnny Ordóñez
El documento muestra cuatro años (2016-2019) de datos sobre el número de equipos ágiles y coaches de Agile. Los números de equipos ágiles y coaches de Agile aumentaron cada año de 2016 a 2019.
O documento introduz o framework Scrum para gestão ágil de projetos de software. Scrum surgiu a partir do pensamento enxuto e visa entregar valor ao cliente de forma incremental através de feedback contínuo. O framework define papéis como Product Owner e Scrum Master e processos como Sprints, Daily Meetings e Retrospectivas para melhoria contínua.
O documento discute métricas e previsões, criticando o uso de estimativas. Ele apresenta métodos alternativos como amostragem, teoria das filas, teoria das restrições e simulação de Monte Carlo para prever métricas de fluxo e tempo de ciclo de forma mais precisa. O documento também discute como limitar variabilidade para melhorar a previsibilidade.
Este documento descreve uma apresentação sobre Scrum. Ele resume Scrum como um framework ágil para gerenciamento de projetos complexos, composto principalmente por papéis, artefatos e eventos com duração fixa. Ele também discute conceitos como iteratividade, interação, auto-gerenciamento e entrega incremental de valor.
1) O documento discute métodos ágeis como Scrum e Kanban e seus benefícios como maior produtividade, entrega mais rápida de recursos e maior valor para os clientes.
2) Estudos mostram que projetos ágeis são 16% mais produtivos e 37% mais rápidos do que projetos tradicionais. Uso de métodos ágeis deve aumentar para 80% dos projetos de software em 2012.
3) Scrum estrutura equipes multifuncionais auto-organizadas para entregar incrementos potencialmente utilizáveis a cada S
Mitos e verdades sobre o MVP (Minimum Viable Product)Rafael Carvalho
Nesta palestra, realizado durante o Lean Startup Machine, Rafael Carvalho derruba vários mitos sobre a definição e o uso de MVPs. Além de dar dicas práticas de como construir MVPs para sua startup.
Os requisitos de qualidade com foco na usabilidade estão relacionados à facilidade de uso e de aprendizado de um sistema pelo cliente, contribuindo para o desempenho na sua utilização e para a satisfação do usuário. Essas características ganham relevância pelo alcance e aprovação amplos que devem apresentar nos sistemas da área financeira. Assim, a pesquisa tem como objetivo aumentar a compreensão sobre a utilização dos requisitos de qualidade de usabilidade. Foram analisadas especificações de 26 sistemas de uma organização financeira pública de grande porte, incluindo sistemas de uso externo e interno à organização. Foi utilizada a análise de conteúdo e o software Nvivo, sendo categorizados e analisados 264 requisitos de qualidade de usabilidade. Considerando que os requisitos de qualidade de usabilidade selecionados diferiam em seu nível de abstração, detalhe e completude, foram definidos critérios para a classificação. Utilizaram-se as subcaracterísticas de Usabilidade da ISO/IEC 25010 para a classificação. Como resultado obtido, constatou-se que grande parte dos requisitos definidos atendem à norma, apesar de terem sido classificados com nomenclaturas diferentes. A análise também identificou requisitos que seguem um padrão comum. Identificaram-se, ainda, as subcaracterísticas de Usabilidade com maior interesse: apreensibilidade (37%) e estética da interface do usuário (27%) dos requisitos elicitados. A subcaracterística de acessibilidade obteve menor percentual de atenção, com 1,89% dos requisitos identificados.
Este documento presenta una introducción a la teoría de "Jobs to be Done" (JTBD). Explica que un JTBD se refiere al proceso que atraviesa una persona cuando intenta cambiar su situación actual por una preferida pero se enfrenta a restricciones. Incluye definiciones de JTBD, los orígenes de esta teoría, cómo detectar un trabajo por hacer, ejemplos de su aplicación y herramientas como el "timeline tool" para entender mejor las necesidades de los clientes a través de entrevistas. El objetivo es ayudar a
1) O documento apresenta as métricas e conceitos ágeis relacionados a fluxo, como lead time, throughput, eficiência de fluxo e WIP.
2) Inclui exemplos de como medir essas métricas e analisar a variação dos dados coletados.
3) Discutem a importância de classificar os dados por tipo de demanda ou serviço para melhor compreender o fluxo.
Métricas e Indicadores em Projetos ÁgeisVitor Pelizza
O documento discute métricas e indicadores em projetos ágeis, mencionando que (1) métricas como burndown e velocidade ajudam a entender e melhorar o sistema de desenvolvimento, (2) poucas métricas devem ser medidas de forma não intrusiva para mostrar onde focar melhorias sem seguir números isolados, e (3) exemplos incluem velocidade, capacidade de trabalho e porcentagem de trabalho encontrado versus adotado.
Métricas em times ágeis: O essencial que você precisa saber, mas não te conta...Cleiton Luis Mafra
O documento discute métricas em times ágeis, enfatizando três métricas fundamentais: quantidade de trabalho em progresso (WIP), tempo de entrega (lead time) e taxa de entrega (throughput). Também fornece dicas sobre como coletar métricas de forma simples e usá-las para tomar melhores decisões e evoluir continuamente.
O documento apresenta as principais características e práticas do framework SCRUM, incluindo os papéis de Product Owner, Scrum Master e time de desenvolvimento, as reuniões diárias, planejamento do sprint e retrospectiva, e como o quadro Kanban auxilia na visualização das tarefas.
Comparing Apples to Apples - A technique to normalize software complexity and...Fernando Ostanelli
presentation delivered at Agile Trends conference, in São Paulo, Brazil, Apr 2016
In this talk we presented a technique we have developed to normalize scope and requirements comprehension that has been proven effective not just to overcome all the challenges and conflicts regarding scope agreements and planning in Agile projects, but also to determine software size in terms of functional complexity and enable a data-driven foundation for continuous improvement. We shared details of the framework including: how it was conceived, why its useful to address such challenges, how it works and how to apply it.
Concepção de um Product Backlog EfetivoFábio Aguiar
O documento discute a construção de um Product Backlog efetivo através do método Product Backlog Building (PBB). O PBB utiliza um canvas para mapear de forma colaborativa os problemas atuais, expectativas, personas, features e itens do backlog do produto. O objetivo é construir um entendimento compartilhado sobre o produto e alinhar as expectativas dos stakeholders.
Framework Cynefin e suas relações com métodos ágeis, waterfall e híbridosVitor Massari
O documento discute métodos híbridos para atendimento de necessidades de negócio. Ele explica o que são métodos híbridos e quando usá-los, utilizando o Framework Cynefin para classificar problemas em simples, complicados, complexos e caóticos. Abordagens híbridas podem combinar elementos ágeis e tradicionais de acordo com cada tipo de problema. O documento enfatiza escolher as ferramentas certas para cada situação independentemente de rótulos.
O documento resume conceitos fundamentais do Scrum como Sprints, Product Backlog, Sprint Backlog e papéis como Scrum Master e Product Owner. Sprints são períodos de tempo para o time agregar valor, geralmente 2 semanas. O Product Backlog é uma lista ordenada de requisitos e o Sprint Backlog contém itens selecionados para uma Sprint. O Scrum Master auxilia o time e o Product Owner é responsável pelo Product Backlog.
O documento discute o conceito de Business Case no PRINCE2, explicando que ele fornece uma estrutura para avaliar se um projeto é desejável, viável e realizável e vale a continuação do investimento. Também descreve os passos para criar e manter um Business Case ao longo do projeto, incluindo desenvolvimento, verificação e atualização quando necessário.
Lean Inception & PBB: Cómo integrar ambas técnicas para construir el Backlog ...Luis Buchelli
Lean Inception es una técnica ampliamente utilizada que ayuda a generar alineación entre todas las personas involucradas en la creación del Producto correcto, además de identificar correctamente su MVP (Producto Mínimo Viable), considerando que ofrezca valor, sea utilizable y factible. La Técnica PBB (Product Backlog Building), a su vez, permite de forma colaborativa la elaboración y refinamiento de un Product Backlog efectivo a través de la utilización del PBB Canvas como herramienta. Durante esta sesión, vamos a aprender cómo integrar ambas técnicas para llegar desde la definición del producto y su MVP hasta obtener el Product Backlog refinado y priorizado, ¡completamente listo para empezar con el desarrollo de su producto!
O documento descreve o método Kanban para gerenciamento de fluxo de trabalho. Kanban usa cartões visuais para limitar o trabalho em progresso e medir o fluxo através do mapeamento do valor, definindo tipos de itens de trabalho e estabelecendo limites de WIP em cada etapa. O método é adaptativo, visualizando o fluxo de trabalho para melhorar o lead time e throughput.
La ilusión de Agilidad - Scrum Day Colombia 2019Johnny Ordóñez
El documento muestra cuatro años (2016-2019) de datos sobre el número de equipos ágiles y coaches de Agile. Los números de equipos ágiles y coaches de Agile aumentaron cada año de 2016 a 2019.
O documento introduz o framework Scrum para gestão ágil de projetos de software. Scrum surgiu a partir do pensamento enxuto e visa entregar valor ao cliente de forma incremental através de feedback contínuo. O framework define papéis como Product Owner e Scrum Master e processos como Sprints, Daily Meetings e Retrospectivas para melhoria contínua.
O documento discute métricas e previsões, criticando o uso de estimativas. Ele apresenta métodos alternativos como amostragem, teoria das filas, teoria das restrições e simulação de Monte Carlo para prever métricas de fluxo e tempo de ciclo de forma mais precisa. O documento também discute como limitar variabilidade para melhorar a previsibilidade.
Este documento descreve uma apresentação sobre Scrum. Ele resume Scrum como um framework ágil para gerenciamento de projetos complexos, composto principalmente por papéis, artefatos e eventos com duração fixa. Ele também discute conceitos como iteratividade, interação, auto-gerenciamento e entrega incremental de valor.
1) O documento discute métodos ágeis como Scrum e Kanban e seus benefícios como maior produtividade, entrega mais rápida de recursos e maior valor para os clientes.
2) Estudos mostram que projetos ágeis são 16% mais produtivos e 37% mais rápidos do que projetos tradicionais. Uso de métodos ágeis deve aumentar para 80% dos projetos de software em 2012.
3) Scrum estrutura equipes multifuncionais auto-organizadas para entregar incrementos potencialmente utilizáveis a cada S
Mitos e verdades sobre o MVP (Minimum Viable Product)Rafael Carvalho
Nesta palestra, realizado durante o Lean Startup Machine, Rafael Carvalho derruba vários mitos sobre a definição e o uso de MVPs. Além de dar dicas práticas de como construir MVPs para sua startup.
Os requisitos de qualidade com foco na usabilidade estão relacionados à facilidade de uso e de aprendizado de um sistema pelo cliente, contribuindo para o desempenho na sua utilização e para a satisfação do usuário. Essas características ganham relevância pelo alcance e aprovação amplos que devem apresentar nos sistemas da área financeira. Assim, a pesquisa tem como objetivo aumentar a compreensão sobre a utilização dos requisitos de qualidade de usabilidade. Foram analisadas especificações de 26 sistemas de uma organização financeira pública de grande porte, incluindo sistemas de uso externo e interno à organização. Foi utilizada a análise de conteúdo e o software Nvivo, sendo categorizados e analisados 264 requisitos de qualidade de usabilidade. Considerando que os requisitos de qualidade de usabilidade selecionados diferiam em seu nível de abstração, detalhe e completude, foram definidos critérios para a classificação. Utilizaram-se as subcaracterísticas de Usabilidade da ISO/IEC 25010 para a classificação. Como resultado obtido, constatou-se que grande parte dos requisitos definidos atendem à norma, apesar de terem sido classificados com nomenclaturas diferentes. A análise também identificou requisitos que seguem um padrão comum. Identificaram-se, ainda, as subcaracterísticas de Usabilidade com maior interesse: apreensibilidade (37%) e estética da interface do usuário (27%) dos requisitos elicitados. A subcaracterística de acessibilidade obteve menor percentual de atenção, com 1,89% dos requisitos identificados.
Este documento presenta una introducción a la teoría de "Jobs to be Done" (JTBD). Explica que un JTBD se refiere al proceso que atraviesa una persona cuando intenta cambiar su situación actual por una preferida pero se enfrenta a restricciones. Incluye definiciones de JTBD, los orígenes de esta teoría, cómo detectar un trabajo por hacer, ejemplos de su aplicación y herramientas como el "timeline tool" para entender mejor las necesidades de los clientes a través de entrevistas. El objetivo es ayudar a
1) O documento apresenta as métricas e conceitos ágeis relacionados a fluxo, como lead time, throughput, eficiência de fluxo e WIP.
2) Inclui exemplos de como medir essas métricas e analisar a variação dos dados coletados.
3) Discutem a importância de classificar os dados por tipo de demanda ou serviço para melhor compreender o fluxo.
Métricas e Indicadores em Projetos ÁgeisVitor Pelizza
O documento discute métricas e indicadores em projetos ágeis, mencionando que (1) métricas como burndown e velocidade ajudam a entender e melhorar o sistema de desenvolvimento, (2) poucas métricas devem ser medidas de forma não intrusiva para mostrar onde focar melhorias sem seguir números isolados, e (3) exemplos incluem velocidade, capacidade de trabalho e porcentagem de trabalho encontrado versus adotado.
Métricas em times ágeis: O essencial que você precisa saber, mas não te conta...Cleiton Luis Mafra
O documento discute métricas em times ágeis, enfatizando três métricas fundamentais: quantidade de trabalho em progresso (WIP), tempo de entrega (lead time) e taxa de entrega (throughput). Também fornece dicas sobre como coletar métricas de forma simples e usá-las para tomar melhores decisões e evoluir continuamente.
O documento apresenta as principais características e práticas do framework SCRUM, incluindo os papéis de Product Owner, Scrum Master e time de desenvolvimento, as reuniões diárias, planejamento do sprint e retrospectiva, e como o quadro Kanban auxilia na visualização das tarefas.
Comparing Apples to Apples - A technique to normalize software complexity and...Fernando Ostanelli
presentation delivered at Agile Trends conference, in São Paulo, Brazil, Apr 2016
In this talk we presented a technique we have developed to normalize scope and requirements comprehension that has been proven effective not just to overcome all the challenges and conflicts regarding scope agreements and planning in Agile projects, but also to determine software size in terms of functional complexity and enable a data-driven foundation for continuous improvement. We shared details of the framework including: how it was conceived, why its useful to address such challenges, how it works and how to apply it.
Concepção de um Product Backlog EfetivoFábio Aguiar
O documento discute a construção de um Product Backlog efetivo através do método Product Backlog Building (PBB). O PBB utiliza um canvas para mapear de forma colaborativa os problemas atuais, expectativas, personas, features e itens do backlog do produto. O objetivo é construir um entendimento compartilhado sobre o produto e alinhar as expectativas dos stakeholders.
Framework Cynefin e suas relações com métodos ágeis, waterfall e híbridosVitor Massari
O documento discute métodos híbridos para atendimento de necessidades de negócio. Ele explica o que são métodos híbridos e quando usá-los, utilizando o Framework Cynefin para classificar problemas em simples, complicados, complexos e caóticos. Abordagens híbridas podem combinar elementos ágeis e tradicionais de acordo com cada tipo de problema. O documento enfatiza escolher as ferramentas certas para cada situação independentemente de rótulos.
O documento resume conceitos fundamentais do Scrum como Sprints, Product Backlog, Sprint Backlog e papéis como Scrum Master e Product Owner. Sprints são períodos de tempo para o time agregar valor, geralmente 2 semanas. O Product Backlog é uma lista ordenada de requisitos e o Sprint Backlog contém itens selecionados para uma Sprint. O Scrum Master auxilia o time e o Product Owner é responsável pelo Product Backlog.
O documento discute o conceito de Business Case no PRINCE2, explicando que ele fornece uma estrutura para avaliar se um projeto é desejável, viável e realizável e vale a continuação do investimento. Também descreve os passos para criar e manter um Business Case ao longo do projeto, incluindo desenvolvimento, verificação e atualização quando necessário.
O documento discute as 6 fases do gerenciamento de escopo de projetos, sendo elas: planejar o gerenciamento do escopo, coletar requisitos, definir o escopo, criar a estrutura analítica de projetos, validar o escopo e controlar o escopo. Além disso, aborda a importância da negociação para gerentes de projetos, especialmente em situações que envolvem alterações de escopo, cronograma ou orçamento. Por fim, discute os desafios em projetos de escopo fechado,
O documento descreve o Rational Unified Process (RUP), um modelo de processo de software que fornece boas práticas para o desenvolvimento de sistemas. O RUP é dividido em quatro fases principais: Iniciação, Elaboração, Construção e Transição. Cada fase tem objetivos, artefatos esperados e critérios de avaliação para marcos importantes no projeto. O documento detalha os principais elementos de cada fase do RUP.
Scrum é uma metodologia ágil para desenvolvimento de software que organiza o trabalho em sprints curtos e reuniões diárias. O documento descreve os papéis, práticas e ferramentas do Scrum, incluindo product backlog, sprints, daily scrums e product owner. Várias empresas usam Scrum com sucesso em projetos de software.
O documento discute a abordagem do PRINCE2 para gerenciamento de mudanças e configuração em projetos. Ele explica que mudanças são inevitáveis e devem ser identificadas, avaliadas e controladas. O PRINCE2 fornece produtos como estratégia de gerenciamento de configuração e registros para rastrear itens, issues e mudanças ao longo do ciclo de vida do projeto.
O documento discute os principais conceitos e estruturas do Scrum, incluindo seus papéis, eventos e artefatos. Resume os principais pontos do Manifesto Ágil e compara o Scrum com outras metodologias. Explica como funcionam user stories, planning poker e kanban.
Scrum permite criar produtos melhor adaptados às necessidades dos clientes de forma ágil, reduzindo o excesso de formalidade que pode limitar o progresso dos projetos. Praticar Scrum traz benefícios como comprometimento, motivação e integração para as equipes, facilitando o gerenciamento e sucesso dos projetos.
O documento discute as práticas do planejamento da Sprint no Scrum, incluindo a apresentação das prioridades do Product Owner, a quebra das histórias de usuário em tarefas técnicas pelo time e a estimativa do esforço necessário para entregar o incremento da Sprint.
O documento discute a revisão da sprint no Scrum. A revisão ocorre no final da sprint para inspecionar o incremento e adaptar o backlog do produto. Nela, a equipe e as partes interessadas colaboram sobre o que foi feito e o que pode ser melhorado na próxima sprint.
Este documento apresenta o método QFD (Desdobramento da Função Qualidade) e seu uso no desenvolvimento de produtos. O QFD ajuda a incorporar as expectativas dos consumidores no produto para aumentar suas vendas. O documento descreve o processo de desenvolvimento de produtos e como o QFD é aplicado na primeira fase conceitual para especificar as qualidades desejadas pelo consumidor no novo produto.
Material de apoio do Workshop de Desenvolvimento Ágil oferecido para estudantes universitário participantes do Ideias Já!, primeira competição universitária de ideias realizado pela Startup House em novembro de 2012.
Muitos gerentes de projetos ainda se perguntam o que irá mudar quando começarem a utilizar o framework Scrum ou o framework Kanban ou Scrum com Kanban, ‘como assim não haverá documentação?’ ou ‘Qual é o tempo ideal para planejar um projeto de software?’
Estas são algumas das perguntas mais frequentes quando cogita-se em fazer alguma migração de metodologia de desenvolvimento. Mas como já diziam alguns dos professores que tive:
- Tá difícil, complicado? Método Jack resolve, é só dividir em partes! (Neste caso, em anéis!)
Este documento descreve os princípios e práticas do framework Scrum. Scrum é leve, simples e focado em times auto-organizáveis que entregam valor de forma incremental a cada sprint. Os papéis principais são o Product Owner, que maximiza o valor do produto, a Equipe de Desenvolvimento, que é multifuncional e autônoma, e o Scrum Master, que auxilia a equipe a seguir as práticas Scrum.
O documento descreve as principais mudanças no Guia Scrum de 2020 em comparação com versões anteriores. As mudanças incluem tornar o Scrum menos prescritivo, focar em um único time para um produto, e introduzir o conceito de Meta do Produto. O documento também descreve os eventos e artefatos do Scrum, como Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
O documento descreve os princípios e práticas do framework Scrum para gestão de projetos ágeis. O Scrum utiliza eventos como Sprints curtas, reuniões diárias e revisões para entregar valor continuamente ao cliente. Equipes multidisciplinares se auto-organizam para atingir metas com flexibilidade e adaptabilidade.
O documento explica a diferença entre épicos e histórias de usuário, sendo que épicos são funcionalidades não detalhadas definidas em nível estratégico e histórias de usuário especificam os requisitos funcionais e critérios de negócios dos épicos. Histórias de usuário possuem menor duração, geralmente de uma semana, enquanto épicos podem durar de 1 a 3 meses.
Gestão de Projetos e Empreendedorismo: TAD-NC4 (02/09/2013)Alessandro Almeida
Slides da aula apresentada no dia 02 de setembro de 2013.
Disciplina: Gestão de Projetos e Empreendedorismo.
Curso: Tecnologia em Análise e Desenvolvimento de Sistemas (TAD-NC4).
Gestão de Projetos e Empreendedorismo: TAD-NC4 (02/09/2013)
++++Product backlog
1. Product Backlog
Um dos pontos mais importantes presentes no framework Scrum refere-se a criação e manutenção
doProduct Backlog. Este contem a relação de todas as atividades que serão realizadas pelo Time de
Desenvolvimento para a entrega do incremento sob a definição de pronto.
Vários são os conceitos por trás deste artefato, o que pretendemos explorar neste artigo.
Vamos lá ?
Introdução
O Product Backlog é uma lista de funcionalidades desejadas de um produto, ou seja, os requisitos que
um cliente espera receber ao final do projeto, descrito com sua própria linguagem. O ponto central do
Scrum é a criação do Product Backlog, é nele que o projeto começa.
Diferente do modelo tradicional de gestão de projetos, onde precisamos fechar o escopo para poder
começar a executar, no Scrum acredita-se que o início do projeto não é o melhor momento para isso.
Afinal nesse ponto ainda não conhecemos suficiente o projeto e precisamos avançar um pouco mais
em algumas hipóteses antes de ter tanta “certeza”.
Quando um projeto é iniciado não há nenhum esforço abrangente, que demanda muito tempo, para
escrever todas as tarefas ou requisitos previsíveis. Normalmente, tudo o que é óbvio consta do projeto,
o que, quase sempre, é mais que suficiente para o primeiro Sprint. A partir daí, o Product Backlogdeverá
crescer e mudar na medida em que se conhece o produto e os clientes.
Características Chave
Para o planejamento eficaz da nossa primeira entrega, precisamos desdobrar as características chave
do produto, programadas para o primeiro Release, em requisitos ou histórias. Na sequência do
processo, esses requisitos são priorizados e estimados, assim como são definidos os perfis e
quantidade dos integrantes do Time de Projeto. Dessa forma é possível, ao final do processo de
planejamento, obter prazos e estimativas de custo para o projeto.
2. Durante a reunião Sprint Planning, o Product Owner prioriza os itens do Product Backlog e os descreve
ao Time de Desenvolvimento que por sua vez determina quais itens ele conseguirá concluir no próximo
Sprint e passa estes itens do Product Backlog para o Sprint Backlog. Ao fazê-lo, o time desdobra cada
item em uma ou várias tarefas de Sprint Backlog para que seja possível um compartilhamento de
atividades mais efetivo.
3. Conceitualmente, o time inicia do topo da lista priorizada de Product Backlog e desenha uma linha logo
abaixo do item que o time considerar ser o último possível de se concluir durante o Sprint. Na prática,
não é incomum ver um time selecionar, por exemplo, os cinco itens mais importantes e dois itens que
estão abaixo na lista, mas associados aos cinco iniciais.
O Product Backlog pode ser mantido em uma planilha Excel. Um exemplo de um projeto real é
apresentado abaixo. Essa planilha Excel mostra cada item do Product Backlog com uma priorização
genérica (Muito Alta, Alta, etc.) feita pelo Product Owner.
As estimativas são realizadas pelos desenvolvedores, mas é notório que são muito imprecisas e
somente são utilizadas para uma grosseira alocação de tarefas nos vários Sprints.
Priorização
Em um artigo publicado por James O. Coplien, publicado em 3 de agosto de 2011 no site da Scrum
Alliance, mas que ainda gera comentários, trata das mudanças na versão atualizada do Guia do
Scrumno que tange a priorização do backlog do produto ou como James explica: ordenação.
Priorizar uma lista significa ordenar seus itens pela importância de cada um em relação aos outros. As
prioridades guiam a comparação dois-a-dois dos itens na lista. Pense na aplicação do algorítmo de
ordenação “por bolhas” (bubble sort) para priorizar o backlog do produto: compare os dois itens do
topo e troque-os de posição se estiverem na ordem errada. Passe, então, para o próximo par e
continue percorrendo a lista até que todos os itens estejam nas posições corretas. Priorização e
ordenação andam de mãos dadas. Todas as comparações são locais, ou seja, são restritas a uma
otimização local.
De forma mais ampla, a equipe Scrum e o Product Owner precisam considerar todo o backlog ao
ordenar seus itens, a fim de otimizar o valor ou o retorno sobre o investimento (ROI). A maioria das
pessoas normalmente acha que o ROI tem prioridade, entretanto você deve pensar o ROI como o
resultado de longo prazo decorrente da ordenação correta de todo o backlog, ao invés da simples soma
do ROI dos itens individuais. Isto é verdade, de certa forma, porque o ROI de um item isolado depende
de sua posição no backlog.
Requisitos
4. A elaboração do Backlog do Produto é realizada através do desdobramento das características-chave,
estabelecidas na Visão do Produto, em:
Requisitos Funcionais;
Requisitos não-funcionais.
Vejamos:
Requisitos funcionais
De uma maneira geral, são funções do produto que podem ser descritas, priorizadas e estimadas. Vou
concentrar a explicação, inicialmente, na forma de descrição desses requisitos. Requisitos também são
conhecidos no mundo ágil como histórias.
Uma história descreve uma necessidade ou situação futura, a qual o cliente pretende alcançar através
da utilização do produto a ser desenvolvido. Normalmente, a descrição de uma história ou requisito
utiliza a seguinte estrutura:
Através dos exemplos acima, conseguimos visualizar necessidades ou situações futuras, a partir de
três pontos de vista diferentes (quem): cliente, atendente e gestor da loja. Na segunda coluna (o que),
é informada a necessidade ou situação futura desejada e, na terceira coluna (para que), sua finalidade.
Uma história, para ser considerada completa, precisa ser formada por essas três partes: quem, o que
e por que. Entretanto, não é uma receita de bolo. Podemos descrever requisitos de outras formas,
como mostrado no exemplo abaixo:
5. Requisitos Não Funcionais
São aspectos subjetivos relacionados à história. Vamos considerar o seguinte requisito: consulta a
posição atualizada do acervo de filmes com tempo de resposta satisfatório. A dúvida usual neste
tipo de requisito é: o que é tempo de resposta satisfatório ?
Trata-se de uma condição que pode gerar várias interpretações. Para mim, tempo de resposta
satisfatório pode ser algo entre dois a três segundos, entretanto, dependendo do perfil do usuário,
podem existir tolerâncias maiores ou menores. Por este motivo, a única forma de resolver este problema
é transformar um requisito não funcional, ou a parte não funcional do requisito, em algo funcional
(objetivo).
Para tanto, precisamos definir o que é “tempo de resposta satisfatório”. Se nossos clientes/usuários
estabelecem uma tolerância máxima de 2 segundos como tempo de resposta satisfatório, conseguimos,
através dessa informação, derivar outros requisitos funcionais necessários para garantir essa condição,
tais como servidores, links de acesso, arquitetura do site etc.
Critérios
Segundo o modelo INVEST, criado por Bill Wake, para um requisito fazer parte do Backlog do Produto,
deve respeitar os seguintes critérios:
Ser independente
Orequisito deve possuir capacidade para atender a necessidade ou situação futura informada pelo
cliente, sem depender de outro requisito. Essa condição é fundamental para garantir flexibilidade
durante o ciclo de desenvolvimento do produto.
Ser negociável
Enquanto não for convertido em produto, o requisito deve permitir alterações, como mudança de
prioridade, aumento/redução da sua abrangência e desdobramento em outros requisitos, podendo
inclusive ser reescrito ou mesmo descartado, desde que mantido o valor esperado pelo cliente final, na
entrega do produto.
Ser priorizado (Valuable)
O requisito deve, obrigatoriamente, assegurar a entrega de valor para o cliente, caso contrário, seu
desenvolvimento poderá representar desperdício de esforço para o Time de Projeto. Por este motivo, o
requisito é priorizado pelo Dono do Produto, de acordo com o valor agregado ao negócio/cliente final.
Ser estimado
6. O requisito deve apresentar condições para que seu prazo de desenvolvimento/entrega possa ser
estimado. Caso o requisito não ofereça essas condições, em virtude, por exemplo, do seu tamanho,
deverá ser desdobrado em requisitos menores, até que possa ser adequadamente estimado.
Ser pequeno (Small)
Este critério está diretamente relacionado ao anterior. O requisito deve estar descrito de uma forma que
permita sua estimativa com certo nível de certeza (quanto menor, melhor). Outro aspecto a ser
observado é que a duração prevista do requisito não deve ultrapassar o prazo de execução dos ciclos
de trabalho estabelecidos para o projeto (Sprints).
Ser inspecionado (testable)
O requisito propriamente dito ou sua descrição deve prover as informações necessárias para que possa
ser inspecionado/testado pelo cliente final. Requisitos que não podem ser validados elevam os níveis
de risco do projeto e podem ocasionar problemas graves em etapas mais avançadas do projeto.
Conforme mostrado até aqui, fica evidente que a elaboração de requisitos não é uma tarefa simples,
principalmente para quem não está habituado a planejar projetos dessa forma. Por este motivo, acredito
que seja melhor explorar um pouco mais o tema, para assegurar o correto entendimento dos conceitos
e práticas relacionadas à elaboração e gestão do Backlog do Produto.
User Story
Para melhor estruturar o Product Backlog utiliza-se o conceito de User Stories, que contém a descrição
detalhada dos requisitos de cada solicitação a ser implementada.
Segundo Mike Cohn:
User Story é uma pequena e simples descrição de uma funcionalidade dita da perspectiva da pessoa
que deseja a nova capacidade, usualmente um usuário ou um cliente do sistema.
Ou seja, deve conter as necessidades dos usuários ou dos clientes, e não as funcionalidades do
sistema. Trata-se de uma mudança de paradigma quando comparado ao modelo criado pelo
PMI(Project Management Isntitute) para gestão de projetos. E é esse um dos papéis do Product Owner:
traduzir as necessidades do cliente, através do Backlog do Produto, em uma linguagem não-técnica
compreensível por todas as pessoas envolvidas no projeto.
7. Exemplo:
Cada User Storie pode ser composta por:
ID
Uma identificação única, apenas um número com auto-incremento. O objetivo disto é evitar que, ao
mudarmos seu nome, percamos o controle sobre as histórias.
Nome
Um nome curto e descritivo para a história. Por exemplo; “Layout do Relatório”. O nome tem que ser
explicativo o bastante, para que os membros do time e o Product Owner entendam minimamente sobre
o que estamos falando, e específico o suficiente para distingui-la das demais histórias. Normalmente
usamos de 2 a 10 palavras.
Importância
Definir qual é importância dessa história na perspectiva do Product Owner (em relação ao cliente). Por
exemplo: 10 ou 150. Quanto mais pontos mais importante.
Estimativa inicial
Estimativas preliminares que o time dá sobre quanto tempo será necessário para concluir uma
determinada história, se comparada as demais. Cada empresa trabalha sua estimativa de uma forma,
8. mas normalmente dá-se uma pontuação que está diretamente relacionada à complexidade da tarefa e
que servirá como base para se calcular quantos dias / horas / pessoas serão necessárias para entregar.
Se a pontuação estiver muito alta, uma dica interessante é quebrar a tarefa em duas atividades, desta
forma ficará mais fácil acertar na estimativa. A unidade está ligada a pontos por história e geralmente
corresponde mais ou menos a “relação homem/dias” ideal.
Faça a pergunta: Em X dias nós apresentaremos uma implementação pronta, demonstrável e testada?
Se a resposta for “com 3 pessoas trancadas em uma sala levará aproximadamente 4 dias” então a
estimativa inicial é de 12 pontos por história.
Demonstração
Em alto nível criamos uma descrição de como a história será demonstrada na apresentação da Sprint. É
simplesmente uma especificação de teste. “Faça assim, então faça aquilo e, então, isso deverá
acontecer.”
Notas
Quaisquer outras – breves – informações, esclarecimentos, referências a outras fontes de informação
etc.
Exemplo:
ID Nome Importância Estimativa Demonstrar Notas
1 Deposito 21 16
Logar-se no
sistema para
abrir a pagina
de deposito,
depositar R$
60,00 ir para a
pagina de saldo
verificar se
houve um
aumento de R$
60,00.
Necessário
diagramam
UML
Priorização
Mantenha o Product Backlog atualizado
Histórias que não estejam mais alinhadas à visão do produto devem ser descartadas do Product
Backlog. Quanto menor for o conjunto de histórias que devem ser priorizadas, mais simples será a
tarefa. Por mais que seja difícil “desapegar” de uma história pensada e, até certo ponto, especificada,
é importante que isso seja feito, pois ela estando no Product Backlog, mesmo que com uma prioridade
baixa, pode influenciar na priorização das demais histórias e alterar o rumo do produto.
Dê importância à Definição de Pronto
A definição de história preparada é outro fator que pode auxiliar bastante na priorização. Sem ela, a
equipe de desenvolvimento pode não saber estimar corretamente uma história, passando uma falsa
9. noção de tamanho da história para o Product Owner, que irá tomar decisões sobre priorização com
base em uma informação pouco confiável.
Conhecimento, incerteza e risco de histórias
Como esses fatores influenciam diretamente o sucesso do produto, histórias com baixo grau de
conhecimento e alto grau de incerteza e risco devem ter uma prioridade alta, pois quanto antes forem
desenvolvidas, antes pode-se perceber o melhor caminho a se seguir, caso contrário pode não haver o
tempo necessário para desenvolver a história e colher os frutos do aprendizado do desenvolvimento da
mesma.
Qual a influência da história na próxima release?
Histórias que permitam um lançamento mais rápido do produto também devem estar no topo doProduct
Backlog. Por exemplo, em um software de geração de nota fiscal, a geração da nota em si é muito mais
importante que o cadastro dos produtos, logo, ela deve possuir uma maior prioridade.
Atenção ao tamanho das histórias
Lembre-se, a história deve ser pequena suficiente (s de small do INVEST) para ser independente e
agregar valor para o software e para o cliente, dessa forma, busque uma uniformidade no tamanho das
histórias, de modo que o Product Backlog, principalmente em seu topo, possua apenas histórias na
menor unidade possível, e a medida que avançamos, podemos encontrar histórias maiores. Assim,
evitamos que a equipe estime histórias muito grandes, que possuem maior risco de apresentar
surpresas em seu desenvolvimento e que possuem estimativas mais suscetíveis a erros.
Atenção à dependência entre as histórias
Apesar da definição de que as histórias devem ser independentes (i de independent do INVEST), muitas
vezes não conseguimos evitar a dependência entre as histórias. Nesse caso a melhor opção é deixar
visível essa dependência, com uma anotação, uma cor diferente, qualquer coisa que chame a atenção
para isso. Se a história A depende da história B, não agrega valor para o negócio fazer a A antes da B
e isso deve estar visível para todos os envolvidos no Projeto.
Ouça todos os interessados no Projeto
A decisão sobre a prioridade do Product Backlog é única e exclusiva do Product Owner, entretanto, ele
deve ouvir todos os interessados (stakeholders) no Projeto para auxiliar o seu processo de tomada de
decisão. Isso é importante pois o produto sendo desenvolvido não deve agradar somente ao PO, mas
sim à todos os envolvidos no Projeto, principalmente interessados e clientes.
Utilize Técnicas de Priorização
Novamente, apesar da decisão sobre as prioridades definidas ser única e exclusiva do Product Owner, a
utilização de técnicas, como a técnica de KANO pode ser bastante útil quando existe dúvida na
prioridade de um pequeno conjunto de histórias. Uitlize as técnicas de priorização como sua aliada para
ajudar a resolver esses pequenos conflitos.
Considere a priorização por temas
Como falei na dica #6, a dependência entre histórias muitas vezes é inevitável. Dessa forma, agrupar
as histórias dependentes em um uma e priorizar o tema também pode ajudá-lo, assim a priorização
pode ser dividida em 2 passos, primeiro se prioriza os temas e, em sequência, as histórias dentro de
cada tema, evitando assim que histórias de um mesmo tema fiquem espalhadas por todo o Product
Backlog.
Se mantenha atualizado!!!
Como sempre, nunca pare de estudar e se atualizar. A cada dia novas técnicas aparecem, e, estarmos
de cabeça aberta para absorver novos conhecimentos é sempre importante para nos ajudar a melhorar
nosso trabalho.
Conclusão
10. Tão importante quando entender os conceitos existentes por traz de um Product Backlog é saber
trabalhar de forma correta na criação e manutenção do mesmo.
A definição das estimativas das estórias é responsabilidade do Time de de Desenvolvimento com apoio
do Scrum Master e Product Owner trabalhando juntos na busca dos objetivos estabelecidos e
produtividade esperada de coerência e produtividade.
Referências Bibliográficas
http://scrumex.com.br/blog/?p=1091
http://imasters.com.br/artigo/20133/agile/o-backlog-do-produto-e-a-arte-da-user-story/
http://www.projectbuilder.com.br/blog-pb/entry/projetos/como-fazer-o-product-backlog
http://www.ufpi.br/subsiteFiles/pasn/arquivos/files/aula12_SCRUM%20na%20pratica.pdf
http://www.ufpi.br/subsiteFiles/pasn/arquivos/files/aula12_SCRUM%20na%20pratica.pdfhttp://blo
g.myscrumhalf.com/2014/04/10-dicas-para-melhorar-a-priorizacao-do-product-backlog/