Escolha uma Página

Transformação Digital: O que é, como aplicar e os seus maiores desafios!

  

A Transformação Digital é um conceito que surgiu no início dos anos 2000, com a popularização da Internet, dos computadores pessoais e do conceito de globalização dos anos 90.

Desde então, a presença da tecnologia no cotidiano das instituições mais diversas tem sido cada vez maior e mais dinâmica. Das casas de família às empresas multinacionais, essa ferramenta já faz parte das nossas vidas.

Mas o que isso significa para os processos manuais de trabalho? Realizar pagamentos com um cartão de plástico, ir a uma farmácia física para comprar remédios ou pedir empréstimos pessoalmente no seu banco? Tudo isso é passado.

Como esse processo generalizado de transformação digital tem afetado as organizações e como fazê-lo de forma eficiente na sua empresa?

O que é Transformação Digital?

Transformação Digital surgiu da demanda de empresas em resolverem problemas de forma mais rápidaeficaz e, de preferência, automatizada.

Para aplicá-la, é necessário o uso de tecnologias que se integrem à cultura e ao modelo de negócios da empresa, otimizando as funções antes desempenhadas de maneira tradicional.

Mais do que isso, a Transformação Digital é um modelo de negócio usado por organizações para se adequarem ao digital. No processo de implementação, a organização torna-se moldada pelo digital.

O uso de canais ou ferramentas digitais, isolado, não caracteriza transformação digital.

A transformação digital depende, além da gestão correta dos recursos organizacionais, de uma mudança cultural dentro da empresa. Essa gestão deve ser feita de forma que boa parte das habilidades técnicas sejam automatizadas. Isso permite que os funcionários possam focar seu desempenho em suas habilidades interpessoais e utilizar as tecnologias como ferramentas.

Os cinco domínios da Transformação Digital são: Clientes, Competição, Dados, Inovação e Valor.
Adquira redes de clientes com funis de venda reinventados, melhor jornada de compra e análise dos padrões de comportamento dessas redes. Construa plataformas, não apenas produtos, usando novos modelos de negócio, retirando intermediários e aumentando o valor competitivo dessas plataformas. Transforme dados em vantagens competitivas ao analisá-los para extrair valor e tomar decisões. Inove com experimentações rápidas, como protótiposMVPs e projeções de escalabilidade. Adapte suas propostas de valor com novos conceitos de mercado, novas trajetórias de saída de mercados em queda e etapas para avaliar a evolução do suporte.
Fonte: Brand Leadership

Exemplos de Transformação Digital

O perfil dos consumidores mudou de forma generalizada após a popularização dos smartphones e das mídias sociais; mídias essas que acabaram se tornando os principais veículos de relacionamento entre clientes e muitas marcas.

Hoje, não basta um serviço ou produto de qualidade: os clientes querem que a experiência seja a parte mais valiosa do que estão comprando e a ascensão da prática do UX Design é reflexo disso.

É importante entender que a transformação digital não se resume ao uso de ferramentas digitais. A organização se aproxima do cliente não através de ferramentas, mas sim da quebra de paradigmas, quebra que deve ser feita visando entregar o que o cliente precisa com mais agilidade.

Transformação digital é algo mais amplo do que usar canais digitais. Ela é sobre começar a tomar decisões com análise de dados. O digital é apenas uma ferramenta para impactar o cerne do negócio. Os dados são o insumo para a tomada de decisão.

Um exemplo é a mudança do processo de envase na linha de produção industrial. As máquinas de envase de garrafas de refrigerante podem passar a captar dados. Haverá registros de quantas garrafas de um litro, dois litros e três litros são envasadas por minuto, por hora e por dia. A análise posterior desses dados auxilia na otimização de custos e na mitigação de falhas na produção.

Alguns Setores que se Beneficiam com a Transformação Digital:

Com a difusão do acesso à internet, é difícil pensar em um setor que não se beneficiaria com a transformação digital. A maioria dos serviços e produtos possui ao menos uma parte do seu processo de venda que pode ser otimizada por um ambiente de cultura fortemente digital.

Tendo isso em vista, sempre há os setores que se beneficiam mais do que outros, e são eles:

  • Financeiro e Bancário;
  • Saúde;
  • Telecomunicações;
  • Varejista;
  • Educacional;
  • e Recursos humanos.
Imagem: Prova Fácil na Web

Transformação Digital no Setor Financeiro

Aqui, vamos olhar o setor financeiro separado dos bancos tradicionais. O motivo dessa abordagem é a ascensão das Fintechs, empresas de pagamento, consultorias de investimento e outras organizações que lidam com finanças mas operam como bancos.

A Importância da Análise de Dados

Os bancos lidavam com um volume grande de dados. Esses dados eram subutilizados pois estavam atrelados apenas a transações. A análise de dados começou a ser feita como parte da transformação digital ao perceberem a ascensão do conceito de Business Inteligence.

Essa análise ajudou na tomada de decisões mais eficazes, baseadas nos dados demográficos dos clientes e em seus padrões de comportamento.

Esses padrões são utilizados para mitigar riscos e detectar possíveis fraudes. Ainda, podem ser empregados na personalização da experiência do cliente.

Tanto em bancos quanto em outras instituições financeiras, ou ainda em outros setores, o embasamento em dados para tomar decisões tem sido fundamental. Calcular melhor os riscos na hora de conceder um empréstimo é um exemplo dessas decisões.

Transformação Digital nos Bancos

O setor bancário já tem se digitalizado há algum tempo. Os bancos foram os primeiros a utilizar canais digitais, na década de 90. Nesse quesito, esse setor sempre esteve à frente do mercado.

Já na remodelagem de negócios para adequar-se à cultura organizacional digital, o atraso nesse setor é igual ao observado em outros setores.

A implementação de caixas eletrônicos nas agências e, depois, o desenvolvimento de aplicativos para internet banking tiraram uma boa carga de atendimento dos funcionários ao digitalizar processos mais simples como saques, transferências e depósitos, mas devido a complexidade de serviços como empréstimos e investimentos, e à preocupação com a segurança, a transformação digital nos bancos só começou recentemente.

Com o surgimento das Fintechs, baseadas em contas exclusivamente digitais e atendimento personalizado para cada cliente, como a Nubank, os bancos tradicionais tiveram de investir ainda mais em inovação. Os grandes bancos tradicionais estão tendo que rever seus valores e suas jornadas de compra.

Isso implica não apenas na aceleração do processo de digitalização dos serviços e produtos, mas também na remodelagem de negócios. É daí que surge a verdadeira Transformação Digital.

Experiência do Usuário voltada à Autonomia

É imprescindível pensar na transformação digital com foco na liberdade e individualidade dos clientes. Hoje, eles priorizam o acesso às suas finanças, de qualquer lugar e a qualquer hora.

Essa tendência surgiu pois os usuários, especialmente os jovens de idades entre 18 e 25 anos, estão mais orientados ao digital e buscam a comodidade, rapidez e facilidade proporcionadas pelos aplicativos mobile como seu meio principal de acesso ao internet banking.

Um passo fundamental para bancos que adotam a transformação é a aquisição de clientes mais jovens que já são familiarizados com ambientes virtuais.

Outro fator comportamental notável é que quanto mais jovem o cliente, menor a importância dada por ele a marcas renomadas e hábitos já estabelecidos. Por isso a necessidade de maior investimento em inovação.

O processo de autoatendimento traz autonomia aos clientes e maior liberdade na tomada de decisões, autonomia que ajuda os funcionários das agências tradicionais a focarem em processos mais demorados e complexos, processos que podem ser otimizados por conjuntos de conhecimentos exclusivos de cada colaborador, atribuindo aos bancos tradicionais um papel mais consultivo.

A redução do número de agências físicas implica na economia de uma renda que, idealmente, deve ser canalizada para a transformação digital. Iniciativas que reforcem a cultura digital dentro dos grandes bancos irão salvá-los da obsolescência.

Sistemas Legados

A maior dificuldade da transformação digital nos bancos é a complexidade e magnitude de seus sistemas legados, que estão rodando há muitos anos de forma satisfatória.

A ideia de ter gastos com a reformulação desses sistemas pode parecer pouco atraente para os líderes da organização. Entretanto, é importante frisar que o investimento em tecnologias mais novas e ágeis gera otimização em todas as operações da empresa.

Se isso for feito tendo o usuário como foco (sendo usuários tanto os clientes quanto os colaboradores), a fidelização e satisfação serão ambas otimizadas. O objetivo é melhorar cada vez mais a experiência dos humanos, tanto clientes quanto colaboradores envolvidos nas transações.

Alguns exemplos desse tipo de tecnologia podem ser vistos no funcionamento das Fintechs, que detalharemos a seguir.

As Fintechs

O Banco Central do Brasil instituiu em 2011 a possibilidade de contas exclusivamente digitais. Isso reduziu o custo das agências físicas e facilitou a conquista de clientes mais jovens, que antes não eram o foco do setor bancário.

As fintechs são empresas que usam a tecnologia para tornar os serviços financeiros mais eficientes. Por causa delas é que este artigo divide o setor financeiro em duas partes: bancos e instituições de pagamento.

É comum que as fintechs sejam instituições de pagamento, e não bancos, entretanto, temos no Brasil um exemplo de fintech que se enquadra em ambas atuações: o Inter.

