Estamos acostumados a sempre discutir e debater sobre como as coisas são ou como elas deveriam ser no nosso ambiente de trabalho, com o uso da filosofia trazemos essa discussão sobre o que fazer ou como conduzir nossas ações e suas ambiguidades, dado que o mundo é do jeito que ele é. O que fazemos em nossos projetos profissionais, e as decisões que tomamos no nosso dia-a-dia, acabam se inserindo nesse contexto de uma forma ou outra. O objetivo desse post é fomentar uma ruptura nas certezas e verdades estabelecidas dentro de todo conhecimento criado em torno da “Agilidade”. O artefato central dessa discussão é o conhecimento, a forma como interagimos com ele e a forma como usamos ele (ou ele nos usa?). Não vejo forma melhor de começar essa série de provocações senão definindo o que é conhecimento para mim:

| Conhecimento é uma crença justificável.

Ou seja, perspectiva e conhecimento estão diretamente relacionados! Uma “coisa” serve como conhecimento até que acreditemos que outra “coisa” possua justificativas que superem as anteriores. Se observarmos uma empresa como uma organização que produz conhecimento, é possível concluir que o ponto de vista do indivíduo que lida apenas com uma parte da realidade não é o suficiente. O conhecimento não é apenas parte da realidade. É a realidade, mas vista a partir de um determinado ângulo. A mesma realidade pode ser vista diferentemente, dependendo do ângulo (contexto/circunstâncias) do qual se vê.

“Na criação do conhecimento, não se pode ser livre do seu próprio conceito. — Nonaka & Takeuchi”

Os contextos econômico, cultural e histórico são importantes para os indivíduos que produzem conhecimento. Esses contextos permitem a interpretação da informação e a criação do significado que se deseja transmitir. É por isso que a externalização do conhecimento pessoal pode levar a falsidades ontológicas e falácias (Spotify model, SAFe, story points, Scrum…), pois a complexidade total de um determinado fenômeno pode permanecer oculta. Por isso, quando criamos conhecimento é importantíssimo ver todo o quadro da realidade (perspectiva) interagindo com outros que a vejam a partir de outros ângulos, isto é, compartilhando seus conceitos! E a partir desses conceitos é que podemos julgar se o conhecimento a ser transmitido é útil ou não ao nosso contexto atual.

Há quem acredite em certezas imediatas, tais como: scrum é ágil, SAFe é a melhor opção para escalar agilidade, estimativas são imprescindíveis sem nem procurar os conceitos por trás. Me perguntei: o que leva essas pessoas a se tornarem ferramentas do conhecimento ao invés de usar o conhecimento como ferramenta? Elas acham que usam o conhecimento, mas na verdade o conhecimento as usa.

O poder das Ideias de Massa

Acredito que o problema principal são as causas que normalmente vem acompanhadas dessas ideias, causas onde os gestores têm onde se agarrar, causas que sempre vem acompanhadas de um grande vislumbramento de como a organização poderia/deveria ser melhor (ideologia). O ponto é sempre colocar as ideias a seu serviço, você será pragmático quando isso lhe for útil. Isso significa que você entende que todas as ideias podem ser úteis se usadas de forma puxada pela situação/contexto. É diferente de tentar impô-las como verdade para todos os contextos existentes/inexistentes como se fossem coisas sempre iguais (outra certeza imediata que consultorias de grande porte vendem). O perigo de se identificar com a ideia é se tornar viabilizador e propagador dela (a ideia te usa), ao invés de beneficiário de sua efetividade perante o contexto/problema que você vive hoje.

“The issue is one of defining your identity by membership of a social group rather than simply a tool user. For example, you could use Pragmatic philosophy without identifying yourself as a Pragmatist. The important thing is not to let an idea, concept, tool or technology define you. A software engineer who uses Java is okay. A Java Developer is not okay. — David J Anderson”

Complexity

Isso tudo na prática

Como o gestor pragmático pode voltar a conhecer, a criar princípios? Só há um meio: experimentando! Os caminhos que levam para cima são sempre diferentes, já os caminhos que levam para baixo, são sempre os mesmos. Fazer do seu projeto um experimento é a única forma de criar conhecimento com real valor para a sua organização. Admitindo que não existem contextos iguais, partimos da premissa de que todo o conhecimento produzido e acumulado sobre gestão, do qual temos acesso, não nos dá nenhuma certeza imediata quanto a efetividade.

