Processo de Desenvolvimento

Introdução

O Processo de Desenvolvimento de Software da Sílex Sistemas segue uma forma de trabalho denominada Scrum, termo apropriado de uma jogada do Rugby na qual o time todo deve trabalhar em conjunto para fazer a bola voltar ao jogo. Este processo foi adaptado e modificado de modo a ser compatível com as exigências do modelo de certificação MPS.Br (Melhoria de Processos de Software Brasileiro).

Scrum é um framework ágil de gestão de projetos usado para entregar aos clientes, de forma iterativa, incrementos de produto de alto valor. Scrum depende de times hábeis e auto-organizados para entregar os incrementos do produto. Também depende de um cliente, ou Dono do Produto (Product Owner), que indique a um time uma lista de funcionalidades desejadas, utilizando-se de mecanismos de priorização. No Scrum, os projetos acontecem em uma série de iterações, com um mês de duração, chamadas Sprints ou Ciclos de Trabalho. Por outro lado, o MPS.BR (nível G) estabelece uma série de exigências de documentação, organização  e procedimentalização relativa aos requisitos de software e ao projeto de software.

O trabalho a ser feito em um projeto Scrum é registrado nas Pendências do Produto (Product Backlog), que é uma lista de todos os desejos de mudança no produto. No inicio de cada incremento é feita uma Reunião de Planejamento de Incremento (Sprint Planning Meeting) na qual o Dono do Produto (Product Owner) prioriza as Pendências do Produto (Product Backlog), e a Equipe Scrum (Scrum Team) seleciona as tarefas que ela podem ser completadas o próximo incremento. Essas tarefas são então movidas das Pendências do Produto para as Pendências do Incremento. Durante um incremento, são conduzidas curtas reuniões diárias chamadas de Scrum Diário (Daily Scrum), que ajudam a equipe a manter-se no rumo. Ao final de cada incremento a equipe demonstra a funcionalidade concluída, na Reunião de Revisão do Incremento (Sprint Review Meeting).

Papéis

Guardião do Processo (Scrum Master)

Descrição

O Scrum Master é o responsável por garantir que o Scrum Team se oriente pelos valores e práticas do Scrum. O Scrum Master protege o time se certificando de que os membros não se comprometam com atividades além da capacidade de trabalho ou alheias ao planejamento da equipe. O Scrum Master facilita o Daily Scrum e se torna o responsável pela remoção de quaisquer obstáculos (impedimentos) enfrentados pela equipe. Por impedimento entende-se qualquer obstáculo que impossibilite ou entrave a realização do escopo do projeto.

  • É o facilitador do projeto, observa o andamento do projeto e  corrige erros nas práticas do processo utilizadas durante o projeto; 
  • É responsável por difundir os valores do Scrum e suas práticas; 
  • Verifica se as reuniões diárias estão sendo realizadas corretamente; 
  • Remove os impedimentos; 
  • Protege o time contra interferências externas; 
  • Assegura que o time esteja totalmente funcional e produtivo; e 
  • Possibilita uma cooperação estreita entre todos os papéis e funções.
  • Não é o gerente de projetos, mas um líder facilitador que gerencia processos Scrum; 
  • Monitora as tarefas do Sprint para assegurar o sucesso do Sprint, mas não cria/atribui tarefas – o time é quem as cria/atribui; 
  • É parte do time: divide responsabilidades com outros membros; 
  • Deve, regularmente se reunir com os demais membros do time.

Habilidades

  • Possuir conhecimentos de Scrum, preferencialmente ser Certified Scrum Master. 
  • Conhecimentos gerais em programação e nas tecnologias utilizadas.
  • Conhecimento do processo de desenvolvimento.
  • Capacidade de gerenciamento de pessoas e de conflitos.

Equipe de Desenvolvimento (Scrum Team)

Descrição

A Equipe de Desenvolvimento constrói o produto que o cliente irá utilizar: o software ou o website, por exemplo.A Equipe de Desenvolvimento é multifuncional – ela contém todas as especialidades necessárias para entregar o produto potencialmente utilizável a cada ciclo. É auto organizável, com um alto grau de autonomia e responsabilidade.

A Equipe de Desenvolvimento:

  • É multifuncional, com cinco (mais ou menos dois) membros; 
  • Seleciona o objetivo do ciclo de trabalho, de acordo com as atividades planejadas, e especifica os produtos de trabalho necessários; 
  • Tem a liberdade de definir as tarefas a serem realizadas dentro das diretrizes do projeto para alcançar o objetivo do Sprint; 
  • Organiza suas própias atividades; 
  • Apresenta os produtos de trabalho ao Dono do Produto (Product Owner). 

Membros da Equipe de Desenvolvimento não têm nenhum dos papéis tradicionais da engenharia de software, como programador, designer, testador ou arquiteto. Todos no projeto trabalham juntos para finalizar a lista de atividades que eles coletivamente se comprometeram a realizar durante o ciclo de trabalho (Sprint) ou durante o projeto.

Na Sílex Sistemas, um Scrum Team típico possui de 3 a 7 pessoas.

Habilidades

  • Conhecimentos e prática em linguagens de programação, plataformas de desenvolvimento (IDE´s) e sistemas de bancos de dados; 
  • Ser capar de trabalhar em equipe. 
  • Conhecimento do Scrum e do processo de desenvolvimento.

Dono do Produto (Product Owner)

Descrição