Algumas dessas empresas desafiam os bancos tradicionais são conhecidas como challenger banks (bancos digitais com licenças que os permitem operar com dinheiro físico) ou neobanks (bancos digitais 100% digitais).

No Brasil, a fintech mais conhecida é a Nubank, criada em 2013. Segundo um estudo da consultoria EY (Ernst & Young), empresas como a Nubank e o Inter são utilizadas por 40% dos clientes digitais no Brasil.

O grande diferencial entre os bancos tradicionais e as fintechs é justamente o foco em consumidores mais jovens. Estes eram ignorados pelos bancos até pouco tempo atrás, enquanto as fintechs já nasceram com foco neles.

Essa negligência por parte dos bancos se deve ao risco de crédito e pelas baixas margens desses clientes, já que a maioria deles está se profissionalizando agora. Isso gerou uma imagem negativa dos jovens para os bancos tradicionais, e vice versa.

Exemplos de Serviços Financeiros Digitais

Na China, os serviços AliPay e WeChat representam 92% dos pagamentos do país. No Quênia, existe a conta mobile M-Pesa, que é focada em quem nunca usou bancos tradicionais.

Na Índia, o WhatsApp já implementou seu serviço de pagamentos. A previsão para o lançamento mundial desse serviço é 2020.

Outros exemplos de ferramentas para pagamentos digitais desvinculadas de um banco ou fintech específico são o PicPay, o PayPal e o PagSeguro.

As tecnologias implementadas nesses serviços são diversas. As mais comuns são o atendimento ao cliente feito por chatbots e o pagamento por aproximação (chamado NFC ou contactless) ou por QR Code.

O foco da Transformação Digital acaba sendo não apenas em otimizar processos com auxílio de canais digitais, mas também em otimizar os recursos humanos ao criar uma cultura fortemente digital dentro da organização. – Imagem: Trello

Transformação Digital na Área da Saúde

análise de dados com Big Data é aplicável a todos os setores que queiram passar pela transformação digital. Ela permite traçar padrões de usuários de um serviço e também seus padrões de comportamento. A rota para isso é avaliar os dados para encontrar características comuns entre pacientes.

Essa análise é fundamental para a otimização de processos, por isso, a transformação digital na área da saúde traz muitos benefícios como:

  • maior agilidade no atendimento médico,
  • maior precisão nas análises e prescrições de medicamentos,
  • maior segurança para o profissional da saúde pois as chances de erros por falta de informações serão menores,
  • diagnóstico precoce de doenças, com base nos padrões de comportamentos e de perfis,
  • monitoramento de um paciente à distância,
  • aumento da precisão de procedimentos.

Essa transformação já começou em alguns dos grandes hospitais do Brasil. O Sírio Libanês, por exemplo, usa robôs para simular procedimentos cirúrgicos e para auxiliar durante esses procedimentos. O Hospital do Coração, utiliza tecnologia de ponta no tratamento Gamma Knife, também conhecido como radiocirurgia estereotáxica, um método não invasivo utilizado para tratar lesões nos órgãos, cabeça e pescoço.

Além disso, os canais digitais podem ser atualizados e utilizados para melhor gestão de todos os processos hospitalares. O acesso remoto e a integração de informações otimizam essa gestão.

Transformação Digital nas Telecomunicações

transformação digital no setor de telecomunicações assemelha-se à dos bancos em alguns aspectos. Por exemplo, na quantidade de sistemas legados, na rapidez em digitalizar mas lentidão em transformar digitalmente, e na demanda dos clientes em terem uma experiência mais eficiente e sem intermediários.

Como citado anteriormente, a análise de dados persiste na sua importância.

Outra tendência que persiste em todos os setores mas que talvez não tenha ficado clara anteriormente é o Omnichannel. As mídias sociais e a experiência mobile tornaram comum que o usuário espere poder começar um processo em um canal digital e terminar em outro.

Transformação Digital no Varejo

No varejo, a disseminação de e-commerces web e mobile para lojas físicas, bem como contas em mídias sociais de brechós e lojas exclusivamente virtuais, aliados ao marketing digital, facilitaram a compra e venda de produtos antes restringidos aos grandes centros comerciais físicos.

As demandas de mercado hoje não dependem mais apenas de intuição. Coletar dados sobre os clientes e suas preferências é crucial para alimentar as estratégias de marketing e vendas e personalizar a experiência de compra com a oferta de promoções específicas e a sugestão de produtos similares.

Há alguns fatores que contribuem no retorno de clientes e recomendação orgânica para clientes novos. Ter as vontades percebidas pelas marcas é um exemplo. Ter essas mesmas vontades levadas em conta no atendimento e na resolução de problemas apontados pelo consumidor final também.

Uma nova dinâmica de venda observada nos varejos é a compra online com retirada em loja física sem cobrança de frete. Essa retirada em loja física facilita a entrega tanto para o cliente quanto para a loja.

Um desafio na transformação digital é a comunicação interna com os vendedores. A digitalização do processo de compra é positiva não só para quem compra, mas também para os funcionários e para a empresa. Ela possibilita que, através do sistema interno, os vendedores possam fechar pedidos feitos em loja física de produtos que não estão disponíveis no estoque daquela unidade. Isso faz com que ainda recebam comissão e evitem que o cliente prefira procurar pelo produto em lojas concorrentes. Varejos que querem utilizar dessa nova estratégia de venda precisam trabalhar sua cultura interna para que os colaboradores entendam as vantagens e auxiliem no processo de transformação digital.

Transformação Digital na Educação

Nas instituições de ensino, há formas de facilitar a aprendizagem dos alunos com a transformação digital.

Os laboratórios de informática e a disponibilização online de material para estudo são algumas dessas formas. Especialmente para aqueles estudantes que possuem menos recursos disponíveis em suas casas.

Entretanto, é importante que a implementação da educação seja feita corretamente. Disponibilizar livros e lições tradicionais não basta; isso é apenas o uso de canais digitais.

A verdadeira transformação digital se trata de articular os canais digitais dinamicamente e tirar proveito da inteligência de dados fornecida pelos alunos para definir as ações a serem tomadas dentro do plano de ensino.

E consequentemente oferecer flexibilidade aos alunos, o que implica na autonomia e estimula o comportamento autodidata.

Transformação Digital nos Recursos Humanos

No RH, alguns processos automatizados ou digitalizados pela transformação digital são:

  • o uso de inteligência artificial no recrutamento e seleção;
  • contato com candidatos pelas mídias sociais ou por videochamada;
  • automação operacional (ponto e banco de horas, geração de folha de pagamento, férias…);
  • calcular taxas de rotatividade e produtividade de funcionários;
  • flexibilização da jornada e local de trabalho devido a meios remotos de comunicação e gestão;
  • análise e cruzamento de dados comportamentais.

Por que a transformação digital falha em tantas empresas?

Silos organizacionais

Um desafio enfrentado por muitas empresas durante a transformação digital é a falta de foco, ou ainda o excesso dele.

Uma transformação digital eficiente não se resume à TI, à experiência do cliente ou à digitalização de arquivos. Empresas que obtêm sucesso nessa jornada são aquelas que integram todos os seus setores de forma a revolucionar a cultura organizacional.

Essa revolução deve ser feita com o combate aos silos, com a revisão e possível mudança do modelo de negócios, e com a aquisição, retenção e evolução de talentos.

Profissionais ligados a tecnologia têm valorizado cada vez mais suas relações interpessoais com seus líderes e colegas de equipe e a experiência pessoal e profissional que podem adquirir com essas relações.

Isso exige que as empresas se preparem para receber melhor esses novos funcionários. Essa preparação inclui planos de carreira definidos de forma previsível mas flexível o suficiente para que predisposições e vocações individuais sejam valorizadas.

Isso só é possível com a integração de todos os setores, onde todos os colaboradores conhecem e entendem todas as operações organizacionais o suficiente para se sentirem parte do todo. Focar apenas na implementação de processos digitais ou apenas no setor de TI é tão equivocado quanto não ter uma estratégia de TI traçada para o futuro.

Sistemas legados e transição para Sistemas Integrados

Tratar a transformação digital como um evento é equívoco cometido pela maioria das empresas, ela é uma jornada na qual é necessário avaliar continuamente a maturidade digital da empresa e a necessidade de manutenção de sistemas legados,

Como citado anteriormente no tópico sobre transformação digital no setor bancário, em muitos casos, levando-se em conta os custos envolvidos, a melhor rota de ação é refatorar os sistemas legados e atualizá-los, ou até mesmo descartá-los por completo.

Isso deve ser feito para criar uma rede de sistemas integrados na organização. Visando melhor desempenho desses sistemas como ferramentas, consequentemente, haverá melhor desempenho comercial.

Expectativa e Realidade na transformação digital

Outro erro recorrente é a falta de alinhamento de expectativas com as realidades atual e projetada da empresa. É imprescindível que haja transparência durante toda a transformação digital. Isso evitará frustrações dos colaboradores e buracos de orçamento ao longo das etapas de mudança organizacional.

Os componentes de uma plataforma digital de negócios são: Clientes, Ecossistemas, Inteligência, Coisas, e Sistemas de TI.
A Inteligência é o centro de tudo. Os Clientes e as Coisas se relacionam pela Análise de Dados.
Cada componente possui sua própria plataforma: plataforma de Experiência do Cliente (CX), de Ecossistemas, de Internet das Coisas (IoT), e de Sistemas de Informação. Cada plataforma serve a um stakeholder: a plataforma de CX serve aos Clientes, a de Ecossistemas serve aos Parceiros, a de IoT serve às Coisas, e a de Sistemas de Informação serve aos Funcionários.
Fonte: Gartner

