Transformação Digital nas empresas

Se você está trabalhando com TI ou ao menos atuando no mundo corporativo assim como eu, certamente você já deve ter ouvido falar em Transformação Digital. Toda semana os principais sites de negócios comentam que a empresa X está fazendo sua transformação digital com a consultoria Y. Ou que a empresa W avança em sua transformação digital através da estratégia de implantar os processos ABC e a solução XPTO.

Mas será que é isso que significa fazer uma transformação digital? Implantar um ERP de mercado? Mudar para processos mais ágeis? Contratar uma consultoria boutique?

Afinal o que é uma transformação digital? O que é uma empresa digital?

Pensando em auxiliar quem está tentando descobrir as respostas para estas perguntas, no artigo de hoje trago algumas definições, estudos de mercado e experiências próprias, com o mínimo de achismo possível e o máximo de fatos e conceitos consolidados. Eu não inventei estas teorias e vários trechos eu li em outros lugares, sendo que informarei os links originais ou citarei o autor sempre que possível.

Curso de Scrum e Métodos Ágeis

O que é Transformação Digital?

Esse é um termo que está cada vez mais famoso no Brasil, certo?

Mesmo por aqui, Transformações Digitais estão eclodindo em todas grandes empresas que não querem ficar de fora da profusão de matérias sobre o tema e da atenção dos investidores. No entanto, ser digital está longe de apenas informatizar processos manuais e trocar tecnologias, exige um redesenho da organização e uma evolução de sua cultura, dois elementos muito mais delicados.

A questão é que transformações de negócios, de qualquer tipo, são extremamente custosas e arriscadas. Para um negócio se tornar digital, não basta adicionar uma camada de tecnologia ou executar o desenvolvimento de software, você tem de inserir a mesma nas entranhas das camadas já existentes. Não é algo que você resolve investido no departamento de TI da empresa, mas distribuindo a TI por toda a empresa. Ou então o contrário, distribuindo business por toda TI. Não importa.

Não ajudei muito até aqui, certo? Calma, vai melhorar.

Muitas corporações estão se deparando com a necessidade de uma transformação digital, mesmo sem saber direito o que é uma. 

De acordo com uma pesquisa de 2017 da CEB chamada “The New IT Operating Model for Digital”, dois-terços dos líderes de negócios acreditam que suas empresas vão perder competitividade se eles não se tornarem significativamente mais digitais. Eles entendem que a sobrevivência de suas empresas depende da sua habilidade de se adaptar a esse novo modelo da economia digital.

Mas o que é ser digital?

A versão online do dicionário Merriam-Webster oferece várias definições para o vocábulo “digital” e duas delas tem a ver com as transformações que estão acontecendo: “dados na forma de dígitos binários” e “interação tátil com os dedos”.

Digital
Digital

Tecnicamente, quando falamos de transformação digital expandimos esses dois conceitos básicos para mais quatro (segundo Phillipe Assouline, da InfoQ):

  • Experiência do Cliente (CX)
  • Cybersegurança
  • Automação
  • Mídias Sociais
Digital Expandido
Digital Expandido

Sendo assim, uma empresa digital é, por essas verticais, aquela que:

  • possui sistemas digitais;
  • sistemas estes de interação fácil e intuitiva (pra não ficarmos preso ao tátil);
  • cujos clientes (internos e externos) possuem uma boa experiência;
  • se preocupa com segurança cibernética;
  • possui processos automatizados;
  • entende e se comunica com seus clientes através de plataformas sociais;

Uma empresa que deseja se tornar digital deve considerar esses seis verticais de prioridades na hora de compor a sua “estratégia digital”. Estratégia essa que pode ser mais ou menos agressiva, mais ou menos intensa, mais inclinada para um vertical e menos para outro, mas sem negligenciar qualquer um deles.

Estratégia de Transformação Digital

No seu famoso Digital Transformation Guide, Assouline menciona que toda empresa passando por uma transformação digital está em um de três estágios: Going, Becoming ou Being Digital e que a jornada de transformação é justamente ir do primeiro estágio ao terceiro.

