Artigos

by Agile.Inc Agile.Inc Nenhum comentário

Você sabe qual a diferença do QA Tradicional e do QA Ágil?

Entenda como o papel do Analista de Testes ou QA é determinante para a qualidade de produtos digitais

Por Rodrigo Matola
Pessoa digitando num computador

A maneira como desenvolvemos produtos está mudando constantemente. Atualmente empresas em todo mundo estão adotando o desenvolvimento ágil de produtos, utilizando alguns de seus frameworks (Scrum, Kanban, Lean…).

Essa nova maneira de trabalho afeta todos os cargos tradicionais, incluindo Analistas de Testes, ou QA (Quality Assurance).

Neste artigo, vamos falar de uma maneira básica sobre as diferenças entre QAs tradicionais e QAs Ágeis, além de um breve conceito sobre agilidade e o framework Scrum.

Contexto tradicional x Contexto ágil

Em um contexto tradicional, os passos do projeto são planejados com antecedência, antes do seu início. O escopo é definido e não pode ser alterado após iniciado o desenvolvimento. Qualquer mudança requer uma aprovação e um novo contrato entre as partes. A data de entrega também é definida.

Para passar de um estágio para o próximo, é necessário inspeção e aprovação. Esse contexto também é chamado de cascata (waterfall), e geralmente segue o modelo da figura abaixo:

No modelo ágil, o software é entregue em pequenos pedaços, geralmente já funcionais, em um prazo que varia de uma semana a um mês, no caso do framework Scrum. Com estes pequenos incrementos funcionais, é possível se adaptar rapidamente a mudanças. Ser ágil não é ser rápido, mas ser adaptativo!

QA tradicional

Com base a figura acima, vemos que os testes só acontecem no quarto estágio do projeto. Nesta etapa, o software está praticamente pronto.

Geralmente, no contexto tradicional, QAs não têm contato direto com os desenvolvedores. Nesta situação, QAs praticamente caçam bugs, às vezes sendo a quantidade de bugs encontrados, uma medida de desempenho.

Nestas circunstâncias, somente QAs são responsáveis pela qualidade do produto. São eles  que garantem que os requisitos foram atendidos corretamente. Qualquer erro no software, ou não conformidade com os requisitos, a responsabilidade é exclusiva da pessoa QA.

O Manifesto dos Testes

O Manifesto Ágil foi criado por um grupo de pessoas que queriam mudar a maneira de como softwares eram desenvolvidos. Alguns anos depois, seguindo os passos do Manifesto Ágil, foi criado o Manifesto dos Testes:

  • Testar por todas as etapas MAIS QUE testar no final;
  • Prevenir bugs MAIS QUE encontrar bugs;
  • Testar o entendimento MAIS QUE checar funcionalidades;
  • Construir o melhor sistema MAIS QUE quebrar o sistema;
  • Time responsável pela qualidade MAIS QUE responsabilidade exclusiva de QAs.

QA Ágil

Pegando como referência o Manifestos dos Testes, vamos aqui descrever um pouco de como deve ser o comportamento de QAs Ágeis. Assim como no Manifesto Ágil, valoriza-se mais o item à esquerda que o item à direita – não é uma substituição, você vai continuar fazendo o que está à direita, entretanto, vai priorizar a esquerda (não confundir com política ok!?). Sendo assim, o QA Ágil deve:

Testar por todas as etapas [mais que] testar no final

Os testes devem começar já na reunião de planejamento. A partir dos critérios de aceite definidos, já é possível pensar nos casos/cenários de testes que serão feitos. 

Se o time já tem mentalidade voltada a testes e realizam TDD, BDD ou outra técnica, é hora de combinar a divisão dos testes (aplicação da pirâmide ou outra estratégia); definir o que vale a pena ser automatizado; como será a integração contínua, etc.

Também é recomendado que QAs façam code review e pair programming. Muitos bugs e inconsistências podem ser pegos durante o desenvolvimento somente observando o código, o que leva ao próximo tópico…

Prevenir bugs [mais que] encontrar bugs

Com os testes sendo feitos durante o desenvolvimento, a chance de um bug ir para produção é muito menor. Nessa fase a correção do bug pode ser imediata, pois o time de desenvolvimento está trabalhando na funcionalidade.

Dependendo do conhecimento, no momento que o bug é descoberto, a própria pessoa QA pode corrigi-lo.

Testar o entendimento [mais que] checar funcionalidades

A qualidade vai além de verificar se o software funciona como foi descrito. Isso pode ser feito por um robô.

Qualidade também engloba o entendimento da necessidade do usuário e garantir que essa necessidade é realmente o que o usuário precisa. Para isso o usuário também deve participar junto com o time no desenvolvimento, dentro do possível.

Construir o melhor sistema [mais que] quebrar o sistema

Como parte de um time, apontar defeitos e encontrar meios de quebrar o sistema vai contra o objetivo de entregar o melhor software possível. Temos que ter em mente que um software sem defeitos, nem sempre significa um software de qualidade.

O melhor sistema é aquele que resolve as dores de seus usuários. Trabalhe para isso.

Leia também: O que é de fato a Transformação Digital?

Time responsável pela qualidade [mais que] responsabilidade exclusiva de QAs

Colocar a responsabilidade da qualidade em apenas uma pessoa ou área é isentar outras pessoas envolvidas no processo de qualquer problema que será identificado. 

Todos que fazem parte, direta ou indiretamente, do desenvolvimento de uma solução devem ser responsáveis por entregar o melhor possível dentro do seu papel.

QAs podem não ser desenvolvedores no sentido de serem a pessoa que codifica a aplicação, mas desenvolvem testes e fazem parte do time de desenvolvimento. Todos que contribuem com o desenvolvimento do produto, incluindo designers/UX, são desenvolvedores e devem se responsabilizar pela qualidade do que vai ser entregue.

Trabalho em conjunto

Como o time é responsável pela qualidade, QAs devem estar presentes em todas as etapas do desenvolvimento, ajudando o time a entregar o melhor produto. A figura abaixo mostra como, em cada etapa da Sprint, QAs podem contribuir com suas próprias responsabilidades e ajudando membros do time.

E também, como parte do time:

  • ajudam a descobrir o produto certo;
  • colaboram para especificar;
  • pensam em exemplos;
  • refinam as especificações criadas pelo time;
  • automatizam as especificações;
  • ajudam a manter a Integração Contínua;
  • ajudam a manter a Documentação Viva atualizada e acessível.

QAs tradicionais x QAs Ágeis

Resumindo em tópicos as diferenças entre QAs tradicionais e QAs Ágeis são:

Além disso, QAs Ágeis:

  • estão sempre aprendendo novas habilidades e tecnologias, se adaptando a mudanças;
  • praticam comunicação clara e efetiva, colaborando com pessoas técnicas e não técnicas;
  • entendem do negócio, defendem o produto e colaboram com o cliente;
  • disseminam a cultura de qualidade e cuidam da saúde do time;
  • promovem e obtém feedbacks, tendo coragem de expor o que errado e elogiando o que está certo;
  • se mantém simples e auto-organizado, não dependendo de instruções para realizar suas atividades;
  • gostam do que fazem 🙂

E você, está no contexto tradicional ou ágil? Se no tradicional, gostaria de ir para o ágil? Se no ágil, faz o foi descrito no texto ou já está além? Deixe um comentário aqui!

by Agile.Inc Agile.Inc 2 Comentários

A Jornada do Agilista: qual o ciclo de vida desse papel dentro de um time?

Entenda melhor como é o começo, meio e o fim da atuação do especialista em Agilidade dentro de time de desenvolvimento de produtos digitais

Por Fabricio Pequeno e Ricardo Avigro
A Jornada do papel de Agilista e seu ciclo de vida dentro de um time Ágil

Considerada uma das 15 profissões emergentes de 2020 no Brasil – segundo um estudo publicado pelo LinkedIn, o Agilista, ou Agile Coach, ou Scrum Master, ou Agile Master, ou Agile Expert, entre outros nomes dados ao papel do especialista em Agilidade, é um dos trabalhos que mais cresce nos últimos tempos… Mas, você sabe como é a jornada do Agilista, seu desenvolvimento e/ou crescimento desta carreira? Ou qual o ciclo de vida desse papel dentro de um time?