Como mudar a cultura da sua organização para que a transformação digital prospere?

Mudar a cultura de uma empresa pode ser uma tarefa difícil. Os líderes responsáveis por pesquisa e implementação de inovações (CIO’sCTO’sGerentes e Coordenadores em geral), precisam mostrar os meios disponíveis e para que fins essas mudanças se fazem necessárias. Entretanto, qualquer alteração na cultura organizacional depende tanto dos gestores quanto dos funcionários, com diálogo constante e possibilidades de crescimento visíveis para todos.

Revisão de processos e do modelo de negócios

Para que haja apoio da equipe nessa caminhada para uma nova cultura, avaliar operações já enraizadas no cotidiano organizacional pode revelar meios inovadores de aumentar eficiência e diminuir gastos.

É importante que todos estejam cientes da importância e urgência da transformação digital. Para isso, ter acesso a cursos que os eduquem a ser mais técnicos e possam entender ao menos o básico de cada operação nessa transformação pode ser benéfico. Essa educação geraria naturalmente uma cultura voltada ao digital e à cooperação entre setores.

Canalizar a otimização de custos para a aquisição desses cursos é uma forma de estimular o surgimento de novos interesses e novos talentos entre os colaboradores.

Investimento em talentos

É importante que a adesão às medidas educacionais tomadas nessa reforma cultural sejam incentivadas pelos líderes de cada setor. A finalidade disso é abrir espaço para que novos perfis de liderança se formem dentro das equipes.

Mapear de forma transparente os custos, riscos e expectativas de resultados da transformação digital dentro do contexto da empresa facilita a caminhada na otimização de custos e aproveitamento de talentos. Assim, há a garantia de que essa nova visão de negócios tenha longevidade.

Uma das tecnologias que podem impulsionar a Transformação Digital é a computação em nuvem. – Imagem: OnlineSites.com

Tecnologias que impulsionam a transformação digital

Tecnologias básicas

Quando se fala em transformação digital, é comum pensar nela como algo intimamente ligado a tecnologias disruptivas, mas isso não é necessariamente verdade.

Antes de pensar em aplicar BlockchainInteligência Artificial ou Internet das Coisas à transformação digital de uma organização, é preciso analisar o modelo de negócios e a cultura organizacional com cuidado, começando pelas tecnologias básicas. Pergunte a si mesmo: de que forma posso otimizar o banco de dados e a inteligência de negócios da minha empresa para aumentar o lucro com a venda de produto X ou Y?

Essas alterações de base ocorrerão naturalmente e de forma concomitante à inovação da cultura organizacional. É importante frisar mais uma vez que a transformação digital é um processo contínuo e exponencial, o que implica em algumas relações de causalidade: melhorar a comunicação interna também melhora a integração entre setores e a experiência dos funcionários, o que resulta em melhoria na qualidade dos serviços e a experiência dos clientes.

Algumas das tecnologias que facilitam a transformação digital são: automação, dispositivos móveis, computação em nuvem, análise de dados, Big Data, Business Intelligence (BI), CRM, mídias sociais e Internet das Coisas (IoT) – Fonte: Neosoft Technologies

Tecnologias disruptivas

Dito isso, após analisar as tecnologias mais simples já implementadas na empresa e melhorá-las ao máximo, o próximo passo é pensar em alternativas mais sofisticadas para resolver problemas:

  • Computação em Nuvem para não precisar se preocupar com servidores;
  • Inteligência Artificial para automatizar partes do atendimento ao cliente,
  • Big Data para auxiliar na tomada mais precisa de decisões…

Ainda aliadas a essas tecnologias, temos as Metodologias Ágeis como o Scrum. A implementação dele pode ser muito benéfica ao processo de transformação digital ao melhorar a eficiência e rapidez das entregas. As possibilidades são muitas, e cabe à gerência escolher o que melhor encaixa ao contexto da empresa.

Saiba Mais sobre Transformação Digital

Caso você queira se aprofundar, os vídeos a seguir são boas fontes de aprendizagem sobre o tema:

Cases de sucesso da Transformação Digital

Netflix

Um exemplo clássico de um case que demonstra o sucesso da transformação digital é a Netflix.

No início dos anos 2000, a Netflix estava no ramo de locação de filmes. Ao contrário da concorrente Blockbuster, a Netflix soube como e quando fazer a transição para o digital.

Magazine Luiza

A Magazine Luiza se consolidou como uma rede de lojas físicas de varejo distribuídas pelo Brasil inteiro antes de começar seu processo de transformação digital em 2017.

Os resultados foram expressivos: um crescimento de quase 600% em relação ao segundo trimestre de 2016.

Hoje, 2 anos depois, a Magazine Luiza é um dos maiores marketplaces do país.

GE Healthcare

Como citado anteriormente, o Scrum também pode ser considerado um agente na transformação digital. Na GE Healthcare, os ganhos de produtividade após a implementação do Scrum foram alcançados em um ritmo sustentável.

Devido ao ambiente de trabalho de alta qualidade fornecido pelo Scrum para os desenvolvedores, conseguiram aumentar a retenção de funcionários e a qualidade de contratação atraindo os melhores profissionais do setor.

IDX Systems (agora GE Healthcare) contratou Jeff Sutherland como vice-presidente sênior de engenharia e desenvolvimento de produtos para estender o Scrum ao desenvolvimento em larga escala.

Essa foi a primeira abordagem na IDX para organizar todo o grupo de desenvolvimento em um conjunto interligado de Scrums.

Foi uma abordagem de base de equipe, incluindo dois vice-presidentes, um arquiteto sênior e vários diretores. O problema em garantir a qualidade do processo em cada equipe foi que toda a organização teve que aprender Scrum de uma só vez.

O IDX Web Framework foi implementado pela primeira vez em 1997. Em 2007, ele foi selecionado como a principal tecnologia web para os sistemas da GE Healthcare.

O IDX alcançou ganhos produtivos médios de 240%. No início, o orçamento da organização de desenvolvimento do IDX era de quase US $ 50 milhões por ano e essas equipes eram cerca de 10% da organização.

Com o Scrum, as equipes alcançaram um aumento médio de produtividade de 666%. O ganho líquido de produtividade de todas as equipes combinadas foi de 240%.

(As informações sobre esse case foram retiradas em tradução livre do site ScrumCaseStudies.com.)

Cathay Pacific Airways

A Cathay Pacific Group, com sede em Hong Kong, oferece transporte de passageiros e de cargas para mais de 200 destinos na Ásia, América do Norte, Austrália, Europa e África, utilizando uma frota de cerca de 200 aeronaves.

Em 2015, a Cathay Pacific tinha um grande projeto em mãos: desenvolver um novo mecanismo de reservas na Internet (Internet Booking Engine – IBE). Eles precisavam de uma estrutura que os ajudasse a entregar dentro de um prazo específico.

Em fevereiro de 2017, a Cathay Pacific adotou o framework Nexus desenvolvido pela Scrum.org e pelo co-criador do Scrum, Ken Schwaber.

Eles começaram a implementar o Scrum como sua principal estrutura para entrega de software. O projeto IBE foi seu primeiro projeto ágil envolvendo várias equipes Scrum trabalhando no mesmo produto.

Como parte do projeto, a Cathay Pacific diminuiu sua equipe de 40 para 29 pessoas. O objetivo dessa diminuição era de simplificar seus processos e poder trabalhar em menos tempo e sem sobrecarga extra.

Dentro de dois meses após a implementação do Nexus para o projeto IBE, os times Scrum aumentaram a frequência de quando eram capazes de liberar incrementos integrados em 200%. De um lançamento a cada três meses, para pelo menos uma vez por mês e até duas a três vezes por mês, com melhoria na qualidade também.

Outro ponto positivo do Nexus Scrum foi o aumento do engajamento do Product Owner. Antes, ele não tinha visibilidade adequada e, portanto, não compreendia totalmente o progresso no desenvolvimento dos entregáveis.

Agora, o Product Owner consegue entender e expressar o que está realizando e entregando em termos de valor.

Outro Exemplo de Transformação Digital na Aviação

Outro case de sucesso da transformação digital no setor de aviação ocorreu em 2012, em uma outra empresa asiática de aviação comercial.

A liderança sênior dessa empresa emitiu uma ordem para aumento de agilidade a fim de tornar a organização mais adaptável e capaz de reagir mais rapidamente a mudanças.

Para conseguir isso, uma equipe de desenvolvedores de TI focada em aplicativos móveis adotou o Scrum. Pouco tempo depois, mais equipes Scrum se formaram para aplicações web e mobile.

Em janeiro de 2015, quatro equipes Scrum se formaram para trabalhar no aplicativo de fidelidade de celular dessa companhia aérea. Cada equipe desse esquema focava em uma parte diferente do aplicativo móvel: front endback enddesign e teste da experiência do usuário, incluindo um Product Owner.

As equipes de desenvolvimento puderam extrair o feedback do usuário da seção de pesquisa e incorporá-lo ao aplicativo.

Assim, liberaram novos recursos em apenas duas semanas. Isso gerou retorno de valor aos clientes e aos negócios em geral. Agora, as equipes Scrum produzem um incremento integrado a cada duas ou quatro semanas. Isso é 30% mais rápido do que antes. O objetivo é entregar de forma mais consistente a cada duas semanas.