Jornada Digital

O autor entende que absolutamente TODAS empresas estão aptas a saírem da inércia e chegarem aos estágios um e dois, sendo que o dois é a famosa Transformação Digital que tanto se fala, onde sistemas, processos, comunicação, experiência do cliente e segurança são aperfeiçoados.

E aí que mora uma falha comum na definição da estratégia digital, ou melhor, na falta de UMA!

Ao invés de planejar como sairemos da inércia para um plano de transformação digital (estágio um, Going Digital) é comum vermos executivos mudando sistemas e implantando novos processos por toda empresa, sem entender o que se está buscando com cada mudança e como elas se conversam entre si, causando um caos completo e banalizando o termo “digital” como algo hipster que está na moda mas que não traz valor algum, coisa de empresa que gasta dinheiro para parecer cool.

O autor afirma que uma empresa digital está mais relacionada à conectividade da empresa com o mercado e a sua capacidade de entregar valor de maneira rápida e barata na ponta do que a adoção de novas tecnologias por si só.

Entender o nível desejado de união entre negócios + tecnologia que se quer alcançar é a chave para planejar, mapear e comunicar a intenção da organização com a transformação digital que se deseja iniciar. Para isso, Assouline, que é Head de Data Science e Market Insights em uma grande consultoria, criou um modelo de planejamento, representado na imagem abaixo, que ele chama de DTF: Digital Transformation Framework.

Digital Transformation Framework
Digital Transformation Framework

Por este framework, temos que a base de toda transformação digital deva ser a segurança cibernética (de comunicação e relação automática com os seres humanos), sustentando três pilares.

O primeiro pilar, Tema Digital, é fortemente baseado na definição do que é ser digital que comentei lá em cima, desdobrados em seis temas que fazem sentido para uma empresa fictícia. Enquanto que User Experience, Automation e Social Media são transcrições literais dos verticais abordados anteriormente (além da própria fundação de cybersecurity), Cryptography, Cloud Computing e IoT são demandas específicas da transformação digital de exemplo.

O autor não menciona isso explicitamente, mas menciona de leve que qualquer um dos temas devem ser substituídos pela sua estratégia de transformação, usando os verticais originais como base e as tendências atuais de mercado. Também é interessante notar que uma transformação pode ser faseada, e diferentes temas ou os mesmos temas com intensidades diferentes podem ser abordados em cada fase, como na metodologia Toyota Kata.

Só para citar como exemplo, no Agibank, onde trabalhei de 2017 a 2019 como Agile Coach, os temas da transformação digital eram 4: Infraestrutura Híbrida, Cybersegurança, Business Agility e Arquitetura Corporativa. Obviamente eu trabalhava focado no tema #3 e apenas apoiava o #2 e #4.

O segundo pilar, Orientação ao Cliente, te ajuda a definir se a estratégia é focada no cliente externo ou interno. Este framework assume que a estratégia digital pode ser composta por várias sub-estratégias, ou seja, podemos ter alguns temas que serão dedicados ao cliente externo em uma estratégia e outros temas ao cliente interno, por exemplo.

O terceiro pilar, Nível de Competência, cruza com os Temas Digitais, onde define-se qual o nível de competência a empresa irá buscar em cada um dos temas definidos para sua transformação digital, considerando três possíveis níveis: Competitivo, Indústria e Mínimo.

  • o nível Competitivo demonstra que a empresa deseja ser referência no tema específico e para isso investirá tempo e dinheiro acima da média do mercado; será um diferencial competitivo;
  • o nível Indústria demonstra que a empresa deseja atender aos padrões de mercado, às expectativas comuns para este tema em sua área de atuação; deseja se equiparar aos seus competidores;
  • por fim, o nível Mínimo demonstra que a empresa deseja apenas alcançar o mínimo de competência, entendendo que estará abaixo de seus concorrentes neste tema, mas que não o deixará desassistido;

Seguindo esta explicação do framework e continuando com o exemplo de transformação anterior, podemos plotar o segundo resultado usando o DTF, como uma proposta de transformação digital (totalmente hipotética, baseado nas necessidades e situação de um cliente fictício).

