Mas, pensando em desenvolvimento de software, será que as filas e estoques de demandas (qualquer item de trabalho de uma equipe de software, como histórias de usuários, bugs, etc…) se comportam da mesma maneira e trazem as mesmas consequências em todos os estágios do fluxo de desenvolvimento? Serão essas consequências sempre negativas?

Para respondermos essas questões, consideremos uma equipe que trabalha com o workflow composto pelas seguintes etapas:

• Backlog: Itens já escritos pelo PO (Product Owner) e que ainda precisam ser refinados com a equipe;
• Ready to Dev: Itens que já foram refinados com a equipe e estão aguardando o início do desenvolvimento;
• In Development: Itens em desenvolvimento;
• Ready to Test: Itens desenvolvidos e aguardando testes;
• Testing: Itens sendo testados pelo time de QA (Quality Assurance);
• Ready to Deploy: Itens já aprovados por QA e aguardando o deploy em produção;
• In Production: Itens em produção.

Da lista acima, conseguimos identificar algumas etapas de filas, onde seria possível acumular estoques de demandas aguardando as próximas etapas. São elas: Backlog, Ready to Dev, Ready to Test e Ready to Deploy.

Como será que os estoques se comportam em cada uma dessas etapas?

Estoque em Backlog?

Cenário: como já tinha uma ideia do que seria trabalhado pelos próximos meses, o PO da equipe decidiu escrever uma grande quantidade de histórias de usuário.

Para este cenário, há um risco considerável de desperdício do esforço do PO e até das histórias de usuário escritas, uma vez que que podem ocorrer mudanças na estratégia do produto. Por exemplo, um concorrente lançou uma nova feature que não estava mapeada e decidiu-se implementá-la também. Novas histórias precisarão ser escritas e outras possivelmente serão fechadas como obsoletas.

Estoque em Ready to Dev?

Cenário: o PO da equipe sairá de férias nos próximos dias e não haverá um substituto. Nos últimos dias de trabalho antes do descanso, o PO e a equipe se esforçaram para refinar uma grande quantidade de histórias de usuário para que a equipe trabalhasse durante o período.

Neste caso, há um risco maior de que os acordos entre PO e equipe, discutidos durante os refinamentos, sejam esquecidos com o passar do tempo (é sempre melhor que esses acordos estejam frescos na cabeça da equipe).

Porém, trata-se de uma opção bastante interessante para que a equipe não sofra de starvation durante a ausência do PO. Além de ser uma opção melhor do que deixar as histórias de usuários na etapa anterior (Backlog), o que poderia elevar o risco de desalinhamento entre o que era planejeado e o que será desenvolvido.

No geral, é importante ter bem claro quem pode tomar as decisões do produto em caso de ausência do PO, pois, mesmo com a adoção dessa estratégia de estoque, dúvidas e incertezas certamente surgirão na sequência do processo. Em muitos casos, essa responsabilidade acaba ficando com alguém da equipe de design, um facilitador do processo ou mesmo com a própria equipe de desenvolvimento, que pode tomar as decisões em conjunto.

Estoque em Ready to Test?

Cenário: o responsável pelo QA da equipe ficará ausente por algumas semanas para realização de uma cirurgia. A equipe optou por continuar o desenvolvimento das histórias de usuário e deixá-las acumulando em ‘Ready to Test’ até o retorno do QA.

Para esta abordagem, como as funcionalidades não serão testadas até o retorno do responsável pelo QA, o ciclo de feedback será mais longo. Isso trará desvantagens como:

1. Aumento no WIP (trabalho em progresso): das filas que discutimos até aqui, esta é a primeira em que há código em progresso sendo estocado (nas anteriores, já havia esforço de análise e design). Com isso, a quantidade de WIP no sistema tende a aumentar, e o Wesley Zapellini já nos explicou em seu e-book “5 Estratégias para otimizar o fluxo de desenvolvimento de software” os principais efeitos colaterais de ter o WIP alto.
2. Redução da visibilidade do processo: com mais tarefas no board da equipe, tende a ficar mais complicado ter visibilidade do que está realmente em andamento.
3. Redução da previsibilidade do processo: com a pausa do processo de testes, todas as tarefas que estiverem ou chegarem na fila de Ready to Test durante o período de ausência do responsável de QA ficarão por lá até o retorno dele, é claro. O lead time do processo (tempo entre o início do trabalho da equipe na demanda e o término dela) será, portanto, impactado.
4. Aumento no número de bugs e não conformidades: como já mencionado no e-book “5 Estratégias para otimizar o fluxo de desenvolvimento de software”, o aumento do WIP tende a impactar diretamente na qualidade do software. Neste cenário, há ainda um ponto adicional: a falta de feedback quanto à conformidade das histórias desenvolvidas faz com que histórias sejam iniciadas com uma base já fora de conformidade, o que tende a sobrepor os problemas.

