Agilidade em escala corporativa – Parte 2

No post passado sobre agilidade em escala corporativa mencionei o famoso modelo do Spotify, também chamado de “Scaling Agile @ Spotify” ou simplesmente “modelo em squads”. Falei sobre os squads, os chapters, as tribes e as guilds. Isso tudo é o que a teoria de 2012 do Spotify nos diz sobre agilidade em escala corporativa e um possível passo número um para grandes corporações inovarem nos seus métodos ágeis para que os mesmos se adequem à realidade de dezenas de times operando Scrum ao mesmo tempo.

Mas será que de 2012 pra cá nada mudou em termos de agilidade para grandes empresas? Será que o próprio Spotify ainda organiza-se da exata maneira em que é citado no famoso vídeo?

Melhoria Contínua

Os três pilares do Scrum são bem claros: transparência, inspeção e adaptação. Estes dois últimos tratam exclusivamente de melhoria contínua. Qualquer time ágil que se preze deve continuamente revisitar seus processos para aprimorá-los e por isso não há como acreditar que há 5 anos o Spotify descobriu o Santo Graal dos métodos ágeis e jamais teve de modificá-lo. E de fato, isso não aconteceu, embora poucas pessoas falem disso.

Segundo Andy Park, um ex-Agile Coach do Spotify, entre 2012 e 2014 o modelo sofreu algumas mudanças que fazem todo sentido para mim, considerando desafios como os que enfrento em aplicar agilidade em escala corporativa no Banco Agiplan.

A primeira mudança é sobre a liderança das tribos. As tribos, para quem não se lembra, são a junção de diversas squads que possuam uma área de negócios/projetos em comum, no caso de um banco, temos a tribo de crédito, a tribo de canais, a tribo de integrações, etc. No modelo original, toda tribo deveria possuir um tribe leader, que responde pelo alinhamento e suporte às squads sob sua responsabilidade. No entanto, este modelo original de um tribe leader nos leva a um impasse em diversos casos: o líder deve ser alguém da área de negócios ou da área de tecnologia?

Algumas tribos são mais de tecnologia e outras mais de negócios. No entanto, dificilmente eles não dependem fortemente de ambas as áreas. Não obstante, muitas vezes o número de squads dentro de uma tribo é proibitivo para apenas um líder consiga exercer seu papel de facilitador com qualidade. E embora sempre possamos argumentar que podemos dividir uma tribo em duas, na prática isso acaba gerando problemas de alinhamento e é algo que queremos evitar.

Mas e se tivéssemos ao invés de um, mais de um tribe leader? Que tal dois, como um líder de negócios e outro de TI, por tribo. Desta forma, garantiríamos que ambas skills garantissem que as squads tenham todo o suporte e alinhamento necessários para seus POs e devs. Claro, dois é uma sugestão, e nem sempre ter mais de um será algo necessário. O que ficou claro é que o Spotify agora não restringe a liderança da tribo a apenas uma pessoa. Isso vai depender da necessidade individual de cada tribo.

Tribo com liderança dividida
Tribo com liderança dividida

A segunda mudança é sobre o alinhamento entre tribos. Uma coisa é implantar o modelo de squads em uma empresa como a Umbler que possui dezenas de funcionários e nem mesmo possui tribos (a startup inteira é apenas uma tribo com diversos produtos, um por squad). Outra coisa é manter o alinhamento entre diversas tribos em uma empresa com dezenas de funcionários apenas no setor de TI, fora a área de negócios que não faço nem ideia do tamanho que é.

Quando se tem várias tribos, é muito comum que deva existir um alinhamento estratégico entre os líderes de tribos, para que os mesmos consigam alinhar as suas squads. Quando temos poucas tribos, isso é simples de fazer, mas conforme a coisa cresce, a preocupação com o alinhamento se torna maior pois ele se torna ainda mais crítico. Para piorar, algumas tribos dependem fortemente de outras, criando um ponto crítico para que o todo funcione.

Entre essas tribos que dependem fortemente umas das outras, recomenda-se atualmente a criação de Alliances (alianças), que são o modelo ágil das superintendências de grandes corporações. Da mesma forma, as Alliances possuem seus líderes, que são responsáveis por manter os líderes das tribos da aliança alinhados, ao mesmo tempo que lhes fornecem os recursos necessários para que suas tribos prosperem, como orçamento, estratégias, etc.

Alianças
Alianças

Algumas tribos não precisam participar de alianças, não é exatamente uma questão de hierarquia. Havendo a necessidade (temporária ou não) de duas ou mais tribos terem um altíssimo alinhamento entre elas, forma-se a aliança e designa-se um ou mais líderes para a mesma.

Voltando às Origens da Agilidade

Você leu bastante a palavra alinhamento neste artigo, certo? Isso porque um alto alinhamento é a chave para termos times autônomos. E times autônomos são a chave para termos agilidade. Mas como obter um alto alinhamento sem o demônio do microgerenciamento invadir nossas empresas?

Uma das possíveis respostas para esta pergunta vem das origens da agilidade: a manufatura industrial japonesa, mais especificamente do famoso chão de fábrica da Toyota Motor Company onde surgiu o processo Lean que inspirou tantas metodologias ágeis incluindo o Scrum, o Lean Canvas (do Ash Mauryia) e o Lean Startup. Dentre tantos aspectos e literaturas a respeito do Toyota Lean, gostaria de destacar um método muito interessante que só fui descobrir recentemente que é o Toyota Kata, mais especificamente o Improvement Kata ou Kata de Melhoria na tradução.

Não quero me estender aqui sobre o Improvement Kata, até porque ainda é um estudo em andamento que estou fazendo e pretendo escrever sobre ele no futuro, mas gostaria de ressaltar o seu funcionamento básico como um incrível método para garantir o alinhamento estratégico e a melhoria contínua dentro das organizações, em especial as grandes, onde problemas de alinhamento são mais comuns.

Basicamente um kata, assim como nas artes marciais japonesas, é a repetição de um método até que ele se torne instintivo. Todo mundo já deve ter visto Karatê Kid, certo? Tanto o antigo do sr. Myagi quanto o mais recente com o Jackie Chan, ambos mostram o que é um kata de maneira bem simplificada com os exercícios repetitivos e monótonos que os meninos realizam para só então, quando a hora chegar, aquilo tudo virar instinto. O Improvement Kata em questão, é um processo repetitivo que apesar de manter o foco e alinhamento no que foi definido como a estratégia da empresa, não restringe a liberdade de execução dos projetos.

Não quero me estender demais para não estragar o conteúdo que estou estudando e deixando para um post exclusivo sobre o assunto. Basta dizer que o Kata é a cola que faltava para sincronizar as tribos, alianças, etc dentro de uma grande organização.

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

Atualizado em 13/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!

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