O Dono do Produto (Product Owner) representa os interesses de todos os envolvidos (Stakeholders), define as funcionalidades do produto e prioriza os itens da Lista do Produto. Ele deve pesquisar junto aos clientes e ao mercado quais as necessidade de negócio que o produto atende ou pode atender. A partir destes conhecimentos ele deve priorizar a elaboração e refatoração de funcionalidades, decidir a data de liberação e conteúdo da versão para o cliente, responder pela rentabilidade do produto (ROI) e priorizar as funcionalidades de acordo com o valor de mercado.

O Product Owner:

  • Participa das Reuniões de Planejamento do Projeto e do Ciclo; 
  • Ajusta funcionalidades e prioridades a cada início do ciclo de trabalho, conforme necessário; e 
  • Acompanha a implementação das funcionalidades assistindo as reuniões diárias e a reunião de revisão ao fim de cada ciclo de trabalho (Sprint).

Considerações

O Dono do Produto (Product Owner) é responsável por fazer a lista de funcionalidades priorizada.

A equipe de trabalho analisa a priorização dos itens da lista de funcionalidades, refina os itens na ordem de prioridade estabelecida e se compromete a finalizá-los durante o Sprint. Esses itens se tornam parte da lista do ciclo de trabalho. Por refinamento entende-se a escolha de quais funcionalidades serão implementadas em um determinado Sprint.

Em retribuição ao comprometimento da equipe de trabalho  em completar/finalizar as tarefas selecionadas, o Dono do Produto (Product Owner) se compromete que ele não imporá novas funcionalidades ao time durante o Sprint. É permitido alterar as funcionalidades, mas apenas fora do ciclo de trabalho. Uma vez que o time inicie o ciclo, deve-se buscar atingir a meta do ciclo de forma “paranoica”.

Uma única pessoa dedicada ao projeto – deve estar disponível para responder às dúvidas do time 

Um membro extra do time que participa das reuniões de planejamento e de revisão do ciclo, além de ser fundamental que assista as reuniões diárias para acompanhar o andamento das tarefas. 

Tipicamente é alguém do Departamento Comercial, do Departamento de Marketing ou um usuário chave quando se tratar de desenvolvimentos internos. Pode ser o próprio cliente, procurador ou representante.

Habilidades

  • Conhecimento do processo de desenvolvimento.
  • Conhecimento do negócio desenvolvido pela empresa, da forma de comercialização e negociação, do mercado alvo que ela atinge. 
  • Conhecimento geral das funcionalidades do produto e das necessidades dos clientes.

Interessados (Stakeholders)

Qualquer pessoa interessada no desenvolvimento do software ou produto. Podem ser clientes, fornecedores, membros da empresa, entre outros.

Atividades

Fluxo Principal do Scrum

Registrar pendência no bugtracker

Frequência Constante
Participantes / Responsáveis Dono do Produto (Product Owner)
Entradas Casos cadastrados pela atividade comercial e de suporte
Saídas Caso cadastrado no bugtracker como “Caso não analisado”

Todos os atendimentos prestados pela equipe de suporte e pela equipe comercial da Sílex Sistemas são cadastrados na ferramenta de bugtracking. Os casos que podem ser solucionados pelo próprio suporte, pela equipe comercial ou independem de programação não fazem parte do processo de desenvolvimento de software. Os casos que possuem necessidade de programação, por se tratarem de erros, de novas implementações ou de melhorias, são transferidos para a programação. Ao serem transferidos para a programação, os casos assumem o status de não analisado.

Priorizar a Lista do Produto (Product Backlog)

Frequência Constante
Participantes / Responsáveis Product Owner
Entradas Lista do Produto sem priorização
Saídas Lista do Produto priorizada

Garantir que a Equipe de Desenvolvimento desenvolva os projetos de acordo com uma ordem de prioridades que leve em conta a factibilidade técnica e a importância comercial de cada funcionalidades. A Lista do Produto Priorizada é composta de tarefas priorizadas a serem realizdas pela Equipe de Desenvolvimento. A Lista do Produto é continuamente analisada e atualizada pelo Dono do Produto (Product Owner) que atribui, a cada caso, um Valor de Negócio e uma Complexidade de acordo com critérios previamente definidos. Esta Lista serve como base para a elaboração de projetos de desenvolvimento.

Reunião de Planejamento e Abertura do Projeto

Frequência Mensal
Participantes / Responsáveis Scrum Team, Scrum Master, Product Owner.
Entradas Lista do Produto Priorizada
Saídas Plano do Projeto, Selected Backlogs de cada ciclo, casos estimados em pontos

A Reunião de Planejamento e Abertura do Projeto é o evento no qual os participantes analisam a Lista do Produto Priorizada à luz o planejamento estratégico da empresa e selecionam casos que irão compor um projeto. Nesta reunião é revisto o planejamento estratégico da empresa e o Dono do Produto apresenta a priorização das funcionalidades de acordo com a Lista do Produto Priorizada. É, então, definido um projeto de desenvolvimento, que consiste no estabelecimento de um objetivo a ser cumprido, bem como na listagem de funcionalidades que permitem a realização deste objetivo. Nesta reunião é feita a estimativa dos casos em pontos (abaixo). São também definidos os casos que farão parte de cada um dos ciclos de desenvolvimento, com detalhamento decrescente do primeiro ciclo para o segundo ou subsequentes. Nesta reunião também é avaliado o tempo disponível da equipe para aquele projeto. Os casos, estimados em pontos, recebem, então, uma estimativa em horas, com base na produtividade dos ciclos anteriores em horas por ponto. Conforme o tempo disponível, o número de casos a serem determinados para o projeto pode ser alterado tendo em vista a factibilidade do projeto.

Reunião de Planejamento do Ciclo (Sprint Planning)

