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.

Then, suddenly, the P.O. discovers that the features D and E were developed by a competitor and that you are losing users because of that. Therefore, the P.O. decides to deprioritize story C. This is only an example of why a card might be deprioritized in the middle of its development. But now that it was deprioritized, what happens to story C?

Well, to answer that, let me make a parallel with an alcohol-based perfume company.

In the backlog column, the company has the bottle ready to be filled but no fluid yet. When the bottle starts to be filled, the card goes to “in progress”. When the bottle is totally filled, the bottle is closed and the card goes to done.

So what happens if another perfume suddenly receives a priority greater than the priority of the bottle being filled? Well, as we all know, alcohol-based fluids are volatile and, with time, they will completely evaporate, requiring them to be refilled.

The same happens with the story and its code. With time, the code that is inside the story gets obsolete and unnecessary, losing its value. What to do with the story depends on the following rationales:

• How long will the story C stay in the same stage?
  • If the story stays too long in the same stage, some part of the work may get useless, therefore, you could just remove it from the board and put it back on backlog, since some refining might be needed when this story is chosen gain.
  • If the story will stay there for a short time, you may want to leave it there and, when it can be worked on, you may still use what was already developed.
• What is the value story C will generate after being done?
  Let’s say that the return on the development of that feature is small. Is it worth to pause its development and run the risk of investing even more money on the development later? Will the return on its development be greater than the development time?

For this to be true, the following needs to happen (visualized in the chart below):

• $ spent with initial development + $ spent with rest of the development < story C $ return
  • The amount spent with rest of the development will increase with time, since the initial development starts to lose value.
• If the amount spent is greater than the return, it is better to ignore the functionality. However, this math is not as easy as it seems… You need to account for risks, increased revenue, increase the number of users of your product, etc. So be careful!

Therefore, based on those, you can possibly do four things:

• Leave it on the column and restart it when its priority arrives
  The pause will be fast and will not harm the development of the card. In this case, it is important to flag the story somehow so that the whole team can see that the story is “blocked” by the P.O. due to its prioritization.

• Take it back to the backlog, and restart it when its priority arrives
  The pause will be long and the card will need more refinement.

• Finish it first, before getting another card
  The card is almost done, and if you stop it, it will not generate value anymore.

• Cancel the card
  The card is a long way from being finished, and its value is too small to pay for the time it will be paused.

It is also important to notice that this should NOT be a common thing in your process. If it is happening too often, you may need to work on your prioritizations!

What are your thoughts on the topic? Leave your comments below

The post The user story in development was deprioritized, what now? first appeared on Plataformatec Blog.

Então, no meio do seu sprint, o P.O. descobre que as features D e E foram lançadas por um concorrente e que vocês estão perdendo usuários por isso. Pensando nisso, a P.O. decide despriorizar a história C. Isso seria apenas um exemplo de como um card pode ser despriorizado no meio do seu desenvolvimento. Mas, e agora, o que acontece com a história C?

Para responder isso, deixe-me fazer um paralelo com uma companhia de perfumes a base de álcool.

Na coluna de backlog, a companhia tem a garrafa pronta mas sem fluído algum. Quando a garrafa começa a ser enchida, o card é passado para “in progress”. Após a garrafa estar cheia, ela é lacrada e o card vai para “done”.

O que acontece então se outro perfume tem sua prioridade elevada a um nível maior do que o que está sendo abastecido? Bom, como sabemos, fluídos com base em álcool são voláteis e, com o tempo, evamporam totalmente, sendo necessário que se reabasteça o recipiente.

O mesmo acontece com uma história e seu código. Com o tempo, o código que compõe tal história se torna obsoleto e desnecessário, perdendo o valor que tinha outrora. Neste caso, o que fazer com a história despriorizada depende dos seguintes pontos:

• Quanto tempo a história C continuará no mesmo estágio?
  • Se a história permanece muito tempo no mesmo estágio, alguma parte do trabalho já feito pode se tornar desnecessário, portanto, você poderia apenas removê-la da coluna e colocá-la de volta ao backlog, já que algum refinamento pode ser necessário para que essa história seja desenvolvida novamente.
  • Se a história vai ficar por um curto período de tempo em tal coluna, você pode optar por deixá-la lá e, quando sua hora chegar, pode continuar aproveitando o que já havia sido desenvolvido.
• Qual o valor que a história C vai gerar quando pronta?
  Digamos que o retorno gerado pelo desenvolvimento de tal feature seja pequeno. Será que vale a pena pausar seu desenvolvimento e ter o risco de investir ainda mais dinheiro no seu desenvolvimento em outro momento? O retorno gerado será maior do que o tempo total de desenvolvimento gasto?

Para que isso seja verdade, o seguinte precisa acontecer (observado na imagem abaixo):

• $ gasto com o desenvolvimento inicial + $ gasto com o resto do desenvolvimento < retorno da história C
  • A quantia gasta com o resto do desenvolvimento aumentará com o tempo, já que o desenvolvimento feito anteriormente vai perdendo valor.
• Caso o retorno seja menor do que o gasto, é melhor ignorar a funcionalidade. No entanto estes cálculos não são tão simples como parecem… Você precisa levar em conta riscos, aumento na receita, aumento no número de usuários, etc… Então tenha cuidado com essa ação.

Portanto, baseado no que já foi dito, você pode ter as seguintes ações a respeito do card C:

• Mantenha-o na coluna “in progress” e recomece o trabalho quando sua prioridade for retomada
  Essa pausa será rápida e não afetará o desenvolvimento da feature. Neste caso é importante deixar visível de alguma forma no quadro que essa história está “bloqueada” por motivos de priorização.

• Ponha-o na coluna de backlog novamente, e recomece quando necessário
  A pausa será longa e o card precisará de um novo refinamento.

• Termine-o primeiro, antes de começar outra história
  O card está quase pronto e, caso você pare seu desenvolvimento, quando pronto, seu valor será menor do que o gasto no seu desenvolvimento.

• Cancele o seu desenvolvimento
  A história está muito longe de ser terminada, e seu valor final é muito pequeno para pagar o tempo que ela ficará pausada.

É importante também notar que isso NÃO deve ser algo comum em seu processo. Se coisas como essa estão acontecendo frequentemente, você pode precisar melhorar suas priorizações!

O que acha do que foi discutido aqui? Deixe seus comentários abaixo!

The post A user story em desenvolvimento foi despriorizada, e agora? first appeared on Plataformatec Blog.