Foi pensando nisso que, nós, Ricardo Avigro e Fabricio Pequeno, resolvemos escrever esse artigo! A ideia da Jornada do Agilista não surgiu para ser uma jornada definitiva, ela foi idealizada a partir do momento no qual foi perceptível um comportamento recorrente em times ágeis.

Não significa também que, seguindo essa jornada, você vai conseguir sucesso absoluto. Esse caminho defende que o Agilista tem um ciclo de vida a cumprir dentro de um time e expõe alguns marcos importantes, no qual devemos ficar atentos antes de cobrar maturidade e auto-organização das pessoas.

Pense que, por alguma vez, conversando com agilistas, você se deparou com dúvidas sobre “como é o nível de sucesso desta função?”. O papel de Agilista sempre deixou muito vago como você pode fazer as coisas e o quanto você pode fazê-las…. Não estamos aqui para limitar sua criatividade, nem o trabalho, muito menos o histórico de cada um, porém é muito importante que a gente tenha um rumo para seguir. E, com isso, nasceu a essa jornada, uma entre tantas outras que pode ser um bom caminho a ser tomado.

… Agora vamos ao que interessa, a Jornada do Agilista

Muita coisa acontecendo, correria, entregas parciais, atividades entrando no meio da sprint, desenvolve nessa sprint e na outra testa, “daily, para que isso?”, “retro só sai problemas direcionado a pessoas e não tem nada de positivo”, mas, no geral o time está bem, faz entregas e é auto-organizável para realizar suas atividades. 

Identificou alguma coincidência com algo citado? Bom, nós já passamos por algumas situações assim, e aí pensamos: “O que fazer? Por onde começo? Como agir?”. Pensando nisso, mapeamos o que chamamos de “Jornada do Agilista”, com base em nossas experiências que deram certo. 

Etapa 1 – ENTENDIMENTO

Cheguei em um time, e agora? Entendemos que é preciso fazer uma leitura do ambiente. Ok! Você já leu isso em todos os lugares, por isso, vamos lá… Como fazer essa leitura ou como chamamos, “Entendimento”, que é dividido em quatro etapas:

Fluxo para explicar a fase de entendimento de times ágeis

1 – Entenda quem é o seu time, quem são as pessoas, converse com cada um e ouça seus desafios, seu momento e suas dificuldades, sem julgamentos! Entenda o perfil técnico também, isso é muito importante. Não precisa entrar no detalhe de código, mas é bom saber minimamente;

2 – Analise o fluxo de trabalho atual. Alguns times acham que tem um fluxo de trabalho quando na verdade é um go horse disfarçado e, na loucura do dia a dia, não conseguem ver o quanto geram de retrabalho para eles mesmo. Examine também as restrições, pois muitas empresas têm processos originados do modelo tradicional e, algumas vezes, precisamos conviver com isso por um certo tempo.

3 – Entenda o backlog do produto e sua priorização. Sim, o Agilista pode ajudar o Product Owner com o backlog, questionar as priorizações e ajudar a gerar mais valor nas entregas, e isso influencia diretamente no próximo ponto.

4 – Saiba o propósito do time. Um time sem propósito vira um time tarefeiro, uma fábrica de software e isso desmotiva as pessoas.

Não existe um tempo ou uma ordem para toda essa análise, colocamos assim pois foram os pontos que achávamos mais importante e que davam base para a ação seguinte.

Etapa 2 – AÇÕES 

Depois que você tiver todo esse entendimento, chega o momento mais desafiador e pode ser contraditório com algumas literaturas, mas, é o momento de “AGIR”!

  • Identifique os problemas, monte uma proposta e apresente para a hierarquia da empresa – é muito importante estar sempre alinhado com seus superiores.
  • Apresente essa proposta para o time e busque aliados para implantação deste plano. Embora muitos falem o contrário e na agilidade pregamos que as mudanças fazem parte, as pessoas tendem a resistir à elas, por isso, quanto mais aliados você tiver, melhor para a implantação da proposta.
  • Deixe essa proposta visível para todos, compartilhe a jornada de desenvolvimento, acordos de trabalho e o que mais achar necessário.

Um dos pontos mais difíceis e cruciais desta etapa é identificar os sabotadores. Nem todos estão preparados para a mudança, seja por qual motivo for – e, sim, sabotadores existem e temos que lidar com eles. Como? Elimine-os!

Nem sempre um sabotador será uma pessoa, às vezes pode ser um processo não muito inteligente que gere desperdício, mas no geral são pessoas, e podem ser pessoas do time, de outras equipes que temos dependência ou até mesmo um gestor desconfiado e centralizador.

Essa é a parte mais complicada, pois não lemos isso (pelo menos nunca li diretamente). Mas, na prática, o sabotador se tornou um impedimento na melhora do fluxo de trabalho, implementação da proposta e/ou dia a dia do time. E falando em impedimento, nós, Agilistas, removemos como ninguém!

Para cada tipo de sabotador, temos um tipo ação a ser tomada:

  • Uma Pessoa do Time: Já li que o time deve ou não permitir uma determinada pessoa ali e, nós como Agilistas, só atuamos quando o time sinaliza. Porém, algumas vezes o time não tem maturidade para isso ou ainda não percebeu que determinada pessoa é um sabotador. Por isso, você Agilista, sim, você mesmo, deve colocar seu casaco de “general” e determinar que o sabotador seja retirado do time. (a forma de fazer isso dependerá da autonomia que terá dentro da organização, porém deve reportar o caso ao gestor direto da pessoa para que a ação seja tomada. Lembrando que deve sempre ter exemplos das situações que o levaram a tomar essa decisão e após feedbacks com esse “sabotador”.)
  • Gestor centralizador: O ideal é entender e minimizar o medo ou insegurança que ele tenha sobre o trabalho, seja falta de visibilidade, achar que o time faz muita reunião e “coda” pouco, achar que a falta de um cronograma prejudica a visão, enfim o ideal é entender e remover esse “sabotador”, pois mesmo de forma inconsciente ou indireta essas atitudes atrapalham o andamento do fluxo e consequentemente as entregas.

O que queremos dizer aqui é que, independente do que ou quem esteja atrapalhando, o andamento do fluxo e proposta estabelecida, deve ser removido.

Outro ponto importante é sempre estimular o time para ações que garantam o fluxo da jornada de desenvolvimento, uma vez estabelecido, ele deve ser cumprido. Considere sempre, os refinamentos e tenha as dependências mapeadas. Elas serão extremamente importantes para o engajamento do time em relação a Qualidade e Entrega – são coisas que não podem ser negociadas e uma não caminha sem a outra.

Nesse ponto que entraremos a seguir – que também é polêmico, pois muitos dizem que a área de Produto não faz parte do papel do Agilista, mas, na prática, como trabalhamos junto com a pessoa que energiza o papel de  Product Owner, é muito importante orientar e ajudar. E como podemos fazer isso?

  • Primeiro, é preciso garantir que o backlog esteja claro, disponível e entendido pelo time, e depois para toda a empresa. 
  • Em seguida, devemos também deixar transparente para todos as entregas do time.

Etapa 3 – DISSEMINAÇÕES 

Tendo a visibilidade do backlog e das entregas do time, começamos a entender e questionar se essas entregas estão alinhadas com o propósito do produto. E, para que isso seja possível, precisamos entender e conhecer nosso cliente, olhar pela ótica de UX e UI, para saber como é sua jornada e sua experiência usando este produto. 

Neste momento, é muito importante que você e a pessoa que atua como PO fiquem próximas de que faz o papel de Designer e do especialista da Área de Produtos. Aliás, essa parceria é essencial em todas as etapas e, levar todo esse entendimento para o time para que participem das decisões estratégicas, traz um senso de “dono do produto”, e você verá que isso fará toda a diferença. 

Por fim, pensando sempre em visibilidade, criamos um painel no qual é possível mostrar todas as entregas do produto, voltadas para as experiências do usuário, independente de times.

Literatura x Realidade

Algumas literaturas trazem modelos do que devemos seguir, eventos com sequências nas quais, independente de serem eficazes ou não, são importantes de se fazer. Não achamos que isto está errado, a questão é que poucas vezes vimos uma orientação realmente voltada ao Agilista nisso tudo…. 

