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.

Neste post, compilei os erros mais comuns que os times cometem quando usam métricas, assim você saberá o que evitar quando adotá-las.

1 – Não ter reação

Se você coleta métricas, você precisa usá-las de alguma maneira. Portanto, um dos erros mais comuns é não reagir ao que as métricas apontam. Métricas podem lhe dar insights e, para reagir, você precisa entender como elas funcionam e o que significam.

Para mais informações sobre como usá-las, dê uma olhada nesses posts:

• Cumulative Flow Diagrams e Lead Time Breakdown
• Throughput e gráfico de Burnup
• O que Lead Time fala sobre seu projeto

2 – Usar métricas com poucos dados

Outro grande erro é utilizar métricas quando não existem dados suficientes para suportar suas conclusões. No começo de um projeto, ou quando começamos a coletar métricas, geralmente ficamos ansiosos para melhorarmos nosso processo. No entanto, com uma quantidade baixa de dados, as métricas não são tão confiáveis.

Uma boa dica seria observar o comportamento dos dados e verificar se algum padrão já se formou. No caso de ter um padrão, você provavelmente já pode começar a usá-las e atuar em cima dos dados.

É importante notar também, que esse não é o único método, mas em geral, eu esperaria no mínimo 3 semanas para começar a questionar o processo. — Mais sobre como agir baseado em métricas pode ser encontrado em nossos blog posts.

Uma possível saída, caso você tenha um projeto curto e precise de métricas o quanto antes, seria utilizar métricas diárias. Temos um post falando sobre isso também: Pros and cons of using daily metrics

3 – Usar métricas sem considerar o contexto

Esse é um erro muito comum, não só no desenvolvimento de software, mas em toda conclusão construída estatisticamente. Números sozinhos são usados apenas em álgebra ou cálculo. Você precisa do contexto nos quais os números estão inseridos para entendê-los. Com isso em mente, para dizer se a vazão do seu projeto está saudável ou não, para entender se a variância do seu lead time é muito grande ou não, observe. o. contexto.

4 – Comparar métricas entre times

Esse problema está de certa forma relacionado com o 3. Não faz sentido falar algo como “time A está melhor que o time B pois eles têm uma vazão maior”. E se o time A possui 10 pessoas enquanto o time B possui 3? E se o time A trabalha com o desenvolvimento simples de um website e o time B com algum deep learning complexo? Tenha cuidado.

5 – Ter métricas individuais

Esse é um problema de microgerenciamento e está relacionado com os erros 3 e 4. Pessoas, tentando melhorar o máximo possível o processo, acabam medindo métricas de indivíduos. É praticamente impossível comparar pessoas diferentes. Apenas não o faça. Se o fizer, estará afetando o ambiente do seu time e vai até diminuir a produtividade geral. Além disso, as métricas do processo devem ser usadas para entender a saúde do processo.

6 – Simplificar demais a leitura das métricas

Ainda relacionado ao contexto, mas agora com o contexto dos números. Por exemplo, se você comunica às outras pessoas que um time entrega em média 4 histórias por semana, é só isso, você não está dizendo nada do time. Talvez os dados sejam {0, 0, 0, 0, 0, 24}, talvez sejam {4, 4, 4, 4, 4, 4}. Então, tenha certeza que você não está simplificando demais a leitura das suas métricas e que todo o seu ferramental constrói a imagem que você está tentando desenhar.

7 – Usar apenas as métricas convenientes

Relacionado ao erro anterior, pessoas reportam as métricas para seus gerentes/diretores mostrando apenas os “números bons”. Então, se a vazão aumenta, você mostra apenas a vazão. Se o backlog diminui, você mostra apenas isso. Seja transparente. Caso contrário, eles estarão vivendo uma mentira e, quando a verdade vier à tona, você não conseguirá se explicar.

8 – Usar apenas os dados convenientes

Outro problema é usar apenas métricas com os dados que você quer. Recortar os dados para ter resultados mais relevantes, como considerar apenas os últimos 2 meses em um projeto de 10 meses, pode fazer sentido já que o contexto de um projeto muda com o tempo e você quer ter certeza que está considerando o contexto certo nos seus resultados. No entanto, tenha cuidado quando fizer isso, pois você pode estar escondendo muitas informações úteis de você mesmo.

9 – Falsificar métricas

Este é de longe o mais comum que vejo. Pessoas tem medo de mostrar os gargalos ou problemas e mascaram resultados (às vezes sem perceber). Agrupam histórias para diminuir backlog, quebram histórias desnecessariamente para aumentar a vazão ou até mesmo mudam pontos de história (quando os usam) para manter a velocidade do time “constante”. Com isso, você está apenas enganando você mesmo e não está melhorando o processo.

10 – Ter metas baseadas em métricas

Esse é um assunto muito polêmico. As métricas não foram feitas para serem metas. Foram feitas para ajudar o time a entender como o processo está e tentar melhorar o fluxo. Metas relacionadas à métricas podem colocar muita pressão no time e ter o efeito contrário ao desejado, fazendo com que o time cumpra uma métrica mas desregule todo o processo. Então, antes de definir uma meta com base em métricas, pense se a meta precisa ser tão “baixo-nível” e, caso precise, confirme com o time se é possível, de fato, atingir essa meta ou se existe algum impedimento inerente ao precesso.

11 – Tentar diminuir o lead time à todo custo

Lead time (LT) é uma métrica que serve para entendermos quanto tempo um item leva para passar por todo o processo. Então, existem duas perguntas que podem ser feitas aos dados:

• O LT está muito alto?
• A variância do LT está muito alta?

A segunda pergunta é muitas vezes mais importante para o time do que a primeira. Ter um LT com distribuição {0, 5, 2, 8} é geralmente pior do que ter uma como {4, 4, 4, 4}. Na primeira os dados não são confiáveis o suficiente para se ter uma predição assertiva, enquanto no segundo você tem maior probabilidade de acertar. No entanto, não esqueça de olhar para o seu contexto!

12 – Tentar aumentar a vazão ao invés de focar na eficácia

Ser eficaz é fazer a coisa certa. Vazão não é importante se você não está fazendo a coisa certa. Então, foque no seu produto, no que é melhor para ele, antes de se importar com o quão rápido você entrega.

O que achou desses erros? Já cometeu algum deles? Deixe seus comentários abaixo!

The post 12 Erros comuns no uso de Métricas de Processo first appeared on Plataformatec Blog.

Neste blog post, apresentarei 2 valiosas técnicas para que você possa compreender de forma holística o fluxo de desenvolvimento de software de uma equipe.

1. CFD

Segundo Brodzinski, Cumulative Flow Diagram (CDF) é um dos gráficos que oferece rápida visão geral do que está acontecendo num projeto ou produto.

O CFD é um instrumento valioso para rastrear e prever projetos ágeis. Ao usá-lo, você pode verificar rapidamente o status atual: quanto trabalho foi feito, o que está em andamento e quanto tempo será necessário para que determinado escopo seja concluído.

A estrutura do gráfico é muito simples. O eixo horizontal representa um período de tempo (semanas, sprints, etc) e o vertical indica, de forma acumulada, o número de itens no processo (total de tarefas, total de histórias, etc.). Cada área pintada no gráfico está relacionada a uma etapa do fluxo de trabalho (backlog, em progresso, finalizado, etc) e as curvas são basicamente o número de itens acumulados em tais etapas.

Para demonstrar como usamos o CFD na Plataformatec, descreverei o exemplo de um projeto. Nesse caso, tivemos um fluxo de desenvolvimento composto pelas seguintes etapas:

• Backlog: itens que precisavam ser refinados.
• Ready to Dev: itens com critérios de aceite definidos e com uma definição explícita de “feito”.
• Developing: itens em desenvolvimento.
• Testing: itens sendo verificados e validados.
• Accepted: itens lançados em produção.

Neste projeto, utilizamos o CFD para: (1) comunicar o progresso; (2) identificar os gargalos do processo; (3) gerenciar as filas. Escolhemos acompanhar o andamento semanalmente, pois precisávamos informar o status do projeto para o CTO nessa frequência.

Os próximos 3 diagramas representam o projeto no início (primeiras 7 semanas), no meio (11ª semana) e no final (semana 22).

O começo

No início do projeto, a equipe enfrentou uma situação em que a relação entre a chegada e a saída dos itens não era proporcional — o throughput médio da equipe era de 3 itens por semana e o escopo aumentava 7 itens por semana. Este comportamento é ruim, porque significa que o número de itens entregues dificilmente será igual ao número de itens do escopo. Naquele instante, a equipe e a PO discutiram soluções para que a taxa de crescimento do escopo acompanhasse a cadência de entrega.

Outra informação que pode ser extraída do gráfico é que alguns itens foram criados (estágio de Backlog), mas não foram detalhados (Ready to Dev). Neste caso, o time refinou junto da PO um conjunto de itens e os deixou prontos para serem trabalhados.

O meio

Ao analisar o CFD no meio do projeto, é possível observar que as etapas de desenvolvimento (Developing) e testes (Testing) não apresentavam acúmulo entre as etapas (sobrecarga). Comparado com as primeiras 6 semanas (início do projeto), a relação entre itens criados e entregues passou a ser a mesma: 3 itens por semana.

A equipe sabia que o throughput precisava aumentar. Além disso, o projeto ainda apresentava indefinições — 15 itens não estavam preparados para serem desenvolvidos. Um dos causadores de tal situação foi a alta incerteza no design da aplicação.

O fim

Uma coisa interessante que percebemos no final deste projeto foi que o trabalho na etapa de teste fluiu bem. Olhando para o gráfico, é possível reconhecer que as linha azuis (etapa de Teste) desapareciam rapidamente. Isso ocorreu porque a interação dentro do time foi intensa. Na semana 19, a equipe e a PO alinharam que nenhum novo item seria incluído no escopo, porque o prazo de entrega estava chegando.

Outra informação que pode ser observada no gráfico de CFD acima é que a equipe não concluiu todas as histórias previstas no escopo — a etapa “Accepted” não ocupou todo o diagrama. Nesse caso, a equipe de desenvolvimento do nosso cliente assumiu os 5 itens que estavam em progresso (2 em desenvolvimento e 3 em testes).

Vale compartilhar que os itens entregues geraram uma solução de qualidade e alinhada com o que nosso cliente precisava.

Adotamos como boa prática verificar o CFD semanalmente para impulsionar melhorias dos nossos processos. Tal diagrama se mostrou um excelente companheiro para discussões sobre limitação e gerenciamento de WIP.

2. Lead time breakdown

Para aprimorar reuniões de acompanhamento do projeto ou retrospectivas, criamos uma visualização chamada “lead time breakdown“.

Resumidamente, este gráfico permite que o time avalie, compare e analise em detalhes a latência entre o início e o término de cada uma das etapas do processo de desenvolvimento, para cada item de trabalho que passa pelo fluxo (bugs, histórias do usuário, etc).

Esse tipo de visualização permite analisar o processo com mais detalhes se comparado com a análise do CFD. Geralmente, o lead time breakdown é utilizado para responder questões como:

• O que está acontecendo com os itens que estão em progresso?
• Existe algum tipo de impedimento atrapalhando a fluidez do time?
• O time está lidando com algum gargalo no processo (exemplo: sobrecarga na etapa de testes)?

Criar a visualização é bem simples. No eixo vertical estão os dias de trabalho; no horizontal, os itens de trabalho em progresso ou já entregues pelo time (exemplo: o montante de histórias do usuário monitorados pelo quadro Kanban). Para representar cada uma das etapas do processo, é utilizado o gráfico de barra acumulado.

Vamos ver um exemplo a partir de um projeto real. A equipe tinha o fluxo de trabalho com as seguintes etapas:

Neste fluxo, há etapas com o objetivo de medir gargalos criados pelas etapas de QA (Waiting for QA) ou pelo responsável pelas aprovações das entregas dos itens (Waiting for Review). O gráfico de lead time breakdown do exemplo ficou assim representado:

Podemos identificar que quase todas os itens do exemplo necessitam de mais de 3 dias para serem revisados (comportamento visto pela barra roxa). Em alguns casos, tal tempo de passagem pode ser inaceitável, dado a criticidade da entrega.

Outro ponto interessante é a alta variabilidade no lead time da etapa de codificação (barra azul). Neste caso, o time provavelmente trazia para o fluxo de desenvolvimento itens com pouca padronização.

