Uso do ORA

O ORA é uma ferramenta para gestão de projetos. Neste documento iremos abordar como usamos ele. Mas não de forma específica, este não é um tutorial de como usar o ORA, e sim uma abstração de como fazemos uso deste tipo de ferramenta.

Usamos o ORA para aplicar a nossa forma de desenvolver usando métodos ágeis. Para melhor aproveitamento deste material é importante que você tenha lido sobre Nosso jeito de fazer desenvolvimento ágil.

Cartões

Story

Cartões deste tipo são usado para indicar histórias de usuário.

Uma história de usuário indica algo que agregue valor a algum stakeholder. Não faz diferença se é um refactor ou feature, se agrega valor é uma história.

Idealmente uma história deve ser curta para que o time consiga implementar em uma sprint e sempre agregar valor.

Os elementos presentes neles são:

• título no formato "como [stakeholder que receberá o valor] quero [ação/funcionalidade que gera valor] (para [razão do valor])";
• descrição para dar contexto do que é a história;
• pode estar atrelado a um épico ou não;
• qual squad que irá executar;
• peso e valor;
• critérios de aceitação, para auxiliar no que deve ser feito:
• os critérios podem ser funcionais ou não funcionais;
• podemos ter histórias técnicas e não técnicas;
• história técnica e aquela cujo o stakeholder beneficiado é interno ao time de desenvolvimento;
• história não técnica é aquela cujo o stakeholder beneficiado é externo ao time de desenvolvimento.

Cartões deste tipo podem ser criados por membros do time (principalmente para histórias técnicas), pelo PO, ou a pedido de algum stakeholder externo. Porém quem as prioriza é somente o PO.

O ideal é deixar o PO criar, e somente informar a ele que se deseja criar um cartão, assim ele já deixa priorizado ou não.

Epic

Cartões deste tipo só ficam no board de épicos, e são utilizados para grupar cartões do tipo story.

Os elementos presentes neles são:

• título,
• que deve iniciar com um verbo,
• e ser semântico agrupando um pedaço do produto;
• descrição para dar contexto;
• agrupado de cartões do tipo story;
• não tem peso nem quem executa, é somente um agrupado.

Somente o PO pode criar cartões deste tipo.

Para controle da etapa de requisitos, pode conter cartões do tipo PI também, tradados mais abaixo.

Task

Durante a sprint, o time pode decidir criar alguns cartões para auxiliar na execução de uma dada história.

Esse tipo de cartão só deve ser criado dentro da sprint. Caso concluído deve ir para validação ou produção.

Os elementos presentes neles são:

• título,
• que deve iniciar com um verbo, indicando o que deve ser feito;
• descrição para dar contexto;
• membro da squad que vai executar;
• relacionamento com a história que está task se destina;
• critérios de aceitação, para auxiliar o membro a executar;
• não tem peso nem valor, dado que este tipo de cartão é uma quebra técnica do que deve ser feito para implementar a história, que já tem peso e valor.

Somente o time pode criar este tipo de cartão, ele tem cunho técnico, e serve somente para a organização interna do time que vai desenvolver algo.

Spike

Durante o refinamento, ou planejamento, o time pode chegar a conclusão que não tem conhecimento o suficiente do escopo ou tecnologia necessário para implementar uma ou mais histórias. O spike é uma atividade técnica com o objetivo de obter conhecimento necessário para reduzir o risco de uma abordagem técnica inadequada e entender melhor os requisitos técnicos para aumentar a confiabilidade do time, e então desenvolver e estimar uma feature com assertividade.

Se o time identificar que precisa de uma spike as histórias atreladas não devem ter peso (dado pelo time), só valor (dado pelo PO).

Histórias técnicas também podem ter spikes, como por exemplo: um estudo de uma nova tecnologia para tornar a documentação do projeto mais legível.

Os elementos presentes neles são:

• título,
• que deve iniciar com um verbo, indicando o que deve ser feito;
• historias que esta atividade bloqueia;
• peso, indicando o esforço que vai ser direcionado a esta atividade, uma vez que pode ser um refinamento, um protótipo, um teste A/B, ou qualquer outra coisa que anteceda uma história.
• O peso indica quanto tempo vai ser dedicado a esta atividade, para não virar uma atividade de estudo solta.
• não tem valor, dado que ao final da execução não gera valor para o negócio, mas é necessário para melhorar o entendimento do time
• squad que vai executar, depois a squad se organiza em quem vai fazer;
• critérios de aceitação, para auxiliar o time a entender quando o estudo foi concluído.

Somente o time deve criar este tipo de cartão, mas o PO precisa estar ciente e priorizar.

Uma spike pode ser tocada muito a frente da história a qual ela se destina, tentando antecipar um conhecimento necessário no futuro, mas tem o risco do time perder o conhecimento adquirido caso não utilizado. Por exemplo, "estudar API do whatsapp", sendo que integrar o whatsapp não faz parte de histórias que são prioridade para as próximas sprints.

Uma spike também pode ser criada sem uma história, com o intuito de aprender uma tecnologia nova, ou melhorar um entendimento sobre algo, que pode ajudar em alguma história futura que possa vir a surgir. Mas tem alguns riscos:

• não ser mais o que foi estudado quando precisar;
• não ter noção clara de para qual fim/problema isso vai ser aplicado;
• o time perder o conhecimento adquirido caso não utilizado.

Bug

Este tipo de cartão é uma história de usuário, mas tem a semântica de consertar algo que não funciona como deveria.

Os elementos presentes neles são:

• título no formato "como [stakeholder que está tendo problemas] estou com problemas para [ação que o stakeholder está com problema];
• squad que vai executar, depois a squad se organiza em quem vai fazer;
• peso, indicando o esforço para fazer a correção;
• valor, indicando quão urgente é realizar a correção.
• Esse valor pode ser dado pelo PO, ou com base no número de usuários que estão enfrentando este problema.
• O valor 13 significa que é extremamente urgente, a squad deve parar o que está fazendo e corrigir imediatamente (hotfix).
• Deve apresentar também quem reportou o erro e quando.

Este tipo de cartão pode ser criado por qualquer um.

Product Idea (PI)

O cartão de Product Idea (PI), fica somente no quadro de requisitos. E serve para indicar uma ideia que tem que ser trabalhada. Isto é ainda está abstrata de mais para ser criado uma história de usuário e entregue ao time de desenvolvimento.

Como o time de requisitos pode criar tasks atreladas a elaboração de uma ideia, esse t´ipo de cartão separa o que é uma ideia a ser trabalhada de uma "task" a ser executada para lapidar uma dada ideia.

Os elementos presentes neles são:

• título, não tem padrão
• descrição para trabalhar melhor o que é a ideia
• pode conter ou não tasks relacionadas
• peso e valor
• pode estar atrelado a um épico

Este tipo de cartão só pode ser criado pelo PO, e seu valor também deve ser definido pelo PO, orientando a equipe de requisitos a priorizar no que pensar.

Quadros

Quadro de Requisitos

• To Do
  • cartões: PI ou task
• Doing
• Done
  • Done é aquela ideia de produto que foi elaborada o suficiente para criar as histórias de usuário e levar o mínimo de clareza ao time de desenvolvimento
  • Neste momento as histórias já tem que ter sido criadas no backlog do produto

Quadro de Backlog

• Bugs
  • cartões de bug somente
• Backlog
  • só tem cartões de spike e story
• Validation
  • tudo que o time de desenvolvimento entregou na sprint e está pronto para ir para produção, em teoria, mas vai passar pelo QA antes
• Production
  • tudo já está em produção

Quadro de Épicos

• To Do
  • cartões do tipo épico
  • fica aqui qualquer épico que não tem história em andamento
  • entende-se em andamento histórias que estão:
    • dentro de uma sprint
    • em validação
    • em coleta de requisitos
    • ou tem algum spike sendo tocado
• Doing
  • fica aqui qualquer épico que tenha pelo menos uma história em andamento
• Done
  • ficam aqui os épicos que tenham todas as histórias concluídas
  • entende-se como concluída histórias que estão em produção
  • épicos completos podem sair de Done, caso novas histórias sejam adicionadas a eles.