Frequência Mensal ou quinzenal (no início de cada ciclo, exceto no primeiro)
Participantes / Responsáveis Scrum Team
Entradas Selected Backlog do ciclo anterior e selected backlog do ciclo atual
Saídas Selected backlog para o ciclo atual com eventuais alterações (inclusões ou exclusões de casos)

Esta reunião é realizada no curso do projeto ao início de cada Sprint. Visa corrigir eventuais erros de mensuração e definição de casos que possam ocorrer. Ela parte de tudo o que foi feito no ciclo anterior e considera o que ainda há por fazer no presente ciclo e nos demais. Visa a ajustar a distribuição de casos ao longo dos ciclos. Se houve casos excedentes e inconclusos do ciclo anterior, ou se casos foram adiantados, nesta reunião será redimensionado o Selected Backlog para o ciclo.

Reunião de Grooming

Frequência Semanal
Participantes / Responsáveis Scrum Team e Dono de Produto
Entradas Caso a ser analisado
Saídas Caso analisado

Este é uma atividade de refinamento dos casos, é o momento no qual o time se dedica a descobrir mais informações sobre um caso para poder trabalhá-lo melhor. Pode ser abordado qualquer tipo de deficiência do time para finalizar o caso, seja referente ao negócio ou técnico. O caso é detalhado e, muitas vezes, subdividido em subcasos detalhados para um melhor entendimento do que deve ser feito. 

Estimar o tamanho de um caso em pontos

Frequência Mensal
Participantes / Responsáveis Scrum Team
Entradas Caso Priorizado pelo Scrum Master (Business Value e Complexidade)
Saídas Caso Estimado em Pontos.

Permite à Equipe de Desenvolvimento (Scrum Team)  tomar decisões de desenvolvimento. A avaliação consiste em dicussão técnica e funcional do caso a ser desenvolvido. A Equipe, com base em sua experiência de desenvolvimento e no histórico de ciclos anteriores, estima o tamanho comparativo de cada funcionalidade. Essas estimativas são mensuradas em “pontos”. Estes pontos não representam nenhuma unidade de medida. Servem como referência relativa de tamanho entre os casos. Por exemplo, um caso de tamanho “2” tem o dobro do tamanho de outro de tamanho “1”. A escala utilizada obedece à seguinte sequência: 1 – 2 – 3 – 5 – 8 – 13 – 20. Esta sequência serve para evitar dificuldades de estimativa que poderiam resultar da proximidade numérica. Casos que poderiam ser considerados maiores que 20 devem ser subdivididos. A estimativa é feita por meio de votação (Poker Planning). Caso haja divergência nos pontos atribuídos ao caso pelos membros da Equipe de Desenvolvimento, ocorrerá nova análise e justificativa dos votos, até que seja obtida uma avaliação consensual. 

Iniciar o andamento de caso no bugtracker

Frequência Constante
Participantes / Responsáveis Scrum Team, Scrum Master, Product Owner (ver explicação) e Stakeholders (ver explicação)
Entradas  Quadro de Tarefas (Agile Radiator) e ata do Daily Scrum anterior
Saídas  Quadro de Tarefas (Agile Radiator), Ata do Daily Scrum, Sprint Burndown Chart

 Quando o desenvolvedor inicia o trabalho, ele deve atribuir o caso para si e iniciar o cronômetro. Todas as vezes em que ele para de fazer o caso ele deverá registrar as atividades desenvolvidas. Esse registro é feito por meio de plugin específico (Tempo) no Jira.

Reuniões de Revisão – Scrum

Reunião de Acompanhamento Diário (Daily Scrum)

Frequência Diária
Participantes / Responsáveis Scrum Team, Scrum Master, Product Owner (ver explicação) e Stakeholders (ver explicação)
Entradas  Quadro de Tarefas (Agile Radiator) e ata do Daily Scrum anterior
Saídas  Quadro de Tarefas (Agile Radiator), Ata do Daily Scrum, Sprint Burndown Chart

 A Reunião de Acompanhmento Diário (Daily Scrum) é uma reunião rápida com todos os membros da Equipe de Desenvolvimento (Scrum Team) e o Guardião do Processo (Scrum Master). Seus objetivos são o acopanhamento do andamento dos trabalhos, o planejamento e replanejamento das atividades e a identificação de impedimentos. Essas reuniões são realizadas no mesmo local e horário. Pode haver alteração do local e do horário caso seja necessário, de modo a possibilitar a participação do maior número de membros da equipe e de interessados. Todos os membros do time devem participar desta reunião. Outras pessoas (por exemplo, a gerência de um departamento, um vendedor ou um desenvolvedor de outro projeto) podem estar presentes, mas apenas como ouvintes. Isso torna as Reuniões de Acompanhamento Diário uma excelente forma da Equipe de Desenvolvimento (Scrum Team) comunicar a situação atual; se algum interessado quiser saber em que ponto está o projeto, deve frequentar esta reunião diária. Apenas os membros do time possuem direito a voz. A Reunião de Acompanhmento Diário não é uma reunião usada para solucionar problemas ou dúvidas. As dúvidas existentes deverão ser solucionadas, preferencialmente, após sua realização. Durante a reunião, cada membro da Equipe de Desenvolvimento (Scrum Team) responde às seguintes perguntas:

  1. O que você fez ontem? – Ou seja, entre a reunião passada e a atual.
  2. O que você vai fazer hoje? – Ou seja, entre a reunião atual e a futura.
  3. Existe algum impedimento?

