Nosso jeito de fazer desenvolvimento ágil

Idealmente no scrum temos um time multidisciplinar, ele deve ter autonomia para executar todos os pedaços do processo, e ser livre para alterar processos internos com o intuito de melhorar o desempenho e qualidade do produto.

Em nossa metodologia ágil usamos como base o LESS, um framework ágil para mais de um time. Juntamos com ele um pedaço do conceito de kanban que é outro framework ágil, porém tem um formato mais de fábrica, com estágios bem definidos.

O presente documento é um material de referencia, para um melhor entendimento de como é o nosso ágil veja os videos abaixo:

Kanban

Em nosso kanban temos 3 estágios, cada um com seu Todo, entradas e saídas diferentes:

1. requisitos
   • Entram ideias de produtos, melhorias ou acréscimos que ainda faltam uma melhor elaboração, não tem ainda uma boa definição do que são os requisitos funcionais.
   • Para cada entrada, deve sair uma ou mais histórias de usuários, com requisitos funcionais bem definidos e pensandos. Pode conter documentos auxiliares que facilitem o entendimento da(s) histórias, como fluxogramas, bpmn, wireframes, e até protótipos.
   • Requisitos não precisa necessariamente criar protótipos, somente quebrar melhor a regra de negócio afim de estressar uma ideia e levar clareza para o time de desenvolvimento.
2. Desenvolvimento
   • Podemos ter 1 ou mais deste estágio em paralelo.
   • Recebem como entrada histórias de usuário, minimamente bem definidas, e priorizadas.
   • Tem como saída um ou mais pacotes que irão agregar ao produto.
     • Isso é, mesmo havendo mais de 1, a saída deve ser conjunta e funcional.
   • Neste estágio o time envolvido deve: coletar requisitos tanto com PO quando stakeholder, codificar, testar, validar, garantir qualidade e entregar.
   • Este é um time tradicional do scrum.
3. QA
   • Tem como entrada os pacotes que os times de estágio de desenvolvimento fizeram.
   • Seu papel é verificar a qualidade do acréscimo ao produto em várias frentes: código, segurança, usabilidade, acessibilidade, ...
   • Tem como saída o pacote acrescido ao produto em produção.

Os estágio de Requisitos e QA são auxílios aos times de desenvolvimento, com o intuito de garantir clareza e qualidade, mesmo em um time com pouca experiência e poucas pessoas. Em um futuro, idealmente, esses 2 estágio serão dissolvidos em times de desenvolvimento.

Os times de desenvolvimento e QA seguem o LESS, que é outro framework abaixo. Isso implica em algumas rotinas, que serão listadas na próxima seção.

Ainda neste documento temos uma seção sobre Papéis: poderes e responsabilidades, onde fica mais claro os poderes e deveres de cara um.

Rotinas do less

O LESS é bem semelhante ao scrum, e traz as rotinas listadas abaixo com o intuito de garantir os princípios do ágil:

1. Sprint Planning Part 1
   • Todos os times participam junto com o PO.
   • Stakeholder externo aos times não participam.
   • O objetivo é o time selecionar do que o PO priorizou algumas histórias pra tocar, e tirar suas dúvidas, clareando o entendimento.
   • Também é momento dos times identificarem como irão cooperar, e quem sabe fazer uma "multi-team sprint" entre 2-3 times.
2. Sprint Planning Part 2 (team and multi-team sprint)
   • Separado, cada time em uma sala.
   • Se 2 ou mais times identificarem pontos de cooperação podem se juntar, para um planejamento conjunto.
   • SM pode participar.
   • Stakeholder externo aos times não participam.
   • O objetivo é o time quebrar as histórias em atividades técnicas para executar, e se coordenar com outras squads se necessário.
   • O time pode sentir a necessidade de mais workshops deste tipo posteriormente para o design tanto de coisas comuns como separado.
3. Daily Scrum
   • Cada time em uma sala.
   • SM pode participar.
   • O objetivo é identificar se o time será capaz de cumprir com o prometido, e se movimentar como for necessário para atingir o objetivo da sprint.
     • Isso pode ser feito com cada um que compõe o time expondo o que fez, o que pretende fazer, e se tem algo impedindo o andamento. E revendo o objetivo da sprint.
4. Coordination
   • Não é uma reunião marcada e sim uma prática prevista no método.
   • Deve ser feito sempre que 1 ou mais time identificar pontos de cooperação.
   • O time deve ser ágil nessa pratica, agindo de forma decentralizada e resolvendo os conflitos entre si.
5. Overall Product Backlog Refinement (PBR)
   • Todos os times participam junto com o PO.
   • O objetivo é alinhar quais itens serão prioridade na próxima sprint, dividir as itens entre os times e dar tempo aos times para refinar entender melhor o problema e dar uma estimativa para cada item.
   • O PO apresenta sua ideia de priorização e principalmente o porquê.
   • O PO coordena com o time se faz sentido cada item, e se é possível, em termos de:
     • impacto no lucro; impacto no cliente; risco comercial; risco técnico; custo de atraso e muito mais.
   • O PO deve levar seu entendimento ao time e tentar entender o time, de modo que os times também sejam donos do produto.
   • Cada time pega um ou mais itens para refinar, que podem entrar na sprint dado a priorização que ficou pre-definida, e dá peso ao item.
   • Esta reunião também é momento dos times identificarem pontos de cooperação.
