Como times ágeis podem identificar e gerenciar ameaças?

O tema não é muito comum, mas é necessário.

Marcos Macedo
Mar 16 · 9 min read
Image for post
Image for post

Para qualquer método de desenvolvimento e gerenciamento de projetos de software, as ameaças e os riscos devem ser considerados, uma vez que podem causar impacto negativo no resultado do trabalho. Como aqui na Concrete sempre falamos de agilidade, então vamos dar um foco para essa discussão: como times ágeis podem identificar e gerenciar ameaças?

O primeiro tópico que fica muito evidente e é bastante defendido são as iterações da abordagem ágil. Elas são um ótimo meio para ajuste de direção, correção de disfunções, alinhamento de expectativas, replanejamento e uma boa oportunidade de identificar ameaças. Vamos mergulhar um pouco mais para saber o que podemos trazer à superfície além das iterações para identificar e gerenciar ameaças antes que cheguem em produção?

Antes disso, porém, vamos falar um pouco sobre o valor que entregamos nos produtos de software, ou o nosso maior foco. Aqui, entenda valor como o sucesso dos objetivos do projeto ou o atendimento às expectativas do cliente, algo que vai trazer benefícios significantes para o negócio, seja ele financeiro ou não.

Para times ágeis, identificar o real valor de algo que estamos desenvolvendo é bastante difícil, mas ao mesmo tempo muito importante para o sucesso do projeto. Algumas vezes pode não estar claro para o cliente nem para o time de desenvolvimento qual é o real valor do que está sendo entregue. Já em outros projetos, que contam com designer de produto e product owner comprometidos, uma visão compartilhada e clara entre todos os envolvidos é mais comum. Se temos algo difícil de conquistar não vamos querer perder facilmente, não é?

Voltando ao tema do post, riscos, relacionando-o ao assunto valor chegamos ao conceito de antivalor.

Se o valor é um lado da moeda, o risco é o outro lado. É por isso que o domínio da entrega orientada a valor também abrange o conceito de redução de risco. Pense que valor são créditos em sua conta e riscos são os débitos. Para criar mais valor precisamos maximizar os créditos e minimizar os débitos da sua conta. Quando um erro ocorre, ele retira tempo e trabalho da entrega de valor, ameaçando os benefícios do projeto.

Portanto, times ágeis não devem ter apenas planos para entrega de alto valor, mas também um plano para prevenir e gerenciar os riscos o mais cedo possível. O antivalor é representado pelos fatores que potencialmente podem corroer, remover ou reduzir o valor.


Pessoas

Como as pessoas formam o único ponto de interação no desenvolvimento de software, os riscos, problemas e soluções passam por pessoas e suas interações. No livro Agile Software Development: The Cooperative Game, Alistair Cockburn descreve cinco modos de falhas. São eles:

Não é surpresa que as pessoas cometem erros. Essa é a principal razão porque iterações e incrementos foram criados no desenvolvimento de software. Essa abordagem reconhece os erros que normalmente ocorrem e gera um mecanismo para se recuperar rapidamente deles, para não sobrecarregar o projeto.

Quando confrontadas com a incerteza, as pessoas tendem a voltar a fazer o que conhecem, mesmo que estejam cientes que não é a abordagem ideal. Por exemplo, quando projetos ágeis começam a sair dos trilhos ou encontrar vários erros, o líder é tentado a voltar para um caminho de comando e controle para rodar os projetos.

Nós preferimos inventar do que pesquisar. Isso descreve a tendência que as pessoas têm de confiar na invenção de novas soluções do que pesquisar soluções que já foram inventadas e reutilizadas. Essa tendência pode ser produto de um sistema de recompensa individual ou satisfação intelectual ao resolver o problema. Pode ser divertido, mas geralmente é mais custoso, consome tempo e é propenso a erro.

Nós somos criaturas de hábito. Mudar a maneira como fazemos as coisas sempre será difícil. Frequentemente sabemos que existe uma abordagem melhor, mas ainda assim não adotamos novas abordagens. Consciente ou inconscientemente, nós não queremos mudar nossa forma de atuar;

Nós somos inconsistentes. Muitas pessoas são muito inconsistentes em seguir um processo. Então, o desafio não é procurar a melhor forma de fazer as coisas, mas fazer as pessoas entenderem e aceitarem um novo caminho, mudarem os hábitos e aplicarem a eles uma nova abordagem.


Ambiente Seguro

E como um ambiente seguro, além de outros benefícios, pode ajudar a identificar ameaças? Um estudo publicado na NeuroLeadershipJournal identificou alguns comportamentos quando pessoas não estão em um ambiente seguro.

Para o estudo, somos menos eficazes quando estamos preocupados em cometer erros ou ter problemas. Tem um ditado que diz: “Ei você tem duas mãos. Se você está usando uma delas para cobrir as suas costas, terá apenas uma para trabalhar”. Pessoas têm embutido um mecanismo de defesa que é desencadeado mental e fisicamente. Quando sentimos uma ameaça ou falta de ambiente seguro, menos oxigênio e glicose são enviados ao cérebro para limitar o sangramento no caso de um ataque, e o inverso ocorre em um ambiente seguro. Ambientes seguros promovem engajamento, um estado em que estamos dispostos a enfrentar atividades difíceis, assumir riscos, pensar profundamente nos problemas e desenvolver soluções. O engajamento está ligado a emoções positivas.

O que deve fazer, então, um líder de time ágil que deseja criar um ambiente seguro? Antes de tudo, não critique pessoas por experimentos que falharam. Se o time tentou uma nova abordagem por uma ou duas iterações e teve resultados piores e não melhores, podemos perguntar o que podemos aprender a partir do experimento e seguir em frente. Deveríamos tentar criar uma cultura de engajamento recompensando times por resolverem problemas, colaborarem e compartilharem novas ideias.


Entendendo problemas

Quando um problema ocorre no projeto, ele pode ser ignorado e o erro apenas continuar avançando ou, às vezes, existe a esperança de que o problema vá embora ou se resolva sozinho. Porém, um único problema pode criar atrasos, desperdício ou gerar retrabalhos que podem atrapalhar ou até impedir o progresso do projeto. A razão pela qual é tão caro procrastinar ao lidar com os problemas é o custo da mudança, porque quanto mais tempo o problema demorar para ser endereçado, mais caro vai ser a sua correção, mais stakeholders serão impactados pelo defeito e mais trabalho será construído.


Ferramentas

Além de usar iterações e promover ambientes seguros podemos utilizar ferramentas para diagnosticar riscos e ameaças. Lead Time e controle de limites (WIP) são exemplos que podem apontar para potenciais problemas antes que eles ocorram ou logo depois de eles ocorrerem.

Lead Time é uma ferramenta que pode ser utilizada para ajudar a identificar e diagnosticar problemas. A ideia é mensurar quanto tempo algo leva para atravessar todo o processo, como por exemplo itens de trabalho do design até a venda, ou de um requerimento desde o desenvolvimento até a implantação.

O Lead Time pode também ser utilizado para análise de uma sub parte de todos os processos, para mensurar, neste caso, quanto tempo algo leva para percorrer parte do processo, entre a codificação e o teste, por exemplo. Conhecer as durações e os ciclos nos permite assumir compromissos confiáveis com o cliente ou organização sobre quanto tempo levará para entregar o trabalho, evitando casos de pagamento de multas por atrasos que ameaçam a saúde financeira do projeto, por exemplo.

Gerenciar o WIP (Working in Progress) também pode reduzir os possíveis pontos de falhas que podem ser criados durante o desenvolvimento. Alternar entre atividades, por exemplo, pode diminuir o nível de concentração e dedicação no desenvolvimento de itens de trabalho. Possivelmente, pessoas vão querer manter a mesma eficiência e falhas podem ocorrer.


Gerenciando Riscos

Times ágeis precisam engajar o time de desenvolvimento, patrocinadores e clientes e outros stakeholders relevantes no processo de identificação de risco. Para isso, possuir uma lista completa de riscos conhecidos e prováveis e incluí-los no backlog do produto de forma ordenada pode ser de grande valia. Se o time de desenvolvimento está envolvido, possivelmente vai estar comprometido, uma vez que ele tem insights únicos e está próximo aos detalhes técnicos. Por fim, há ferramentas que integram perfeitamente e nos ajudam a priorizar ações de resposta aos riscos em nosso trabalho.

“Gerenciar é uma atividade muito importante para ficar nas mãos apenas de uma pessoa”.


Dependendo do contexto, você vai precisar…

Em alguns projetos é muito confortável a ordenação dos requerimentos dos clientes com base no valor de negócio. Mas algumas vezes vai ser necessário dar valor à prevenção e às atividades de mitigação do risco. Criar um ranking às vezes vai ser subjetivo, porque ele será baseado nas preferências e sentimentos do cliente. Contudo, nós podemos pegar mais parâmetros sobre a construção de um backlog de riscos usando um retorno de investimento. E aí podemos usar uma fórmula:

EVM (Expectativa do Valor Monetário) = Impacto do Risco (valor monetário) x Probabilidade do Risco (porcentagem)

EVM = $10.000 x 50% = $ 5.000

Este exemplo permite dizer aos patrocinadores do projeto que o valor econômico para mitigar o risco é de $5.000. Portanto, a prioridade de responder a este risco deveria ser a mesma de uma feature de valor funcional de $5.000. Claro que nem todos os riscos vão passar por uma ação efetiva, alguns erros podem ser assumidos e atividades de alto risco entram mais cedo nas iterações dos projetos. Durante o progresso, o time precisa continuar monitorando o risco e se as ações efetivas para redução dele estão ocorrendo. Isso pode ser avaliado por duas métricas: probabilidade e impacto do risco.

Existe uma desvantagem ao usar a métrica EVM, porque ela pode focar mais no exato valor monetário do que no valor relativo do risco. Então, para ajudar, existe outra métrica que podemos usar para determinar a resposta à prioridade do risco , a chamada severidade do risco. Para calcular a severidade, em vez de utilizar a probabilidade e o valor monetário, você pode ranquear a probabilidade e impacto em uma simples escala como: baixa (1), média (2) e alta(3). Dependendo do contexto, será necessário que o risco seja priorizado com base no valor monetário ou essa necessidade será apenas de uma priorização do risco com base no valor relativo do risco. O progresso do risco pode ser acompanhado por meio de um gráfico de burndown, no qual o eixo vertical será representado pelo risco acumulado e o eixo horizontal pelo tempo representado em meses ou iterações.

Exemplo para o cálculo relativo do risco:

Severidade do risco = probabilidade x impacto

3 probabilidades x 3 riscos = 9 (grau de severidade)


Nem tudo são flores

E problemas vão aparecer em produção. O que fazer neste caso? Infelizmente, não importa o quanto tentamos identificar e prevenir defeitos, pode existir um erro ocasional que atravesse todos os nossos processos de testes e controles de qualidade e acabe no produto final. Esses são os chamados defeitos escapados. Os defeitos perdidos pelo time são os mais caros para correção. Quando descobrimos um defeito desse tipo, obviamente já é tarde demais para evitá-lo, mas podemos usar essas informações para melhorar nossos processos no futuro e reduzir o número de defeitos dessa natureza na próxima iteração.

As taxas de defeitos podem ser usadas para entender como um processo está funcionando. Uma taxa crescente de defeitos, por exemplo, deve ser uma sugestão para perguntar por que o processo parece estar piorando. Métricas simples podem ser discutidas pelo time e fazê-lo alcançar o seu potencial máximo. A interação do time ao ler das métricas também pode gerar o comprometimento necessário para criar ações de melhoria.

Para terminar, seguem alguns gráficos que podem ser utilizados para acompanhar erros escapados:

Image for post
Image for post
Image for post
Image for post

Outro gráfico que mostra o período que o defeito foi inserido e corrigido pode ser utilizado para identificar o tempo e evolução e ajudar a minimizar o custo de correção de defeitos. Algumas equipes podem rastrear ativamente o tempo médio do ciclo de defeito e estabelecer metas para a rápida resolução dele. O gráfico do exemplo abaixo pode ajudar esse acompanhamento.

Image for post
Image for post

E é isso! Espero ter ajudado e ter trazido boas ideias para implantação nos projetos de vocês. Lembrem-se:quando você tem um martelo na mão, nem tudo é prego. Quer aprender mais em tempo real com o nosso time de agilidade? Dá uma olhada aqui, procure uma vaga com o seu perfil e vamos aprender juntos. =) Se você tiver alguma dúvida ou algo a dizer, é só aproveitar os campos abaixo. Até a próxima!

Concrete

Nós desenvolvemos produtos digitais com inovação, agilidade…

Marcos Macedo

Written by

Concrete

Concrete

Nós desenvolvemos produtos digitais com inovação, agilidade e excelentes práticas, para que o mercado brasileiro e latino-americano acompanhe a velocidade do mercado digital mundial.

Marcos Macedo

Written by

Concrete

Concrete

Nós desenvolvemos produtos digitais com inovação, agilidade e excelentes práticas, para que o mercado brasileiro e latino-americano acompanhe a velocidade do mercado digital mundial.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store