As imagens a seguir apresentam a distribuição do lead time das demandas da equipe imediatamente antes e após as férias do profissional de QA (para entender melhor os gráficos, recomendo o blogpost do Raphael Albino “Métricas Ágeis: o que Lead Time fala sobre seu projeto”). Na primeira delas, antes do início das férias do profissional, é possível ver que há pouca variabilidade no lead time das entregas e pouco WIP.

Já após as férias, é possível perceber uma tendência de aumento no lead time (média projetada já bastante acima do percentil 95%), o que deve contribuir para uma redução na previsibilidade das entregas. Além disso, é possível ver que a quantidade de trabalho em progresso também teve um aumento considerável:

Já vimos os possíveis impactos dessa estratégia, mas o que podemos fazer em uma situação como esta? Supondo que não haja outro profissional de QA disponível para a equipe, alguém do time pode assumir essa atividade ou, o que temos feito com sucesso em alguns contextos, a equipe como um todo pode se dividir para realizar os testes: sempre que alguém mover uma demanda para QA, antes de iniciar uma nova, pode verificar se há alguma pendente de testes e já puxá-la. A única sugestão é para que uma demanda não seja testada pela mesma pessoa que a desenvolveu.

Estoque em Ready to Deploy?

Cenário: por opção do PO, decidiu-se que todas as histórias mapeadas inicialmente precisariam estar prontas para que as novas features fossem para produção.

Neste caso, o maior impacto do ponto de vista do processo é que será preciso garantir que essas histórias praticamente prontas não criem um empecilho para que outras linhas de desenvolvimento integrem código em produção. De maneira geral, a sugestão é integrar código pronto em produção sempre que possível (há técnicas para se fazer isso sem necessariamente liberar as funcionalidades para os usuários, como a técnica de Feature Toggle). Além de desbloquear futuros deploys que precisem “passar na frente” (como bug fixes, por exemplo), essa estratégia ainda permitirá que os deploys sejam mais tranquilos e sem grandes riscos.

Do ponto de vista de produto, e considerando o Cost of Delay conforme nos apresentou o Lucas Colucci em seu blog post “Quanto a empresa perde financeiramente quando o projeto atrasa?” sobre o assunto, é sempre interessante disponibilizar as novas features para o cliente, mesmo que todas as features planejadas no escopo de um projeto não tenham sido finalizadas.

Um outro cenário muito comum, especialmente em equipes maiores, é o da existência de janelas e filas para deploy. Geralmente, essa estratégia é adotada quando:
1. o ferramental de deploy/rollback exige tempo e trabalho manual (frequentemente, com recursos compartilhados por várias equipes),
2. quando há falta de confiança quanto à qualidade do que está sendo colocado no ar (alguém se perguntaria: será que o código está adicionando bugs?)
3. ou quando há muitas equipes trabalhando em um mesmo produto.

Essa burocracia para o deploy (horários pré-definidos, dias da semana permitidos, comitês para decidir o que vai e o que não vai pro ar…) contribuirá para atrasar a entrada das novas funcionalidades em produção. Para reverter esse cenário, o ideal é investir em cobertura de testes e em automações em geral (tanto da execução dos testes, quanto de deploy/rollback), o que fará com que o processo de colocar código novo no ar se torne mais simples e indolor, tanto para quem faz o deploy quanto para quem usa o produto.

Conclusão

Em geral, as filas e estoques no desenvolvimento de software, especialmente em contextos ágeis, trazem como consequência aumento no risco de desperdício de esforço e de oportunidades de negócio representadas pelas demandas em estoque, principalmente as que já estão mais próximas de serem finalizadas e que poderiam gerar receitas para a empresa ou melhorias para os usuários.

Porém, como vimos acima, há também outras consequências que variam conforme o estágio do fluxo de desenvolvimento em que a demanda está, podendo impactar na qualidade do código e aumentar o número de bugs, ou até evitar uma possível situação de starvation da equipe.

E você? Quais situações já enfrentou com estoques e filas em suas equipes? Deixe seus relatos e comentários abaixo!

The post Estoques no desenvolvimento de software first appeared on Plataformatec Blog.

Constantemente ao conversar com alguns amigos que estão adotando a agilidade, ou ao chegar em alguns clientes, percebo que há dúvidas quanto à execução do refinamento dos cards (refining ou grooming, este último tem entrado em desuso, dado que em alguns países de língua inglesa a expressão tem sido relacionada a casos de assédio. Inclusive o Scrum Guide abandonou o uso da palavra em 2013).