Concentrando-se no que cada pessoa concluiu até a reunião e irá realizar após a mesma, a Equipe de Desenvolvimento (Scrum Team) tem uma visão melhor do trabalho que foi concluído e o que ainda falta fazer. A Reunião de acompanhamento diário não é apenas uma reunião de atualização do projeto, onde um chefe coleta informações sobre quem está atrasado (Status Meeting). Ao invés disso, ela é uma reunião na qual os membros da equipe se comprometem entre si (Peer Pressure) e replanejam suas atividades. Em casos em que o Guardião do Processo (Scrum Master) não consegue remover os impedimentos diretamente (por exemplo, questões técnicas que fugirem às suas capacidades), ele deve assegurar que alguém do time solucione o problema.

Existe uma antiga piada na qual uma galinha e um porco estão conversando e a galinha diz: “Vamos abrir um restaurante.” O porco responde, “Boa ideia, mas como iremos chamá-lo?” “Que tal ‘Presunto e Ovos'”, diz a galinha. “Não, obrigado” diz o porco. “Eu estaria comprometido enquanto você estaria apenas envolvida”. A piada tem como objetivo evidenciar a diferença entre as pessoas que estão comprometidas em um projeto e aquelas que estão apenas envolvidas. O Scrum confere um status especial àqueles que estão comprometidos. Somente os comprometidos têm permissão de falar durante a Reunião de Acompanhamento Diário.

O Guardião do Processo (Scrum Master) é responsável por solucionar quaisquer impedimentos identificados o mais rapidamente possível. Vejamos alguns exemplos de impedimentos:

  • Meu _____ quebrou e eu preciso de um novo hoje.
  • Eu ainda não recebi o software que pedi um mês atrás.
  • Eu preciso ajudar ao(à) ________ a depurar um problema.
  • Eu estou me esforçando para aprender ________ e gostaria de fazer isto em par com alguém.
  • Não consigo retorno da equipe de suporte técnico do fornecedor.
  • O grupo _______ não tem tempo para se reunir comigo.
  • O diretor da área me pediu para trabalhar em outra coisa “por um dia ou dois”.

Reunião de Revisão Semanal (Weekly Scrum)

Frequência Semanal (em toda semana em que não Reunião de Revisão do Ciclo ou Reunião de Revisão do Projeto)
Participantes / Responsáveis Scrum Team, Scrum Master, Product Owner (opcional) e Stakeholders (opcional)
Entradas Lista do Ciclo e Quadro de Tarefas (Agile Radiator)
Saídas Lista do Ciclo e Quadro de Tarefas (Agile Radiator)

Durante a Reunião de Revisão Semanal o andamento do Ciclo é avaliado baseado no Sprint Goal, determinado durante a Reunião de Planejameto do Ciclo (Sprint Planning). Nesta reunião são verificados o andamento do ciclo, os principais obstáculos (impedimentos) e realizado replanejamento de alto nível das atividades da semana seguinte de modo a aproxima o projeto do Sprint Goal. A Reunião de Revisão do Projeto é uma reunião informal. Trata-se de um Daily Scrum ampliado, no qual a semana que passou, a semana subsequente e o andamento do sprint são avaliados.

Reunião de Revisão do Ciclo (Sprint Review + Retrospective Meeting)

Frequência Quinzenal
Participantes / Responsáveis Scrum Team, Scrum Master, Product Owner (opcional) e Stakeholders (opcional)
Entradas Lista do Ciclo e Quadro de Tarefas (Agile Radiator)
Saídas Lista do Ciclo e Quadro de Tarefas (Agile Radiator)

O Ciclo de Desenvolvimento se encerra com a Reunião de Revisão do Ciclo. Na Sílex Sistemas, a Reunião de Revisão do Ciclo engloba, sucessivamente, o Sprint Review, no qual são demonstradas as funcionalidades desenvolvidas e potencialmente utilizáveis, e o Retrospective Meeting, no qual é avaliada a qualidade do processo de desenvolvimento. Apresentar aos interessados (Stakeholders) as funcionalidades desenvolvidas e analisar a qualidade do processo de desenvolvimento.  Durante esta reunião, o Scrum Team apresenta o que foi realizado durante o Sprint. Tipicamente, esta apresentação é feita na forma de uma demonstração das novas funcionalidades. A Reunião de Revisão do Ciclo inclui, na sua primeira parte, o Product Owner, o Scrum Team, o Scrum Master, a diretoria, clientes e demais interessados. Na segunda parte, somente é obrigatória a presença do Scrum Master e da Equipe de Desenvolvimento.Durante a Reunião de Revisão do Ciclo o projeto é avaliado baseado no Sprint Goal, determinado durante a Reunião de Planejameto do Ciclo (Sprint Planning). Embora o ideal seja que a equipe tenha concluído todos os itens do Product Backlog alocados para o Ciclo, é mais importante que ela alcance o Sprint Goal. 
Em seguida a esta avaliação, o Scrum Team discute o que está dando certo e o que não está, propõe e consente em ações para mudança. Uma abordagem adotada é que todo o time se reúna e discuta o que ele gostaria de: 

  • Começar a fazer 
  • Parar de fazer 
  • Continuar fazendo 

O objetivo desta segunda parte da reunião é rever o que aconteceu durante o processo de desenvolvimento, de modo a permitir a melhoria constante das práticas de trabalho (Kaizen). Nesta parte, não é necessária a presença do Product Owner nem dos demais Stakeholders.

Reunião de Revisão do Projeto