DTF Preenchido
DTF Preenchido

Neste exemplo do DTF preenchido temos uma estratégia composta por duas sub-estratégias, conforme explicação a seguir.

A estratégia 1 (verde claro) é de investir pesado em automação de processos para clientes externos (finais), tornando-se extremamente competitivo neste campo, acima de seus competidores, enquanto que a UX destes mesmos clientes externos deva atender às exigências do seu mercado, equiparando com seus concorrentes.

Já a estratégia 2 (amarelo) é de atender às exigências médias de mídias sociais para sua área de atuação com os clientes externos (talvez esta empresa não se comunicava com os clientes por redes sociais) e oferecer o mínimo de infraestrutura em nuvem para os clientes internos (talvez alguns ambientes para os time de tecnologia).

Essas duas estratégias não abrem mão de segurança digital, não sendo uma opção investir ou não nesse tema.

No próximo artigo, vou explorar como desdobrar esta estratégia em ação na sua empresa, ainda usando o framework DTF de Phillipe Assoulini.

Quer um material de referência para Transformações Ágeis em empresas? Conheça meu livro sobre o assunto clicando no banner abaixo.

Livro para Agile Coaches

Lean Inception: concepção de produtos enxutos

Lean Inception
Lean Inception

Atualizado em 26/01/2020!

A Lean Inception é uma técnica de concepção de produtos enxutos criada por Paulo Caroli, consultor da ThoughtWorks. É um método bem popular entre os agilistas brasileiros e é fortemente documentada no livro Lean Inception, do mesmo autor.

Caroli conta em suas palestras e livros que até então as inceptions (reuniões para concepção de um novo produto) duravam mais de um mês na TW e como Caroli atuava como consultor, não raro ele tinha de passar várias semanas por mês fora de casa, fazendo inceptions em clientes. No entanto, quando seu filho nasceu, ele decidiu que não mais ficaria tanto tempo longe da sua família e construiu uma técnica que, em apenas uma semana, é possível definir tudo que é necessário para se conseguir de fato tangibilizar um produto para que tenhamos insumos suficientes para o time de desenvolver começar a trabalhar.

Lean Inception, Sprint 0, Pré-Jogo…

A Lean Inception ocorre logo no início do projeto, no período que antecede a primeira sprint do time de desenvolvimento, período popularmente chamado de Sprint 0 ou Pré-Jogo. Embora o Scrum não aceite a existência de uma Sprint 0, é comum que isto aconteça de fato logo no início de grandes projetos onde a incerteza é tão grande que não vale a pena iniciar o desenvolvimento às cegas.

A ideia central da Lean Inception é fornecer momentos únicos de interação entre os membros do time e os stakeholders para definição dos conceitos elementares do produto, suas funcionalidades, jornadas do usuário, escopo das entregas, roadmap, etc. Tudo em uma semana muito intensa onde a cada dia novas atividades são realizadas e documentadas.

A ideia deste artigo é dar uma resumida no processo completo, cabendo aos interessados em aplicar esta dinâmica na prática buscar os livros do Caroli ou os treinamentos dele e dos treinadores certificados, como a Mayra Souza. O resumo do treinamento que fiz com esta última pode ser visualizado no vídeo abaixo.

Dia 0: Antes de Começar

O trabalho da Lean Inception começa antes do primeiro dia de dinâmicas. Você terá de montar um grupo heterogêneo de profissionais que possam colaborar com a definição do MVP do produto (objetivo final da inception) ou que estejam diretamente interessadas na construção do mesmo (usuários-chave ou stakeholders, por exemplo). Converse individualmente com cada uma destas pessoas e faça o convite pessoalmente, explicando a importância do comparecimento em todos os dias, como que funciona o processo, etc.