6. Product Backlog Refinement (PBR)
   • Cada time em uma sala.
   • Não é uma reunião agendada.
   • Dado os itens que cada time pegou no Overall Product Backlog Refinement, o time deve ir atrás de entender o que é, o que deve ser feito.
   • O time deve ir atrás do PO, ou preferencialmente do stakeholder impactado diretamente pelo item para clarificar as coisas, melhorando o entendimento quanto ao item, melhorando os requisitos e a estimativa de prazo dada.
   • OBS: a planning não é para descobrir o que vai ser feito, é para identificar pontos de cooperação entre os times, e operacionalizar do que vai ser feito, aqui deve ser definido o que deve ser feito com clareza. O como vai ser feito será definido na planning 2.
   • Se o time identificar no "Overall Product Backlog Refinement" que tem coisas em comum, esse workshop pode ser feito em conjunto para clarificar as coisas para todos os times envolvidos
7. Sprint Review
   • Todos participam.
   • Stakeholder externo participa.
   • O objetivo é apresentar para os stakeholder o que ficou pronto durante a sprint, e coletar feedback deles.
8. Team Retrospective
   • Cada time em uma sala.
   • É uma reunião prevista para o time olhar para trás e levantar melhorias para o operacional do time.
9. Overall Retrospective
   • Todos os times participam.
   • PO não precisa participar.
   • É uma reunião prevista para os times olharem para trás e levantar melhorias para o fluxo todo, comunicação, rotinas, ...

Pontos importantes no less

• um time tem que ter no mínimo 3 pessoas e no máximo 8;
• podemos ter no máximo 8 times;
• 1 PO somente, que deve intermediar o meio interno e externo, em termos de priorização
• 1 SM para até 3 times;
• 1 potencial incremento ao produto, (independe de ferramental, api, microsserviço, ...);
• 1 backlog para todos, 1 sprint backlog para cada time;
• cada time é responsável pelo mesmo produto e assim cabe ao time coletar os requisitos também;
• o produto deve ser acrescentado continuamente (continuos integration), assim os times conseguem se coordenar melhor e enxergar conflitos mais cedo;
• manter sempre 2 sprint de histórias já refinadas;

Definição de pronto

Para o time de desenvolvimento uma atividade técnica está pronta se ela foi feita e revisada por alguém da área. Agora história de usuário está pronta se foi feita, revisada e validada com o stakeholder.

Chapters

No ágil as reuniões que tem todo mundo o foco é no produto e em identificar pontos de cooperação, são tratados regras de negócios e dores,envolve muito pouco a parte técnica. Os chapter são agrupados técnicos, com o intuito de fomentar a disseminação e discussão de ferramentas, técnicas e boas práticas de cada área.

Atualmente temos os seguintes chapters:

• ux e ui
• ciência de dados
• front-end web, mobile e backend
• devops, segurança, helpdesk

Algumas áreas estão agrupadas, e conforme o time crescer pode fazer sentido dividir mais com o intuito de especializar cada vez mais cada área.

Na seção abaixo temos uma lista dos papeis existentes e responsabilidades.

Papéis: poderes e responsabilidades

SM

• Aculturar o time quanto a metodologia.
• Participar das reuniões previstas na metodologia, como condutor e facilitador.
• Auxiliar o PO na criação das histórias de usuário e manipulação da ferramenta de gestão de projetos.
• Ajudar o time com problemas que possam estar impedindo o desenvolvimento do projeto.
• Garantir o cumprimento dos prazos.
• Monitorar a performance geral das squads.

PO

• Garantir consistência do produto.
• Intermediar entre os diversos stakeholders.
• Auxiliar no levantamento de requisitos (nem todo PO faz isso por definição).
• Criar as histórias de usuários que as squads irão executar.
• Priorizar as histórias de usuários de modo a atender as exigências de entrega do negócio.
• Garantir o cumprimento dos prazos e a corretude das entregas.
• Tirar duvidas dos times quanto as regras de negócios decorrentes das histórias de usuários, mas preferencialmente apontar qual stakeholder pode dar essa clareza.
• Definir junto as squads o peso/prazo para execução das histórias de usuário, isso inclui os lançamentos, betas, ...

QA

• Garantir que o acréscimo corrente (sprint) atenda qualidades funcionais e não funcionais ( manutenabilidade, performance, segurança, ... ).
• Gerar insumo para a continua melhoria técnica do time.
• Gerar insumo de melhoria continua do projeto, tanto técnico quando de negócio.
• Realizar correções no acréscimo corrente (sprint).
• Tem o poder parar membros de uma squad para que eles façam as devidas correções no acréscimo corrente.
• Realizar inspeções no projeto inteiro em busca de melhorias relativos a critérios não funcionais e funcionais.
• É responsável por tudo que irá entrar em produção.

Requisitos

• Auxiliar o PO na criação de histórias de usuário.
• Auxiliar na melhor definição das histórias de usuário.
• Garantir consistência do produto.

Squad representatives

• Um ou mais membros de uma squad que representa o todo em algumas rotinas da metodologia.
• Tem o mesmo papel do squad member, mas participa de algumas rotinas representando a squad para reduzir a quantidade de pessoas na reunião.
• O representante deve ser capaz de falar em nome daqueles que compõe sua squad.
• Pode ser rotativo ou não.

Squad member

• Definir o peso/prazo para execução das histórias de usuários.
• Definir junto ao PO as histórias que irão entrar na sprint.
• Desenvolver as histórias de usuários.
• Garantir o cumprimento dos prazos e a corretude das entregas.
• Refinar a história de usuário a fim de que ela faça sentido para o time e para o produto.
• Garantir qualidade de usabilidade, responsividade e acessibilidade das entregas.
• Contribuir para a melhoria continua do produto seja em termos de regra de negócio, experiência ou qualidade técnica.
• NOTA o dever e poder de qualquer um dentro da squad é igual, o que muda é sua área de atuação, cada um contribui de um modo, mas a squad como um todo deve ser multidisciplinar o suficiente para: coletar requisitos, operacionalizar, estimar prazo, implementar, validar

Chapter lider

• Garantir a evolução técnica do time.
• Desenvolver/evoluir o onboarding de novos membros.
• Organizar as squads garantindo diversidade para que uma squad seja auto-suficiente e tecnicamente capacitada.
• Contratar/gerir membros em sua área de domínio técnico.
• Monitorar a performance dos membros em sua área de domínio técnico.
• Ajudar as squads com problemas que possam estar impedindo o desenvolvimento do projeto.
• Acompanhar individualmente os membros de seu chapter.
• Chapter member
• Contribuir para a evolução técnica do time.
• Ajudar os times com problemas que possam estar impedindo o desenvolvimento do projeto.
• Auxiliar os times com a qualidade e boas praticas de mercado.
• Realizar revisões nos códigos.

FAQ

O que acontece dentro de uma sprint?

Tudo que foi listado de rotina acima ocorre dentro de uma sprint. Uma sprint termina quando a seguinte inicia. Isso é, planejar, refinar e tudo o mais faz parte de uma sprint.

Caso de teste para o fluxo desenhado

Os casos de teste abaixo são do ponto de vista do item. Entenda o item como uma demanda, algo que o time deve fazer e que agrega valor ao produto, isso pode ser uma história de usuário, uma ideia de produto, um bug, ... Esta seção contém um descritivo de como essa demanda entra e como ela chega em produção, por quais etapas ela passa nesse meio do caminho.

Demandas sem escopo conhecido

1. demanda chega: "contratar a asset dentro do planfy"
2. requisitos entra em ação (fora da sprint)
   1. defini qual será a jornada do usuário
   2. quais comunicações a plataforma fará com o usuário e por qual meio
   3. defini brevemente os textos
   4. cria wireframes para ilustrar a jornada
   5. valida exaustivamente com stakeholders
   6. cria as histórias de usuário junto ao PO
3. PO define que as histórias são prioridade da próxima sprint
4. PO aponta a prioridade para o time no refinamento, cada time pega uma ou mais histórias para tocar
5. Cada time refina sua história, individualmente ou em conjunto caso identifiquem pontos de cooperação
6. Durante a planning 1, o PO apresenta novamente os itens, confirmando que o plano não mudou desde o refinamento, e cada time pega uma ou mais histórias, preferencialmente aquelas que eles mesmos refinaram, e tiram suas dúvidas finais com o PO.
7. Durante a planning 2 o time operacionaliza o que vai ser feito, quebrando a história em tasks.
8. Durante o andamento da sprint de desenvolvimento:
   1. ui cria as telas e dev implementa a funcionalidade
   2. o time fica com algumas dúvidas e as tira com o PO e cliente final
   3. o time finaliza o desenvolvimento da funcionalidade
   4. alguém da área (back, front, mobile, ...) revisa os códigos
   5. o time junta com a funcionalidade feita por outra squad
   6. o time testa a atualização para ver se não conflitou com os acréscimo de outras squads
   7. o time valida a funcionalidade com o PO e cliente final, já em stage
9. A sprint de desenvolvimento termina, o time vai para a review onde apresentam os resultados para todos os stakeholders na reunião
10. O time de QA entra em ação:
    1. analisa os acréscimos da sprint 1
       • código
       • corretude da funcionalidade
       • padrões do projeto
       • acessibilidade, responsividade
       • ...
    2. identificam algumas correções necessárias, eles mesmos as corrigem e geram insumo para melhoria contínua para os times
    3. identificam também algumas correções que não são criticas, assim eles decidem deixar isso como melhoria para o time de desenvolvimento fazer depois
    4. o time testa as correções
    5. o tima lança o produto em produção, fazendo os avisos de atualização e tudo o mais que for necessário

Demandas com escopo conhecido (acréscimos de uma frente já existente)

Bugs não críticos

Bugs críticos

Melhorias (pequenos acréscimos de uma frente já existente)