Frequência Mensal
Participantes / Responsáveis Scrum Team, Scrum Master, Product Owner (ver explicação) e Stakeholders (ver explicação)
Entradas  Quadro de Tarefas (Agile Radiator).
Saídas  Quadro de Tarefas (Agile Radiator), Sprint Burndown Chart.

 A Reunião de Revisão do Projeto deve ser realizada ao final de cada projeto para demonstrar as funcionalidades desenvolvidas. É equivalente à Reunião de Revisão do Ciclo (Sprint Review) mas abrange todo o projeto.  Tipicamente, esta apresentação é feita na forma de uma demonstração das novas funcionalidades. A Reunião de Revisão do Ciclo inclui, na sua primeira parte, o Product Owner, o Scrum Team, o Scrum Master, a diretoria, clientes e demais interessados. Na segunda parte, somente é obrigatória a presença do Scrum Master e da Equipe de Desenvolvimento.
Durante a Reunião de Revisão do Ciclo o projeto é avaliado baseado no Sprint Goal, determinado durante a Reunião de Planejameto do Ciclo (Sprint Planning). Embora o ideal seja que a equipe tenha concluído todos os itens do Product Backlog alocados para o Ciclo, é mais importante que ela alcance o Sprint Goal. A Reunião de Revisão do Projeto é uma reunião informal. É proibido o de apresentações em Power Point. Não são permitindas mais que duas horas de preparação. Uma Reunião de Revisão do Projeto não deve se tornar uma distração ou um desvio significativo para o Scrum Team. 

Outras Atividades – Scrum

 Analisar Pedido de Mudança (Change Request)

Frequência Esporádico (Sempre que necessário)
Participantes / Responsáveis Product Owner (ver explicação)
Entradas Lista do Projeto
Saídas Lista do Projeto Modificada

 Analisar Pedido de Mudanças das funcionalidades originalmente previstas nos escopos previstos para cada fase do projeto ou para cada ciclo de desenvolvimento. O Dono do Produto (Product Owner) analisará os pedidos de mudança feitos no ciclo em relação a prazos, escopo, duração e custos. Seu objetivo é analisar o impacto de cada mudança no projeto. A partir dessa análise, torna-se possível decidir se as mudanças requeridas serão ou não aceitas.

Reunião de Planejamento Estratégico do Produto

Frequência Quinzenal (Variável conforme a necessidade)
Participantes / Responsáveis Scrum Team, Scrum Master, Product Owner.
Entradas Planejamento Estratégico do Produto
Saídas Planejamento Estratégico do Produto Revisado

Reunião periódica de revisão do planejamento estratégico da empresa tendo em vista a definição dos produtos. Tem por objetivo alinhar o desenvolvimento dos produtos com o planejamento estratégico da empresa. Consiste em uma reunião na qual o planejamento estratégico da empresa é revisto e debatido. Este planejamento é confrontado com os casos em backlog, de modo a fornecer subsídios para que o Product Owner lhes sejam atribua Business Values Posteriormente.

Reunião de Planejamento do Projeto

Frequência Diária
Participantes / Responsáveis Scrum Team, Scrum Master, Product Owner (ver explicação) e Stakeholders (ver explicação)
Entradas  Quadro de Tarefas (Agile Radiator) e ata do Daily Scrum anterior
Saídas  Quadro de Tarefas (Agile Radiator), Ata do Daily Scrum, Sprint Burndown Chart

 

Artefatos de Trabalho

Listas e casos

A escolha e análise dos casos que serão desenvolvidos passa por um processo contínuo de refinamento: 

Lista do Produto (Product Backlog) > Lista do Produto Priorizada (Selected Backlog) > Lista do Projeto > Lista do Ciclo (Sprint Backlog).

Na primeira lista, são registrados todos e quaisquer casos. Esses casos são analisados e lhes é conferida uma pontuação em termos de Valor de Negócio (Business Value) e Complexidade (Priorização). Nesse momento, já há descartes de casos, assim como fusão de casos duplicados ou desdobramentos de casos muito grandes em casos menores que servirão como base para a montagem da lista do projeto. A Equipe de Desenvolviment (Scrum Team), então, de acordo com a ordem descendente de priorização, analisa o tamanho relativo de cada caso (Poker Planning) atribuindo-lhe um valor do esforço necessário para os respectivos desenvolvimento (Story Points) e assim são selecionados os casos que farão parte da Lista do Projeto, respeitando o limite máximo de story points reservados para o mesmo.

A partir da Lista do Projeto e de acordo com os critérios técnicos supramencionados originam-se duas sublistas denominadas Lista do Ciclo (Sprint Backlog).

Lista do Produto (Product Backlog)

Registrar os erros, sugestões e as possíveis funcionalidades a serem desenvolvidas nos produtos. Servir de base para a priorização de casos.

A Lista do Produto (Product Backlog) consiste em uma lista de casos (issues) cadastrados no Jira que são originados tanto de erros identificados pelos clientes, pelos testadores ou pela programação, quanto são advindas de oportunidades de negócio, modificações na legislação ou sugestões de todos os interessados (Stakeholders), entre outras fontes. Esta lista é constantemente analisada pelo Dono do Produto (Product Owner) que atribui, a cada caso, uma Complexidade e um Valor de Negócio (Business Value) conforme critérios pré-definidos.

A relação entre BV e Complexidade gera a prioridade do caso. O Dono do Produto pode também descartar casos que julgar errôneos, irrelevantes ou fora dos objetivos de negócio. A análise da Lista do Produto tem por objetivo a geração de uma Lista do Produto priorizada.

Frequência Constante
Participantes / Responsáveis Dono de produto
Entradas Histórias de Usuário
Saídas Lista do produto priorizada

Lista do Produto Priorizada