Monte uma lista de emails contendo o contato de todos os membros do grupo e dias antes da inception já comece a lembrá-los de que ela vai começar em breve. Certifique-se que seu grupo tenha até 30 pessoas e que tenha facilitadores suficientes para dar conta desta galera toda, em média 1 facilitador para cada 10 pessoas. Os facilitadores não executam as atividades, apenas conduzem, sem influenciar. Também garanta que todos os perfis abaixo estejam presentes neste grupo:

  • Product Owner do produto;
  • Scrum Master do time (geralmente um dos facilitadores);
  • profissionais técnicos do time (programador, analista, etc);
  • profissionais criativos de UX, UI, marketing, etc;
  • profissionais das áreas de negócio da empresa;
  • profissionais das áreas de atendimento da empresa;
  • usuários-chave do sistema;

Dia 1: Segunda-feira

Como a inception dura a semana inteira, o ideal é que ela comece em uma segunda-feira, para que não aconteça quebra de raciocínio. Mande um email reforçando o início da inception para todos os convidados e tenha um ambiente minimamente dedicado para que a dinâmica aconteça todos os dias no mesmo local e com os mesmos materiais, para que nada se perca entre cada um dos dias.

No primeiro dia as regras da inception são explicadas e em alto nível o que é a ideia do produto (geralmente o Product Owner dará este briefing). Geralmente pede-se que todos os membros do grupo se apresentem, expressem suas expectativas e faz-se uma dinâmica de energização para quebrar o gelo e animar o pessoal. Paulo Pontual, Zip-Zap-Zum, entre outras são sugeridas.

São formados grupos de trabalho, geralmente de 2 a 5 e na parte da manhã a primeira atividade é escrever a Visão do Produto. Cada time escreve a sua visão usando o template abaixo:

Para [cliente final],

cujo [problema que precisa ser resolvido],

o [nome do produto]

é um [categoria do produto]

que [benefícios-chave, razões para comprá-lo].

Diferente do [alternativa de mercado],

nosso produto [diferença-chave].

Depois, cada grupo apresenta a sua versão da visão do produto e ao término das apresentações, consolida-se em apenas uma só, gerando debates para que esta consolidação gere o melhor resultado. Documente a Visão do Produto com fotografias, isso será útil mais tarde, e preferencialmente transcreva-a para um cartaz que deverá estar fixo na sala da dinâmica a semana inteira.

Product Vision
Product Vision

Na parte da tarde (que tal uma energização após o almoço?) faz-se a dinâmica de definição do produto, também chamada de É-Não É, Faz Não-Faz. Aqui a ideia é que cada grupo trabalhe em um cartaz dividido em 4 quadrantes: É, Não É, Faz, Não Faz.

É-Não É-Faz-Não Faz
É-Não É-Faz-Não Faz

Em cada quadrante os membros do grupo discutem o que o produto é, o que ele não é, o que ele vai fazer e o que ele não vai fazer. Depois que cada grupo cria as suas definições individualmente, novamente cada grupo apresenta e o resultado final é consolidado em apenas uma versão após várias rodadas de discussão envolvendo cada quadrante.

As evidências destas duas dinâmicas são enviadas a todo o grupo no final do dia, bem como quaisquer outras fotos tiradas e uma descrição rápida de como o dia passou. Caso não seja possível deixar os cartazes consolidados nas paredes da sala, o facilitador deve guardar os mesmos para que seja possível manter o histórico da dinâmica completa.

Livro para Agile Coaches
Livro para Agile Coaches

Dia 2: Terça-feira

Começa-se o segundo dia reforçando o compromissos com todos via email, antes mesmo da dinâmica começar. Quando a dinâmica começa de fato, após a energização/quebra-gelo (sim, sempre faz-se uma no início do dia) inicia-se uma recapitulação do dia anterior, mostrando o produto final das dinâmicas de Visão do Produto e da É-Não é-Faz-Não Faz, para que todos estejam na mesma página novamente.

Uma vez que temos em alto nível os conceitos mais fundamentais do produto, é hora de falarmos de quem vai usá-lo/comprá-lo: as personas. As personas são arquétipos de usuários-chave típicos do produto. Cada produto possui no mínimo uma persona, enquanto que alguns podem possuir várias.