(As informações sobre esses dois cases foram retiradas em tradução livre dos sites Scrum.org e ScrumCaseStudies.com, respectivamente).

Transformação Digital é sobre otimizar tecnologias e utilizá-las para uma boa gestão de documentos e recursos dentro da empresa. – Imagem: Accenda Digital

FBI Sentinel Project

O Virtual Case File (ou VCF) foi um aplicativo desenvolvido pelo Federal Bureau of Investigation (FBI) dos Estados Unidos entre 2000 e 2005. O projeto não estava nem perto de ser concluído quando foi oficialmente abandonado em janeiro de 2005. Esse abandono acabou sendo um fiasco para o FBI.

Além de desperdiçar pelo menos US$ 100 milhões, o fracasso manchou a imagem da agência e de seu diretor, Robert S. Mueller III.

US$ 575 milhões de dólares desperdiçados nas duas primeiras tentativas do projeto.

O Scrum Studio foi criado no porão do Hoover Building e a equipe reduziu de 400 pessoas para 40. Ao retomar o projeto, em 1 ano e com US$ 30 milhões, o código do projeto estava completo, com uma redução de custos de mais de 90%.

(As informações sobre esse case foram retiradas em tradução livre do site ScrumCaseStudies.com).

Cateno

Aqui na Zappts nós também temos alguns cases de nossos clientes.

Cateno é uma joint venture criada pelo Banco do Brasil e pela Cielo para atuar na gestão de meios de pagamento.

Em parceria com a Zappts, a Cateno alcançou resultados de performance, de agilidade e qualidade. Reduzimos para 3 dias um processo que antes demorava de 30 a 40 dias para os usuários finais.

Desenvolvemos uma conta digital em 90 dias para clientes reais utilizarem. Com o uso, validamos hipóteses no processo de escalabilidade da solução para o mercado.

GIGA

Outro case de sucesso aqui na Zappts é a GIGA. Seu aplicativo de segurança, o Giga Monitor, teve ganhos relevantes no estudo e implementação de interfaces com base nas necessidades dos usuários finais.

Além disso, houve 67% de ganho na performance para ativação de câmeras de segurança, o que gerou uma melhora de 121,5% das avaliações na App Store e na Play Store:

Simplificando, os cinco passos para a transformação digital são: elaborar novas experiências e modelos de negócio; desenvolver uma cultura de DNA digital; aplicar novas tecnologias à infraestrutura existente; tomar decisões baseadas em dados e não em intuição; e cocriar e coinovar com novos parceiros. – Fonte: Constellation Research

Quero Implementar a Transformação Digital na minha Empresa, e Agora?

Neste artigo deixamos claro que a transformação digital é realidade e é URGENTE!

Mas iniciar esse processo sem um guia pode ser mais trabalhoso do que o necessário, mas você pode contar com um especialista no assunto, como a Zappts, que tal? Temos squads de desenvolvimento dedicados para cada projeto. O intuito dessa divisão dedicada é entregar soluções com agilidade e eficácia para nossos clientes.

Este artigo está em constante atualização. Por favor, deixe as suas sugestões, dúvidas ou críticas nos comentários!

Scrum: entenda de uma vez por todas o que é, como ele aumenta expressivamente os seus resultados e porquê utilizá-lo

  

O Scrum é um framework para desenvolver e manter produtos complexos. A metodologia foi definida no guia escrito pelos seus criadores, Ken Schwaber e Jeff Sutherland, e intitulado Guia Do Scrum.

Dentro desse framework, pessoas podem tratar resolver problemas igualmente complexos adaptativos, enquanto produtiva e criativamente entregam produtos da melhor forma e com o mais alto valor possível. O instrumento para isso é o desempenho de papéis, eventos e artefatos unidos e integrados por regras específicas.

O Scrum está sendo usado desde o início de 1990 e continua relevante até hoje. Isso acontece pois ele foi idealizado para ser inerentemente leve e simples de entender, porém extremamente difícil de dominar, como um jogo de pôquer.

Para explicar isso de forma aprofundada, é necessário entender o paradigma inicial da indústria de desenvolvimento e o como e porquê ele foi modificado. Começaremos conhecendo um pouco mais sobre as metodologias de desenvolvimento.

As Metodologias de Desenvolvimento

A Metodologia Tradicional

No início da indústria de desenvolvimento de software, a metodologia utilizada para gestão de projetos consolidou-se em fases bem definidas. Eram elas:

  • levantamento de requisitos,
  • análise de requisitos para esboço da arquitetura,
  • implementação via código/programação,
  • testes,
  • lançamento do produto,
  • e suporte/manutenção.

Essa metodologia foi posteriormente denominada Cascata (ou Waterfall), pois cada fase é executada hierarquicamente, uma após a outra. Uma fase só começa quando a anterior termina.

A Cascata é planejada em reunião com o cliente. A forma como isso é feito não admite mudanças, pois tudo é estabelecido logo no começo do processo. Todos os requisitos, escopos de produto e de projeto e, consequentemente, planejamento de custos são fixos. Não há análise de riscos ou maior participação do cliente até a entrega do produto finalizado.

Por ser um processo tão baseado em fases, ele acaba sendo demorado e engessado. Essa demora impede que os clientes tenham o desenvolvimento de entregáveis na velocidade que necessitam.

A longo prazo, isso gera sistemas já lançados em tecnologias ultrapassadas ou com carência de funcionalidades específicas para a resolução do problema proposto inicialmente, que pode ter mudado durante o desenvolvimento do sistema.

Além disso, cada profissional do time fica responsável por uma parte do projeto e não se comunica com frequência, sem muita consideração pelas “skills” de cada um. Para neutralizar esses problemas e diminuir a burocracia envolvida, surgiram as metodologias ágeis.

As Metodologias Ágeis

Nas metodologias ágeis (muitas vezes encurtadas para Ágil ou Agile), o time discute e elabora em conjunto a entrega do produto final.

Há distribuição de tarefas conforme o conhecimento técnico e o desempenho de cada integrante. Isso garante a viabilidade do planejamento ao levar em conta as peculiaridades dos indivíduos envolvidos.

A implementação de projetos é feita de forma cíclica e iterativa. Um projeto é composto por vários ciclos. Sempre é considerada sua efetividade na resolução dos problemas e dores propostos pelo cliente. Muitas vezes ele passa por adaptações ao final de cada ciclo de acordo com as demandas que acabam surgindo.

Isso significa que os métodos ágeis são flexíveis e proporcionam entregas constantes para o cliente, sempre levando em conta seu feedback. Contraste ao método tradicional de desenvolvimento de software.

A sinergia da equipe de desenvolvimento é imprescindível para que a Agilidade funcione. Essa sinergia, nesse caso, não é restrita apenas à equipe. Ela deve se estender a todos os indivíduos e setores envolvidos no projeto, para que o time de desenvolvimento possa manter seu foco e performance altos.

Ao identificar falhas de gestão ou de comunicação, a equipe deve utilizar de todos os agentes disponíveis na organização para neutralizá-las. Sendo, assim, autossuficiente no seu gerenciamento de riscos, processos e resultados.

Exemplos e Características de Metodologias Ágeis

O conceito de metodologia ágil foi baseado no Lean Manufacturing. O Lean é um modelo de manufatura utilizado pela Toyota após a Segunda Guerra Mundial. Mas ele só foi formalizado em 2001, pelo Manifesto Ágil.

Semelhanças comuns a todas as Metodologias Ágeis

Algumas das metodologias ágeis mais utilizadas nas empresas atualmente são o Scrum e o Kanban. O que elas têm em comum, além da Agilidade, é um conjunto de práticas baseadas em certos valores, discriminados no Manifesto Ágil como:

  • Priorizar indivíduos e interações mais do que processos e ferramentas. Todas as pessoas envolvidas no processo devem trabalhar em conjunto e diariamente, comunicando-se de forma constante e aberta. Todos devem buscar sempre manter um ambiente de trabalho sustentável que propicie suporte, motivação e confiança.
  • Valorizar o bom funcionamento do software mais do que a documentação abrangente. Software funcional feito de forma rápida e com qualidade é a medida primária de progresso.
  • Colaborar com o cliente mais do que negociar contratos.
  • Responder a mudanças mais do que seguir um plano. Avaliar o progresso do projeto a cada ciclo e aceitar mudanças de requisitos mesmo no fim do desenvolvimento. Assim o cliente pode tirar vantagens competitivas.
  • Maximizar a quantidade de trabalho que não precisou ser feito ao primar por excelência técnica dos membros do time e por design e usabilidade simples e intuitivos.
  • Construir, pela convivência diária, times auto-organizáveis. Os membros do time refletem sobre maneiras de aumentar sua produtividade e efetividade com base nos resultados de cada ciclo. Assim, ajustam seu comportamento a fim de otimizar sua sinergia e aumentar sua frequência de entregas.

Diferenças entre Scrum e Kanban

Já o que as diferencia é:

  • Scrum é sobre autogestão e sobre como os desenvolvedores interagem e o que fazem quando não estão escrevendo código.
  • Kanban é sobre evitar desperdício de recursos e otimizar a produção. Isso acontece ao limitar a carga de trabalho de cada desenvolvedor. É criada uma visualização do fluxo de recursos na linha de produção com post-its em um quadro.