Os casos cadastrados na lista do produto são analisados e lhes é conferida uma pontuação em termos de Valor de Negócio (Business Value) e Complexidade (Priorização), gerando assim, a Lista do Produto Priorizada.

Frequência Constante
Participantes / Responsáveis Dono de produto
Entradas Lista do produto
Saídas Lista do produto priorizada

Lista do Projeto

Lista de funcionalidades selecionadas a partir da Lista do Produto para fazer parte do Projeto.

A Equipe de Desenvolvimento (Scrum Team), de acordo com a ordem descendente de priorização, analisa o tamanho relativo de cada caso (Poker Planning) atribuindo-lhe uma pontuação (Story Point) que quantifica o esforço necessário para o respectivo desenvolvimento.  Em seguida a Equipe de Desenvolvimento (Scrum Team) se reúne com o Dono do Produto (Product Owner) para que este selecione os casos que farão parte da Lista do Projeto, respeitando o limite máximo de Story Points do Projeto.

Frequência Mensal
Participantes / Responsáveis Equipe de desenvolvimento
Entradas Lista do produto priorizada
Saídas Lista do projeto

Lista do Ciclo (Sprint Backlog)

Lista de funcionalidades selecionadas a partir da Lista do Projeto para fazer parte do ciclo. Lista de funcionalidades que será desenvolvida ao longo de um Ciclo de Trabalho (Sprint). Contém o trabalho que o time se comprometeu para o Sprint, incluindo todas as tarefas que devem ser executadas para implementar os itens do Product Backlog. O Sprint Backlog pertence ao time.

Frequência Mensal
Participantes / Responsáveis Dono do produto, equipe de desenvolvimento, guardião do processo
Entradas Lista do projeto
Saídas Lista do ciclo

Item da Lista do Produto (Caso ou Issue)

Um item do Product Backlog é uma unidade de trabalho suficientemente pequena para ser concluída por uma equipe em uma iteração Sprint. Os itens de Backlog são decompostos em uma ou mais tarefas.

O Sprint Backlog é composto por uma lista de tarefas que o time precisa fazer para completar os itens do Product Backlog que se comprometeram no início do Sprint. As tarefas do Sprint têm atributos para mostrar os pontos por pessoa, o estado da tarefa (ou seja, não iniciada, em andamento, impedida ou feita) e a quantidade de tempo restante para completar a tarefa.

As tarefas do Sprint são o menor nível de trabalho representado nos Backlogs e referem-se ao trabalho que normalmente dura até 16 horas.

Story Point

É a medição empregada para indicar o esforço necessário para implementar uma estória de usuário, ou uma característica do Product Backlog.

Team

O Scrum Team é um grupo multifuncional com de 5 a 9 pessoas que se comprometem a fornecer incrementos de funcionalidade do produto com elevado valor para os clientes em cada Sprint. O Scrum Team define o seu próprio destino, uma vez que estão habilitados a organizar-se para ter certeza de que todo o trabalho está concluído.

Modelo do plano do projeto

Documento que apresenta, de forma resumida e organizada, a concepção, fundamentação, planejamento e meios de acompanhamento e avaliação do Projeto, sendo a referência básica para sua execução.

O Plano de Projeto deve conter: objetivos e escopo definidos, definição do ciclo de vida do projeto, cronograma de atividades com marcos, definição das partes interessadas, definição de riscos e estimativas de tamanho para as atividades.

O desenvolvimento do projeto só é iniciado após o preenchimento deste documento.

Termo de abertura do projeto

É um documento que descreve o projeto de forma geral contendo sua justificativa e seus objetivos.

Nesse documento são descritos: 

  • Justificativa do projeto. 
  • Objetivo do projeto.

Sprint (Ciclo)

Uma sequência de atividades com prazo definido, durante a qual um incremento na funcionalidade do produto é implementada. 

Sprint Goals

O Product Owner e o Scrum Team irão identificar algum escopo para o Sprint para fornecer algumas indicações sobre as expectativas para o Sprint e fornecer alguma medida de sucesso. Os objetivos do Sprint ajudam a fornecer foco para as decisões de design e implementação do Scrum Team. 

Gráfico de progresso do ciclo (Sprint Burndown Chart)

O Sprint Burndown Chart é uma representação gráfica do trabalho restante no Sprint. 

Usado pelo time para dimensionar o quanto o trabalho está indo bem.

A estimativa de trabalho restante no Sprint é calculada diariamente e representada graficamente, resultando em um Sprint Burndown Chart . O eixo vertical mostra o tempo do esforço restantes para o Sprint. O eixo horizontal mostra os dias do Sprint. O Burndown é exibido pela linha que desce a partir do início do Sprint com as horas iniciais, até ao final do Sprint, sem horas restantes. 

O time faz o possível para alocar a quantidade certa de trabalho no Sprint, mas às vezes, durante a Reunião de Planejamento do Ciclo (Sprint Planning), aloca-se atividades a menos ou a mais e, nestes casos, o time precisa adicionar ou remover atividades. No Sprint Burndown Chart acima você pode observar que o time alocou atividades a mais inicialmente e ainda tinha, aproximadamente, 600 horas até dia 16/5/02. Neste caso o Dono do Produto (Product Owner) foi consultado e foi acordada a remoção de algumas atividades do Sprint, o que provocou a grande descida no gráfico entre os dias 16/05/02 (619 horas) e 17/05/02. A partir de então, o time manteve um progresso consistente e finalizou o Sprint com sucesso.

 

Sprint Burndown

 Quadro de tarefas (Agile Radiator)

O Quadro de Tarefas mostra todo o trabalho que o time está desenvolvendo durante o Sprint. Antes ou durante um Reunião de Acompanhmento Diário (Daily Scrum), as estimativas são alteradas (para mais ou menos) e os cartões são movidos no quadro. 

Abaixo, um exemplo do Quadro de Tarefas Físico utilizado (versão antiga):

 

Antigo Agile Radiator manual

Exemplo do Quadro de Tarefas Físico utilizado gerado pelo Jira:

Cada linha no Quadro de Tarefas é um item do Sprint Backlog (neste exemplo, casos). Cada caso deles é representado por um cartão de tarefa que é colocado no Quadro de Tarefas. Cada cartão de tarefa é colocado inicialmente no Quadro de Tarefas na coluna “A fazer”. As colunas são:

Pendente – A descrição do caso são exibidas nesta linha. Pode ser utilizado (mas não é obrigatória) a forma de História de Usuário (“Como PAPEL eu quero FUNCIONALIDADE para OBJETIVO”) 

Em andamento – Qualquer atividade que está sendo feita fica nesta coluna. O programador responsável move o cartão quando se está pronto para iniciar a tarefa. Isto acontece preferencialmente durante a Reunião Daily Scrum. 

Em Teste – Uma vez desenvolvida da funcionalidade, o caso passa para a posição em teste. Estes casos são submetidos ao suporte. Caso testes não sejam necessários (por exemplo, funcionalidades que dependem de código automaticamente gerado) o caso pode ser concluído diretamente. 

Documentação – Deve ser elaborada a documentação para aquela caso 

Concluído – Os cartões são empilhados nesta coluna quando estão concluídos. Eles são removidos no final do Sprint. 

Atualmente a Sìlex Sistemas mantém um quadro de papel físico e outro quadro eletrônico no Jira por meio do plugin Grasshopper.

Existem várias maneiras diferentes de se implementar um Quadro de Tarefas. Times alocados no mesmo local podem usar uma parede. Times alocados em locais distintos podem usar alguma ferramenta. 

Incremento de produto potencialmente utilizável (Software Entregável)

O resultado do projeto é um incremento de produto potencialmente utilizável.

Ao final do projeto é necessário que seja entregue um incremento de produto potencialmente utilizável. Este incremento deve ser um software ou parte potencialmente utilizável por um usuário (preferencialmente o usuário final). Pode ser, por exemplo, um arquivo executável, ou um software implantado em um servidor web que possa ser acessado e possa oferecer uma maneira de visualizar as funcionalidades criadas. Deve, também, ser criada a documentação de usuário daquele sistema, seja na forma de “Ajuda” ou “Documentação de Usuário”. 

Release

Uma Release é a transição de um incremento do produto potencialmente utilizável do time de desenvolvimento para o uso rotineiro dos clientes. 

Release Burndown Chart

Em um projeto Scrum, o time acompanha seu progresso com um plano de libertação, atualizando um Release Burndown Chart ao final de cada Sprint. O eixo horizontal do Release Burndown Chart mostra os Sprints; o eixo vertical mostra a quantidade de trabalho restante no início de cada Sprint.

O escopo deste gráfico é uma única Release, entretanto, um Product Burndown Chart abrange todas as Releases. 

Testes de funcionalidade

O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.

Recomendações

Caso de Pesquisa

Caso complexo e que usará tecnologia desconhecida ou ambiente de desenvolvimento diferente para resolvê-lo e que, por isso, depende de estudo/pesquisa por parte do programador.

Story Points

O Story Point é uma estimativa relativa de tamanho da atividade comparada com outra atividade no projeto. Portanto, espera-se que uma história de 10 pontos demore o dobro do tempo que uma história de 5 pontos.

Estimar não é o mesmo que quantificar, mas incluir, implicitamente, o entendimento do time sobre a complexidade, o risco e o tempo para o trabalho que está sendo estimado. Um Story Point é único para o time e não pode ser comparado com o Story Point de outro time. A estimativa de Story points é feita pela Equipe de Desenvolvimento com base nas suas experiências anteriores e com base na análise da complexidade dos casos apresentados. 

Riscos

É um conjunto de eventos incertos que podem afetar positiva ou negativamente o andamente e a consecução de objetivos de um projeto.

Utilizamos uma escala de 1 a 3 que define baixo, médio e alto, respectivamente para categorizar a probabilidade e o impacto de cada risco. E a prioridade é obtida multiplicando-se a probabilidade e o impacto.

Estimando o Valor de Negócio (Business Value)

O Business Value representa o quanto determinado caso ou funcionalidade é importante do ponto de vista comercial.

O Business Value é analisado com base nos critérios abaixo:

Estimando a Complexidade

Técnica de estimativa de complexidade dos itens da Lista do Produto.

A complexidade dos itens da Lista do Produto é avaliada a partir de critérios inspirados na contagem de pontos de função. Optamos por não utilizar a contagem estrita de pontos de função por julgarmos que traria uma dificuldade desnecessária ao processo.

Vejamos os critérios abaixo: 

Observações: 

Campos | Tabelas – Número de tabelas e de campos que são criados ou alterados. 

Campos | Telas – Número de telas e de campos que são criados ou alterados. 

Complexidade do Estudo – Alta: envolve estudos em áreas cujo desenvolvimento não foi ainda feito. Por exemplo, se a a equipe nunca trabalhou com Javascript e o projeto requer o uso da linguagem. Média: envolve estudos em áreas que a equipe possui pouca experiência, mas já fez algum trabalho. Por exemplo, se a equipe já implementou nota fiscal eletrônica de serviços para um município e necessita de implementar para outro. Pequena: tarefas com as quais a equipde de desenvolvimento está habituada a trabalhar. 