Cada grupo de trabalho pega uma persona para trabalhar, preenchendo um cartaz com os quatro quadrantes sobre a persona que escolheram:

  • nome e retrato: qual o nome ou apelido deste usuário-chave do produto? como ele se parece, se veste, etc?
  • perfil: idade, nacionalidade, etnia, renda, formação, profissão, etc
  • comportamentos: hobbies, crenças limitantes, crenças fortalecedoras, etc
  • necessidades: o que ele está buscando? Quais as suas dificuldades? As suas “coceiras”? As suas aspirações?
personas
personas

Uma vez que um produto pode ter várias personas, pode ser que cada grupo fique com uma diferente, não havendo necessidade de consolidação. Caso alguma persona se repita, deve-se consolidar os resultados obtidos para a mesma persona. De qualquer forma, cada grupo apresenta aos demais os resultados obtidos.

No mesmo dia, na parte da tarde, é hora de fazer a Descoberta das Features. Uma feature ou funcionalidade é a descrição de uma interação do usuário com o produto ou alguma ação que o sistema é capaz de realizar. As descrições das features devem ser simples e sem entrar em detalhes técnicos.

Para fazer esta descoberta de features existem diversas dinâmicas possíveis, desde simples brainstormings até entrevistas com usuários-chave. A técnica sugerida pela Lean Inception é fazer uma matriz onde cada coluna é algo que o sistema faz (lembra do Faz-Não Faz?) e cada linha é uma persona. O cruzamento das personas com o que o produto faz deve induzir às features necessárias.

Personas x Features
Personas x Features

Note que esta matriz é para ajudar o raciocínio para a descoberta de features, não para limitar a criatividade das pessoas nem para obrigar a fazer todas as combinações de coisas que o produto faz com as personas existentes. No entanto, é sempre interessante descartar features neste momento que de fato não auxiliem na resolução de nenhuma necessidade das personas, direta ou indiretamente.

Ao final do dia, tiram-se fotos dos cartazes das personas e do resultado da descoberta de features. É interessante também adicionar uma numeração nas features para facilitar a organização posterior. Envia-se um email a todos envolvidos com as evidências da dinâmica.

Este artigo ia ficar muito grande, resolvi quebrar em duas partes, sendo que a segunda parte está neste link. Para se aprofundar no assunto, leia o livro do Caroli, abaixo. Para mais conteúdo sobre Métodos Ágeis de desenvolvimento de software, recomendo o meu livro Scrum e Métodos Ágeis: Um Guia Prático e o meu curso sobre o mesmo assunto.

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Backlog DEEP, Histórias INVEST e Tarefas SMART

Atualizado em 29/12/2019 com os slides e vídeo!

Quem trabalha comigo há algum tempo sabe o quanto eu repito a frase “agile não é bagunça” e quando o assunto é o backlog do time, isso não pode ser menos verdade. Existe uma má interpretação do Manifesto Ágil e da própria cultura Lean-Agile em geral que entende que não se precisa ter documentação em projetos rodando sobre frameworks ágeis.

Pura mentira!

A grande mudança de mindset nos métodos ágeis é criar a documentação estritamente necessária e somente quando for necessária, ao invés de gastar meses escrevendo documentos de Visão do Produto, Especificações Funcionais e Não-Funcionais e por aí vai. Isso não quer dizer, no entanto, que jamais vamos ter este tipo de documentação ou algo próximo à elas, mas que vamos distribuir a sua produção ao longo de várias sprints conforme nosso entendimento for aumentando e a necessidade se torne emergente.

E por que eu falo que agile não é bagunça?

Porque justamente em um ambiente auto-gerenciável e sem metodologias prescritivas é que precisamos do mais alto grau de organização e isso começa com nosso requisitos ágeis. No artigo de hoje falarei sobre três acrônimos bem populares para ajudar na organização dos requisitos ágeis:

É importante ressaltar que estes acrônimos são norteadores para a criação e organização destes artefatos e de que não devem se tornar uma “religião” nem criar fanáticos que impeçam os projetos de prosseguirem apenas porque alguma demanda não atende 100% a todos requisitos do acrônimo. Use-os como guias e não como grilhões.