Subentende-se que o Agilista deverá saber como se comportar e que a evolução do time irá acontecer perfeitamente como descrito a partir das situações propostas. O entendimento dos ciclos em muitas vezes é aplicado para produtos e para a maturidade do time, porém não é aplicado para a evolução do Agilista sobre a ótica de progresso do time como um todo. 

Nossa proposta é de conscientizar a todos que existe um ciclo de vida para a atuação do Agilista dentro de um time e que, esse ciclo, a partir de sua completude, não indica que uma deverá ter uma promoção e sim um critério de sucesso, visando o direcionamento de carreira. Assim, podemos buscar um outro time no qual nossa atuação terá resultados mais expressivos – visando a maturidade como um todo em uma empresa.

Essas foram algumas ações que adotamos e nos fizeram alcançar sucesso nos projetos que atuamos. Claro que nem sempre acertamos e aqui contamos apenas o que funcionou…

Deixe nos comentários se já passou por algo parecido e o quanto essa jornada se aplica a sua realidade. Valeu, até a próxima!

 
 
E se você precisa de bons Scrum Masters e Product Owners, nós podemos te ajudar! Clique aqui e agende uma conversa com nossos especialistas que te ajudamos a selecionar os melhores profissionais.
 
 
by Agile.Inc Agile.Inc Nenhum comentário

Você parece Ágil, mas não tem foco no Cliente? Provavelmente está perdendo o jogo!

Entenda como o foco no usuário e em sua jornada deve ser o ponto central do desenvolvimento para um produto digital de sucesso

Por Antonio Costa
Placar do jogo

Muitas empresas que estão no processo de Transformação, seja Digital ou Ágil, estão cometendo um erro muito grave em sua esteira de Desenvolvimento de Produto. Existe um grande foco no Produto e um baixo foco no Cliente. Isso faz com que a organização até tenha entregas mais organizadas e mais rápidas, mas ainda pouco eficazes. 

E sabe por que isso acontece? Às vezes a empresa tem um grande foco em ganhar dinheiro e não percebe que se dar mais atenção para a dor do cliente e atacar essas dores de forma mais organizada, o lucro vem por consequência.

Para isso, é necessário haver uma mudança de pensamento, na qual chamamos por aqui de “Foco em Produtos para Foco em Jornada e Cliente”. Vou explicar melhor no que consiste esse conceito.

Foco em Produto

É quando uma organização olha apenas seu produto, esquecendo seu cliente – o produto vem em primeiro lugar. Pode ser que ela até tenha um time ágil ou práticas ágeis, mas provavelmente o pensamento predominante venha a ser o pensamento tradicional, que faz o time buscar a eficiência operacional. Empresas com foco em eficiência demasiada, ou com grande foco no produto possui algumas características, como:

  • Começar a análise para a criação de produto ou funcionalidade, pelos sistemas internos – o sistema interno vai moldar a solução;
  • Focar em fechar requisitos, ter tudo detalhado;
  • As áreas de Negócio e TI trabalhando ainda separadas, onde não existe grande confiança entre elas;
  • Times de desenvolvimento olhando apenas sua entrega, buscando entregar mais tarefas;
  • Desalinhamento dos canais, pois como o foco é em eficiência, não precisa um canal esperar o outro;
  • Grande foco na produtividade dos times;
  • Mudanças de requisitos não são bem-vindas;
  • Foco em lançar novas funcionalidades, sem medir o que já existe;
  • Entregar o produto é mais importante que a qualidade do que já está feito.

Essa lista pode ser extensa e caberia aqui um novo texto para enumerar mais características e até detalhá-las…. Entretanto, vamos falar do que realmente importa: o modelo correto – Foco na Jornada e no Cliente.

Foco em Jornada e Cliente