Exemplo: muito se discute sobre a dualidade Eficiência x Eficácia, em qual investir primeiro? Qual priorizar dado o meu contexto? O que o framework XPTO fala sobre isso? E se eu te dissesse que os dois são uma única coisa? Faz parte do senso comum achar que quando estamos criando ideias (upstream) a eficácia predomine, pois não queremos cometer o erro de construir a coisa errada, e na construção (downstream) a eficiência é mais importante para fazer as coisas de forma rápida. Porém se nos colocarmos além dessa dualidade é possível enxergar um outro ângulo: focando eficácia apenas no upstream (opções de ideias) temos o risco de ocorrer starvation no downstream (solicitações de execução), sem eficácia no downstream é necessário confiar cegamente no upstream para que seja eliminado os riscos de demandas que não entreguem valor entrarem no fluxo. No final das contas a realidade é bem mais complexa do que estamos acostumados a categorizar (pensamento cartesiano do século XVIII) e arquivar como “certezas” em nossas mentes.

Toda essa teoria pós-moderna de criação do conhecimento organizacional que foi apresentada aqui, pode ser estudada com mais aprofundamento técnico na obra Gestão do Conhecimento publicada por Hirotaka Takeuchi e Ikujiro Nonaka. A definição ocidental mais comum sobre o que é conhecimento enfoca a “veracidade” (conhecimento das coisas em si) como atributo essencial para a construção do conhecimento, ou seja, esperam que a verdade seja sempre limpinha. Aqui alimento a natureza do conhecimento como “crença justificada” onde a perspectiva tem mais valor do que a “veracidade”, isso serve como um convite para uma grande pluralidade de ideias e experimentos que ainda estão por acontecer, essa experimentação permitirá uma gama completamente nova de conhecimentos, mais audazes, mais genuínos!

E você? Como tem sido sua relação com o conhecimento?

The post O Agilista e o Martelo first appeared on Plataformatec Blog.

O desafio agora é outro: como adaptar os métodos adaptáveis para necessidades, digamos assim, de gente grande? As startups começam a crescer e empresas tradicionais percebem a oportunidade. Agile começa a chamar a atenção como um diferencial para o negócio e não apenas mais para TI. Projetos (ou iniciativas) de software isoladas são relativamente simples; Conversar com  o pessoal de operações, auditoria, times remotos, fazer terceirizações, gerenciar projetos maiores, ter uma visão holística de programas, portfolio, trazer previsibilidade, alinhar as iniciativas às necessidades de marketing e jurídicas etc. Esses e outros fatores trazem uma complexidade maior que, a princípio, os primeiros métodos ágeis não eram capazes de responder ou pelo menos não o faziam de maneira muito simples.

A pergunta da vez então era: “como eu escalo isso?” Uma série de iniciativas surgiram para provar que tal método escalava e também alguns frameworks voltados exclusivamente para escala. Num mapeamento não exaustivo recente, levantei algumas abordagens: SAFe, LeSS, Nexus, Scrum at Scale, o próprio DAD e até mesmo o controverso Case Spotify. Nesse artigo, vou discutir minhas percepções sobre o Disciplined Agile Framework.

De antemão, acho honesto informar que minha experiência em escalar Agilidade vem de necessidades específicas de contextos onde trabalhei: necessidades regulatórias (SOX, Basileia etc, PCI entre outros), necessidades de terceirização com times remotos  e limitadas por requisitos trabalhistas e também limitações impostas por estruturas funcionais rígidas com alta especialização (banco de dados, operações etc.). Não cheguei a usar o DAD em profundidade e, apesar de ter estudado o framework, não passei por nenhum dos cursos oficiais e não me aprofundei o suficiente para conhecer todas as suas nuances. Esse artigo é apenas opinativo. Dito isto, vamos em frente.

O DA Framework

Segundo a definição, O Disciplined Agile (DA) Framework de decisão é uma estrutura que fornece orientação para ajudar organizações a simplificar seus processos, de maneira sensível ao contexto, dando uma fundação sólida para a agilidade nos negócios.

Historicamente, o Disciplined Agile Framework  nasceu em 2009 como um framework proprietário da IBM, voltado exclusivamente para estratégias de delivery de software, com sua primeira versão “madura” lançada para o mercado em 2012, por ocasião da publicação do “livro do veleiro”. Mais ou menos na mesma época que o SAFe veio à tona. Naquela época, ao procurar por visões de agilidade em escala, não eram raras as representações do DAD (Disciplined Agile Delivery) como o kernel do SAFe; Enquanto o DAD fava uma visão de como entregar, o SAFe tentava organizar isso em visões táticas e estratégicas. Em 2014 o DAD passou oficialmente para as mãos do DA Consortium, teoricamente rompendo seus laços com a IBM e finalmente, no final de 2017, com a publicação do DA Framework, o DAD tornou-se independente da visão do SAFe, fornecendo sua própria abordagem de agilidade para as visões em níveis de operação, área de TI e para a organização como um todo.

Escala na visão do DA Framework

O DA Consortium tem uma abordagem bem pragmática para aquilo que considera escalar ágil. Ele cita diversos fatores de escala: tamanho do time, distribuição geográfica, distribuição organizacional, compliance, complexidade técnica, complexidade de domínio. Eu particularmente concordo com essa abordagem pois, dentro da minha experiência, são esses os fatores que tendem a complicar o uso do ágil.

O que eu senti falta, ou pelo menos não encontrei de forma tão explícita, foi uma maneira de endereçar especificamente os fatores de complexidade explicitados na teia acima. Como o DA Framework se posiciona como um “framework de decisão sensível ao contexto”, acho que essas decisões poderiam ser mais direcionadas de acordo com um assessment feito com base na escala desses fatores.

Um novo Manifesto Ágil

Uma coisa legal que eu achei na iniciativa é a noção de que a agilidade não deveria ficar restrita às necessidades do cliente e nem às iniciativas de desenvolvimento de software. Nesse sentido, o DA propõe uma evolução do Manifesto Ágil.

O termo “software em funcionamento” seria substituído por Soluções Consumíveis, para dar visibilidade de que nem sempre software é o que agrega valor para a organização. Nesse contexto, soluções consumíveis é um termo bem mais abrangente, numa primeira iniciativa para expandir a agilidade para além da TI.

O termo “colaboração com o cliente” seria substituído por “colaboração com stakeholders”, para dar visibilidade de que num contexto corporativo, é preciso interagir com uma gama de outras partes interessadas não restritas apenas ao cliente da solução. Nesse sentido, a palavra stakeholders é bem mais abrangente e ajuda a dar um contexto da complexidade enfrentada nas iniciativas de desenvolvimento das soluções consumíveis.

Particularmente, acho que mais do que as palavras escolhidas para o manifesto ágil, o que deve ser valorizado é o mindset, e nesse sentido, seria desnecessária qualquer evolução do manifesto original. Por outro lado, essas pequenas alterações podem ser interpretadas como uma licença poética para explicar o conceito do DA, e realmente me ajudaram a pegar o tom da proposta.

Os 7 princípios

Num aprofundamento dos conceitos por trás do manifesto modificado, o DA propõe 7 princípios. Esses princípios são os direcionadores para a mentalidade que alguém buscando escalar a agilidade em sua organização deveria ter.

Existe um princípio core que faz com que o foco seja mantido nos clientes – “Delight Customers” e outros 6 princípios que orbitam, ou melhor, habilitam este princípio. Inicialmente eu achei a ideia um pouco contraditória com o “novo manifesto”, melhor seria se o princípio  fosse “Delight Stakeholders“. Mas depois eu entendi que é preciso colaborar com os stakeholders para no final poder encantar os clientes das soluções consumíveis. Um outro ponto de desconforto em relação a esse princípio é que em alguns momentos o DA parece defender que o cliente seja surpreendido positivamente. Eu particularmente discordo dessa abordagem de gold plating. Eu sou muito mais adepto à gestão de expectativas e à abordagem de customer success do Lincoln Murphy, por exemplo.

Alguns princípios como “be awesome, optimize flow e choice is good” não definem muito o DA Framework além do que os princípios fundamentais do Agile já fazem, por isso não vou entrar muito nos detalhes.

Outros princípios como Enterprise Awareness, Pragmatism e Context Counts por outro lado, vão de encontro à ideia principal do framework.

Enterprise Awareness chama a atenção para os times das iniciativas de que existe um mundo lá fora, e é preciso ter consciência de que esse mundo impacta a maneira como você trabalha e vice-versa.

Context-Counts chama a atenção de que não é possível que um framework prescritivo se encaixe em todos os contextos, principalmente naqueles de maior complexidade. Pragmatismo, outro princípio, complementa o Context-counts  no sentido da falta de compromisso com um framework específico, e o princípio “choice is good” fecha o quebra cabeça, fornecendo estratégias para escolher as melhores ferramentas dado determinado contexto.

Conceitualmente, a ideia me pareceu bastante consistente, embora na prática eu não tenha conseguido enxergar muito como isso funcionaria. Por exemplo, o DA vende sua ideia de ser um “agregador de todos os métodos”, chegando inclusive a criticar corpos de conhecimento como ITIL e PMBoK.  

Contudo, a parte de “choice is good” e a estratégia de utilizar “lâminas de processo” que podem ser escolhidas conforme a necessidade, fazem do DA Framework um grande “AgileBoK”, adotando exatamente a estratégia criticada. O fato de referenciar o PMBoK por PMIBoK e o fato de utilizarem a mesma estratégia criticada denotam uma possível falta de conhecimento dos autores sobre o assunto,  tornando um pouco frágeis seus argumentos de venda.

A Big Picture

Nesse ponto, o DA começa a apresentar suas “Disciplinas”, exatamente como fazem os corpos de conhecimento. Eu gosto de corpos de conhecimento, os BoKs da vida, pois acho legal agregar ferramentas e técnicas e permitir sua comparação. Minha única crítica, mais uma vez, é que fica parecendo que o DA Consortium criou exatamente aquilo que jurou combater.

Essencialmente, o Framework atua nos níveis de entrega, DevOps, Área de TI e Organizacional, sendo que originalmente direcionava apenas a parte de entrega.

No nível de Delivery, a estratégia é fornecer fluxos completos de ciclo de vida, com várias estratégias que podem ser escolhidas levando-se em consideração desde a maturidade do time até mesmo a estratégia de negócios: há sugestões de fluxos de agile básico usando Scrum, e até mesmo fluxos exploratórios para startups. O que é bem legal e pertinente. Tenho visto Agile Coaches forçando a barra de processos em cima de times que ainda não têm  condições de adotar práticas mais avançadas e realmente a abordagem do DA traz essa reflexão.

No nível de DevOps, a ideia é discutir boas práticas na interação do desenvolvimento junto com operações. As abordagens são bem interessantes, discutem agilidade do ponto de vista de Segurança, Help Desk, Administração de Dados, Operações e gestão de releases. Entretanto, foi ao subir para esse nível que fiquei decepcionado, pois, sinceramente, esperava a apresentação de uma estratégia para aplicação de agilidade além da Tecnologia, o que não aconteceu.

No nível de Área de TI, são apresentadas estratégias em nível tático e estratégico de gestão de tecnologia, assim como a interação da área de TI com o restante da empresa. São apresentadas estratégias de gestão de pessoas, produtos, portfolio, governança, arquitetura organizacional e engenharia de reuso, contudo, num nível bem mais raso do que DAD e DevOps.

Finalmente, no nível Organizacional (Disciplined Agile Enterprise), a coisa ficou bem confusa pra mim. Minha impressão é que foram ultrapassados os limites de um framework, invadindo disciplinas como Marketing, Vendas, Financeiro, Jurídico e Compras, para as quais já existe muito conhecimento e práticas que foram desenvolvidas ao longo de décadas. Eu esperava que a abordagem simplesmente citasse alguns requisitos, pontos de contato dos outros níveis mas em alguns momentos o DA Framework. Entretanto, o as diretrizes do DA parecem tentar ensinar para esses departamentos qual é o jeito correto de se trabalhar. Resumindo, passou do ponto.

Conclusão

Juntando tudo, me pareceu que:

• De verdade, apesar da tentativa, o foco continua em TI (e vai ser difícil sair)
• Me pareceu que faltou uma estratégia de assessment e implantação mais clara.
• Faltou também uma estratégia um visão específica para as variáveis de escala: tamanho do time, distribuição geográfica e organizacional, compliance, complexidade técnica e de domínio
• Tentativa de reinventar a roda na Administração de empresas, mas sem arranhar a superfície da complexidade dessas disciplinas

No final, é um bom Framework geral, bem estruturado e pertinente, mas seu detalhamento é, assim como o PMBoK, um bom BoK (body of knowledge)

Este texto também faz parte da ContÁgil, nossa newsletter mensal com curadoria de conteúdo pela equipe da Plataformatec sobre gerenciamento de projetos, metodologias e cultura ágil. Se você ainda não é assinante, assine agora!

The post Disciplined Agile Framework – Primeiras Impressões first appeared on Plataformatec Blog.

• Será que temos capacidade produtiva suficiente para operar a quantidade de iniciativas (evoluções nos produtos atuais e criação de novos produtos) que foram definidas para suportar a estratégia da empresa?
• Os critérios de priorização das iniciativas estão claros para os diferentes níveis da empresa? Todos compreendem as motivações pelas quais as iniciativas foram organizadas do jeito que estão?
• Como está a saúde do portfólio de produtos da empresa? Todos os produtos estão operando eficientemente e gerando resultado financeiro positivo?