No final deste artigo você encontra este material em forma de slides e nesse link você vê o vídeo da minha palestra sobre este assunto.

Vamos começar?

Backlog DEEP

DEEP é um acrônimo para Detalhado, Estimado, Emergente e Priorizado e são as características que o Product Owner deve buscar sempre em seu backlog.

Detalhado quer dizer que o backlog deve ter os detalhes suficientes para garantir clareza que propicie execução, mas não detalhado em demasia que gere desperdício. Entenda que a necessidade de profundidade no detalhamento é proporcional à emergência de uso do backlog, ou seja, os itens que vão entrar na próxima sprints (mais emergentes) devem estar melhor detalhados, enquanto que os itens que vão entrar daqui a várias sprints, podem estar bem menos detalhados.

Detalhamento de Backlog
Detalhamento de Backlog

Estimado quer dizer que todo item quando chega a um nível de detalhamento suficiente deve ter uma estimativa de esforço associada a ele, uma vez que o backlog não é apenas uma ferramenta de trabalho, mas e planejamento. Essa estimativa pode ser em horas, em pontos, em t-shirt size, em E/EE/EEE ou o que você possa imaginar e que faça sentido para seu time. Essa estimativa inclusive lhe auxilia a entender se o nível de detalhes está bom o suficiente, pois via de regra itens de backlog com uma estimativa muito alta deveriam ser quebrados em itens menores (a técnica de Planning Poker ou de Nivelamento de Features ajuda nisso).

 

T-Shirt Size
T-Shirt Size

Emergente quer dizer que o backlog evolui conforme o Product Owner vai aprendendo sobre o produto e o mercado vai lhe dando feedback sobre seus lançamentos (seu MVP, por exemplo), ele não é estático. O constante refinamento do backlog permite que o produto reaja bem a mudanças de estratégia e de escopo, ao invés de se apegar a um planejamento waterfall. O segredo aqui é rever todo o backlog a cada ciclo construir-medir-aprender do Lean Startup.

Ciclo do Lean Startup
Ciclo do Lean Startup

Priorizado quer dizer que a ordem em que os elementos estão dispostos no backlog importa. Os itens mais prioritários devem estar ao topo, enquanto que os menos prioritários devem estar mais embaixo. Os critérios e técnicas utilizados para priorização variam muito de Product Owner para Product Owner, de produto para produto e de mercado para mercado. Para o Scrum, não importa qual é a sua técnica, mas sim que o resultado deve gerar valor para os clientes e para a empresa.

WSJF - Técnica de Priorização do SAFe
WSJF – Técnica de Priorização do SAFe

Histórias INVEST

O acrônimo INVEST é um trocadilho para dizer que devemos “investir” tempo na escrita de boas histórias de usuário, tema de outro artigo aqui do blog. INVEST significa Independente, Negociável, Valiosa, Estimável, Small (Pequena) e Testável.

Independente significa que uma boa história de usuário não depende de outras e que outras não dependem dela. Que qualquer história deveria poder ser desenvolvida em qualquer ordem, conforme a prioridade que o Product Owner determinar. Sabemos que isso não é lá muito fácil de se alcançar, mas é sempre bom chegar o mais próximo possível disso.

Negociável significa que toda boa história é uma co-criação, uma negociação entre profissionais de negócio e profissionais técnicos. Uma história deve capturar a essência de um requisito, mas não os seus detalhes, que devem ser criados de forma colaborativa e emergente. Ao longo do tempo, mais detalhes serão adicionados a cada história conforme o produto evolui e os usuários demonstram novos comportamentos. Aqui entram os 3C’s necessários em todas histórias: Card, Conversation e Confirmation.

Valiosa quer dizer que toda história deve agregar valor ao produto e principalmente, ao usuário-chave da mesma. Uma historia jamais deveria agregar valor apenas ao desenvolvedor ou apenas ao negócio, e sim sempre centrada no cliente. O Product Owner sempre se deve perguntar se ele tornará melhor a vida do cliente ao colocar aquela historia em produção. A técnica de Nivelamento de Features pode ajudar a determinar o quão valiosa é cada história.