Durante este projeto, a equipe sofreu pois tinha que compartilhar um especialista de teste (repare na altura das barras exibidas em amarelo no gráfico). À medida que a equipe e os stakeholders acessavam periodicamente o gráfico, o problema ficava evidente para todos e soluções foram discutidas para resolvê-lo. Uma delas foi o Scrum Master exercer o papel de especialista em teste, em alguns períodos do ciclo de vida do projeto.

Como boa prática, em todos os projetos que atuamos, temos utilizado o gráfico de lead time breakdown periodicamente para entender o status atual da equipe. Tal ferramenta tem sido útil para:

• Guiar discussões recorrentes de como remover desperdícios no processo.
• Promover melhorias no processo baseadas em dados.
• Deixar evidente o tempo de espera ao longo do desenvolvimento dos itens de trabalho.
• Analisar mais facilmente as demandas que estão próximas de serem finalizadas.
• Utilizar as informações para apoiar retrospectivas quando a pauta é relacionada ao processo.
• O que o time precisa manter?
• O que o time precisa mudar?

Concluindo

A visualização do fluxo através do CFD ou do lead time breakdown fornece uma visão quantitativa e qualitativa de problemas potenciais no processo de desenvolvimento de software. Encontrar soluções é uma outra história.

Para aprender mais sobre o CFD, recomendo 4 boas referências:

• O excelente artigo, Cumulative Flow Diagram do Pawel Brodzinski.
• O livro do Daniel Vacanti, Actionable Agile Metrics for Predictability.
• The Cumulative Flow Diagram in a nutshell.
• Minha publicação recente e em português, Métricas Ágeis – Obtenha melhores resultados em sua equipe.

E você, como tem utilizado o CFD? Qual a sua opinião sobre a visualização do lead time breakdown? Compartilhe sua opinião nos comentários abaixo!

The post Métricas Ágeis: Cumulative Flow Diagrams e Lead Time Breakdown first appeared on Plataformatec Blog.

Nossa contribuição se expandiu. Palestras e workshops em eventos agile tornaram-se parte das atividades do nosso time, e para firmar nosso compromisso com a comunidade ágil, estamos patrocinando o Lean Kanban Brazil 2017. \o/

Lean Kanban Conferences

A Lean Kanban Conferences Internacional apoia conferências em diversos países, e Brasil está na lista. Com temas relacionados a gestão, a programação da segunda edição brasileira está dividida em três.

1. Webinars

Democrático e inclusivo, a organização preocupou-se em eliminar a restrição geográfica. Quem não pode participar do evento em São Paulo, tem opção de webinars pré-conferência.

No dia 17/10, nosso carismático agile consultant, Breno Campos falará sobre priorização de backlog e desenvolvimento de produtos/plataformas digitais no webinar Cost of Delay – Você perde por esperar. Ele vai mostrar que atrasos de projetos significam perda de grana $$$. Você levará um choque de realidade. o.O

2. Workshops

6 workshops focados em gestão, com duração de 4 horas, ocuparão salas no Espaço Franklin Covey (mapa).

Claro que o Raphael Albino — professor, mestre, doutorando, autor de livro e nosso agile consultant — estará lá no dia 27/10 promovendo o workshop Vamos falar sobre Métricas de Processo? Você não terá moleza. Vai por a mão na massa, praticar de verdade! Se conhecimento é poder, você será poderoso(a) depois dessa aula. :bulb:

3. Palestras

Estão dividas em 2 tracks, marcadas para o dia 28/10, no Grand Mercure Ibirapuera (mapa). Você terá oportunidade para networking nos coffee-breaks e almoço.

Pensa que acabou? Tem mais!

Nosso estande

Vamos compartilhar mais conhecimento nas Coaching Sessions que teremos no nosso estande.

Sério! Será imperdível! Sabe por quê? Porque não são coaching sessions sobre o que queremos ensinar. Abordaremos O QUE VOCÊ QUER APRENDER!

Para isso, você precisa nos ajudar a te ajudar (Tropa de Elite, caveiraaa!). Como? Basta responder neste formulário o tema do seu interesse.