Neste blog post, compartilharei uma técnica que temos utilizado na Plataformatec e que vem ajudando nossos clientes a terem visibilidade sobre em que estágio os diferentes produtos do seu portfólio se encontram.

Premissas para uma boa gestão de portfólio de produtos

Antes de aprofundar na descrição da técnica, gostaria de compartilhar três premissas importantes que apoiam uma gestão de portfólio de produtos inteligente:

• Estabeleça resultados de negócio: um erro comum que tenho observado nas empresas que atuam com produtos digitais é uma obsessão pela entrega de funcionalidades (features) e pouca discussão sobre como o entregável de fato está contribuindo para um melhor resultado no negócio (aumento da receita, diminuição da evasão de clientes, aumento no número de clientes ativos, etc.). Sendo assim, para que o portfólio de produtos seja administrado de forma inteligente, é fundamental que todos da empresa estejam engajados em como ajudar o negócio a gerar melhores resultados.
• Colete e divulgue as métricas de negócio: para que todos tenham consciência do impacto que o seu trabalho tem no resultado da empresa, se faz necessária a coleta e a disseminação das métricas do negócio (para mais informações sobre o assunto, não deixe de ler o blog post O que seriam boas métricas para produtos digitais?). Neste sentido, desenvolver rotinas que garantam visibilidade sobre a saúde do negócio se torna algo primordial para que as pessoas criem uma cultura orientada a dados. Algumas formas inteligentes que tenho observado e recomendado são: envio de uma mensagem diária através de um canal assíncrono (ex: email) com os principais indicadores do negócio; criação de uma plataforma analítica com as métricas do negócio disponíveis para consulta; reuniões quinzenais sobre como as funcionalidades construídas estão impactando os resultados dos produtos; reuniões mensais sobre como está a saúde financeira do portfólio de produtos e para a definição de planos de ação; reuniões trimestrais para a definição de OKRs (há um tempo atrás escrevi um blog post sobre como definir OKRs em equipes ágeis).
• Equilibre os investimentos: expandir o negócio atual e explorar novas oportunidades é algo tentador, principalmente em empresas que acabaram de captar montantes consideráveis de dinheiro. Porém, lembre-se que manter e desenvolver o território atual do negócio da empresa é algo que garantirá uma saúde financeira no curto prazo. Portanto, balancear a carga de recursos (financeiros, pessoas, tecnologia, pesquisa, etc.) investidos garantirá que a empresa olhe para o curto, médio e longo prazo, a partir da combinação de evoluções nos produtos atuais, em inovações para o mercado atual e na exploração de um mercado futuro.

Analisando os diferentes estágios dos produtos

Vamos ao que interessa. Com objetivo de analisar o portfólio de produtos em uma empresa, tenho utilizando um modelo que leva em consideração três estágios de um ciclo de vida que são:

1. Discovery: neste estágio, a empresa identificou uma oportunidade de mercado, desenvolveu um modelo de negócio, definiu uma estratégia comercial, criou uma solução tecnológica mínima que entrega valor aos usuários e estruturou um processo, mesmo que ineficiente, para sustentar a operação do produto. É muito comum acontecerem mudanças e desperdícios, pois há o desafio de descobrir uma solução que o mercado enxergará valor. Além disso, o estágio de descoberta exige um maior investimento e geralmente é mais estressante.
2. Refinamento: neste estágio, o produto já se encontra em operação e o modelo de negócio precisa ser refinado para que a operação se torne viável. Evoluções na plataforma tecnológica, intensificação na promoção através das estratégias em marketing e a identificação de novos canais de vendas são temas corriqueiros no dia a dia de produtos neste estágio. O produto ainda está descobrindo a melhor forma de gerar resultado e qualquer estímulo do mercado (ex: concorrência, clientes, preço de venda, etc.) pode ser crítico para que ele se torne um player de expressão.
3. Market share: o último estágio do modelo tem como objetivo garantir que o produto esteja gerando lucro para a empresa em um horizonte de curto, médio e longo prazo e, pode ser dividido em duas frentes:

• Eficiência operacional: as evoluções e melhorias no produto têm como foco o ganho através da escala. Redução no custo de aquisição por cliente, redução no custo de atendimento aos clientes e diminuição nos custos de infraestrutura tecnológica são exemplos de direcionadores que garantirão uma maior eficiência operacional para a empresa.
• Inovação: as evoluções têm como cerne a criação de um diferencial competitivo que torne o produto cada vez mais valioso, raro, difícil de ser imitado e insubstituível. Para que a empresa promova a inovação no produto é importante que ela compreenda as necessidades dos clientes, promova rotinas que estimulem soluções “fora da caixa” e pense em maneiras de expandir o mercado atual.