Quando um time foca na jornada e no cliente, significa que o usuário final REALMENTE está no centro de todo desenvolvimento de um produto. Entenda um pouco melhor sobre as características desse time:

  • Começa pela necessidade do cliente para definir a solução viável;
  • Têm clara a jornada dos usuários e personas;
  • Áreas de Negócio e TI trabalhando diariamente em conjunto, de forma colaborativa;
  • Times orquestrando as entregas, com foco em valor;
  • Experiências iguais em todos canais (omnichannel);
  • Ciclos curtos para coletas de feedbacks com clientes;
  • Análises baseadas em dados dos clientes;
  • Abertura para mudança de escopo;
  • Foco no cliente e também em suas emoções;
  • Objetivos da empresa com foco em negócios ou cliente, e não metas para entrega de projetos;
  • Grande preocupação com a qualidade do produto (pois se você lançar algo que não funciona direito, nada agregará para o cliente;
  • preocupação em medir as features utilizadas ou não utilizadas e simplificar as funcionalidades – ao invés de lançar mais coisas novas;

Essa lista também não acaba por aqui, mas nela constam os principais pontos que vemos no mercado. A grande mudança, em termos gerais, consiste em se preocupar com a experiência do cliente, na sua jornada ao usar aquele produto digital.

Exercício

Visto os pontos acima, sugiro que você volte nessas listas e faça uma reflexão: “quantos itens acima você consegue identificar em seu time? Eles estão trabalhando com foco no cliente ou mais foco no Produto?

Sugiro também você se colocar no lugar do cliente, mas da seguinte forma, por alguns instantes: 

  1. Lembre-se de algum serviço ou produto que você consumiu recentemente, que proporcionou uma experiência muito desagradável para você… Lembre-se antes de seguir.
  2. O que você sentiu? Raiva, impotência? Pensou ou falou mal desta marca? Qual foi sua atitude?
  3. Agora se pergunte: será que o produto que você está criando, pode estar gerando esses mesmos sentimos em seu usuário? Ele pode estar reclamando da sua marca ou está desapontado com a experiência que teve ao usar esse produto?

Por fim, tenha em mente que o cliente vai consumir seu produto não por que você usa Scrum ou Kanban ou qualquer outro método ágil; não por que você possui tecnologias legadas ou disruptivas; o cliente vai comprar seu produto ou serviço, por que ele gera algum benefício para ele ou resolve uma dor do seu dia a dia.

E se você quiser tirar alguma dúvida ou falar mais sobre esse assunto, deixe seu comentário aqui ou fale conosco!

by Agile.Inc Agile.Inc Nenhum comentário

Não há nada tão inútil do que fazer com grande eficiência, aquilo que não deveria ser feito

Seu time lança diversas funcionalidades, trabalha muito, mas os resultados não aparecem? Entenda agora as principais causas tudo isso

Por Filipe Machado e Thiago Fregni

Em qualquer negócio, seja ele um produto digital ou não, uma das principais preocupações é atender as necessidades dos stakeholders e isso acaba se tornando um dos grandes objetivos a serem cumpridos. Com isso, o time trabalha muito, se empenha em lançar várias funcionalidades, mas vai deixando de lado uma meta muito importante: a maximização de valor e o retorno de investimento daquela iniciativa.

Ou seja, por mais que a Agilidade tenha sido implantada e as entregas estejam acontecendo com mais velocidade, ainda há stakeholders super descontentes. “Não há nada tão inútil do que fazer com grande eficiência, aquilo que não deveria ser feito.” Essa frase do Peter Drucker é uma daquelas que pode resumir de forma simples esse cenário. O time está trabalhando bem, com diversas funcionalidades em produção, mas será que estão fazendo algo realmente útil?

Isso soa comum para você? Pois realmente acontece em muitos negócios que estão iniciando uma transformação digital e por três principais motivos:

  • Maximização de valor e o retorno de investimento

Geralmente, o Product Owner fica muito preocupado em atender os stakeholders e acaba deixando de lado uma das suas principais responsabilidades que é a maximização de retorno do investimento.

  • Senso de propósito

É comum o time (Agilista, PO e Devs) não saber de forma clara qual o objetivo do produto ou não ter visão sob o motivo de estarem trabalhando em determinada demanda. Sabem o que é, como deve ser feito, mas não o por quê – não possuem senso de propósito!

  • Discovery/Ideação/Upstream 

A maximização de valor do produto, ou seja, aquilo que o cliente recebe na ponta, precisa passar por um processo de discovery e refinamento, antes de iniciar o desenvolvimento. E não é sempre que isso acontece!

Mas qual é a causa raiz desse problema?

É possível identificar alguns sinais que ocasionam essas situações descritas acima. Os principais são: 

  • Baixa autonomia do Product Owner, que depende de outras pessoas para tomar decisões e esclarecer detalhes;
  • Product Owner que não tem a competência correta;
  • PO tirador de pedido (PO Proxy/Escriba), que não tem ownership do produto. Anota os pedidos sem entender o porquê da solicitação e quais os resultados esperados;
  • Time se preocupa em encher o capacity. Ou seja, durante reuniões de Planejamento, existe uma preocupação maior em “arrumar” backlog suficiente para deixar todos ocupados, do que gerar realmente valor para o cliente;
  • PO que não sabe quanto custa cada PBI e não tem noção do custo do time, o que o impossibilita de fazer trade-offs baseados no RoI;
  • Times que não possui objetivos claros, impossibilitando-os de fazer escolhas e manter o foco no que mais gera valor;
  • Não possui Discovery (UX). Ou seja, assim que a solicitação chega, vai direto para o time desenvolver. Não existe um processo no qual o cliente é envolvido e hipóteses são tratadas como verdades;
  • Não existe uma visão Customer Centric, focada no consumidor/usuário.

Bom, se você tiver identificado alguns desses pontos acima em seu time de transformação, você está cometendo esse erro. E isso pode ser nítido em um time ágil que ainda está no paradigma tradicional de trabalho.

Resolvendo essas questões 

Quando identificamos esse cenário – que é bem comum, fazemos um trabalho bem intenso de coaching com o Product Owner, com o Scrum Master e com os stakeholders. Para isso, executamos técnicas como:

Criar um time de discovery: a fim de descobrir que funcionalidades devem ser implementadas para atender as necessidades dos usuários;

Técnicas de ordenação de backlog: o backlog deve estar ordenado e tais técnicas nos ajudam a ordená-los de acordo com os objetivos a serem alcançados;

Criar bem claramente um esteira ágil utilizando Flight Levels: esta técnica dá visibilidade de portfólio até chegar na mão do usuário final;

Organizamos os times por Value Stream ligados ao usuários, com objetivos claros, utilizando OKR´s, por exemplo;

Definição de objetivo do produto e deixar o claro qual o valor (aumentar 10% as vendas, aumentar a taxa de conversão em 5%, entre outros) esperado a ser atingido por aquele item, mais valor de itens;

Roadmap: uma visão geral dos próximos passos do produto;

Utilizar dados para tomada de decisão em itens de backlog;

Criação de conceitos de hipóteses: uma ótima forma de trabalho que ajuda a validar as hipóteses é chamada HDD (Hypothesis Driven Development). Este método auxilia na escrita do nosso backlog, orientado à validação de hipóteses.

No geral, tentamos dar o correto propósito para o time como um todo, ligado a valor para o cliente ou negócio… Por que, quando não se sabe onde quer chegar, qualquer caminho serve. E, por isso, o trabalho se torna eficiente, mas não realmente eficaz!

Mais valor entregue, com menor investimento

Solucionando essas falhas durante o processo de desenvolvimento de um produto com um time ágil, é possível ter diversos benefícios, entre eles:

  • Conseguir trabalhar no processo empírico, focando sempre no objetivo desejado;
  • Se torna mais fácil gerenciar a ansiedade dos stakeholders quanto aos resultados;
  • O stakeholder fica mais contente com a entrega, pois ela está ligada ao propósito, com foco em gerar realmente valor com a iniciativa;
  • O clima de confiança do stakeholder com o time melhora;
  • Resumindo, mais valor entregue, com menor investimento e foco na maximização de valor e o retorno de investimento da iniciativa.

Esperamos que você consiga aplicar essas sugestões em seu dia a dia. Qualquer dúvida, estamos à disposição para ajudar… É só entrar em contato conosco!

by Agile.Inc Agile.Inc Nenhum comentário

Seis dúvidas comuns ao implementar uma transformação ágil

Como esclarecemos os principais questionamentos que surgem nesse processo inicial de implementação da agilidade numa empresa

Por Eduardo Alcaraz

Iniciar uma transformação numa empresa, seja ela ágil, digital ou cultural, realmente é uma decisão muito significativa, levando em conta o impacto que causa. Mesmo que positiva e com tantos benefícios, essa jornada de mudanças ainda gera muitos questionamentos na mente de líderes. E, por isso, vamos compartilhar algumas das  dúvidas comuns ao implementar uma transformação ágil que ouvimos nos últimos tempos.

“Escopo aberto é cheque em branco?”

Essa é a primeira das seis dúvidas comuns ao implementar uma transformação ágil, principalmente partindo de gerentes de TI: “escopo aberto é cheque em branco?”. É comum que a Agilidade seja confundida com bagunça e falta de comprometimento com os objetivos da entrega. Por isso, a primeira maneira de mitigar este estigma é justamente entender o propósito do que deve ser feito

Em seguida, apresentamos uma das diferenças entre a entrega features e entrega de valor:

Uma outra característica que é muito importante no SCRUM é a entrega de incremento de valor em cada Sprint. Um projeto que, a cada 14 dias tem uma entrega de software rodando, gera muito mais transparência ao cliente.

Falando nisso, outra característica que deve ser levada em conta na hora que surgem essas dúvidas ao implementar uma transformação ágil é a transparência. Um projeto de escopo apresenta rapidamente os típicos blocks, que impedem que um software vá para a produção. Proceder nesses pontos de maneira honesta e, não personificada, faz com que os stakeholders possam agir e resolver tais blocks para que o projeto todo tenha sucesso.

Finalmente, o desenvolvimento de um projeto pode sofrer várias adaptações. Seja pela mudança de target do projeto, de algum block ou de uma mudança no mercado. O escopo aberto não se esconde atrás de um contrato pré-definido, mas engaja cliente e fornecedor em torno de um objetivo: entrega em produção.

“Mas o que vou receber?”

Falamos um pouco das diferenças entre escopo e valor. Invariavelmente, este valor significa software em produção – e rápido. Sendo assim, surge essa segunda questão, bem frequente entre as dúvidas comuns ao implementar uma transformação ágil.

A Agilidade oferece essa entrega de valor de uma maneira muito simples. Os times engajados no propósito são capazes de fazer pequenas entregas em produção, sempre. E essas pequenas entregas servem para manter o cliente e os times engajados, e dá a possibilidade de priorizar próximos passos com o “software na mão”. 

Então, as pequenas entregas em produção dão ao cliente o conforto de saber o que está sendo feito, a qualquer tempo.

“Como eu acompanho a evolução do desenvolvimento?”

Essa é uma das perguntas que mais ouvimos! Por isso, é importante ressaltar que o cliente faz parte do time, seja como Product Owner, seja como stakeholder. Logo, o acompanhamento é automático e fluido.

Sendo assim, o cliente é parte integrante do status report. Ele, como o restante do time, tem a responsabilidade de mitigar, adaptar e dar publicidade diariamente.

Vale aqui a menção do antigo PMO (Project Management Office) para projetos de escopo fechado. O PMO tradicional cobra e entrega um status report. E esse status não costuma apresentar exatamente o que está acontecendo no projeto.

“Meu chefe não me deixa fazer isso.”

Essa é outra fala que  faz parte das dúvidas comuns ao implementar uma transformação ágil. Entretanto, acreditamos que esta posição de “chefe” está lá por um ótimo motivo. Ou ele ficou muitos anos em sua empresa, galgando posições e conquistou seu espaço. Ou ele é muito competente no que faz e foi trazido para liderar e resolver problemas na sua organização.

Nesta situação, o ideal é entender as motivações dele para se manter no modelo tradicional. Geralmente há dois grandes motivos:

– Para multinacionais, pode ser uma diretriz da matriz (apesar de pouquíssimo frequente);

– A empresa está acostumada a “ter alguém para colocar a culpa”, caso o projeto dê errado.

No primeiro caso, a saída mais óbvia é começar a criar a cultura de agilidade dentro da organização. E o departamento de Recursos Humanos pode te auxiliar nisso!

Na segundo cenário, temos uma porção de argumentos reais que fazem a Agilidade ser uma boa saída para a transição do modelo tradicional para entregas com mais sentido e mais valor agregado. 

“E quais são as minhas garantias?”

A principal garantia do cliente é justamente a entrega contínua de valor. Sabemos que a Agilidade expõe os fatos rapidamente e o cliente é constantemente informado – levando em conta que o cliente faz parte do projeto, como PO.

E aí surge o questionamento: “mas se o software não ficar pronto na data?”

Deparamos a todo momento com datas fatais: dias das mães, dia dos pais, Natal, lançamento de marca, rodada de investimentos, entre outras. A principal ferramenta para mitigar a entrega é a priorização. Avaliar o que é mais importante, trabalhar em pequenos ciclos de entrega, se adaptando a todo momento, focado em entregar o melhor produto na data… Essa é a melhor técnica de sucesso para cumprirmos a tal data!

“Ainda somos muito tradicionais e Agilidade não é para nós.”

Além de todas essas questões, por fim, ainda ouvimos muito essa afirmação durante a negociação de uma transformação tão grande como essa. 

Mas, mais uma vez, é preciso entender que o mundo mudou. Não só por conta de um vírus desconhecimento que ocasiona a COVID-19, mas pela ânsia dos profissionais em serem mais felizes em seus trabalhos, em todas as escalas.

  • As organizações cartesianas (aquelas “meu chefe manda e eu executo”), está cada vez mais em decadência.
  • As entregas contínuas fazem cada vez mais sentido nesse mundo VUCA, no qual já falamos muito neste artigo aqui.
  • Então, a nossa resposta é: “SIM, a Agilidade é para todo o mundo!”

Tem mais alguma dúvida sobre esse assunto? Entre em contato conosco que vamos te ajudar.

Conheça alguns dos nossos cases de sucesso.

by Nelson Legal Nelson Legal Nenhum comentário

Experiência de Usuário: Entenda o que falta para o sucesso do seu negócio digital

Saiba quais são os benefícios de UX e como essa prática faz o cliente se tornar um fã do seu produto

Por Nelson Legal 
Mulher feliz olhando o celular

Eis que virando a esquina ele vem chegando, o mais desejado, o mais disputado, o mais querido e valioso, o cliente! Também conhecido como consumidor, usuário, público alvo e por aí vai… Todas as empresas precisam dele para existir, e manter o consumidor fiel à sua marca vem sendo uma tarefa cada vez mais difícil. 

Ficou para trás o tempo em que, para ter o coração do consumidor, bastava vender um produto bom e barato. É preciso muito mais… Hoje, grandes marcas competem para ter a chance de proporcionar a melhor experiência para o consumidor

Recebendo tanta atenção, o cliente ficou extremamente criterioso e atento a qualquer deslize e, caso isso aconteça, ele não pensa duas vezes pra mudar de marca.

A cada problema que aparece no caminho do consumidor, existem inúmeras empresas que o resolvem com uma mão nas costas. Mas uma empresa que, além de resolver o problema, ainda seja capaz de colocar um sorriso no rosto e trazer um calor no coração desse cliente, isso é bem mais difícil de se conseguir.

E é difícil porque a empresa precisa criar um vínculo especial com seu consumidor, tem que ir a fundo e ser capaz de predizer o que ele gostará ou não, e quanto esforço estará disposto a empenhar. E o mais importante, garantir que tudo o que foi feito ficará claro e será entendido intuitivamente. Complexo, né?

Pois é aí que entra a UX, User Experience ou Experiência de Usuário, traduzido do inglês. Criada por Don Norman na década de 90 enquanto trabalhava na Apple, a definição surgiu pois ele queria melhorar a experiência do usuário com seus computadores. Não só no momento em que interagiam com o computador ligado, mas no antes e depois disso. 

Um bom exemplo disso é como um restaurante que tem o melhor hambúrguer da cidade. De nada adianta um hambúrguer perfeito se não pensarem no conforto, no atendimento e no menu, entre outros detalhes tão importantes quanto. Cada um desses itens pode fazer um cliente decidir se gasta mais ou menos, se volta ou não, se indica ou fala mal do restaurante. Tudo tem que ser muito bem planejado para agradar e realmente atendê-lo!

Mas como a prática de UX vai impactar meu negócio?

Esse planejamento, focado na experiência do usuário, também pode economizar esforço e dinheiro, e aumentar os lucros de sua empresa. Segundo o livro de Robert Pressman, “Engenharia de Software: Uma Abordagem Profissional”, a cada R$ 1,00 gasto em UX para resolver um problema durante o planejamento do produto, R$10,00 seriam gastos para resolver o mesmo problema no desenvolvimento e R$ 100,00 ou mais para que o problema fosse resolvido depois que o produto fosse lançado. Ou seja, além de evitar problemas, esse planejamento também pode direcionar e facilitar o caminho entre o cliente e seu produto.

Um recente estudo realizado pela Forrester Research revelou que uma interface de usuário bem projetada pode aumentar a taxa de conversão de um site em até 200%, e uma boa experiência de usuário pode subir as taxas de conversão em 400%. 

Não é à toa que grandes empresas multinacionais são defensoras de investimentos em UX. A Amazon, por exemplo, aplica testes A/B continuamente em todos os aspectos das interfaces que atendem seus clientes, atualizando-as e redesenhando-as  constantemente com base em dados. Desde 2015, a Amazon vem sendo a maior loja de e-commerce do mundo e a mais valiosa nos Estados Unidos. 

Já aqui no Brasil temos o caso do Nubank, a principal fintech da América Latina que nasceu em 2013 e hoje já conta com mais de 5 milhões de clientes fiéis. Desde o nascimento, a fintech tem o usuário como centro de todas as suas decisões. Segundo Guilherme Neumann, ex-UX Lead do Nubank, “a solução de design ou de interface que surge é consequência não só do trabalho que o designer faz, mas da preocupação que todo mundo no Nubank tem com a experiência de quem usa o produto.”

Vemos como a UX se mostrou importante para essas empresas, e pode ainda ajudar outras a alcançar inúmeros benefícios, como:

  • Aumentar o lucro e conversão: usuários se tornam leais a produtos fáceis de usar;
  • Aumentar índices de satisfação do consumidor: usuários amam produtos bem desenhados que dão o que ele precisa e o que ele nem sabe que precisa;
  • Diminuir contatos com suporte: testes com usuários resultam em usabilidade mais fluída e intuitiva para o maior número de pessoas;
  • Evitar o retrabalho no desenvolvimento do produto: UX foca no entendimento da jornada de usuários e na aplicação de testes, o que diminui a ocorrência de erros de planejamento;
  • Reduzir o risco de produzir o produto errado: as pesquisas com usuários vão buscar produtos que agreguem real valor a eles no dia-dia.

Para começar a investir em UX, o primeiro passo pode ser agregar um Product Designer ao seu time, alguém que seja capaz de trazer a cultura de User Experience para dentro da empresa e engajar os times como um todo.

O passo seguinte é formar times com especialistas em áreas específicas da UX, como pesquisa, escrita, interface (UI), prototipagem e testes. O ideal é que todos se complementem, ao mesmo tempo que, individualmente, tenham capacidade de atuar em todas as áreas da UX.

Quer saber mais sobre esse assunto? Entre em contato com a gente para conversarmos sobre como incluir UX na prática. Várias empresas já tiveram resultados positivos depois de incluir UX no dia a dia e a sua pode ser a próxima!

Sem Parar: Entenda como uma das maiores empresas de pedágio do mundo aumentou sua base de usuários no app em 315%

by Agile.Inc Agile.Inc Nenhum comentário

As 5 disfunções de um time e como evitá-las para ter pessoas mais engajadas

Por Filipe Machado

Durante o dia a dia de trabalho, um time pode apresentar algumas disfunções, seja por brigas internas, desconfiança, falta de comprometimento ou mesmo por disputa de posição. Esses problemas são comuns, mas podem se tornar impedimentos para que a equipe atue de forma engajada e com alto desempenho.

Mas, se você está lendo esse texto, deve estar pensando: como exigir que um time composto por pessoas com diferentes experiências, personalidades e motivações reme junto para o mesmo objetivo?

Foi sob essa ótica que Patrick Lencioni escreveu o livro “As 5 Disfunções de um Time“, que traz um modelo piramidal com essas cinco disfunções: Falta de Confiança, Medo do Conflito, Falta de Comprometimento, Ausência de Responsabilidade e Falta de Resultado.

Confiança

Falta de confiança é a base da pirâmide das 5 disfunções de um time. Sem confiança entre os membros não há como sustentar as outras 4 disfunções. Quando um time está em formação, os indivíduos se protegem dentro de uma casca para não se tornarem vulneráveis. Eles são incapazes de demonstrar suas fraquezas e se abrir uns com os outros. Relutam em pedir ajuda ou a se prontificar a ajudar uns aos outros. A ausência de confiança traz uma enorme perda de energia e tempo para os membros do time.

Contudo, para se ter confiança é necessário quebrar essa casca e mostrar suas deficiências, fraquezas, necessidades… Nem todos os dias são perfeitos e os membros do time precisam confiar uns nos outros para expor e entender tais situações. Uma boa dose de empatia ajuda muito a construir uma base sólida de confiança. Além disso, o time precisa ter as habilidades necessárias e confiar que são capazes de resolver determinado problema de negócio.

Conflitos

Times sem confiança são incapazes de encarar conflitos da forma que precisam ser encarados, causando certa harmonia artificial. O medo do conflito cria intrigas e discussões veladas que não são saudáveis quando o time deveria estar comprometido e focado na direção de um único propósito. Afinal de contas, quando falamos de time, todos ganham e todos perdem. Por essa razão, os conflitos devem ser encarados de frente, com transparência e respeito.

Comprometimento

Quando os conflitos são encarados de frente, o time passa a exigir mais comprometimento interno de modo que todos consigam falar e serem ouvidos. É necessário que os membros do time tenham abertura para expor suas ideias e que todos tenham respeito uns pelos outros. Contudo, nem tudo que é falado será acatado.

É necessário encontrar um ponto em que uma decisão seja tomada de modo que todos estejam de acordo, que o propósito esteja claro para todos. Dessa forma, todos estarão engajados e comprometidos no mesmo objetivo.

Ausência de Responsabilidade

Times que não são comprometidos não têm responsabilidade. Uma vez que o time esteja comprometido é necessário que seja consciente e não se esconda de suas responsabilidades. Responsabilidade é mais sobre ação do que reação, ou seja, num time responsável, que caminha na mesma direção, não deve haver delegações.

Preferencialmente, os membros devem ser auto-organizados e pró-ativos na criação de soluções. Um time responsável não encontra culpados, pelo contrário, busca junto soluções pois sabem que estão envolvidos dentro do mesmo objetivo e que o sucesso ou fracasso depende de todos.

Falta de Resultado

Quando os indivíduos não são responsabilizados, os membros da equipe naturalmente tendem a buscar seus próprios interesses e não os interesses da equipe. Porém, quando há responsabilidade e comprometimento, os conflitos são encarados abertamente e a confiança está plena, os membros do time naturalmente focam seus esforços em prol dos resultados, pensando no bem coletivo em detrimento às realizações pessoais.

Removendo essas falhas

Para que um time atinja alta performance e entregue cada vez mais, resultados melhores, de forma eficaz e eficiente, naturalmente você precisará tratar essas 5 disfunções.

Os benefícios desse processo para o time são: 

  • Reconhecer suas fraquezas e limitações e sentir-se mais confortáveis em pedir ajuda; 
  • Compartilhar skills;
  • Focar na solução de problemas, pensando no coletivo;
  • Tomar decisões de forma mais rápida;
  • Enfrentar problemas críticos de frente;
  • Estar sempre alinhados e focados no mesmo objetivo; 
  • Aumentar o engajamento das pessoas.

Por fim, entenda que todas as disfunções estão conectadas. A chave é começar construindo uma base sólida de confiança e, em seguida, incentivar conflitos saudáveis, manter a responsabilidade e definir objetivos claros, garantindo que o time comunique-se sempre com clareza.

Precisa de ajuda sobre esse assunto? Nós temos algumas ferramentas essenciais para resolver situações como essas! Clique aqui e conheça.

https://old.agile.whit.digital/voce-parece-agil-mas-nao-tem-foco-no-cliente-provavelmente-esta-perdendo-o-jogo/


by Agile.Inc Agile.Inc Nenhum comentário

A importância da Pirâmide de Testes para a qualidade de softwares

O risoto de sobras é uma ótima analogia para explicar de forma didática a relevância da pirâmide de testes para os stakeholders

Por Rodrigo Matola

Às vezes é difícil para um stakeholder que não técnico entender a importância de testar bem uma funcionalidade antes de colocar a aplicação em produção. Sempre ouvia: “eu entendi a importância da pirâmide de testes, mas preciso lançar isso ao final da próxima Sprint. Se colocar testes unitários vai demorar mais pra entregar, eles não são prioridade”.

Com isso, pensei em algumas analogias para poder explicar a pirâmide de testes e sua importância durante o desenvolvimento de um produto digital. Vamos falar agora do “risoto de sobras”!

Como fazer um risoto de sobras

Lembro muito bem do risoto que minha mãe e tias preparavam no dia seguinte de alguma festa, principalmente as de fim de ano, na casa da minha falecida avó, com as sobras. Eu gostava ainda mais quando o risoto ia ao forno.

Entretanto, fazer esse risoto é bem simples. Com a ajuda de mais duas pessoas, no mínimo, para formar um time de 3 e otimizar o processo. Pode chamar mais, se quiser, mas é recomendável que o time não ultrapasse 9 pessoas. Siga essas instruções:

– Faça uma nova panela de arroz e misture com o arroz que sobrou (e que não dá pra todos comerem);

– Pegue as sobras das carnes de porco, peru, chester, tender e todas as outras disponíveis. Desfie e misture no arroz;

– Pegue todas as outras sobras, pique em pequenos pedaços. Misture na mistura anterior;

– Coloque queijo parmesão ralado por cima e leve ao forno até gratinar.

Agora vamos começar as analogias…

Colocando em produção

Ao servir o risoto, cada pessoa a mesa faz o “download” para o seu prato. Aí começam as reclamações: “Tá com gosto azedo”; “Isso tá estragado!”; “Eu achei doce”; “Doce? Minha parte estava extremamente salgada!”. 

Cada pessoa relata um bug diferente. Você terá que jogar o risoto fora e tomou um prejuízo grande, já que terá que pedir comida pra família toda agora sairá caro… Mas antes, como stakeholder, você quer descobrir o que deu errado. Mas como descobrir o que está errado dentro dessa mistura toda?

Aplicando a pirâmide de testes

Voltando ao desenvolvimento de produtos digitais, após a analogia contada acima, podemos entender o quanto é importante o processo de testes para garantir a qualidade do produto final. Para isso, podemos elencar:

Testes unitários

Voltando no tempo, até o momento da montagem da equipe, para evitar que o ocorrido contado anteriormente aconteça, cada participante do seu time deveria provar o ingrediente antes de colocá-lo no risoto. O teste unitário de cada item deve ser realizado primeiro. Esses testes mostrariam que o arroz que foi deixado fora da geladeira, estaria azedo e que a carne de porco estava estragada, por exemplo.

Os testes unitários servem justamente para testar a menor parte de um sistema. No risoto, testaria se cada ingrediente estava bom para ser adicionado. Num código, testa-se cada unidade (função, objeto, entre outros) está se comportando e respondendo como deveria frente a vários cenários.

Testes de integração

Mesmo que cada unidade esteja pronta e de acordo com as especificações passadas é preciso também verificar se, quando colocados juntos, eles combinam, ou seja, se integram.

Voltando a analogia do risoto de sobras, vamos primeiro pegar a reclamação que “o risoto estava muito salgado”. É preciso ir testando a quantidade de sal até que ela fique ideal. Apesar do sal ter passado no teste unitário de validade, no de integração ele retornou um valor muito maior que o esperado, que “quebrou” o risoto.

Já na reclamação do muito doce, foi pedido que se colocasse azeitonas pretas. Mas, a pessoa que ficou encarregada dessa parte não conhecia bem o negócio e colocou uvas-passas. O teste unitário passou, apesar de ter sido desenvolvido errado, mas no de integração não passaria. Nesse caso, o teste unitário deve ser refeito.

Testes funcionais e exploratórios

Mesmo que a azeitona preta se integre bem com o arroz, por exemplo, talvez não “funcione” se misturar outro ingrediente junto. A cada incremento do risoto (software) é preciso testar se está “funcionando” como o esperado. Se alguém resolve colocar castanhas ou amendoim no risoto simplesmente porque gosta, apesar de funcionar e ficar gostoso, outros convidados podem não gostar ou terem alergia.

No mundo de softwares, pode ser que alguém tenha feito uma implementação diferente da que estava na especificação ou até invente uma. Com os testes funcionais é possível identificarmos isso. 

Como extensão, se alguém deixou passar um pedaço de osso, somente um teste exploratório iria detectar. Nesse caso, o erro estaria em uma parte específica do risoto (código) que somente um usuário na mesa (produção) iria achar.

Testes de regressão

Também devemos “testar” (provar) o risoto a cada implementação. Ao adicionar sal, teste para ver se ficou salgado. Teste a consistência do arroz para ver se precisa de mais água e cozinhar mais.E coloque o sal e a água aos poucos. Se colocar uma quantidade fixa desses ingredientes, pode ficar salgado, virar uma canja ou ficar cru.

Trazendo esse exemplo para o desenvolvimento de softwares, teste-o por completo a cada nova implementação. E não faça implementações gigantescas, como colocar a quantidade final de sal e água juntos, por exemplo. Faça pequenos e constantes lançamentos, de somente uma funcionalidade, pois se der algo errado, fica mais fácil de consertar.

Testes de aceitação

Por último, deve ser realizado testes com o produto completo antes de ser servido. Não é aconselhável uma só pessoa testar, mesmo que tenha especificações detalhadas, pois o produto final será consumido por várias pessoas. Quanto mais pessoas provarem (testarem), mais qualidade seu produto final terá!

No caso do risoto, não é viável fazer um teste automatizado (utilizando uma análise química, por exemplo). Os testes tem que ser manuais e exploratórios, mas no caso de um software, os testes podem (e devem) ser automatizados, deixando os manuais para cenários que não valem a pena o esforço de automação.

Conclusão

Esse exemplo do risoto de sobras é uma maneira diferente que usamos para explicar a pirâmide de testes para pessoas sem base de programação, a importância de dividir e, principalmente, fazer testes durante o ciclo de desenvolvimento e não apenas no final.

Testar cada elemento de um produto digital antes de oferecer ao público pode realmente demorar um pouco mais. Entretanto, assegura que o produto tenha uma melhor qualidade e que os clientes finais fiquem mais satisfeitos.

Gostou do texto? Tem dúvidas sobre o processo de automação de testes? Deixe seu comentário aqui!

Ainda tem dúvidas de como implementar esses testes, marque um bate-papo conosco, nós podemos te ajudar!

 

Por que os processos Ágeis não estão ajudando na Transformação Digital?

by Agile.Inc Agile.Inc Nenhum comentário

Você sabe quais são os pilares para uma Transformação Digital correta?

Entenda agora as cinco bases necessárias para ter sucesso e vantagem competitiva nesse processo de Transformação Digital

Todos os dias podemos perceber o quanto o mundo está se transformando e como isso está acontecendo cada vez mais rápido. “Estamos a bordo de uma revolução tecnológica que transformará fundamentalmente a forma como vivemos, trabalhamos e nos relacionamos. Em sua escala, alcance e complexidade, a transformação será diferente de qualquer coisa que o ser humano tenha experimentado antes”, disse Klaus Schwab, Fundador e Presidente Executivo do World Economic Forum, sobre o futuro insondável, ambíguo e aberto da Quarta Revolução Industrial.

Neste cenário, a Transformação Digital acabou virando uma nova buzzword no mercado, no qual muitos dizem que fazem essa jornada de mudanças, mas poucos realmente realizam de forma eficiente, com uma visão holística do tema. 

Vale ressaltar que algumas empresas já nasceram na era Digital e de uma forma Digital, enquanto outras empresas nasceram Tradicional e só agora estão tentando migrar para um mundo Digital. Com isso, não é raro ver pessoas que tentaram transformar empresas tradicionais sem sucesso, se desligarem dessas corporações e criarem uma nova companhia, agora já com a cultura digital enraizada, desde seu nascimento. 

Por isso, atualmente, classificamos as empresas em dois grupos: 

  • Empresas que nasceram de forma tradicional e agora estão tentando migrar;
  • Empresas que já nasceram com a cultura digital.

Como já explicamos mais profundamente em um outro texto aqui do blog, entendemos por Transformação Digital como uma mudança fundamental na forma como a empresa se organiza, com uso de tecnologia, pessoas, processos e modelos de negócios, visando estar adaptado à um universo mais complexo e dinâmico, onde é fundamental ter foco na geração de valor ao cliente. Isso será decisivo na vida das empresas: quanto mais mindset digital a organização possuir, maior vantagem competitiva no mercado ela terá nesse novo mundo VUCA.

Para essa mudança acontecer, ou seja, a empresa sair do Tradicional e ser mais Digital, nós da Agile.Inc criamos um modelo que ajuda nesse processo de migração. Esse conceito foi desenvolvido pela nossa equipe, depois de muitos estudos e prática no dia a dia. 

Temos então cinco pilares para uma Transformação Digital correta:

Pilares para uma Transformação Digital correta

CULTURA

A mudança de cultura está como primeiro pilar para a verdadeira Transformação Digital acontecer, não por acaso. Afinal, tudo se resume em uma mudança cultural e de mindset. 

Entre as diversas mudanças de cultura, podemos destacar: 

  • Colocar realmente o cliente como ponto central do seu negócio;
  • Ter uma cultura de inovação aplicada;
  • Empoderar os times, mas com alto alinhamento;
  • Criar uma cultura de “não ter medo de falhas” e
  • ter mais transparência nas ações, decisões e planos

Esses são alguns exemplos de como a mudança cultural é o ponto primário da transformação.

“Você comete muitos erros ao longo do caminho, mas tudo bem. Não há problema em cometer erros, contanto que você aprenda com eles. (Meu pai e CEO) Vince tem uma expressão: ‘Tudo bem cometer erros, mas nunca cometer o mesmo erro duas vezes.’” – Stephanie McMahon, diretora de marca da WWE durante debate, em 2018. – https://www.istoedinheiro.com.br/confira-10-frases-inspiradoras-do-forum-economico-mundial-de-davos/

CAPACIDADES INTERNAS

Além da cultura, as empresas precisam de novas capacidades internas, ou seja, os times precisam ter novas habilidades para resolver problemas mais complexos. 

Entre essas competências, podemos ressaltar algumas como:

  • Trabalhar com novas tecnologias (Big Data, Blockchain, Machine Learning, entre outras);
  • Agilidade no desenvolvimento de produtos,
  • Gestão lean na concepção de produtos;
  • Uso do Design de maneira estratégica.

Esses são apenas alguns exemplos de capacidades internas que precisam ser desenvolvidas, dependendo do contexto de cada negócio.

ESTRUTURA E GOVERNANÇA

Esse pilar consiste em repensar a forma como a empresa está organizada. Empresas que já são digitais, se organizam de forma diferente das tradicionais:

  • Como as áreas da empresa estão estruturadas?
  • Como quebrar os silos da organização?
  • Como o budget é definido?
  • Como as iniciativas são priorizadas?
  • Como o acompanhamento do trabalho é feito de forma transparente?
  • Como criar maior eficiência operacional, por exemplo, com automação?

Novamente, esses são alguns exemplos de questionamentos que são abordados durante essa transição de empresas Tradicional para a era Digital, no que se refere a estrutura e governança, variando muito para cada tipo de negócio.

PESSOAS

Ter as pessoas certas, nos lugares certos e com o correto direcionamento é fundamental. Nesse pilar da verdadeira Transformação Digital, olhamos:

  • Papéis e responsabilidades (destacando que, não adianta estar apenas definido, mas deve ser seguido e monitorado de forma natural por todos), 
  • Como está a motivação das pessoas;
  • E qual modelo de liderança a ser aplicado.

Como pensamos aqui na Agile.Inc – no final do dia, são sempre pessoas trabalhando com pessoas para criar produtos para outras pessoas

Mas, infelizmente, ainda vemos muitas empresas tratando pessoas como recursos, de uma forma bem “comoditizada”, no qual basta apenas contratar colaboradores da consultoria que for mais barata, por exemplo.

MODELOS DE NEGÓCIOS

O quinto pilar da Transformação Digital consiste em pensar em novos modelos de negócios para o mundo VUCA. A forma como as pessoas compram e consomem serviços está mudando e as empresas precisam se adaptar o mais rápido possível.

Por exemplo, o típico caso do banco que começa a cobrar algo sem que você veja e saiba, já não é mais aceito por todos. Se isso acontece, as pessoas logo vão para as redes sociais ou sites de reclamação falar sobre isso, gerando problemas para a imagem da instituição. Surge então com mais frequência novos modelos de serviços, como os de Assinatura, Freemium, OnDemand, entre outros, visando sempre a experiência do usuário.

O trabalho consiste então em desenvolver esses cinco pilares para uma Transformação Digital correta nas organizações. Sentimos que cada empresa possui um dos pilares mais ou menos desenvolvido, ou com a necessidade de desenvolvimento de um pilar primeiro, etc.

Entretanto, acreditamos muito que alguns pontos são alavancas propulsoras para a transformação, ou seja, nem tudo vai acontecer ao mesmo tempo. As alavancas são:

  • Desenvolver a liderança
  • Capacitar os times
  • Aplicar conceitos de Agilidade

Se começarmos por esses três pontos, todo o resto acaba sendo incentivado de forma positiva. Conte conosco nesse processo de transformação – queremos cada vez mais levar a verdadeira transformação digital para as empresas e pessoas. 

Leia também:

by Agile.Inc Agile.Inc 1 comentário

O que de fato é a Transformação Digital?

Enquanto você não entender em detalhes o que é a Transformação Digital, seu time vai continuar tendo grandes esforços com baixos resultados. Entenda de vez e saia na frente!

Será que a transformação digital pode me ajudar a fazer mais com menos? Consigo entregar mais resultados em minha empresa? Trabalhar de forma mais eficiente, que gere mais entregas? O que posso melhorar no meu dia a dia, para ser mais digital? 

Essas são algumas das várias dúvidas que chegam até nós, todos os dias, sobre o que é e quais os benefícios dessa tal transformação digital… Entretanto, ainda existe muita nebulosidade sobre o tema, tanto por falta de informação consistente, quanto por modismo de muitos tentando vender esse tipo de serviço ou realizar essas mudanças, cada um à sua maneira.

Como várias outras modas do passado e outras que aparecerão no futuro, elas podem ser exageradas em algum momento por quem não entende do tema. Contudo, as dúvidas mencionadas acima permanecem na cabeça das pessoas.

Bom, mas o fato é que não basta as empresas seguirem a moda ou fazerem algo apenas “para inglês ver”, de forma mecânica… Como diz Antonio Costa, sócio da Agile.Inc: “No final do dia, o cliente vai comprar seu produto ou serviço, não por que você usa Agilidade ou por que você faz a Transformação Digital. O cliente vai comprar seu produto porque você realmente gera algum valor para a vida dele.

O que está acontecendo no mercado?

Basicamente, boa parte da transformação digital está pautada na Quarta Revolução Industrial, que está acontecendo no mercado, nos dias atuais. 

  • A Primeira Revolução Industrial usou a energia da água e vapor para mecanizar a produção. 
  • A Segunda usava energia elétrica para criar produção em massa. 
  • A Terceira usou eletrônica e tecnologia da informação para automatizar a produção. 
  • Agora, a Quarta Revolução Industrial está se consolidando na Terceira – a revolução digital que ocorre desde meados do século passado. É caracterizada por uma fusão de tecnologias que está desfocando as linhas entre as esferas física, digital e biológica.

Fonte: https://www.weforum.org/agenda/2016/01/the-fourth-industrial-revolution-what-it-means-and-how-to-respond/

A forma como as pessoas estão conectadas por celulares, as novas gerações que surgem de clientes, de colaboradores que já nasceram num mundo digital e se comportam totalmente diferente, o poder de novas tecnologias como impressão 3D, nanotecnologia, IoT, IA, entre outros, tudo isso faz com que o mundo e os negócios se tornem muito mais complexos e dinâmicos, dentro do cenário VUCA, como é amplamente falado. 

Ou seja, as empresas precisam estar adaptadas a essa nova realidade! Como diz  Fernando De La Riva: “Estamos usando teorias de administração do século 19, com estruturas organizacionais e de incentivo do século 20, num ambiente de negócios do século 21. VUCA é o novo normal do ambiente de negócios”.

O que de fato não é a Transformação Digital?

Diante deste cenário de mercado, vamos entender primeiro o que não é Transformação Digital:

– Não é algo prescritivo que você compra e vêm em uma caixinha, bastando apenas instalar;

– Não é uma bala de prata;

– Não é apenas “colocar uma roupa ágil” e cometer erros básicos muito comuns;

– Definitivamente, não é digitalização de canais;

– Não é pagar treinamentos para a equipe, quando tem budget sobrando, para seguir uma tendência e evolução de mercado.

Mas, e o que é a tal Transformação Digital?

Transformação Digital é um processo de mudanças com o objetivo de ajudar as empresas a obterem mais resultados, a entregar mais valor constante, a trabalhar de uma forma mais responsiva, produzindo mais e mais aderente às necessidades atuais dos clientes e dos funcionários.

Nós, da Agile.Inc, entendemos por Transformação Digital como: 

Uma mudança fundamental na forma como a empresa se organiza, com uso de tecnologia, pessoas, processos e modelos de negócios, visando estar adaptado à um universo mais complexo e dinâmico, onde é fundamental ter foco na geração de valor ao cliente. Isso será decisivo na vida das empresas: quanto mais mindset digital a organização possuir, maior vantagem competitiva no mercado ela terá nesse novo mundo VUCA.

Esse conceito consiste em vários pontos, tais como:

– Mudar a forma com que as áreas de uma empresa se conectam ao trabalharem em conjunto, principalmente suportando as áreas de negócios;

– Realmente colocar o cliente no centro das tomadas de decisão;

– Ter mais transparência e dar visibilidade ao que está acontecendo para todos;

– Priorizar as entregas e se perguntar sempre “será que estamos fazendo a coisa certa?”;

– Integrar o mindset Ágil em uma base diária dentro dos times;

– Descentralizar decisões, mas com alto alinhamento;

O risco de não fazer direito é muito latente

Muitas dúvidas podem estar passando por sua mente agora, especialmente aquela sensação de não estar fazendo e nem se preparando para a transformação digital ainda. E isso é muito arriscado! Em recentes pesquisas, identificou-se que o risco de não fazer a Transformação Digital corretamente é a ameaça número 1 apontada por diretores, executivos e C-levels, em 2019. 

“As operações existentes e a infraestrutura de tecnologia legada representam um risco para as empresas que não conseguem se transformar com rapidez suficiente para competir com as que ‘nasceram digitais’”, revela um estudo realizado pela Iniciativa de Gerenciamento de Riscos da Universidade da Carolina do Norte e pela empresa de consultoria de gerenciamento Protiviti Inc.

Fonte: https://blogs.wsj.com/riskandcompliance/2018/12/05/businesses-predict-digital-transformation-to-be-biggest-risk-factors-in-2019/

Ou seja, caso a empresa não consiga fazer a correta Transformação Digital, ela vai perder espaço no mercado para as organizações que estão conseguindo fazer o processo da maneira adequada. Levando em conta que algumas empresas já nasceram digitais, já são customers centric e conquistaram a preferência de seus clientes; e possuem uma cultura forte e um mindset de inovação e melhoria contínua, desde a escolha dos funcionários, processos internos, até a postura de sua liderança.

Conclusão

Diante de todos esses fatos e explicações sobre um dos assuntos mais falados dos últimos tempos, você se sente preparado para fazer essa mudança fundamental na forma como sua organização trabalha? Como fazer essa transformação acontecer da melhor forma possível, de modo que a empresa possa sair na frente? Como não ficar para trás e ser obrigado a reagir de forma desesperada no futuro?

Essas são perguntas que muitos executivos possuem e para responder esses questionamentos que nós da Agile.Inc trabalhamos.

Tem alguma outra dúvida? Conte-nos aqui nos comentários!

LEIA TAMBÉM:

Evite erros comuns durante a Transformação Digital

Se você já está transformando sua empresa, entenda como a Agilidade pode estar atrapalhando esse processo

Top