Você quer o “faz-me rir” (faca na caveira)? Que tal 20% de desconto na compra da entrada?

Clique aqui e responda o que você quer ver nas Coaching Sessions

The post Estamos patrocinando o Lean Kanban Brazil 2017 first appeared on Plataformatec Blog.

É comum no ambiente de equipes que trabalham com a construção ou evolução de produtos a necessidade da definição de objetivos, a projeção de resultados esperados e o planejamento de entregas. Se você convive com tais desafios, confira a seguir uma dinâmica na qual obtive ótimos resultados no processo de concepção de OKRs.

O que é OKR e para o que serve

Bom, antes de escrever sobre o assunto, vale a pena definir o termo OKR.

Segundo definição do pessoal da Lean Performance, OKR — do inglês Objectives and Key Results –, utilizado no Silicon Valley por empresas como Google, Facebook, Linkedin, Intel etc, é um framework para definir metas. Trata-se de um sistema simples para criar alinhamento e engajamento em torno de metas mensuráveis e dinâmicas, tipicamente definidas trimestralmente.

OKRs são uma ótima forma das organizações criarem e comunicarem objetivos e resultados. Seu maior propósito é promover conexão entre os objetivos da empresa, do time e dos indivíduos a partir de resultados mensuráveis, fazendo com que todos se movam na mesma direção.

Em resumo, utilizar OKRs adequadamente auxilia no aumento do alinhamento e do engajamento entre as pessoas, e torna o processo de planejamento estratégico mais ágil, com maior cadência de revisão, adaptação e participação de toda a equipe.

O alinhamento e engajamento entre as pessoas aumentam, pois o time passa a fazer parte do direcionamento do produto, gerando maior senso de pertencimento em cada um.

Certa vez, no projeto de um dos nossos clientes, após a equipe definir os OKRs, fui informado pelo QA que o bug que estava ocorrendo no ambiente de produção iria impactar diretamente um dos OKRs, se não fosse corrigido imediatamente. Esse fato me deixou realmente surpreso, pois jamais veria uma ação assim se não compartilhassemos a responsabilidade com todo o time.

Com a aplicação de OKRs, ganhamos mais uma ferramenta na priorização do backlog e, mais importante, temos o escopo direcionado para um objetivo comum.

Ao aplicar dinâmicas de OKRs, espera-se que a empresa, equipe ou pessoa tenha em mãos:

1. Objetivos: Possuem, por essência, característica qualitativa, inspiracional, com prazo definido e apontem para metas, ou seja, dizem para onde se deve ir.
2. Key results: Quantificam toda a ideia inspiracional. Devem ser atingíveis, mensuráveis e realistas. Em outras palavras, indicam como será possível atingir os objetivos.

Beleza Raphael, entendi os conceitos e percebi que isso pode ser útil, mas você pode dar um exemplo?

Objetivo: Aumentar o número de clientes a partir de melhor experiência de uso do aplicativo.

Período: Primeiro trimestre de 2017.

Key results:

• Aumentar a taxa de conversão mobile global de 5% (último trimestre de 2016) para 10%.
• Aumentar o volume de sessões entrantes de 161 mil (último trimestre de 2016) para 240 mil.
• Vender 10.000 mil licenças básicas.
• Vender 500 licenças premium.

De onde vamos tirar esses indicadores?

Aqui vai um ponto importante: para definir bons key results, que sejam mensuráveis e reflitam a situação real, é essencial que a organização seja orientada a dados e indicadores. Basicamente, a empresa deve possuir métricas de produto que assegurem uma tomada de decisão assertiva, dando a real noção de direção e esforço; e não somente baseada em intuições e experiências. Esses dados ajudam a definir as estratégias do próximo período com maior segurança e a otimizar os recursos empreendidos.

Os dados devem direcionar as seguintes questões:

• Quais desafios temos à frente? Quais indicadores estão ruins? O que devemos fazer para melhorar tal indicador? Ex: Diminuir o churn, aumentar prospects e leads, melhorar os processos operacionais etc.
• Qual frente do produto precisamos melhorar para atingir o objetivo X da organização?
• Quais riscos esses dados evidenciam e onde devemos manter a atenção?