Conclusão

A visualização dos produtos a partir dos estágios apresentados anteriormente tem os seguintes benefícios:

• Quando tudo é prioridade, nada é prioridade. Dar visibilidade aos diferentes stakeholders sobre o número de produtos que a empresa está operando e criando e, ajudar a repensar a estratégia caso a relação entre a capacidade de entrega e o número de demandas seja elevadamente desproporcional.
• Questione a crença de que todos os produtos dão o mesmo resultado. Estruturar e acelerar o processo de tomada de decisão no caso de produtos que estejam há um tempo sem gerar resultado para a empresa, bem como dar clareza sobre os critérios utilizados para a manutenção do atual portfólio de produtos.
• Promova o desapego nas decisões. Equilibrar os investimentos e a alocação das equipes sem ficar preso a desenhos organizacionais, mas sim com base na necessidade de aceleração dos resultados do negócio.

E você? Os estágios apresentados acima fazem sentido para o contexto de produtos da sua empresa? Deixe seu comentário abaixo.

Ps: Caso você trabalhe com serviço, saiba que estamos aplicando no portfólio de serviços da Plataformatec todos os conceitos apresentados neste blog post

The post Avaliando os estágios do portfólio de produtos em uma empresa digital first appeared on Plataformatec Blog.

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.

Quando estamos lidando com prazos, famosos deadlines (não poderiam ser successlines?!), essas perguntas provavelmente irão surgir em vários momentos do projeto antes da entrega, e com certeza muitas outras vezes se o prazo inicial não for atendido. Independentemente do período em que esteja o projeto, você já pensou que muitos problemas relacionados com essas perguntas são causados por falta de alinhamento na expectativa da data de entrega?

Aqui na Ptec estamos trabalhando com uma dinâmica chamada Reality Check, ou verificação de realidade. É uma dinâmica muito eficaz para quando há um prazo de entrega bem apertado. Meu amigo Lucas Colucci contou um pouco sobre como esta dinâmica funciona em seu blogpost Desenvolvendo melhoria contínua em seu processo ágil: A cerimônia de Reality Check. Nós testamos esta dinâmica e a evoluímos e, com isso, encontramos algumas novas práticas que podem agregar valor para esta ferramenta. Nos exemplos que serão apresentados a seguir, os resultados foram muito positivos! Vamos conhecer?

Salvando o prazo do seu projeto!

Arrisco defender o seguinte: na maioria das vezes, é mais relevante para o projeto deixar as expectativas de data de entrega bem alinhadas do que efetivamente cumprir um prazo inicialmente empurrado para a entrega do projeto. Defendo isso porque, no início do projeto, ou de alguma parte dele, dificilmente conseguimos prever uma data precisa de entrega, pois as diversas variáveis que interferem nessa promessa de data influenciam demais no que efetivamente irá acontecer, como, por exemplo, ausências diversas, feriados e as deliciosas emendas de sextas-feira, desmotivação, problemas novos não existentes no início do planejamento, mudanças de escopo não controladas, férias de colaboradores não programadas com antecedência, entre tantas outras. Entretanto, todos esses pontos não significam que não podemos mostrar o que realmente está acontecendo. Prazo não deve ser uma restrição, mas sim uma meta!

É possível trabalhar a questão abordada de uma forma bem simples: deixe claro, de forma explítica e antecipada, quando a entrega irá efetivamente ocorrer. Dessa forma, seu cliente sempre terá o controle da situação, caso a equipe descubra antecipadamente que o prazo inicial não será atingido.

A ideia é muito simples: mostrar a realidade do que está acontecendo no time, concedendo visibilidade quanto ao prazo! Apresentar a real situação ajuda a deixar as expectativas de data de entrega muito bem alinhadas, e de forma antecipada. De quebra, em um formato colaborativo, o Reality Check tem a capacidade de empoderar a equipe sobre a apresentação da data de entrega e, dessa forma, cria um vínculo de parceria e responsabilidade com seu cliente. A mensagem é que somos um único time, e estamos fazendo o melhor!

Explica como funciona?

Primeiramente, tenha o seguinte cenário: um escopo e um prazo. Bem simples, não? Segundo passo: obtenha o detalhe do escopo de alguma maneira. Isso pode ser feito via Story Mapping, decomposição do escopo para obter os pacotes de trabalho de uma EAP (Estrutura Analítica do Projeto), grupos de tarefas de um cronograma, etc. Enfim, tenha um conjunto de itens que, juntos, somam todo o escopo de sua entrega. É importante também que esses itens sejam, mais ou menos, de “tamanhos” semelhantes ou de mesma natureza técnica, evitando misturar demandas muito grandes com as muito pequenas, por exemplo. No nosso caso, usamos histórias de usuário de um Backlog de produto, todas oriundas de um Story Mapping e, na medida do possível, já priorizadas no contexto da próxima entrega do projeto.

Em seguida, escreva todos os seus itens de escopo em post-its (existe algo melhor do que esses papeizinhos que grudam?). Depois, em um quadro branco, por exemplo, ao lado direito de todos os seus itens de escopo, desenhe faixas verticais de períodos iguais que representam a evolução temporal do projeto, ou, em outras palavras, faça várias faixas que mostrem cada semana até a data de entrega do projeto. A última faixa poderá corresponder à data de entrega. Não recomendo dividir esses períodos em dias ou meses, pois são distâncias curtas e longas demais, respectivamente. Depois, trace uma linha horizontal quase no topo do quadro e, em cada espaço de faixas verticais, declare qual é o respectivo período que aquele intervalo representa no projeto.

Para facilitar, você poderá fazer essa dinâmica no primeiro dia de trabalho de uma semana. Não recomendo que o Reality Check seja feito para um período muito longo. Entendo que, no máximo, um trimestre (entre 12 e 14 semanas) seja aceitável para que a dinâmica funcione corretamente. Um período maior do que este fará com que a equipe não consiga ter uma visão adequada e acabe estimando o trabalho futuro de uma forma muito relativa. Quanto mais distante, menos assertivo. Dessa forma:

Feito isso, reúna o time, apresente o desenho e peça para a equipe mover os itens que estão no Backlog para dentro das faixas semanais, declarando em qual semana cada item irá ser finalizado, e não quando começam (faremos isso de outra maneira). Se o mesmo item for durar mais do que uma semana, não é necessário duplica-lo, mas somente coloca-lo na semana de término. O objetivo é distribuir todos os itens na linha do tempo, estimando o quanto de trabalho será feito em cada semana e, principalmente, descobrindo se é possível encaixar todo o esforço do projeto dentro do prazo solicitado pelo cliente. É extremamente importante que a equipe tenha a autonomia de distribuir seus respectivos trabalhos no quadro, e que o gestor do produto / PO esteja presente durante essa parte da dinâmica.

A equipe não precisa buscar ser extremamente assertiva quanto a essa distribuição, mas sim tentar encontrar um volume de trabalho semanal que seja condizente com a realidade. É interessante que, neste momento, a equipe perceberá se será possivel atingir o prazo do projeto e quais são as dependências entre cada item do escopo. Vários outros debates podem surgir e, de repente, você poderá ter a primeira oportunidade de negociar o prazo do projeto ou, se este for inegociável, tentar reduzir o escopo para que ele se encaixe dentro do período mostrado no Reality Check.

Ao final, para finalizar essa primeira parte da dinâmica, distribua um post-it para cada membro do time e, de forma individual, cada um (exceto o facilitador e o gestor do produto / PO) escreverá um valor de 1 a 4, sendo a menor nota representando que a data de entrega não é factível de ser atingida e, à medida que a nota aumenta, o prazo é plausível de ser atingido. Depois, o facilitador da dinâmica calcula a média dessas notas e apresenta para a equipe. Se a nota for 1 ou 2, é interessante rever o planejamento colocado no Reality Check. Se for 3 ou 4, é possivel entender que todos estão confortáveis quanto ao prazo da entrega do projeto. Também é válido conceder a oportunidade para quem colocou notas extremas (1 e 4) comentarem suas posições, visto que essas pessoas podem estar enxergando pontos que os demais membros do time deixaram passar despercebidos. Algum plano de ação poderá surgir neste momento, com o objetivo de melhorar alguma nota baixa, por exemplo.

Na segunda semana, no primeiro dia de trabalho, todos se reúnem novamente para atualizar o Reality Check. É interessante que o cliente esteja presente nesses momentos de atualização do quadro. Agora, a equipe irá deixar os itens que foram concluídos na semana anterior e, caso todos não tenham sido concluídos, o time deverá pensar como irá realocar os itens remanescentes na semana corrente e/ou nas próximas e, portanto, movendo algo que estava nessa semana para a próxima, e assim sucessivamente. Repetindo isto em todas as semanas, a equipe conseguirá alocar os trabalhos do projeto nos períodos e, dependendo da situação, visualizará que a entrega não conseguirá ser desenvolvida até a data estipulada, ou que será necessário a alocação de mais pessoas para o projeto, ou reduzir o escopo, entre outros. Ou seja, o cliente terá visibilidade sobre o andamento do projeto e conseguirá apoiar a equipe a encontrar opções viáveis para solucionar a questão. A foto abaixo, tirada de um exemplo desta dinâmica, reflete a situação do projeto em uma sexta semana:

Para complementar a dinâmica, a equipe poderá adotar alguns mecanismos visuais para ajudar a interpretar cada item do Reality Check. Como sugestão, colocamos:

• Um adesivo azul, no canto superior esquerdo do post-it, para mostrar quando aquele item (no nosso caso, histórias de usuário) estava em desenvolvimento;
• Um adesivo vermelho, no canto inferior esquerdo do post-it, para representar algum bloqueio naquela história de usuário (algo que esteja atrapalhando o andamento do desenvolvimento, ou algum impedimento que precisa ser removido);
• Um adesivo retangular, no canto superior direito do post-it, para declarar em qual semana aquela história de usuário tinha começado a ser desenvolvida (somente para quando a semana de início não era a mesma de término da história);
• Um post-it amarelo menor, no canto inferior direito do post-it principal, que representava alguma pendência daquela história (com um pequeno texto explicativo).

Além disso, quando havia dependências entre os itens, como, por exemplo, a história de usuário B somente poderá começar após o término da história A, a equipe desenhava uma seta de ligação, a fim de representar esta dependência. Post-its de cores diferentes também podem ser utilizados para que haja uma identificação de tema, como, no nosso exemplo, uma cor para representar histórias de desenvolvimento de código e uma outra cor para demandas relacionadas com layout. O “tamanho” de cada item também poderá ser declarado, evitando que a equipe planeje desenvolver demandas muito grandes na mesma semana, por exemplo. Para ajudar no entendimento de tudo isso, crie uma legenda ao lado do quadro, semelhante a esta foto:

Portanto, a dinâmica de Reality Check tem o potencial de agregar valor de gestão para toda a equipe, minimizando problemas de alinhamento quanto às expectativas de entrega dentro de determinado prazo, bem como mostrando como está a realidade do desenvolvimento do projeto.

Dicas extras

Algumas práticas podem facilitar a utilização dessa dinâmica:

• O facilitador do projeto pode manter o quadro atualizado durante a semana. Depois, no início da próxima, o time poderá focar em distribuir os post-its. Para isso, sempre tenha por perto todos os utensílios necessários (adesivos, caneta de quadro, etc.);
• O facilitador precisa apoiar o time em momentos de debates quanto a prazos, pois é normal que o cliente queira a entrega dentro do prazo inicial. Logo, conversas sobre horas extras, por exemplo, podem surgir, caso a equipe não consiga encaixar todo o escopo dentro do prazo. Cabe à equipe decidir se vale a pena esse esforço adicional, pois, talvez, é melhor tentar negociar um novo prazo, ou mesmo “quebrar” partes do escopo e encaixar o que for possível dentro da data desejada;
• Evite identificar a pessoa que está desenvolvendo cada item do escopo. O Reality Check não pode se transformar em uma ferramenta de cobrança, ou mesmo que exponha algo irrelevante para o projeto/time. O quadro, o progresso e as decisões são do time, e não de atores individuais;
• Tenha outras ferramentas para a gestão do projeto. O Reality Check é um item adicional e funciona muito bem quando sincronizado com um quadro Kanban, por exemplo. Ele também poderá agregar valor quando seu projeto ainda não possuir dados históricos para a utilização de métricas, sendo uma potencial ferramenta para conceder, no início do projeto, previsibilidade sem dados;
• O Reality Check não precisa ser utilizado em todas as entregas do projeto. Talvez ele seja naturalmente demandado quando o contexto do projeto (um prazo apertado, por exemplo) justificar sua utilização, ou mesmo quando os membros da equipe encontrarem alguma motivação;
• Se você estiver trabalhando com Scrum, o Reality Check poderá ajudar o time durante a Daily. O próprio time poderá identificar essa oportunidade.

E você, gostou dessa dinâmica? Fique à vontade para comentar, feedbacks e opiniões são sempre bem-vindos!

The post Alinhando expectativas de prazo com o Reality Check 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.