-
Notifications
You must be signed in to change notification settings - Fork 45
Como pontuar o backlog
Ao se fechar o backlog inicial para a segunda Release, onde é adotado as metodologias ágeis, um passo muito importante para a equipe se alinhar acerca da pontuação das história é definir o que é uma história pronta, nessa definição entram fatores principalmente em relação à métricas aceitáveis.
Após definir o que é uma história pronta, é possível seguir alguns passos para se conseguir pontuar todo esse backlog rapidamente e de maneira eficaz.
A primeira coisa a se fazer é levantar todas as histórias que deverão ser estimadas. Eu aconselho que elas estejam escritas em cartões, assim será mais fácil trabalhar com elas.
Você precisa considerar os épicos e temas (ou, qualquer outro nível de rompimento) também, como eles são itens de alto nível, normalmente se encontram na parte inferior do seu Product Backlog.
Após levantar todas as histórias que estavam estacionadas em seu Backlog, coloque elas em uma mesa para que possam ser movimentadas facilmente.
A mesa é legal, pois todos podem ficar em volta dela para discutir e confirmar a utilidade e prioridade de cada história de maneira mais fácil e eficaz.
Escolha qualquer história para começar, faça a equipe estimar o esforço dela em “pequena”, “média” ou “grande”.
Usar P, M ou G é uma forma simples e rápida para atribuir esforço em torno do trabalho nesse primeiro momento.
Para atribuir peso, faça o seguinte:
- Se for uma grande história (ou seja, a equipe acredita que aquela história irá demandar um esforço grande) a coloque em uma extremidade da mesa, lado esquerdo, por exemplo;
- Se for uma pequena história coloque na outra extremidade da mesa;
- Se for uma história média, coloque no meio.
Agora pegue uma 2° história e pergunte para a equipe se o esforço para faze-la é mais ou menos o mesmo da história que está na mesa.
Por exemplo, supondo que a 1° história foi considerada de tamanho G (grande), pergunte a equipe se o esforço para implementar essa 2° história selecionada é similar a 1° história que é do tamanho G.
Se a resposta for sim, a coloque sobre a mesa na mesma extremidade das cartas de esforço grande.
Usando esta técnica, é possível passar por 100 ou mais histórias de usuário dentro do Product Backlog e estimar o seu esforço relativo em menos de uma hora.
Agora, se você prefere utilizar Story Points, siga o que vou lhe explicar agora!
Pegue um grupo de histórias, pode ser o com esforço “pequeno” (P) que são, teoricamente, mais fáceis.
Junto com a equipe, comece dando a pontuação de 1 para todas daquele grupo, depois passe uma por uma e analise se a pontuação está coerente.
Por exemplo, se você avaliou a primeira história e deu 2 pontos para ela, a segunda você irá comparar com essa, se você perceber que a história atual é duas vezes mais trabalhosa, você dá a pontuação de 4 pontos para a mesma, se for três vezes mais trabalhosa você dá a pontuação de 6.
EPS/MDS - FGA/UnB
Métodos de Desenvolvimento de Software
Gestão de Portfólio e Projetos de Software
RUP (Rational Unified Process)
Fase Elaboração (RUP) Planejamento(PMBOK)
Fase de Construção (RUP), Execução/Monitoramente e Controle (PMBOK)
Fase Transição (RUP), Finalização (PMBOK)
Acceptance Test Driven Development (ATDD)
Integração Contínua Deploy Contínuo
Automação de Ambiente com Docker
Orquestração de Containers com Docker Compose
Automação de Ambiente com Vagrant
Deploy Contínuo na Plataforma Heroku
Integração Contínua com Travis CI
Disponibilizando a Aplicação com o Proxy Reverso Nginx
Tutorial de Instalação do Ionic
Android Integração contínua com Circle CI
Configuração de Ambiente para React Native
Tutorial Instalação Ruby on Rails
Teste Automatizado Cucumber JS
Teste Automatizado Cucumber Rails
Testando AngularJS com Jasmine
Teste Automatizado com Selenium IDE
Configurar o SonarCloud para um projeto usando Jest
Configurar o SonarCloud para um projeto usando Pytest
Configurar o SonarCloud para um projeto usando Mocha e Istambul