Também há dúvidas quanto a importância deste processo: “Por qual razão devo usar no meu time?” , “É realmente útil?”. Acredito que o processo de refining é extremamente importante para o bom andamento de um projeto. Sua principal função é deixar as user stories melhor descritas, com o menor número de incertezas possíveis. Sua execução visa criar um maior alinhamento das expectativas das partes interessadas, deixando claro para todos o que será construído. Gera uma série de benefícios, como:

• Com user stories melhor descritas a previsibilidade de conclusão é mais clara;
• A chance de um imprevisto surgir durante o desenvolvimento e criar um bloqueio se torna menor;
• Todos do time de desenvolvimento ficam cientes do passo a passo para conclusão do requisito, por exemplo.

O ponto é que ainda é nebuloso para muitas pessoas a escrita de cards e a respectiva execução do levantamento.

Um entendimento que podemos ter acerca do assunto e que defendo é:

• Se o levantamento do card ocorre todo no mesmo momento, seja de planejamento, replenishment, refining ou outro nome que você costume usar. E começa a escrever o card ali, adicionando dúvidas, critérios de aceite e tudo nesse momento. Então sim, concordo que seu refining é uma reunião (ainda que toda reunião seja – ou deveria ser- um processo, hehe).
• Se o levantamento do card vem sendo feito antes da reunião, alguns dias antes você começa a levantar os impedimentos, dúvidas, critérios de aceite, possíveis bloqueios, integrações, etc para chegar com o card escrito. Ou seja, está fazendo um processo de levantamento do card, logo, refining se torna um processo.

A ideia deste texto é explicar, e defender, quais as vantagens de tratar o refining como um processo e não como uma reunião. Mas antes, o que é um processo? Um dos possíveis significados para processo é: “…um método, sistema, maneira de agir ou conjunto de medidas tomadas para atingir algum objetivo.”. No caso, o objetivo de um processo de refining é gerar user stories prontas para serem desenvolvidas.

Agora, vamos começar a parte legal. Qual a razão de transformar o refining num processo, e não uma reunião?

Acredito que haja algumas razões que façam com que o processo se sobressaia à reunião e crie um output com user stories melhores escritas ao final. Essas razões oneram menos o time de desenvolvimento, trazem um peso maior sobre a agenda do responsável pelo produto e do responsável pelo processo, entretanto flexibiliza para o restante do time. [Ok! Mas, como?]

Quando se define um processo de refining, deixando claro os passos para antes e depois da reunião, conseguimos atingir alguns pontos cruciais:

• Melhor preparo para a reunião com o time: [como?] Bem, ao saber que você terá uma reunião você normalmente se prepara (espero que sim), correto? Definindo o processo corretamente, você sabe quais passos precisará tomar, para estar preparado para o refining. Uma boa reunião, acredito que seja influenciada por alguns fatores: uma pauta bem definida, um time box fechado e um facilitador para que a reunião seja fluida;
• Otimizar o tempo do time: quando você se prepara para um refining, escrevendo os cards antes, realizando pesquisas e levantando possíveis dúvidas, você está reduzindo o tempo em que todos precisarão ficar juntos para fazer isso. Otimizando o tempo de todos os envolvidos;
• Reduz possibilidade de devaneios: quantas vezes você esteve refinando uma user story, e do nada alguém começou a devanear durante a reunião? Levando uma user story melhor descrita para o momento da discussão reduz as chances de alguém começar a puxar um debate de algo que não está no escopo do card.

Que ótimo, como eu realizo um refining?

Você deve estar se perguntando, não?

Uma coisa imprescindível é definir um processo para o refining (para não sermos muito “disruptivos”), e reduzir a confusão na cabeça de algumas pessoas. Costumamos dizer aqui na Plataformatec que dividimos o refining em duas etapas, sendo que ambas fazem parte do processo de refining: pré-refining e o refining em sí, isto é, o encontro para que o time feche o entendimento do que foi escrito na user story.

Opa, maravilha. Pré-refining e refining, mas o que seriam?

Chamamos de pré-refining todo o preparo tido para que a user story chegue mais redonda para o time. Costumamos começá-lo mais assíncrono, e realizando alguns passos.

Primeiro, como responsável pelo processo e auxiliando a pessoa de produto, costumo estudar o escopo de negócio para entender do que se trata a user story, de forma a ter o mínimo de conhecimento para escrever e questionar critérios de aceite, ou formas de implementação (falando de negócio, não de código). Os critérios de aceite são adicionados à user story, de forma que fique claro para todos os envolvidos o que é necessário para que o card seja tido como completo, ou seja, que a user story seja aceita como pronta.

Desta forma, é possível que já sejam levantadas dúvidas do produto dentro da user story. E esse é o segundo passo, conversar com a pessoa de negócio, passando o primeiro filtro no card, e anotando dúvidas que possam surgir relativo ao escopo do projeto ou da user story. Esses questionamentos ficam anotados no card, de forma que todo o time possa ver.

Em seguida, procuro algum dos desenvolvedores e converso sobre a user story, demonstrando o que já foi levantado, para que passemos por um segundo filtro da escrita. Nesta conversa com o desenvolvedor surgem as dúvidas mais técnicas, dúvidas de integrações, por exemplo.

A ideia neste passo, como dito anteriormente, é deixar a user story minimamente escrita de forma a otimizar o tempo de todos. Como o especialista em negócio e um dos especialistas técnico do projeto já foram consultados, em teoria os cards já possuem informações suficientes para que sejam levados para o refining. Caso ainda existam dúvidas que não foram sanadas, com grande risco de não serem respondidas durante o encontro, o ideal é que essas respostas sejam obtidas antes do mesmo.

Levantei todas as dúvidas, deixei o card pronto! O desenvolvedor pode puxar a user story?

Opa! Calma lá jovem Padawan, não é bem assim! Você validou a hipótese do card com apenas duas pessoas! O seu time provavelmente possui bem mais pessoas que isso! Agora sim, vamos ao encontro para refining!

Agora é onde há o acordo do time, que aquilo que está escrito na user story faz sentido, e é entregável! É o momento em que o responsável pelo negócio dá sua palavra de que é aquilo que ele espera como produto do card desenvolvido, e também é o quando analistas de qualidade e desenvolvedores entram em acordo do que será construído e testado.

Quais os passos de um refining?

Calma! Queria apenas deixar claro o que faremos a partir de agora! Já que estamos entendidos, vejamos agora algumas dicas de como fazer isso!

Primeiro de tudo, há algo muito importante que eu defendo: traga as pessoas certas para as reuniões certas. No caso, como estaremos falando do desenvolvimento, é imprescindível a participação de desenvolvedores. Falaremos também de testes, então um analista de qualidade é muito importante! E também falaremos de incrementos ao negócio, logo, a participação do responsável pelo produto é essencial! Entretanto, não há a necessidade de participarem todos os desenvolvedores, por exemplo. A user story deve estar escrita de forma clara o suficiente para que alguém que não participou do encontro seja capaz de ler e compreender o que deve ser feito. Na equipe que trabalho atualmente, utilizamos o valor máximo de 50% dos desenvolvedores na reunião. Veja bem: máximo, há momentos em que participam menos.

É indispensável que este momento seja síncrono! De forma que estejam todos alinhados no mesmo momento, e saiam sem dúvidas quanto ao que foi discutido (as chances de restarem dúvidas são maiores em uma discussão assíncrona, por exemplo). Com um encontro síncrono, as pessoas costumam entender melhor o que está sendo discutido.

Outro dois pontos cruciais que devem andar juntos: objetivo e time box! Antes de entrar na discussão do refining deixe bem claro qual o objetivo da conversa, e qual o time box vocês terão para isso. Algo como: “Pessoal! Temos 3 user stories que precisam ser refinadas! Usaremos 20 minutos para cada uma!”. Desta forma, o time sabe que precisará otimizar seu tempo para que a discussão gere frutos dentro deste tempo definido. Outra coisa bem legal de se fazer, é deixar um computador com um timer regressivo contando este time box (basta dar um Google com o termo “timer” e pronto! Mágica realizada!). Desta maneira, a medida que o time evolui, haverá alguém atento a isso e cobrando os demais.

Lembre-se, este é o momento de entendimento do time. É onde todos devem estar comprometidos quanto ao que será entregue, e como será entregue. As user stories devem sair bem descritas para que entrem dentro do ciclo de desenvolvimento. Aconselho fortemente que, caso ao final destes 20 minutos ainda restem muitas dúvidas, incertezas ou que o time não esteja seguro quanto a entrega, que o card não entre no ciclo de desenvolvimento, e passe por um novo processo de refining. Não queremos cards com alto grau de incerteza dentro do processo, queremos?

E você, como lida com o refining dentro do seu time? Você acha que é uma reunião? Um evento? Um processo? Conta pra gente aí nos comentários como você lida com isso dentro do seu time!

The post O que aprendi sobre o Refining de User Stories em projetos first appeared on Plataformatec Blog.