O Kanban é contínuo e o Scrum é iterativo. O Scrum tem ciclos fechados com objetivos definidos que se repetem, enquanto o Kanban é mais adequado para times que possuem trabalho não planejado à vista. Por exemplo, problemas de suporte e funcionalidades requisitadas emergencialmente – pois não possui ciclos.

Agora, após esse conteúdo introdutório, vamos abordar o Scrum. Definiremos o que ele é, mostrando de onde ele veio, e destrinchando todos os seus papéis, eventos, artefatos e regras.

E então, o que é o Scrum?

Origem do termo Scrum

O nome veio do rugby, no esporte, há um movimento chamado Scrum. Ocorre quando os jogadores dos dois times formam um círculo ao redor da bola, encostando suas cabeças e medindo forças para pegá-la.

O Scrum é considerado uma demonstração da força e união da equipe para atingirem seu objetivo.

É por isso que a metodologia ágil abordada aqui adotou esse mesmo nome.

Diferença entre Scrum e Agile

É comum ter a impressão de que esses termos são iguais. Entretanto, Agile é um conjunto de métodos e práticas baseadas nos valores expressos no Manifesto Ágil.

Já o Scrum não é um processo ou uma técnica para construir produtos. Ele é uma estrutura metodológica (ou framework) incremental que é usada para implementar o desenvolvimento Ágil. Você pode empregar vários processos ou técnicas para isso.

O Scrum deixa clara a eficácia das práticas de gerenciamento e desenvolvimento de produtos das empresas em que é implementado, de modo que elas possam melhorar essas práticas.

O framework consiste nos times Scrum associados a papéis, desempenhados por membros da equipe durante eventos, com auxílio de artefatos.

Como descrito no Guia Do Scrum, cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. As regras integram os eventos, papéis e artefatos, administrando as relações e interações entre eles.

De onde o Scrum surgiu?

O criador do Scrum

Jeff Sutherland trabalhou como militar no exército dos Estados Unidos durante 11 anos. Após esse período, ele decidiu estudar Medicina na Universidade do Colorado. Ele acabou se envolvendo com coleta de dados e desenvolvimento de sistemas.

Durante os anos 90, Sutherland enxergou um problema recorrente na sua nova área de interesse. Empresas que demandavam projetos de software com um cronograma apertado e orçamento incompatível. Ele decidiu encontrar uma solução para esse problema.

O grande diferencial do Scrum

Pesquisando, Sutherland acabou chegando ao Lean Manufacturing utilizado na Toyota e em outras empresas japonesas. Com auxílio de Ken Schwaber, criou a metodologia Scrum com base nesse sistema de manufatura.

Depois de provada a eficácia do Scrum por uma série de sucessos, essa nova metodologia popularizou-se rapidamente na indústria de desenvolvimento de produtos.

O Scrum representa a troca da visão algorítmica de projetos para uma visão heurística. As pessoas e a autogestão são a chave para resolver problemas. Eles são priorizados em tarefas individuais e delegados aos membros da equipe mais bem preparados para cada uma delas.

Imagem: Método Ágil

A Equipe Scrum

Times (ou Equipes) Scrum são auto-organizáveis e multifuncionais. Ser auto-organizável significa que os membros é que escolhem a melhor forma de realizar seu trabalho, ao invés de serem dirigidos por pessoas fora da equipe. Ser multifuncional significa que uma equipe tem nela todas as competências necessárias para realizar o trabalho sem depender de agentes externos.

O modelo de equipe do Scrum foi pensado para otimizar a flexibilidade, a criatividade e a produtividade. Geralmente um time possui de três a dez membros. Quando dez pessoas não dão conta do trabalho, o time é dividido em dois. Novos membros são adicionados a cada nova equipe, junto com os membros originais.

Dependendo do tamanho do projeto e da quantidade de times, é aconselhado aplicar o Scrum of Scrums, que abordaremos mais adiante. Os membros do time desempenham papéis específicos.

Product Owner: O Dono do Produto

O papel desta pessoa é representar os interesses do usuário final, sendo a ponte entre o time técnico – representado pelo Scrum Master – e os demais stakeholders. O PO estará sempre balanceando as demandas dessas duas partes.

Esse membro tem autoridade para dizer o que vai fazer parte do produto final ou não. Normalmente ele é um usuário chave do sistema, ou um usuário com boa compreensão dos requisitos e do que ele e outros usuários precisam.

O Product Owner precisa saber Programar?

Ele pode tanto ser alguém com background técnico (alguém que já foi um desenvolvedor front end ou um UX designer, por exemplo) como pode não ser (um analista de negócios, o CEO da empresa ou o próprio cliente).

Apesar de ser listado como parte da equipe Scrum, o Product Owner não é um elemento integrante dela.

Sua presença e disponibilidade para a equipe são constantes mas ele não faz parte do processo de desenvolvimento. O que ele faz é mais ligado a estratégias de negócio entrega de valor. Sua função é muito mais “política” do que técnica.

O Product Owner é responsável pelo Product Backlog, que é uma lista de tarefas descrevendo as funcionalidades necessárias do produto final e ordenadas por prioridade. Quem determina o grau de prioridade de cada tarefa é o Product Owner, baseando-se no valor de negócio e no ROI previsto delas.

Para isso, ele deve ter entendimento claro e profundo da visão do produto, ter autonomia para tomada de decisões, e ser comunicativo o suficiente para poder transmiti-las claramente para o resto do time.

Scrum Master: O Dono do Processo

O papel do Scrum Master é garantir que os valores e regras do Scrum sejam seguidos cotidianamente pelo resto do time. Ele é responsável por decidir o tamanho dos ciclos de desenvolvimento de software. No Scrum, esses ciclos são chamados de Sprints. Cada Sprint pode durar de uma a quatro semanas.

Além disso, ele é o intermediário entre a equipe de desenvolvedores e o Product Owner. O Scrum Master serve de “alívio” para que o Product Owner possa focar nas estratégias de negócio e na entrega de valor com os demais stakeholders. Enquanto isso, o Scrum Master lida diretamente com o time de desenvolvedores e gerencia o Sprint Backlog.

Por quê Dono do Processo?

O Scrum Master pode ser chamado informalmente de Dono do Processo pois ele é o membro que equilibra as relações internas e externas da equipe Scrum. Ele lida diretamente com o Product Owner e com o time de desenvolvimento, mas pode transitar entre outros setores da empresa ou entre outros stakeholders, por exemplo.

Isso acontece pois a outra responsabilidade do Scrum Master, além do Sprint Backlog, é blindar os desenvolvedores. Ele filtra quais informações chegam aos “devs” e evita interferências no Sprint, trabalhando sempre para resolver qualquer impedimento ao progresso da equipe.

Durante o Sprint, este membro age como mentor e gestor dos desenvolvedores, conversando com eles constantemente para resolver possíveis impedimentos. “Minha máquina está com problema e por isso não consigo programar”, “não tenho conhecimento suficiente nessa tecnologia para executar essa tarefa”, “o colega que senta ao meu lado está me irritando”, “sou interrompido muitas vezes durante o dia”, entre outros obstáculos técnicos ou pessoais, por exemplo.

O SM sempre mantém o Sprint Backlog atualizado para analisar a performance individual e coletiva. Além disso, ele vê quais tarefas são completadas e em quanto tempo, assim prevendo e ordenando quais tarefas terão de ser adiadas para o Sprint seguinte.

A estimativa do trabalho que não pode ser adiado para o próximo Sprint é calculada todos os dias, e colocada em um gráfico chamado de Sprint Burndown Chart (ou apenas Burndown Chart – Gráfico de Queima, em tradução livre).

Mentor e Facilitador para os Desenvolvedores

Sendo mentor dos desenvolvedores, o SM precisa mantê-los motivados e certificar-se de que as tarefas do Sprint estão sendo executadas do jeito certo. Ele faz isso levando os pedidos do PO e dos demais stakeholders em consideração.

Entretanto, a autoridade e autonomia do SM são menores do que as do PO, já que seu escopo de ação é restringido ao time de desenvolvedores.

As medidas de blindagem que ele pode tomar acabam dependendo da colaboração de agentes externos à equipe Scrum. Por isso, é importante que o SM seja um bom negociador e saiba conversar com os stakeholders de forma amigável.

O Scrum Master precisa saber Programar?

background técnico do Scrum Master na área de software, assim como o do Product Owner, é opcional. Porém, é interessante que ele entenda ao menos o básico dos conceitos de desenvolvimento e das tecnologias aplicadas ao projeto da sua equipe. Isso lhe trará mais segurança ao garantir a qualidade dos entregáveis.

O Scrum Master não é responsável pela execução das tarefas do Sprint, mas precisa assegurar que essa execução é feita da melhor maneira possível dentro das capacidades, limitações e acordos do time.

Desenvolvedores

Quando se fala de Time Scrum, os primeiros membros a serem mencionados geralmente são os desenvolvedores de software.

Na equipe de desenvolvedores, é necessário que os membros sejam alocados de forma que qualquer problema no software possa ser solucionado por eles em sua totalidade, sem ajuda externa.

Não existe necessariamente uma divisão dos membros por funções desempenhadas individualmente. Como, por exemplo, designer, front end, back end, arquiteto, analista de testes…

No Scrum, todos os membros trabalham juntos para entregar ao final de um Sprint aquilo que foi prometido no início dele. Por isso, todos acabam sendo fullstack em maior ou menor grau.

O Scrum é baseado em refletir sobre o desempenho passado com transparência e comprometimento. Todos os integrantes sabem o que cada um está fazendo e como cada tarefa está progredindo. Todos se comprometem em mudar o que for necessário para melhorar o desempenho da equipe.

É importante que a equipe permaneça ágil, integrada e comunicativa. Fazer parte de um time sinérgico acaba naturalmente ajudando todos os membros a se manterem motivados e empenhados em criar um processo mais eficiente.

Artefatos Scrum

Os Artefatos Scrum são disseminadores de informação que representam trabalho ou valor. Eles fornecem transparência ao dar oportunidades de inspeção e adaptação do processo de desenvolvimento.

Eles são projetados especificamente para maximizar a transparência de informações, para que todos os stakeholders tenham o mesmo entendimento do conteúdo de cada artefato.

Os artefatos obrigatórios do Scrum são apenas o Product Backlog, o Sprint Backlog e o Product Increment. Porém, além deles ainda existem artefatos opcionais, cujo uso é decidido pela equipe. Os artefatos, tanto obrigatórios quanto opcionais, são:

Product Backlog: a lista de desejos

Product Backlog – a Reserva do Produto, em tradução livre – representa uma listagem das funcionalidades desejadas pelo cliente. Em acordo entre o Product Owner e o cliente, elas precisam ser desenvolvidas com maior urgência.

Os itens discriminados neste backlog são priorizados, adiados ou descartados por valor de negócio pelo Product Owner, e podem ser tarefas técnicas ou não.

O Product Backlog não precisa estar completo desde o início do projeto. No começo os desenvolvedores podem trabalhar só com o que for mais simples ou óbvio ao sistema projetado. Depois, à medida que os Sprints são concluídos e o software é incrementado, pode-se adicionar mais coisas ao backlog.

Assim, com negociação entre os stakeholders e análise contínua das funcionalidades entregues, esse backlog pode crescer e mudar, sempre levando em conta o que se aprende sobre o produto e sobre a jornada do usuário.

Sprint Backlog: os afazeres desse ciclo

Durante o Sprint Planning, que abordaremos no tópico de Eventos Scrum, o PO prioriza os itens do Product Backlog e os descreve para o SM e para a equipe.

A equipe então determina quais dos itens descritos ela poderá completar durante o próximo Sprint. É disso que surge o Sprint Backlog, que nada mais é do que uma lista de tarefas ou afazeres.

Esses afazeres são divididos entre os integrantes do time pelo Scrum Master, de acordo com a percepção da equipe sobre as habilidades de cada membro e sobre o tempo que será empregado para completá-los.

Mudanças de escopo nos itens do Sprint Backlog após o início do Sprint devem ser evitadas ao máximo. Elas atrapalham o andamento do Sprint e tiram o foco da equipe no trabalho. Se for necessário modificar algo, o Scrum Master deve negociar com os desenvolvedores e com o Product Owner sobre como e o que mudar e quais são os motivos para essa mudança.

User Stories: Histórias do Usuário

Até agora, nós nos referimos aos itens dos backlogs como tarefas, mas nem todas as equipes Scrum falam assim. Algumas preferem falar de User Stories, ou Histórias do Usuário.

“Tarefa” é uma palavra genérica para os itens dos backlogs e que pode ser usada isolada ou conjuntamente com “Histórias”.

O cérebro humano funciona melhor quando escuta histórias. Temos maior entendimento e empatia quando um interlocutor nos transmite os motivos das suas escolhas descreve sua trajetória. Nesse contexto, o interlocutor é o usuário do sistema.

Assim, resumidamente, as User Stories são descrições simples e curtas de uma funcionalidade a ser implementada no software.

Elas são contadas do ponto de vista do usuário, apontando por qual motivo ele deseja que o software seja capaz daquela função. Geralmente, as Stories são escritas nesse padrão:

“Como USUÁRIO, eu quero FUNCIONALIDADE para que RAZÃO”.

Por exemplo: “Como gerente de estoque, eu quero poder adicionar ou remover produtos do cadastro de estoque, para que haja maior controle do fluxo de vendas”.

As User Stories geralmente são escritas em cartões ou em post its. Eles podem ser dispostos em paredes, lousas ou mesas para facilitar o planejamento e a discussão. Essa disposição também pode ser feita em ferramentas digitais, como o Trello.

Isso ajuda na visualização das funcionalidades. O foco muda da escrita sobre recursos para a discussão ativa e coletiva sobre eles. Assim, o time está exercendo os princípios Scrum de comunicação e transparência.

Como detalhar as User Stories?

Se necessário, detalhes podem ser adicionados às Histórias de duas maneiras:

  • quebrando uma História mais complexa em outras menores e mais simples,
  • ou adicionando condições de conclusão ao cartão que a descreve.

No primeiro cenário, já é presumido que as novas Stories criadas contém detalhamento adicionado a elas.

No segundo cenário, as condições de conclusão são apenas um obstáculo colocado ali para garantir maior cuidado no desenvolvimento daquela funcionalidade. É natural que todas elas sejam cumpridas por consequência desse cuidado.

Qualquer um no Scrum pode escrever User Stories. Cabe ao Product Owner aceitá-las na fila de prioridades que é o Product Backlog. Ao longo do ciclo de vida do projeto, é esperado que todos os membros do time acabem escrevendo uma História em algum momento.

A identidade do autor da User Story é irrelevante. O que realmente importa é quem vai discutir sobre ela e trabalhar em cima dela no decorrer do projeto.

Da mesma forma, não é obrigatório que todos os itens dos backlogs sejam escritos no formato de História. Às vezes, é muito mais fácil, rápido e intuitivo simplesmente escrever palavras chave, escrever casos de uso ou desenhar diagramas ou layouts simples. O Scrum descreve o que precisa ser feito, mas não há regra sobre como fazer.

Story Points: a unidade de medida do progresso

Um Story Point é uma medida abstrata do esforço necessário para implementar uma User Story. Assim como User Stories, o uso de Story Points e de Burndown Charts é opcional.

Resumindo, é um número que informa a equipe sobre o nível de dificuldade da História. Nível esse que está relacionado a particularidades, riscos e esforços envolvidos na execução de cada História específica.

Na maioria dos casos, um Story Point usa uma das seguintes dimensões:

  • Sequência de Fibonacci: 1, 2, 3, 5 ,8, 13, 21;
  • Tamanhos análogos aos tamanhos de camiseta: PP, P, M, G, GG;
  • Ou a sequência simples do 1 seguido de múltiplos de 2: 1, 2, 4, 8, 16.

Os Story Points representam estimativas de alto nível e geralmente são feitos após o Sprint Planning. O PO, o SM e o time de desenvolvimento fazem uma estimativa grosseira onde checam se:

  • o planejamento foi conduzido de forma eficiente;
  • há informação suficiente para cumprir tudo que foi designado para aquele Sprint; e
  • se as User Stories foram divididas de forma razoável entre os membros da equipe.

Estimativas baseadas em medidas de tempo como horas ou dias, em contrapartida, são estimativas de baixo nível. Elas representam o esforço palpável (relação hora/homem da mão de obra) demandado para completar aquela User Story.

Story Points são Medidas de Tempo?

Na verdade, Story Points e medidas hora/homem têm propósitos diferentes para situações diferentes e não devem ser comparados ou utilizados de forma exclusiva. O certo é evitar relacioná-los para que o Sprint e o lançamento do produto sejam melhor executados.

A hora/homem não é igual para todos os desenvolvedores, mas os Story Points sim. Isso permite que pessoas com velocidades diferentes e níveis de habilidade diferentes consigam chegar num consenso.

Atribuir determinada quantidade de Story Points para uma User Story é mais flexível do que atribuir uma quantidade de horas ou dias. Assim, a janela de entrega da Story acaba sendo a mesma para todos os membros do time.

Cada Story Point representa uma distribuição normal de tempo. Por exemplo: um Story Point pode representar um intervalo de 4 a 12 horas, dois Story Points seriam de 10 a 20 horas e assim por diante.

Essa distribuição de tempo é desconhecida durante a estimativa, pois ao usar Story Points, não é necessário saber quanto tempo leva, só é necessário ter uma indicação aproximada de quanto tempo vai demorar para aquilo ser concluído. O Planning Poker é utilizado para designar os Story Points.

Burndown Charts: uma visão geral do projeto

O monitoramento do progresso do projeto, no Scrum, geralmente é feito com um gráfico chamado Burndown Chart ao final de cada Sprint.

Existem várias formas de Burndown Chart. A forma utilizada é determinada pelo Scrum Master em conversa com os desenvolvedores.

O trabalho que ainda resta pode ser mostrado na unidade preferencial da equipe, que usualmente são Story Points. Sua finalidade é permitir que o projeto esteja no caminho para entregar a solução esperada dentro do cronograma desejado.

O Burndown não é obrigatório de forma alguma. Ele é apenas uma ferramenta para visualizar o progresso no projeto e no Sprint, e esse progresso é que deve ser medido obrigatoriamente. O ideal é que o SM meça isso diariamente.

A equipe pode escolher o método que quiser, inclusive outros tipos de gráficos ou outras métricas, desde que haja uma forma consistente de inspecionar o progresso do produto.

Product Increment: as funcionalidades ou entregáveis