Feita essa introdução, vamos para a dinâmica de definição dos OKRs para que você possa aplicá-la e aprimorá-la.

Parte 1 – Compreendendo o negócio

O primeiro tópico a ser discutido diz respeito a revisão ou criação do modelo de negócios do produto.

Baseado nas personas, a equipe poderá analisar os canais, formatos de relacionamento com o cliente, fontes de receita, atividades chave, recursos chave, parceiros chave e estrutura de custo.

Para levantar tais informações, sugiro que você leve as seguintes perguntas:

• Personas: qual o perfil de clientes que utilizam o produto?
• Canais: como os clientes chegam ao produto, geralmente?
• Formatos de relacionamento: como ocorre o relacionamento dos usuários com o produto atualmente?
• Fontes de receita: quais são as fontes de receita atuais?
• Atividades chave: quais as principais atividades que precisam ser realizadas no dia a dia da operação para que o produto possa entregar o valor que se propõe?
• Recursos chave: o que o produto possui de diferencial competitivo?
• Parceiros chave: quais parceiros ajudam a empresa a viabilizar/alavancar o produto?
• Custos: qual a estrutura necessária para tornar a operação do produto viável?

Assim, a equipe terá maior clareza sobre o estágio atual do produto. Caso o produto não possua um modelo de negócios, não deixe de desenvolver um. Uma dica de leitura para que você possa construir um é o livro Business Model Generation.

Após a revisão do modelo de negócio, o próximo passo será analisar as principais métricas do produto. Cada pessoa da equipe poderá explorar o produto a partir de:

• Informações financeiras: churn, ticket médio, custo de aquisição do cliente etc;
• Comportamento de acesso: número de acessos, taxa de saída, tempo despendido nas páginas do fluxo de venda, origem do tráfego, dispositivo utilizado para acessar o fluxo de venda etc;
• Perfil do cliente: dados demográficos, nível de serviço contratado, faixa etária etc.

A partir das métricas de produto, cada membro da equipe deverá identificar pontos de melhoria e pontos onde o produto aparenta estar bem.

Parte 2 – Definindo os OKRs

Feita a análise das métricas de negócio e do modelo de negócio, levante com a equipe os potenciais objetivos que serão trabalhados no período de tempo (exemplo: próximo trimestre).

Se você estiver facilitando a discussão, tenha em mãos as seguintes dicas antes da equipe determinar os objetivos:

• Tenha poucos objetivos (de 3 a 4). Motivo? O trimestre, por exemplo, é curto para se assumir muitos objetivos.
• Relacione os objetivos do produto com os objetivos da empresa.
• Relacione os objetivos com problemas e necessidades reais.
• Utilize as métricas de negócio para definir os objetivos.

Caso os objetivos levantados sejam complexos ou grandes, vale a pena fomentar discussões para que a equipe simplifique. O mantra que deve ser pensado aqui é: pequenos incrementos que geram valor econômico para o negócio.

Para medir os objetivos, a equipe deverá elencar quais serão os key results que serão acompanhados ao longo do período. Para que a equipe tenha um norte:

• Defina poucos key results (de 3 à 4). Motivo? Se o objetivo precisa de muitos itens para ser medido é provável que ele seja complexo demais.
• Os key results devem ser expressos através de números.
• Quais resultados garantirão que alcancemos nossos objetivos?

Parte 3 – Definindo um roadmap

Dado que os objetivos e os key results estão definidos, a equipe pode se questionar: bom, e agora, o que vamos fazer para atingir nossos OKRs?

Sugiro como última parte da dinâmica o desenvolvimento de um roadmap, a fim de identificar entregáveis macro e quando eles deverão ser entregues ao longo do período (ex: trimestre).

Técnicas de brainstorming e story mapping ajudam a ter uma ideia de cronologia e dependência entre as possíveis funcionalidades que serão construídas para alcançar os OKRs.

Antes que alguém me crucifique dizendo que não estou sendo lean, gostaria de deixar algo claro. O roadmap criado será uma referência que COM CERTEZA (repita, C-O-M C-E-R-T-E-Z-A) sofrerá alterações ao longo do tempo por conta das mudanças e experimentações que acontecerão para atingir os objetivos e key results definidos.

Conclusão