Estimável é semelhante ao que já falamos no DEEP sobre o backlog. Para entregar um backlog estimado que me permita planejar meu roadmap de produto, é necessário ter histórias estimadas primeiro. E para conseguir estimar as histórias elas precisam ser pequenas e claras, com detalhes suficientes e bom nível de entendimento entre negócio e técnicos. Esta estimativa não precisa ser precisa, mas deve dar noções de grandeza que ajudem na tomada de decisão, priorização, etc.

Small (Pequena) para que seja possível entregá-la em no máximo uma sprint, caso contrário ela será um épico. O grande desafio obviamente é o equilíbrio entre histórias pequenas o suficiente para que seja possível estimar, mas não tão pequenas que não entreguem valor algum para o cliente. Na verdade esse é o desafio de todo o INVEST, conciliar todas as características desejáveis em uma história. Via de regra, uma história não deveria levar mais do que alguns dias de um par de programadores trabalhando nela, se está levando mais de uma semana é uma dica de que deveríamos pensar em quebrá-la.

Testável indica que toda história deve poder ser coberta de testes para validar se seus requisitos funcionais e não-funcionais foram atendidos, geralmente abordados nos critérios de aceitação da história. Uma história que não podemos testar para garantir seu funcionamento não é uma boa história, pois ou não está Independente ou é pequena demais e não entrega valor algum.

Livro para Agile Coaches
Livro para Agile Coaches

Tarefas SMART

E para terminar, o acrônimo SMART é o mais famoso dentro e fora da computação uma vez que é usado para definir muito mais do que tarefas de qualidade, mas boas métricas, bons objetivos e por aí vai. Isso porque SMART é um acrônimo para Specific (Específica), Mensurável, Alcançável, Relevante e Temporal.

Specific (Específica) indica que toda tarefa deve ter uma responsabilidade única, ser coesa com seu objetivo e entregar apenas uma parte de uma história de usuário. Para quem é programador, é o mesmo que aplicar o princípio SRP (Single Responsibility Principle) do SOLID para tarefas. Ser específica ajuda a história ser Alcançável, Mensurável e Temporal, além de garantir o entendimento de todos no time.

Mensurável é uma característica desejável para apoiar o planejamento da sprint. Se eu não tenho como medir uma tarefa, como sei se entregaremos ela a tempo? Aqui não importa a unidade de medida, embora o ágil encoraje muito mais o uso de pontos do que de horas, desde que a unidade faça sentido para todos no time e gere informação valiosa para o time e para a empresa.

Alcançável é um requisito básico para toda tarefa. O time tem que ter as competências e recursos necessários para conseguir entregar a tarefa. Simplesmente não adianta definir como prioridade uma tarefa que ninguém sabe fazer ou que vai levar tanto tempo que ela por si só deveria ser uma história ou épico. Definir tarefas inalcançáveis para o time é o primeiro passo para perder o time, até mesmo por isso que geralmente a atividade de quebra de histórias em tarefas e feitas pelo Dev Team e não pelo PO.

Relevante tem a ver com o valor que esta tarefa agrega ao todo da história. Se a tarefa não agrega em nada, ou seja, é irrelevante para a história, ela não deveria ser feita. Tarefas são quebradas para ajudar os desenvolvedores a organizarem seu trabalho, mas cada uma deveria poder ser explicada em como contribui para a história principal.

Temporal quer dizer que toda tarefa tem um tempo para ser realizada, ela tem de estar delimitada a uma timebox específica, previamente combinada entre os membros do time e utilizada para ajudar na priorização e planejamento da sprint.

Claro, nenhum desses acrônimos é bala de prata e usar todos eles juntos, todos os dias, é um desafio imenso. Mas não desista, é justamente esta busca pela perfeição no trabalho com backlog, histórias e tarefas que cria maturidade em times ágeis.

E você, conhece algum outro acrônimo que eu não citei aqui? Deixe nos comentários!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis