User Stories – Descrição de requisitos que humanos entendem

Atualizado em 30/01/2018!

Dentro da Engenharia de Software temos um sub-campo que é a Engenharia de Requisitos. A Engenharia de Requisitos é a “ciência” que estuda todas as formas de elicitar, analisar, validar, especificar e documentar requisitos, visando gerar insumos para a fase de projeto do software, coordenada por arquitetos de software ou analistas de sistemas, dependendo da empresa.

É nesta “fase de requisitos” que exploramos o quê, como e para quem iremos desenvolver as próximas funcionalidades do sistema. E no Scrum não é muito diferente disso, essa fase existe, embora distribuída em “pedaços”, no início de cada sprint, sendo executada durante a Sprint Planning.

Mas uma coisa que o Scrum não nos diz é: como organizar e/ou documentar as tarefas que devem ser realizadas a cada Sprint? Uma ideia é fazê-lo com User Stories ou Histórias do Usuário: um artefato ágil para especificar requisitos citado na metodologia ágil Extreme Programming (XP).

Histórias do Usuário

Vamos partir aqui de algumas premissas básicas: toda funcionalidade que vamos desenvolver vai impactar a vida de no mínimo uma pessoa. Se não impacta a vida de ninguém, não deveria existir. O impacto pode ser grande ou pequeno, desde um botão que vai economizar 15 minutos de tarefas repetitivas ou um formulário que vai atender a uma norma legal do governo que poderia fechar a empresa.

Então sempre começamos com um “quem”.

Toda user story, como o próprio nome sugere, começa com um usuário. Este usuário é o ator principal da história, uma persona que todos no time conhecem e entendem como pensa, como age, quais são as “dores”, etc. É importante mapear essas personas que serão utilizadas antes de escrever user stories com elas.

A descrição de uma persona, e isso não faz parte da user story em si, pode ser como abaixo (exemplo da Umbler):

“Luiz é um desenvolvedor e também um empreendedor. Ele cria diversos projetos usando tecnologias como ASP.NET e Node.js e gosta de publicá-los em ambientes confiáveis e com preços razoáveis. O Luiz ocasionalmente tem amigos que o ajudam nestes projetos e quase sempre bola maneiras de rentabilizar os projetos. O Luiz prefere fazer deploy via Git ao invés de FTP por ser mais rápido e confiável, além de gostar de pagar apenas pelos recursos que consome no servidor ao invés de um fixo mensal.”

Eu poderia continuar escrevendo sobre essa persona, mas acho que você já deve ter entendido a ideia.

Assim, quando uma user story começa com “Enquanto Luiz…”, todo o time, que já conhece aquela persona (os mesmos podem ser apresentados antes da leitura de cada história) e já entende as motivações dela, tornando mais fácil tomar decisões futuras. Sempre que o desenvolvedor que estiver implementando uma funcionalidade que é “para o Luiz” estiver em dúvida sobre algo, ele sempre deve se projetar (através de empatia, jovem gafanhoto!) e pensar “se eu fosse o Luiz, como eu gostaria que isso funcionasse?”.

Ponto de vista do usuário

Depois de definirmos para quem estamos desenvolvendo uma nova funcionalidade, devemos definir o que será desenvolvido.

Note que quem escreve as histórias do usuário é quem gerencia o produto: o Product Owner. Como alguém não-técnico e centrado no produto, cabe ao P.O. especificar “o quê” deve ser feito e “para quem”, mas não “o como”. A funcionalidade deve ser descrita a nível de usuário e a nível de negócio, jamais a nível de programação.

Um bom exemplo seria:

“Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus projetos web.”

Um mau exemplo seria:

“Enquanto Luiz, eu gostaria de ter um formulário em React para criação de banco MongoDB, com os campos nome do banco, usuário e senha, que quando preenchidos iniciassem uma tarefa de criação de instância no datacenter 03 da Umbler e me retornasse os dados de acesso por email quando estivesse pronto.”

Um dos “mandamentos” é que o time deve se auto-gerenciar, eles devem decidir como cada funcionalidade deve ser desenvolvida. O P.O. sabe que MongoDB é uma demanda do mercado e que devemos ter isso em nosso catálogo de produtos pois temos muitos “Luizes” como clientes, mas se isso deve ser implementado com React, se deve ser assíncrono, em qual datacenter vai ficar, etc é com a galera técnica.

Sendo assim, sua história de usuário deve ser:

  1. sem detalhes de implementação;
  2. focada no que o usuário quer fazer;
  3. explicada do ponto de vista do usuário;
  4. curta e objetiva;

A motivação

O último elemento de uma user story é a motivação. Por que o usuário quer essa funcionalidade? Para quê ela vai servir exatamente (do ponto de vista de ‘entrega de valor’)? O que isso vai impactar na vida dele?

Estas e outras perguntas devem ser respondidas na motivação, que é a terceira e última parte da user story.

Muitas vezes quando estamos desenvolvendo não entendemos porque estamos desenvolvendo aquela feature. E quando isso acontece, geralmente não tomamos as melhores decisões sobre dúvidas que temos. Esta listagem deve ter uma busca no topo ou uma paginação? Esta tarefa deve ser síncrona ou assíncrona? Essa informação será buscada com texto-livre ou através de opções fixas?

A motivação costuma deixar isso tudo muito mais claro e ajudar a criar features que realmente entregam valor ao usuário. Como no exemplo abaixo:

“Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus projetos web porque usando serviços de terceiros sai mais caro e a latência é alta.”

Aqui deixamos explícito que o usuário quer ‘MongoDB na Umbler’ porque isso seria mais barato e mais rápido para seus projetos web. Sendo assim, no momento da implementação desta funcionalidade (que confesso pode ser quebrada em tarefas menores, mas é apenas um exemplo), podemos inferir que nossa solução:

  1. não pode ser resolvida através de integrações (add-ons);
  2. tem de ter uma baixa latência (no mesmo datacenter que o projeto dele);
  3. deve ser cobrado na mesma moeda do país dele (as soluções atuais são em dólar);

Essa informação ajuda a nortear as decisões, bem como se aliarmos às informações da persona do Luiz, veremos que se ele gosta de Git, é provável que goste de fazer deploy do seu banco MongoDB via linha de comando também.

Alguns autores defendem que a motivação, o “por quê” da user story, é opcional. Embora eu entenda que em alguns casos até possa ser verdade, eu encorajo a você sempre tentar deixar isso o mais explícito possível, usando aquela “máxima” de “o óbvio sempre precisa ser dito”.

Critérios de Aceitação

Quando a User Story possui regras de negócio ou requisitos não-funcionais específicos, vale definir os critérios de aceitação da mesma. Basicamente os critérios de aceitação são um checklist de requisitos que esta história em particular deve atender para que a mesma possa ser dada como pronta (DONE) pelo Product Owner.

Usando a mesma história que vínhamos criando, podemos ter os seguintes critérios de aceitação:

  • a senha do banco MongoDB criada deve ter no mínimo 10 caracteres alfanuméricos;
  • a tela deve ser desenvolvida conforme layout criado pelo time de UX;
  • o nome do banco MongoDB criado pelo usuário não pode ser igual a outro já existente;

Se você estiver usando cards ou post its grandes para escrever suas user stories, você pode usar o verso do card para os critérios de aceitação. Caso contrário terá de documentá-los em outro local. Onde trabalho atualmente usamos o Visual Studio Online para Task Management, e nesta ferramenta temos um campo para Acceptance Criteria dentro do cadastro das User Stories. Outra hora vou escrever um post aqui ensinando a usar, é uma ferramenta bem bacana.

User Stories na prática

O jeito mais tradicional de usar user stories é usar o Product Backlog como insumo e escrevê-las em post its, uma por post it. Algumas equipes costumam imprimir cards já com o esqueleto da user story nele, para não esquecerem nenhuma das três informações centrais e até mesmo com outros campos como o número de pontos daquela tarefa, os critérios de aceitação, etc.

Segue um exemplo bem elaborado, que pode servir de inspiração:

User Story Card
User Story Card

Esses cards são muito práticos e podem facilmente ser combinados com técnicas como Kanban (incluindo com Trello), para organizá-los e Planning Poker, para estimá-los (Story Points). Uma ressalva aqui é quanto ao “tamanho” da história.

Algumas histórias ficam tão abrangentes que costumamos chamá-las de épicos. Devemos sempre quebrar épicos em histórias de maneiras que elas possam ser “digeridas” pelo time que vai implementá-la. Não existe uma regra clara que diferencia um épico de uma história, mas o bom senso ajuda bastante. Algumas dicas nesse sentido são:

  • se não cabe em uma sprint, é um épico;
  • se consigo quebrar em dois ou mais story cards, é um épico;
  • se no Planning Poker gerou muita divergência de pontuações é um épico;

E um último ponto digno de nota é: não subestime a utilidade de artefatos mais tradicionais da engenharia de requisitos. Vão ter projetos, em que um story card não vai ser o suficiente e você terá de ter um artefato de apoio como um mockup, um diagrama UML ou até um caso de uso.

Enquanto que para muitos times e projetos user stories se encaixam como uma luva, para outros, você precisará de técnicas complementares ou até substituir essa técnica por uma mais tradicional. Então fique atento, Scrum não é bala de prata!

A Anelise Gripp, uma famosa agilista tem uma apresentação de slides bem bacana que explica bem sobre User Stories também:

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

Tutorial app Android com Firebase – Realtime Database

Este artigo é uma continuação da série “Tutorial app Android com Firebase” onde ensino como utilizar todos os serviços oferecidos pela plataforma de Backend-as-a-service do Google. Hoje, vou falar do serviço mais famoso deles: o realtime database, que permitiu a muitos desenvolvedores de apps que não sabem criar APIs para fazer conexão com banco de dados externo, pudessem colocar seus apps em produção rapidamente.

Não apenas isso, como o próprio nome sugere, a realtime database do Firebase permite comunicação em tempo real com o banco de dados, incluindo uma arquitetura no melhor estilo dos padrões Observer e Pub-Sub. Além disso, permite salvamento offline com sincronização automática quando a conexão é reestabelecida.

Usarei como exemplo neste tutorial o app ForcaVendas que iniciamos no primeiro artigo desta série. No entanto, não se preocupe, ele apenas possui uma tela de login e uma MainActivity com um olá mundo. Sendo assim, você consegue fazer este tutorial sem ter feito os anteriores, desde que já saiba como programar para Android, é claro. Também existe a possibilidade de baixar os fontes do app através do formulário existente no final de cada post desta série.

#1 – Configurando o Realtime Database

Primeiramente, para configurar o database do Firebase para o seu app, vá no menu Tools > Firebase do Android Studio e clique na opção “Save and retrieve data” da seção Realtime Database.

Configurando o Firebase
Configurando o Firebase

Na seção seguinte que vai se abrir temos os passos de configuração propriamente ditos. O passo 1 é bem simples e exige que você se conecte ao Firebase primeiro.

Realtime Database
Realtime Database

O segundo passo adiciona as dependências para se trabalhar com Realtime Database no seu app e pedirá confirmação para instalar dependências e alterar alguns arquivos de configuração.

Feito isso, estamos prontos para usar nosso banco realtime!

#2 – Entendendo o Realtime Database

Como explicado no site oficial do Firebase Realtime Database:

O Firebase Realtime Database é um banco de dados hospedado na nuvem. Os dados são armazenados como JSON e sincronizados em tempo real com todos os clientes conectados.

Ou seja, você cria o seu banco na nuvem do Firebase e conecta seu app nele para enviar e receber objetos JSON em tempo real. Simples assim. As mudanças no banco são refletidas automaticamente para todos os dispositivos (e aplicações, pois você pode usar na web também) conectados, em tempo real (daí o nome). Isso lembra os documentos do MongoDB. O site oficial ainda diz que:

Todos os dados do Firebase Realtime Database são armazenados como objetos JSON. Pense no banco de dados como uma árvore JSON hospedada na nuvem. Ao contrário de um banco de dados SQL, não há tabelas nem registros. Quando você adiciona dados à árvore JSON, eles se tornam um node na estrutura JSON com uma chave associada.

Um recurso muito importante do Realtime Database é que combinando com o suporte de autenticação do Firebase você pode definir quem tem acesso a quais dados, garantindo a autorização dos mesmos. Existe uma opção de deixar o seu banco público, mas na maioria dos casos isso não é recomendado.

Como o Realtime Database é associado ao seu projeto Firebase, por padrão ele só permite o acesso aos dados por usuários autenticados, como mostra a imagem abaixo do Firebase Console.

Firebase Realtime Database Authentication
Firebase Realtime Database Authentication

Caso não tenha feito o tutorial de autenticação em Firebase, você pode opcionalmente deixar os dados públicos na mesma tela acima. De qualquer forma recomendo dar uma olhada no respectivo tutorial para entender o básico da plataforma Firebase, pois é lá onde explico isso.

Outro recurso interessantíssimo do Realtime Database é o suporte offline. Se seu app ficar sem Internet, os dados serão salvos localmente e depois sincronizados quando a conexão voltar.

Assim como no MongoDB, a modelagem de um banco no Realtime Database deve ser feita com cuidado, sempre tendo em mente como desejará consultar estes dados depois. Algumas dicas incluem:

  • não aninhe muitos níveis dentro dos seus objetos JSON. Apesar do Firebase suportar até 32 níveis, isso não é uma boa prática por tornar consultas muito pesadas e escritas muito arriscadas.
  • evite a normalização excessiva (espalhando demais os dados) e foque na consulta rápida, mesmo que isso exija duplicação de dados. Em bancos NoSQL, tamanho não é problema, desde que o dado esteja fácil de ler e baixar.

Vale salientar que dificilmente você terá custos enquanto estiver estudando como usar o Realtime Database, mas que dificilmente não terá considerando que para seu app ir para produção você irá querer recursos mais avançados como backup do seu banco, por exemplo, disponível apenas nos planos superiores.

#3 – Criando a tela de Cadastro

Mesmo que não tenha feito os outros tutoriais de Firebase aqui do blog, não tem problema. Você apenas precisar ter uma aplicação com o template padrão do Android Studio, aquele com a MainActivity contendo um “Hello World” e um floating button no canto inferior direito.

Nos tutoriais anteriores comentei que iria fazer um app de Força de Vendas para autônomos. A ideia é apenas registrar os pedidos, compras e dívidas, de uma maneira fácil de buscar depois, ajudando na organização do vendedor, que geralmente usa caderninhos para isso. Assim, essa MainActivity (a tela inicial) futuramente será a listagem de registros principal do app. Como não temos dados para serem listados ainda, vamos apenas programar o floating button dessa tela nos levar para uma tela de cadastro.

Essa alteração é bem simples, troque o ícone do floating button para algo que faça mais sentido do que o envelope tradicional usando o XML abaixo no activity_main.xml (dentro da pasta res/layout):

Note que alterei somente a propriedade srcCompat que determina o ícone, onde estou usando o ícone de sistema do botão de “+”, que representa bem uma adição.

Agora vamos criar a próxima Activity, de cadastro, do tipo Empty Activity com o nome de AddActivity, aproveitando que o Android Studio criará para nós o arquivo de layout activity_add.xml automaticamente. Mas o que irá ter nesta tela?

Pensando em um fluxo de uso bem simples, os registros deverão conter uma descrição, um valor, uma data e um tipo. O tipo pode ser Venda Paga, Venda Não Paga (fiado, bem comum entre vendedores autônomos) e Venda Futura (apenas tirou um pedido). Obviamente esta é apenas uma proposta, você pode criar algo mais elaborado se quiser.

Com isso em mente, edite seu activity_add.xml para que pareça com isso:

Tela de Cadastro
Tela de Cadastro

Caso você não faça ideia de como criar este layout, recomendo fazer o tutorial de Constraint Layout primeiro ou verificar as diversas lições presentes em meu livro. Se estiver na correria, apenas copie e cole o código XML abaixo no seu activity_add.xml:

Note que para o Spinner exibir corretamente os tipos eu tive de criar outro arquivo XML, desta um de valores (tipos.xml), na pasta res/values. Neste arquivo XML de strings, o qual eu reproduzo abaixo, apenas listo os textos dos valores possíveis, considerando aqui que eles são fixos (caso contrário eu deveria carregar do banco).

E para referenciar este XML no Spinner (o componente visual de seleção de tipo) você usa a propriedade entries, como abaixo (esse código já está contemplado no XML completo da página que mostrei antes):

Agora para conseguirmos chegar até esta página e ver se a tela ficou ok no simulador ou no seu device android físico, devemos programar a ação do floating button existente na MainActivity. Essa ação já vem programada no evento onCreate da Actvity por padrão, para apenas exibir uma mensagem, vamos trocar para realizar a troca de tela.

Com isso programado, já temos o suficiente para testar a nossa aplicação no simulador e ver se conseguimos chegar até a tela de cadastro. Se você veio fazendo este tutorial deste o início, terá de se autenticar como um usuário válido primeiro.

Após você testar e se certificar que este básico está funcionando, vamos fazer mais um ajuste pequeno, porém útil para facilitar a digitação.

Data Atual

O campo data deve vir com a data atual por padrão. Para fazer isso, no onCreate da AddActivity, adicione o seguinte código que pega a data atual e a coloca no campo com id txtData (eu defini esse id para o campo de data, talvez o seu seja diferente):

Quando você abrir a tela de cadastro, encontrará a data atual no respectivo campo. É uma coisa pequena, mas ajuda.

Como este post está ficando extenso, deixarei a parte de conexão com o banco para leitura e escrita para o próximo artigo que deve sair em breve. Aguarde!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Android clicando no banner abaixo pra aprender outras dicas incríveis!

Criando apps para empresas com Android

Agilidade em escala corporativa

Escalar o Scrum é uma tarefa extremamente complicada. Quando comecei a trabalhar com Scrum em 2010, era minha responsabilidade aplicar a metodologia em apenas um time que era crítico para a empresa. E deu super certo. De lá para cá a complexidade foi aumentando e desde minha passagem pela Umbler que a necessidade de escalar o Scrum e os problemas que isso traz se tornaram evidentes.

Atualmente no Banco Agiplan, uma corporação com centenas de funcionários apenas na sede em Porto Alegre (e milhares em todo Brasil), aplicar agilidade em escala é não apenas um grande desafio, mas uma necessidade se quisermos sair na frente da concorrência. Uma questão de sobrevivência.

Uma das maneiras mais conhecidas de escalar agilidade é o modelo proposto pelo Spotify em 2012, popularmente conhecido como “modelo em squads” e ele será o tema do artigo de hoje, caso ainda não conheça. O modelo completo e toda a cultura de engenharia do Spotify pode ser entendida no clássico vídeo abaixo (em Inglês):

Scrum é apenas o começo

O primeiro ponto a se entender, antes de partir para conceitos mais avançados, é que Scrum é apenas o começo. Isso assusta bastante no início e conheço vários agilistas que torcem o nariz quando ouvem isso. Como bem o Scrum Guide explica, o Scrum é cheio de lacunas e a maior de todas elas é a integração entre diferentes times trabalhando em um mesmo épico. Não é à toa que um dos criadores do Scrum, Ken Schwaber escreveu o Nexus, que é um exoesqueleto para o Scrum e outra alternativa para o modelo do Spotify.

Toda empresa que quer começar a praticar o gerenciamento ágil de projetos deve começar com Scrum na minha opinião, mas não deve permanecer nele (ou apenas nele) por muito tempo. Os próprios pilares de inspeção e adaptação conduzirão o time a algo maior que o próprio Scrum, e é assim que começa a história do Spotify de reestruturação do seu framework ágil.

Primeiramente, assim como já disse aqui no blog em outra ocasião, o que mais importa são os princípios da agilidade, mais do que qualquer framework. Embora exista o que é certo e errado perante o Scrum, não há as mesmas regras quando o assunto é o que funciona ou não na sua empresa.

Princípios acima de Processos

Queria começar estabelecendo alguns princípios que estão acima de qualquer processo ágil. Muitas vezes queremos copiar métodos de outras empresas sem percorrer o caminho que levou até aquelas conclusões. Essa busca por uma receita mágica de agilidade costuma levar a implementações flácidas e mecânicas baseadas em Scrum.

Mas agilidade não é Scrum.

Por trás do manifesto ágil, temos alguns princípios que são extremamente válidos de apontar para uma reflexão. São como mantras do gerenciamento ágil de projetos:

“Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de valor”.

Parece o propósito da Agiplan, mas não é. Este é o princípio mais importante dos métodos ágeis. Quando implantamos agilidade em uma empresa é porque queremos priorizar a satisfação do cliente. Ser ágil não é entregar mais software mais rápido, porque ninguém quer software, os clientes querem soluções.

“Aceitar mudanças de requisitos…para que o cliente possa tirar vantagens competitivas.”

Novamente, foco no cliente. Tenho lutado diariamente para criar uma cultura na equipe de canais digitais que promova a colaboração para construção de produtos ao invés de simplesmente entregar projetos. A diferença pode parecer sutil, mas não é.

“…negócios e desenvolvedores devem trabalhar em conjunto…”

Colaboração. Minha maior surpresa quando entrei na Agiplan foi descobrir que o time de produtos é um e o time de desenvolvimento é outro. Construí minha carreira trabalhando com startups e nesse tipo de empresa, quem faz o produto é o time de produto. Não apenas quem especifica ele em um documento, mas estamos trabalhando nisso.

“…indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão o seu trabalho.”

Ambiente, suporte e confiança. Aqui entram os líderes ágeis. Não importa o título que está no seu cartão de visita, se você não é a pessoa que está na linha de frente do projeto, você é a pessoa que deve garantir o ambiente, dar o suporte e confiar que o trabalho será bem feito.

E por fim

“As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.”

E eis que entramos em um ponto crucial, talvez o coração da agilidade: os times.

Times Ágeis em Escala

Na Agiplan estamos trabalhando para montar uma estrutura mais moderna de times ágeis, organizada em squads. Um squad é um grupo de até 8 profissionais multi-funcionais que possuem um objetivo em comum, como entregar o app de cartão múltiplo, ou fazer a arquitetura da nova abertura de contas. Para cumprir sua missão, eles devem ter autonomia para tomar decisões, ter todos os membros necessários com as habilidades necessárias e apoio dos seus líderes.

Times Ágeis em Escala
Times Ágeis em Escala

Toda squad deve ter no mínimo um Product Owner, que é o responsável da área de negócios que baliza o que está sendo feito naquela squad. Também deve ter um Scrum Master ou Agile Coach responsável por ajudar o time a melhorar sua eficiência, geralmente estes profissionais são compartilhados entre alguns squads dentro de uma mesma tribo, como Canais Digitais, por exemplo, onde temos os squads de Contas e Cartões, como já citado e que necessita de um líder da tribo que esteja olhando para os diferentes projetos.

Transversalmente aos squads, temos os chapters, que seriam os setores tradicionais como infra, mobile, web e UX. Estes setores ainda existem para garantir a evolução técnica do todo, compartilhamento de conhecimento da área, etc. Responsáveis pelos chapters geralmente são os líderes técnicos de cada área.

E transversalmente às tribos, temos as guilds ou comunidades, que são menos setorizadas que os chapters mas possuem objetivo semelhante e mais amplo (como garantir a cultura ágil em toda empresa ou a comunidade de estratégia corporativa). Um bom exemplo é o trabalho que o nosso Arquiteto Líder, Rubens Veronez, realiza de arquitetura de software nas diversas tribos da Agiplan.

Vantagens e diferenças do Modelo

Times autônomos, experientes e multifuncionais ganham copas. Possuem sentimento de dono, são mais motivados e geram inovação.

Times sem autonomia, que apenas seguem ordens, apenas fazem mais do mesmo. E se as empresas modernas quisessem apenas mais do mesmo, eu não estaria aqui hoje escrevendo sobre agilidade.

Os papéis não mudam muito em relação ao Scrum tradicional, apenas jogam um pouco mais de luz em áreas pouco explanadas. A evolução do conceito de Scrum Master para Agile Coach surgiu mais como uma necessidade de descolar este papel do framework Scrum em si, e mais tarde também trouxe uma conotação mais forte de coach e mentor agilista da organização. Os conceitos de agilidade são simples, difícil mesmo é ter a disciplina de aplicar diariamente.

O mesmo vale para as cerimônias, que temos as mesmas do Scrum com pequenas variações. A Sprint Review na Agiplan, por exemplo, que temos chamado de Demo Friday, mesmo quando ela não acontece nas sextas, está se tornando não apenas uma review, mas uma celebração das conquistas das equipes na última sprint, visando aumentar a motivação, o engajamento e aumentando a responsabilidade com a entrega, que é pública.

Sprint Review Agiplan
Sprint Review Agiplan

O restante segue como deve ser, com ênfase na Sprint Planning onde o time decide como que as tarefas serão realizadas e quanto tempo irá levar, desde que de acordo com a prioridade estabelecida pelo PO.

A cereja do bolo da agilidade, e talvez o maior desafio em termos de tecnologia para a Agiplan e diversas outras empresas é aplicar DevOps. DevOps tal qual definida pelos métodos ágeis nos levará a uma velocidade na entrega do valor sem precedentes, com o modelo self-service de deploy fortemente apoiada em contâiners e clusters.

Eu não sou a pessoa mais indicada para falar de DevOps para vocês mas presenciei isso acontecendo na última startup que trabalhei (Umbler) e é fenomenal.

Precisa-se de líderes

Nada disso pára em pé sem bons líderes que apoiem a causa. As squads precisam de suas missões e precisam de um ritmo. As squads mais competentes ainda precisarão de alinhamentos de quem tem uma visão mais ampla seja da tribo, do chapter ou da empresa inteira.

Somente um alto alinhamento permite que os times tenham autonomia sem isso aqui virar um caos completo. Mas para isso precisamos de confiança. Se hoje tem alguém no seu time que você não confia para dar autonomia, existe uma chance de você ter contratado a pessoa errada ou ela ainda não está pronta. De qualquer forma, você e somente você é o responsável por resolver isso.

Para encerrar, uma frase que eu gosto bastante do Mario Andretti, campeão mundial de fórmula um (e outras categorias do automobilismo) que diz o seguinte: se tudo parece sob controle, é porque você não está indo rápido o suficiente.

Na Agiplan obtivemos o apoio do presidente e do diretor de TI para fazer uma revolução completa na estrutura de pessoas e processos para torná-la mais ágil. Tem sido um trabalho árduo mas muito gratificante e já estamos colhendo alguns frutos como metas importantes sendo alcançadas, engajamento maior nos times, etc. Mas estamos apenas começando.

Quer continuar lendo sobre Agilidade em Escala Corporativa? Leia a segunda parte deste artigo.

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.