A estrutura de OKR pode ser replicada no nível empresa, equipe e, até mesmo, indivíduo. Uma dica que sempre compartilho é: comece com poucos objetivos e trace em torno de 3 à 4 key results. O motivo? Foco. Quanto mais direcionado, mensurável e acionável for a sua estrutura de OKR, maiores serão as chances de alcançar o planejamento desenvolvido.

Lembre-se que os OKRs devem ser revistos com frequência para que o time possa tê-los sempre em mente e, juntos, decidirem onde despender esforços para caminharem na direção correta.

É essencial que a empresa possua uma cultura questionadora, desapegada de ferramentas e soluções revolucionárias e tenha um ambiente que promova aprendizado com as falhas, pois certamente haverão erros no início.

A dinâmica que apresentei teve como objetivo conectar negócio, resultados atuais e futuro (OKRs + funcionalidades).

E você, como tem aplicado dinâmicas de OKR? Compartilhe os resultados e desafios.

Até próximo dilema

Algumas referências:

• Metas Ágeis com OKR
• The Art of the OKR
• OKRs
• The Basics of OKR – Google’s Secret Sauce

The post Dilemas de PO: como definir OKRs em equipes ágeis first appeared on Plataformatec Blog.

Neste post, vou apresentar como usamos os gráficos de Throughput e Burnup na Plataformatec, durante o ciclo de vida de um projeto.

Aprendendo a partir do Throughput

A LeanKit define Throughput como o número médio de unidades processadas por unidade de tempo. No fluxo de desenvolvimento de uma equipe, os exemplos podem ser “cartões por dia”, “cartões por semana” ou “cartões por mês”.

Uma observação importante a respeito o Throughput é que a métrica difere do “Velocity” (quantidade de story points entregue por iteração ou sprint) utilizado no Scrum.

Na Plataformatec, consideramos Throughput como o número de itens (por exemplo, história do usuário) entregues por semana.

Geralmente, analisamos o Throughput para responder questões como:

• Quantos itens de trabalho a equipe entrega por semana?
• O time está criando uma tendência crescente de entrega?
• Algum fator tem bloqueado a capacidade de entrega da equipe?

Vamos ver um exemplo prático. Imagine uma situação que você, como Gerente de Desenvolvimento, precisa ajudar o time a explorar o Throughput passado a fim de gerar melhorias futuras.

Primeiramente, podemos observar no gráfico acima que somente em 15% das semanas (4 de 27) a quantidade de itens entregues foi zero (0).

Além disso, é possível extrair mais informações do gráfico de tendência. Caso o Throughput esteja em crescente, a equipe está aumentando o número de itens entregues em uma semana. Se a tendência é de queda, pode colocar em risco o prazo de entrega de um projeto. Um limite inferior pode ser estipulado como forma de fornecer um indicador de quando ações corretivas podem ser necessárias. Nesta equipe, o Throughput aumenta nas primeiras semanas, seguida de uma ligeira queda e, finalmente, estabiliza-se.

Olhando para a distribuição de Throughput da equipe temos uma situação em que a média (linha verde), a moda (linha laranja) e a mediana (linha laranja) possuem quase o mesmo valor (aproximadamente dois). Portanto, é razoável dizer que o time, em geral, entrega dois itens por semana.

Outra forma de validar o argumento sobre a capacidade de entrega da equipe é buscar o percentil 80 (linha cinza). Ele nos diz que apenas em 20% das semanas, a equipe conseguiu entregar mais de três itens por semana.

Uma boa prática que definimos para os projetos na Plataformatec é uma verificação semanal do Throughput, como um processo de compreensão das causas que afetam o ritmo de entrega. Geralmente, o Throughput de uma equipe cai pelos seguintes motivos:

• Requisitos ruins — exemplo, baixa qualidade nos critérios de aceite de histórias de usuário;
• Dívidas técnicas — exemplo, necessidade de refatorações inesperadas;
• Gargalos do processo — exemplos, especialista de testes sobrecarregado, pipeline de implantação falho;
• Backlog com baixo nível de itens prontos para desenvolvimento;
• Mudança de escopo — por exemplo, aumento no escopo de uma história de usuário.

Olhando para o gráfico de Burnup