Ao encerrar o primeiro Sprint de um projeto, a equipe Scrum precisa, mesmo que de forma rudimentar, resolver o problema do usuário final. Daí vem o conceito de MVP (Minimum Viable Product – Mínimo Produto Viável, em tradução livre).

O MVP é muito utilizado no mundo do empreendimento e das startups, já que a maioria dessas pequenas empresas inovadoras surge justamente com um MVP.

A grande diferença do Scrum para o Cascata está nesse conceito, já que as iterações têm por base entregar incrementos do produto ao longo do tempo. Isso é contrário ao paradigma antigo onde havia uma única grande entrega ao final do projeto.

Para que o Sprint termine com sucesso, é necessário que seu objetivo tenha sido atingido. Esse objetivo é definido pela equipe e geralmente envolve a entrega de pelo menos um incremento de software que esteja funcionando.

Por isso é que “incremento”, “entregável” e “funcionalidade” acabam sendo palavras intercambiáveis nesse contexto. O incremento precisa ser validado pelos analistas de testes e pelo PO para que seja incorporado ao produto final.

Imagem: Henrik Kniberg

Eventos Scrum

Os Eventos são usados no Scrum para criar regularidade e minimizar a necessidade de reuniões imprevistas. Todos os eventos são timeboxed, o que significa que eles têm um tempo mínimo e um tempo máximo de duração.

Todos os Eventos são ligados ao Sprint, que é o principal deles, e todos se repetem cada vez que um Sprint acaba e outro começa. Daí a natureza iterativa do Scrum.

Antes do Sprint começar, idealmente na primeira Sprint Planning do projeto, sua duração é fixada pelo Scrum Master. Ela não pode ser reduzida ou aumentada.

Os eventos restantes também têm timeboxes mas podem terminar antes do previsto caso o objetivo proposto para cada um deles for alcançado mais rápido. Assim há garantia que uma quantidade apropriada de tempo seja gasta sem permitir desperdício no processo. Os Eventos Scrum são:

Sprint Planning: o planejamento

Antes de iniciar um Sprint, o Product Owner apresenta para o Scrum Master e para os desenvolvedores os itens mais prioritários do Product Backlog. O time seleciona os itens que farão parte do Sprint Backlog.

Depois disso, o SM e o PO se retiram da reunião para que o time “dev” defina tecnicamente como serão desenvolvidos os itens do Sprint Backlog. Essa definição é auxiliada pelo Planning Poker, que veremos mais à frente no artigo. Essas são as duas etapas do Sprint Planning.

Durante a primeira etapa, o Product Owner apresenta os itens do Product Backlog sob a ótica de negócios, mostrando o raciocínio utilizado por ele para definir quais itens têm maior prioridade. O time pode tirar dúvidas com o PO e já idealizar quais são as possíveis soluções técnicas para cada item, uma vez que esses itens formarão o Sprint Backlog.

Após formado o Sprint Backlog, a equipe Scrum completa irá definir um objetivo para o Sprint, descrevendo de forma sucinta o que o time deve ter como foco para essa iteração.

Já durante a segunda etapa, os desenvolvedores se reúnem para que possam traçar o planejamento técnico de cada item do Sprint Backlog. Cada item é quebrado em tarefas menores ou transformado em User Stories caso necessário. Estima-se o tempo que será despendido neles. Essa estimativa geralmente é feita com o Planning Poker.

A análise da efetividade do Sprint Planning acontecerá no Sprint Review.

É importante que os membros da equipe lembrem-se de qualquer folga, período de férias, feriados, viagens, ou qualquer outro detalhe de programação que ocorrerá durante o Sprint e que possa afetar o seu andamento. Assim, poderão estimar com a maior precisão possível qual será a quantidade de trabalho realizada.

Planning Poker: o jogo e suas regras

Equipes que utilizam Story Points também costumam usar um exercício parecido com um jogo de pôquer. As cartas de baralho são utilizadas para estimar o esforço que será despendido em cada tarefa.

A equipe de desenvolvedores pegará um item do backlog e discutirá brevemente sobre ele. Cada um dos integrantes pensará em uma quantidade de Story Points que considera adequada para a execução dele. Todos pegam e mostram aos demais uma carta de baralho com o número equivalente à sua estimativa.

Se todos estiverem de acordo, o exercício acaba aqui. Se houver discordância, cada desenvolvedor deve entender a lógica por trás das diferentes estimativas.

A estimativa deve ser uma atividade de alto nível. Isso significa que as discordâncias não podem ser muito gritantes. Se alguns membros estimaram 1 Story Point enquanto outros estimaram 5, conversem mais um pouco, até que esses números se aproximem.

A equipe deve ter um consenso sobre o número máximo de Story Points, horas de trabalho, ou qualquer que seja a medida escolhida pelos integrantes.

As Sprint Retrospectives são o momento do time refletir sobre a precisão e eficácia de iterações anteriores daquele projeto. Essa reflexão inclui a precisão de suas estimativas.

O Quão Preciso é Preciso Ser?

Em uma sessão de Planning Poker, imagine que metade da equipe estimou 3 Story Points e a outra metade estimou 5 Story Points para uma História.

É fácil aceitar 4 Story Points como a estimativa e seguir para a próxima tarefa, mas a equipe deve ter sinergia e maturidade suficientes para entender que não é produtivo fazer isso. Isso só gera uma falsa sensação de precisão. Não há necessidade de ser 100% preciso. O que é necessário é ser preciso o suficiente para garantir o bom andamento do Sprint e planejar tudo com antecedência.

Além disso, pode haver perda de transparência no processo caso a decisão mais fácil seja tomada. Essa decisão gera uma diminuição na comunicação do time. Talvez 5 Story Points seja uma estimativa melhor e vocês nunca saberão se não conversarem sobre isso.

Sprint e seus Estados (To Do, Doing, Done)

Um Sprint é um ciclo com começo e fim, com uma duração de tempo pré-determinada pelo Scrum Master. O Sprint é o centro do Scrum. Todos os outros eventos e artefatos giram em torno dele e da sua execução.

Ao final de cada Sprint, há uma nova funcionalidade a ser validada ou barrada pelo Product Owner. Depois, implementada em definitivo ou modificada até que fique dentro das regras e valores de negócio propostos por ele.

A Duração dos Sprints

O SM precisa analisar a estabilidade dos escopos de produto e de projeto antes de definir a duração dos Sprints. Se um deles for muito mutável e essas mudanças estiverem relacionadas a tempo de entrega, é mais prudente que os Sprints tenham uma ou duas semanas de duração. Se os recursos disponíveis aos escopos são mais estáveis, Sprints de duas a quatro semanas podem funcionar melhor.

Como já mencionado neste artigo, não é comum e nem recomendável que os Sprints de um projeto variem de tamanho, pois isso gera instabilidade e imprevisibilidade na velocidade de execução do mesmo.

O Sprint termina quando o tempo de duração definido para ele se esgotar ou quando o objetivo definido durante o Sprint Planning for atingido. Para que o Sprint termine com sucesso, é necessário que haja entrega de um incremento de software.

Durante o Sprint, cada tarefa tem um estado. Esse estado serve para indicar a que pé está sua execução.

Estados do Sprint

Algo comum, e semelhante ao que é feito no Kanban, é dividir as tarefas do Sprint por colunas em um quadro físico ou virtual. Cada uma delas equivale ao estado de um cartão. Esse cartão transita pelas colunas à medida que o que está descrito nele é implementado. Os Estados mais comuns são:

  • Backlog. Designa o Product Backlog.
  • Blocked (Bloqueado). Contém tarefas que não poderão ser inseridas em To Do por algum impedimento.
  • To Do (Por Fazer). Designa o Sprint Backlog.
  • Doing ou Work in Progress (Fazendo). Lista tarefas que estão sendo feitas, com indicação do desenvolvedor responsável por fazê-las em cada cartão.
  • Verify (Verificar). Onde estão as tarefas já desenvolvidas que precisam ser testadas.
  • Done (Feito ou Pronto). São tarefas já concluídas.

Os Estados obrigatórios são apenas To Do, Doing e Done.

Para que todos os stakeholders estejam alinhados sobre o que significa a conclusão de uma tarefa, existe um documento chamado Definition of Done (Definição de Pronto). Nele há a descrição genérica de quais são os passos mínimos para a conclusão de entregáveis.

Esse documento é como uma garantia da qualidade dos incrementos. Ele pode ser modificado ao longo das iterações, à medida que é revisado em cada Sprint Review.

É obrigatório que todos os stakeholders estejam de acordo com a Definição de Pronto para que haja transparência e confiança entre eles durante o projeto.

Daily Scrum: as reuniões diárias

Todos os dias, a equipe se reúne para conversar sobre o andamento do Sprint atual. O objetivo aqui é promover o alinhamento contínuo entre todos os membros do time e ajudar o Scrum Master a prever o que poderá realmente ser entregue ao final do Sprint.

Essa reunião diária é chamada de Daily Scrum ou apenas Daily. Ela costuma durar por volta de 15 minutos. Pode ser estendida com membros específicos do time dependendo do que for conversado e de possíveis impedimentos que podem surgir.

A participação do time completo é obrigatória. Para esse evento, isso sempre inclui o Scrum Master mas nem sempre o Product Owner. A participação de outros stakeholders, como os gerentes de outros setores ou o cliente, é menos comum mas pode ocorrer, porém eles serão apenas ouvintes.