Quadros de sprints

• cada squad tem o seu
• cada quadro tem um cartão com o squad goal
• o quadro fica
• To Do
  • cartões: bugs, story, tasks e spikes
• Doing
• Done
  • se for uma task, spike ou bug: done significa implementado e revisado
  • seja um estrutura, uma documentação, um protótipo, um código, ...
  • se for uma story: done significa implementado, revisado e validado com stakeholder (não importa a ordem)
  • independente do tipo do cartão, para ser considerado concluído, os critérios escritos no cartão devem ter sido atendidos

Tags

Tags são flexíveis, e não fazem parte da metodologia. São boas práticas que serão listadas aqui para consulta e oficialização de uma boa prática.

Tags de membros:

• Como não pagamos o ORA para todos, usamos tags para indicar a pessoa exata que irá executar algo.
• Elas tem o formato m-nome-do-membro
• m-victor-moraes
• m-jose
• Temos uma tag para cada membro que executa algo nos times.

Tags de revisores:

• Para indicar quem deve revisar algo temos estas tags.
• Revisar significa rever o trabalho técnico de outra pessoa, seja código, UI, ou um documento. Tudo deve ter um duplo checkup.
• Elas tem o formato r-nome-do-membro
• r-victor-moraes
• r-jose

Tags informativas:

• Temos também algumas outras tags úteis que trazem mais informações a respeito do cartão:
• refinar: cartão que precisa ser melhor refinado
• pedido de usuário: um história pode ser criada por diversas pessoas, esta tag indica que esta história foi explicitamente solicitado por algum stakeholder externo ao time, para indicar que já tem alguém cobrando essa funcionalidade/refatoração
• história técnica: novamente, um história pode ser criada por diversas pessoas, esta tag indica que a história em questão tem como beneficiário algum stakeholder interno ao time

Note que "história técnica" diz respeito a quem a história se destina, já "pedido de usuário" indica se foi um stakeholder externo que solicitou. A maioria das histórias são para stakeholders externos, mas não tem a tag "pedido de usuário", se não foi explicitamente pedido pelo usuário.

Milestone

No fluxo principal, tudo que chega pronto ao final da sprint de desenvolvimento vai para QA e ao final vai para produção. Mas por algum motivo, as vezes queremos separar os lançamentos. Por exemplo:

• lançar em produção somente quando temos um conjunto de histórias, que não temos condições de tocar todas em uma sprint;
• segurar o lançamento do mobile, mas deixar o lançamento do web seguindo a sprint;
• lançar um beta, e depois de um tempo lançar para produção;
• ...

Para casos como o de cima, fazemos uso da milestone. Assim, uma milestone é uma forma de organizar os lançamentos que não irão ocorrer na time box de uma sprint.

Criações de milestones podem quebrar o fluxo de entrega continuo e gerar artefatos dependentes um do outro. Sendo assim uma milestone deve ser criada junto com o time. Todos devem estar cientes das milestones para organizarem a produção de pacotes em conjunto e evitar conflitos.

Vamos para um exemplo, suponha uma time box de uma sprint de 15 dias para desenvolvimento + 15 dias para qa.

1. Vamos assumir que temos 4 milestones
2. Lançar gestão de finanças pessoais para beta - time box 45 dias
   • Funcionalidades A, B, C e D devem estar prontas
3. Lançar gestão de finanças pessoais em produção - time box 90 dias
   • Deve ser o mesmo conjunto do de cima, mas após fechado o beta
   • Ao decorrer do beta esta milestone vai ganhando mais histórias conforme usuários vão reportando.
4. Lançar planejamento automatizado - time box 30 dias
   • Funcionalidade E, F devem estar prontas
5. Lançar plano de saúde - time box 60 dias
   • Funcionalidade G, H devem estar prontas
6. Sprint 1 (15 dias)
7. Time-alpha faz a funcionalidade A e D
8. Time-beta faz a funcionalidade E e F
9. Sprint 2 (30 dias)
10. QA avalia/corrige o pacote que tem A e D relativo a "Lançar gestão de finanças pessoais para beta"
    • QA não pegar as funcionalidades separadas, isso já deve estar em um pacote único que faça sentido pra milestone
11. QA avalia/corrige funcionalidade E e F, e coloca em produção. (Milestone 3 atingida no prazo)
12. Time-alpha faz a funcionalidade C
13. Time-beta faz a funcionalidade B
14. Times alpha e beta se coordenam e juntam B e C no pacote já continha A e D
15. Sprint 3 (45 dias)
16. QA avalia/corrige o pacote da milestone "Lançar gestão de finanças pessoais para beta" que agora contém todas as histórias necessárias
17. QA lança o beta de "Lançar gestão de finanças pessoais para beta". (Milestone 1 atingida no prazo)
18. Time-alpha e beta se juntam e fazem a funcionalidade G da milestone "Lançar plano de saúde"
19. Sprint 4 (60 dias)
20. QA avalia/corrige a funcionalidade G relativo ao pacote da milestone "Lançar plano de saúde"
21. Time-alpha faz correções do "Lançar gestão de finanças pessoais para beta"
22. Time-beta faz a funcionalidade H relativo ao pacote da milestone "Lançar plano de saúde"
23. Sprint 5 (75 dias)
24. QA avalia correções do "Lançar gestão de finanças pessoais para beta", e atualiza o beta
25. QA avalia/corrige o pacote da milestone "Lançar plano de saúde", e coloca em produção. (Milestone 4 atingida com atraso)
26. sprint 6 (90 dias)
27. Não retorna nada crítico segundo o PO quanto ao beta.
28. QA coloca em produção o que estava em beta, e a milestone "Lançar gestão de finanças pessoais em produção" é concluída no prazo

OBS: QA não avalia funcionalidades e coloca nos pacotes de cada milestone, cabe aos times definir como serão os pacotes, manter atualizado e garantir que não quebre ao acrescentar itens. O QA avalia o conjunto, resultado total da sprint de todos os times, e coloca em produção ou não de acordo com o que foi combinado.

OBS2: Perceba que a milestone 3 tem o timebox de 30 dias, que é igual a soma do time box de desenvolvimento + QA. Isso é, não precisaria desta milestone, essas funcionalidades estariam somente seguindo o fluxo normal, mas o time achou por bem deixar isso anotado para melhor controle.

Membros no ORA

FAQ

Qual a diferença entre spike e task?

Spike é uma atividade que antecede a execução de uma história, e bloqueia a execução de uma ou mais histórias. Tasks é o conjunto de ações técnicas necessárias para implementar uma história.

Sou QA e o resultado da sprint não completa a milestone ainda, posso deixar para validar depois?

Sim, mas como QA você deve garantir qualidade dentro do prazo, deixar para avaliar/corrigir somente quando o artefato da milestone estiver completo é um risco, dado que terão mais itens para avaliar em uma sprint, e potencialmente mais coisas a serem corrigidas.

Tenho uma história que é prioridade, mas não conseguimos executar em uma sprint e nem quebrar mais, o que fazer?

Em ordem de prioridade: 1. certifique-se que realmente não tem como quebrar mais a história, as vezes tem algum meio de entregar menos valor e depois melhorar. Isso não significa enviar para produção algo parcial, se trata de validar pedaços. Temos milestones justamente para segurar lançamentos até a conclusão de um conjunto de histórias. 2. verifique se o time não consegue executar por falta de conhecimento técnico ou de conhecimento do negócio, se este for o caso, basta criar uma spike para melhorar o entendimento. 3. se a história não pode ser quebrada, o time tem clareza do que fazer, mas não consegue fazer em uma sprint, talvez a história possa ser feita em conjunto com uma ou mais equipes para chegar a conclusão ao final da sprint. 4. se nada a cima funcionou, você pode criar um, ou mais spikes para ir tocando aos poucos conjuntos de componentes técnicos necessários para reduzir a complexidade da história, assim a cada sprint a história se torna mais fácil de ser concluída e em algum momento o time vai se sentir confortável em trazer ela para dentro da sprint. Evite essa abordagem ao máximo, o objetivo do ágil é entregar valor continuamente.