O gráfico de Burnup é uma ferramenta valiosa para gerenciamento do escopo. Ele apresenta a quantidade de trabalho entregue por uma equipe e, fornece mais informações do que o Burndown, pois combina escopo e total de entrega na mesma visualização.

É comum ver gráficos de Burnup com linha de tendência para estimar o prazo de entrega do escopo que está sendo analisado.

Tenho visto Product Owners e Agile Coaches projetando cenários baseados em três perspectivas:

• Pior caso: projetar a performance futura da equipe com base no menor Throughput histórico.
• Melhor caso: considerar que a equipe atuará no futuro com base no maior Throughput histórico.
• Caso mais provável: considerar que a equipe terá no futuro um comportamento semelhante ao Throughput “médio” (recomendo a leitura do post que escrevi sobre o motivo pelo qual você deve ter cuidado ao usar a média como medida).

Em nosso contexto, o gráfico de Burnup está nos ajudando a responder perguntas como:

• O escopo do projeto está crescendo de forma saudável?
• Quando a equipe terminará o escopo atual do projeto?

O exemplo abaixo aconteceu com um cliente da Plataformatec e as circunstâncias eram as seguintes:

• Duração do projeto: 23 semanas (quase seis meses).
• Expectativa do cliente: ter uma solução para resolver um problema de processo interno (projeto do zero, sem código legado).
• Roadmap do produto: após a sessão inicial de story mapping, a equipe e o cliente reduziram o escopo da entrega.
• Desafio do projeto: assegurar que o software estivesse disponível para uso na data acordada.

Neste projeto, usamos o gráfico de Burnup como ferramenta para comunicar o progresso do projeto. O gráfico foi desenvolvido para exibir:

• O número de itens de trabalho planejado para a entrega (escopo);
• O número de itens entregues;
• Cenários para possíveis datas de entrega do projeto.

Os próximos três gráficos representam o projeto no início (primeiras seis semanas), no meio (doze semanas) e no fim (semana 23).

Analisando o início do projeto, tivemos um cenário de aumento do escopo e algumas entregas.

Em relação ao escopo, o aumento aconteceu devido ao refinamento de um conjunto de histórias de usuário criadas após o story mapping.

Um indicador útil para analisar o crescimento do backlog é calcular a taxa de aumento semanal de novas histórias de usuários (no exemplo, sete histórias de usuário foram criadas por semana no início do projeto). Aqui na Plataformac, usamos esse indicador como ferramenta para manter o aumento do escopo previsível.

No meio do projeto, houve crescimento contínuo do escopo (seis novas histórias de usuário criadas por semana). Neste momento, tivemos que sentar com o cliente para alinharmos formas de simplificar o escopo, porque, caso o mesmo continuasse a crescer, dificilmente entregaríamos uma versão do software no final do contrato. O gráfico de Burnup foi útil para definir estratégias para melhorar o Throughput com base nos resultados das entregas realizadas.

A técnica de projeção utilizada foi importante para chegar ao final do projeto entregando todas as funcionalidades necessárias para o software.

Na conclusão do projeto, realizamos uma sessão de lições aprendidas e a equipe destacou que o gráfico de Burnup foi útil, pois:

• trouxemos visibilidade ao processo do desenvolvimento garantindo que o cliente estava alinhado com o progresso e o prazo de entrega;
• mostramos visualmente como o aumento do escopo influencia o prazo de entrega, sendo assim, uma boa ferramenta de negociação.

Conclusão

Monitorar o Throughput significa melhorias do processo com base em dados, que expõe o que está sendo feito com transparência à todos envolvidos no projeto.

O gráfico de Burnup é uma ferramenta poderosa de comunicação que pode ser usada para negociar com stakeholders, visto que, revela como mudanças de escopo afetam o prazo de entrega desejado, ao mesmo tempo que informa o progresso real.

Se você busca material avançado em métricas, recomendo o livro Métricas Ágeis – Obtenha melhores resultados em sua equipe. — Tudo bem, é um jabá! Eu sou o autor do livro, mas acredite, minha recomendação é genuína.

The post Métricas Ágeis: Throughput e gráfico de Burnup first appeared on Plataformatec Blog.