A Daily não deve se aprofundar em discussões técnicas. Qualquer questão que surja durante ela deve ser estendida apenas com os membros diretamente envolvidos ou afetados por essa questão. Se necessário, o que foi discutido nessa etapa é passado de forma resumida para os membros que não estavam envolvidos.

As questões que devem ser respondidas pelos desenvolvedores na Daily, assim reportando seu progresso ao Scrum Master, são:

  • “O que eu fiz ontem” ou “o que eu fiz desde a última Daily”;
  • “O que pretendo fazer hoje” ou “o que pretendo fazer até a próxima Daily”; e
  • “Existem os seguintes impedimentos para que eu possa concluir minhas tarefas” ou “não existem impedimentos para as minhas tarefas”.

Tendo em conta o que foi respondido, o Scrum Master deve trabalhar para eliminar os impedimentos. Caso eles não existam, deve trabalhar para que o que ainda falta nesse Sprint seja concluído com qualidade e dentro do prazo.

Sprint Review: revisando o ciclo

Após o final do Sprint, o time mostra como aconteceu o desenvolvimento dos entregáveis. Normalmente estão presentes no Sprint Review o Product Owner, o Scrum Master e o cliente ou os stakeholders que o representam. O foco da reunião é demonstrar as novas funcionalidades com o mínimo possível de bugs e funcionando relativamente bem. O ideal é que a duração do Review não seja maior do que duas horas.

Os incrementos devem ser revisados de acordo com o objetivo do Sprint que foi acordado no Sprint Planning. A equipe deve sempre se esforçar para alcançar esse objetivo.

Sprint Retrospective: refletir para melhorar

O último Evento Scrum é a Retrospectiva. A equipe analisa o rendimento do Sprint que acabou e conversa sobre maneiras de melhorar seus processos de trabalho para o próximo Sprint. Há discussão e exposição de dificuldades e como a equipe acha que pode evitá-las.

Isso está relacionado com alguns fatores. São eles:

  • empenho de cada desenvolvedor,
  • divisão de tarefas feita no Sprint Planning,
  • e os impedimentos apontados na Daily, além das decisões do SM para resolvê-los.

A equipe decide como agir dali em diante para melhorar sua eficiência no próximo Sprint. Os integrantes devem visar o aumento da sua produtividade sem perda de qualidade.

Assim como a Daily, a Retrospectiva também tem uma duração ideal. Nesse caso é de uma hora, mas os envolvidos em alguma questão mais complexa podem continuar conversando após a reunião.

Uma das técnicas de Retrospectiva é o start-stop-continue:

  • “Devemos começar a fazer…” (start)
  • “Devemos parar de fazer…” (stop)
  • “Devemos continuar a fazer…” (continue)
Imagem: Blog Europneumaq

Scrum of Scrums: a solução para projetos grandes

Scrum of Scrums ou Meta Scrum é um mecanismo de escalabilidade criado na IDX Systems (atual GE Healthcare).

É definido pela Agile Alliance como “uma técnica para escalar Scrum até grandes grupos (mais de uma dúzia de pessoas), consistindo em dividir os grupos em equipes ágeis de 5 a 10 integrantes”.

Ainda, é definido por Jeff Sutherland como “responsável por adequar o software de todas as equipes à Definição de Pronto no final do Sprint, ou a lançamentos durante o Sprint”. Quando trabalhavam na IDX, Jeff Sutherland e Ken Schwaber implementaram-no como uma técnica para dimensionar equipes Scrum individuais para o nível corporativo.

O Gerenciamento de um Scrum of Scrums

A coordenação das várias equipes é feita em uma reunião do Scrum of Scrums. Essa reunião pode ser realizada diariamente, duas vezes por semana ou, no mínimo, uma vez por semana.

Cada equipe Scrum tem seu representante. Ele pode ser o Scrum Master ou outro membro da equipe escolhido pelos outros integrantes. Se o assunto que uma das equipes quer discutir é muito técnico, tanto o membro da equipe tecnicamente qualificado quanto o Scrum Master podem querer participar.

A reunião do Scrum of Scrums é executada de forma muito semelhante à Daily Scrum. Apesar de não ter uma duração de tempo predeterminada, é comum que ela dure 15 minutos, assim como a Daily de Scrums comuns. Na reunião do Scrum of Scrums, cada “embaixador” de cada time Scrum deve responder:

  • O que sua equipe realizou desde a última reunião;
  • Quais problemas ocorreram (se ocorreram) e como afetaram negativamente sua equipe;
  • O que sua equipe deseja realizar antes da próxima reunião;
  • Quais ações da sua equipe em futuros Sprints podem interferir nos Sprints das outras equipes;
  • E se sua equipe vê alguma interferência proveniente de outras equipes.

O propósito da reunião do Scrum of Scrums é assegurar a coordenação e integração dos resultados das várias equipes, eliminando todos os impedimentos. Para isso, pode haver envolvimento de duas ou mais equipes trabalhando juntas por um tempo ou renegociando responsabilidades.

Isso precisa ser gerenciado com um Product Backlog próprio do Scrum of Scrums e mantido pelo Scrum Master eleito como chefe desse processo. Ou, ainda, por um Gerente de Projetos que tenha o Product Backlog do Scrum of Scrums como sua principal demanda.

Como Organizar o Scrum of Scrums

Um framework Scrum of Scrums pode ser eficaz mesmo em organizações maiores com múltiplas equipes. Ou em projetos com Scrums distribuídos em locais diferentes. Desde que as reuniões próprias dele sejam conduzidas adequadamente.

A ênfase deve estar na coordenação das várias equipes e na resolução de impedimentos. O objetivo é garantir que as equipes individuais cumpram suas metas. Assim, o objetivo geral do projeto de todas as equipes será atingido.

O desperdício de tempo, trabalho e recursos é diminuído ao máximo por um time formado especificamente para ajudar o Scrum Master ou Gerente de Projetos encarregado do Scrum of Scrums. Os membros são selecionados de cada Scrum ou são integrantes exclusivos.

Isso garante a manutenção da transparência e boa comunicação entre todas as equipes Scrum. Ken Schwaber chamou isso de Integration Scrum (Scrum de Integração) em seu livro The Enterprise and Scrum (“As Empresas e o Scrum”, em tradução livre). Ter pelo menos um lançamento a cada três meses é a meta.

Como implementar o Scrum na sua empresa

A implementação do Scrum tem muito a ver com a implementação da Transformação Digital. Além do Scrum ser uma ferramenta de Transformação Digital, ambos os processos dependem diretamente de mudanças na cultura organizacional.

Essas mudanças só podem ocorrer de forma efetiva se forem feitas gradualmente e com muito engajamento dos líderes da empresa e dos colaboradores. Os líderes sempre terão que balancear os prós e contras com transparência diante de suas equipes, visando integrar todos os setores da empresa.

Metodologias Ágeis para Organizações

O que acontece em implementações organizacionais de métodos ágeis não é o uso do Scrum propriamente dito, mas sim de frameworks modificados.

Eles também são baseados nos princípios do Manifesto Ágil, porém com essa integração de setores já considerada desde a sua concepção.

Um exemplo desses frameworks é o SAFe, que aborda todas as camadas de uma organização. Dean Leffingwell, o criador do SAFe, o define como “uma estrutura para implementar práticas ágeis em escala corporativa”.

Transição para o Scrum

A transição de tradicional para ágil deve ser cuidadosa e muito bem alinhada internamente. Assim como qualquer outra mudança de cultura organizacional, devido ao impacto que isso trará aos colaboradores.

As equipes de cada setor devem ser multidisciplinares. Os silos organizacionais devem ser diminuídos ao máximo para que a sinergia entre setores seja sempre priorizada.

Essa sinergia e multidisciplinaridade ajudarão na Agilidade, já que colaboradores proficientes em várias frentes poderão auxiliar uns aos outros e trazer visões diversas para a empresa.

É esperado que alguns dos colaboradores demonstrem resistência ao processo de transição. Aí é que se encaixa o papel principal dos líderes dos setores. Eles devem alinhar expectativas de forma sempre transparente e explicar quais serão as melhorias obtidas para cada setor com a implementação do Scrum – ou de qualquer outra metodologia ágil.

Saiba mais sobre o Scrum

Scrum – Aprenda Scrum em 9 minutos por Denisson Vieira

Scrum // Dicionário do Programador pelo canal Código Fonte TV

Scrum ou Kanban na Metodologia Ágil? – Beer For Devs (parte 2) pela TOTVS

Scrum – Metodologia Ágil: o que é e para que serve? por Mário Conde

Metodologias Ágeis – Scrum pelo canal Tu quer saber mais?

Scrum Cases de sucesso

O Scrum é uma das ferramentas que podem fazer parte da Transformação Digital. Por esse motivo, alguns dos cases de sucesso do Scrum foram citados no nosso artigo de Transformação Digital.

Dois dos cases mais simbólicos são o da GE Healthcare (antiga IDX Systems) e o do FBI. O case da GE foi citado na seção de Scrum of Scrums deste artigo. Ele está disponibilizado traduzido na íntegra aqui no nosso blog.

Na Zappts, os times de desenvolvimento são geridos com Scrum. Cada time é dedicado para cada projeto, não recebendo demandas de projetos paralelos. Isso garante a agilidade e o bom andamento dos Sprints. A qualidade das soluções que oferecemos aos clientes é assegurada dessa forma.