Erro reproduzido – Caso o atendimento seja relativo a erros para os quais existe um fluxo (passo-a-passo) certo e definido. 

Erro esporádico – Caso o atendimento seja relativo a erros para os quais não existe um fluxo (passo-a-passo) certo e definido.

Técnicas de Estimativa

Na medida em que são adicionados itens ao Product Backlog, o tamanho destes itens são estimados pelo Scrum Time.

Scrum não descreve técnicas específicas de estimativa. 

A estimativa pela analogia é uma técnica utilizada por Scrum Times. O mecanismo é muito simples e consiste em comparar itens do Product Backlog similares a outros itens do Product.

Backlog que já tenham sido implementados. A falta de dados limitará a eficácia desta técnica.

Planning Poker é uma abordagem iterativa popular de estimativa. Os passos são:

Um baralho é dado a cada membro do time e cada carta tem um valor de estimativa válido

O Product Owner lê uma estória e esta é discutida rapidamente 

Cada membro do time escolhe uma carta representando sua estimativa 

As cartas são abertas para que todos possam vê-las 

As diferenças das estimativas são discutidas (especialmente os valores discrepantes) 

Faz-se re-estimativas até que haja consenso

Priorizando a Lista do Produto (Product Backlog)

Como priorizar a Lista do Produto de acordo com a relação entre a Complexidade e o Business Value.

O Product Backlog é priorizado de acordo com uma relação entre Business Value (BV) e Complexidade (C):

Prioridade = BV/C

Ou seja, um caso cujo BV seja alto e tenha baixa complexidade, possui alta prioridade. Um caso cujo BV seja baixo e tenha alta complexidade, possui baixa prioridade.

Gráfico de Progresso (Burndown Chart)

O BurnDown Chart é um gráfico que mostra o fluxo de realização das atividades propostas, medidas em pontos. É um gráfico de acompanhamento do andamento da realização das tarefas. Representado pela duração do ciclo de trabalho no eixo x em dias em função do total de horas de trabalho planejadas para aquele ciclo.

No início de cada projeto, é montado um gráfico com o número de pontos que precisam de ser feitos. À medida que os casos são implementados, o estoque de pontos a fazer se reduz, o que pode ser melhor visualizado por uma curva descendente neste gráfico. O gráfico é automaticamente gerado pelo Jira.

Abaixo, exemplo simplificado do gráfico. A linha em vermelho demonstra a execução real do projeto (redução do estoque de pontos a fazer) e a linha azul é uma referência de execução ideal.

Velocidade

A velocidade é uma métrica que indica a taxa de entrega para um time. A velocidade de um time mostra quantos pontos de estória eles são capazes de converter em incrementos de produto potencialmente utilizável em cada Sprint.

Esforço Tarefa

Cada item da lista do ciclo de trabalho tem uma quantidade de esforço associado a ele. O esforço estabelecido para cada item é calculado levando-se em conta duas características: tempo necessário para implementar e complexidade. São utilizados pontos de histórias de usuário para medir o esforço.

Impedimentos

Os impedimentos são quaisquer obstáculos ou dificuldades que a equipe encontra e que dificultam a sua capacidade de trabalho nas suas tarefas no Sprint. Os impedimentos não são descobertos, e sim relatados, durante a reunião diária, o seu descobrimento acontece durante a realização das tarefas no dia a dia. O Scrum Master é responsável por garantir que os impedimentos sejam resolvidos. Eles são cadastrados no Jira no projeto “Impedimentos” e a sua resolução é acompanhada através do Jira.

Repositórios de Arquivos e de Documentos

Definição dos programas e dos locais nos quais devem ser armazenados a documentação, os aquivos e demais documentos do desenvolvimento de software.

A documentação relativa ao processo de desenvolvimento de software deverá ser elaborada no Confluence, plataforma de wiki da Atlassian. Documentação tal como: plano de projeto, reniões diárias, reuniões de revisão, pedidos de mudança e demais atas das reuniões que ocorrem ao longo de um projeto. Os arquivos relativos a esta documentação deverão ser anexados às respectivas páginas uma vez elaborados. Assim, planilhas preenchidas, pdfs, documentos de texto, docs e outros serão anexados. 

Documentos de ajuda, tutoriais do desenvolvimento e padrões de programação de uso interno, ou quaisquer outros documentos que sejam sigilosos deverão seguir as diretrizes anteriores. 

Arquivos que não dizem respeito diretamente ao processo de desenvolvimento deverão ser arquivados no Alfresco nos respectivos espaços. 

Arquivos de executáveis, de programas ou arquivos muito grandes (que não sejam suportados pelas ferramentas acima) deverão ser organizados no sistema de arquivos do servidor de arquivos.

Exemplos

Lista do Produto (Product Backlog)

Referências

  • COHN, Mike. Agile Estimating and Planning. New York: Prentice Hall, 2005. 368p. 
  • COHN, Mike. User Stories Applied. Boston: Addison-Wesley Professional: 2004. 304p. 
  • INTERNATIONAL FUNCTION POINT USERS GROUP. Function Point Counting Practives Manual. Release 4.2.1. Princeton Junction: IFPUG, 2005. 
  • SCHWABER, Ken. Agile Software Development with Scrum. New York: Prentice Hall, 2001. 158p.
  • SCHWABER, Ken. Agile Software Project Management with Scrum. Seattle: Microsoft Press, 2004. 192p.

Rolar para o topo