Scrum e Kanban não garantem, mas ajudam

Falar de agilidade é mais do que falar de métodos. O mais importante é a mentalidade. Veja o que diz os dois primeiros dos 12 princípios do manifesto ágil:

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

Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

Sem um método de desenvolvimento, dificilmente será possível satisfazer o cliente. Ao mesmo tempo, não será possível garantir entrega adiantada e contínua de software de valor com métodos muito engessados. Aí que entram as metodologias ágeis.

As metodologias não garantem que certa empresa tenha de fato uma mentalidade ágil, mas elas ajudam bastante a se chegar à agilidade.

Scrum

O Scrum é baseado em Sprints. Cada ciclo de trabalho dura um período fixo de tempo, geralmente de 2 semanas. No final de cada Sprint há a reunião de revisão, onde o entregável daquela Sprint é apresentado aos stackeholders.

O fato do Scrum gerar um entregável a cada ciclo, faz com que o produto possa ser testado logo no mercado, em vez de esperar até o final do projeto. Depois da Sprint, o backlog da próxima Sprint pode ser repriorizado. Desta forma, após o produto ser testado no mercado, é fácil pivotar se for preciso.

Kanban

O Kanban é um método criado para aumentar o foco de trabalho. O time puxa a tarefa do topo de uma lista de tarefas e executa cada etapa do processo de desenvolvimento. O número de tarefas que podem ser executadas ao mesmo tempo é limitada, desta forma é garantido que não haverão tarefas incompletas em excesso. O ideal é que as tarefas sejam de tamanho parecido, de forma a facilitar a previsibilidade das entregas.

O Kanban facilita o fluxo contínuo de tarefas, buscando remover rapidamente os impedimentos, sem iniciar tarefas novas. Um time que roda o Kanban tem maior facilidade de ter entregas constantes e frequentes. Fora isso, a lista de tarefas pode ser alterada a qualquer momento, facilitando a mudança de escopo.

Quero os dois

Scrum e Kanban são compatíveis, isto é, pode-se ter os dois simultaneamente. O primeiro foca mais nas cerimônias de equipe e na definição de entregável, enquanto o segundo foca mais no fluxo de trabalho e na melhoria de processos.

Pré-requisito

Tanto o Scrum quanto o Kanban precisam de um pré-requisito para funcionarem bem e serem verdadeiramente ágeis: autonomia. Mais um princípio ágil:

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

Times que tem liberdade para decidir como se organizar, como executar as tarefas e quando elas serão entregues, conseguem fazer um trabalho de maior qualidade. Desta forma, entregando software de valor. O coração da agilidade está na satisfação do cliente.

Fit for purpose – Você é adaptado ao seu ambiente?

Inspirado no livro Fit For Purpose, de David J Anderson e Alexei Zheglov

Assim como as espécies se adaptam ao meio ambiente ao longo do tempo, desse modo também funcionam os produtos e serviços. Aqueles que são bem adaptados produzem uma situação de ganha-ganha-ganha: clientes satisfeitos, funcionários felizes e bons resultados econômicos.

A tendência é que os produtos pouco adaptados percam mercado para os produtos mais adaptados. Assim como a natureza, sempre em mudança, estão os mercados. Portanto, para continuar adaptado é necessário mudança contínua.

Quem se adaptou muito bem ao seu ambiente foram os táxis de Londres. Apesar de não nascerem adaptados, com o tempo foram se ajustando até entrarem em sintonia com a cidade. Atualmente, os táxis tem o formato ideal para fazer curvas nas estreitas ruas da cidade, além de permitirem grande espaço para bagagens. O fato das bagagens irem junto aos passageiros economiza tempo, pois o motorista não precisa sair do carro para abrir mala, sendo assim possível fazer embarques e desembarques mais rápidos. Além disso tudo, é obrigatório passar por uma preparação de dois anos antes de ser taxista em Londres. Os motoristas conhecem muito bem a cidade e suas ruas e são muito orgulhosos de seu profissionalismo.

O Uber chegou em Londres, assim como em muitas cidades do mundo. Mas por lá o impacto nos taxistas não foi tão grande. Altamente adaptados ao seu ambiente, o táxi resistiu ao novo serviço que chegou para competir.

Para um produto ou serviço ser adaptado a seu ambiente, é preciso que seu design, implementação e entrega atendam aos seus propósitos. O táxi de Londres tem um bom design, por causa das características do carro; tem uma boa implementação, pois levam o cliente a seu destino com raros erros de percurso; e tem boa entrega, pois os motoristas se portam de maneira profissional e fazem do táxi um ambiente agradável. A falha de um desses fatores – design, implementação ou entrega – pode arruinar o sucesso do serviço.

O segredo para conseguir boa adaptação é conhecer o seu cliente. Só é possível saber se o design, implementação e entrega atendem ao seu propósito se este for bem conhecido. Esta é a chave para se manter adaptado.

Requisitos funcionais e não funcionais. Como você descreveria seus super poderes?

O Homem de Ferro é um herói que, através da sua engenhosa armadura, consegue incríveis feitos, como voar, atirar lasers, alterar voz e obter informações do ambiente através de realidade aumentada.

Na descrição acima, falei dos requisitos funcionais da armadura do Homem de Ferro. Ou seja, falei sobre o que a armadura faz ou não faz. Geralmente, quando pensamos em um produto, temos mais facilidade de listar os requisitos funcionais, pois é intuitivo pensar no que o produto faz ou não faz, ou então, no que ele tem ou não tem.

Entretanto, é indispensável se pensar também nos requisitos não funcionais. Estes são os que dizem como o produto exerce suas funções, ou até o quão bom ele o faz. Por exemplo, na armadura do Homem de Ferro: qual a velocidade que a armadura alcança durante o vôo? Qual a potência dos lasers atirados? Qual o tempo que a armadura demora para exibir informações importantes no visor?

Na construção de um produto, os requisitos funcionais ocupam boa parte do planejamento, pois dependendo da quantidade de requisitos, pode ser complexo planejar e acompanhar o andamento do desenvolvimento de todos eles. Uma boa abordagem é implementar a menor quantidade de requisitos que consiga suprir sua demanda. A partir desse momento, se começa a olhar mais de perto para os requisitos não funcionais.

É importante que os requisitos não funcionais estejam alinhados com as métricas de desempenho. Por exemplo: supondo que os inimigos do Homem de Ferro voem a 80 km/h, é importante que o herói consiga voar a pelo menos a mesma velocidade, para que não tenha desvantagem na luta. Para isso, é preciso ter a potência de seus propulsores a 500 kW.

Nesse contexto, além do requisito não funcional da potência do propulsor não poder ser esquecido quando o a armadura for projetada, é importante que ele vire uma métrica a ser acompanhada, para que o Homem de Ferro continue tendo vantagem sobre seus inimigos nas lutas.

Com o uso da armadura, vai ficando claro se tanto os requisitos funcionais quanto os não funcionais estão atendendo ao propósito principal: de vencer os inimigos. Desta forma, a energia pode ser direcionada para as melhorias que mais estão de acordo ao propósito principal.

Um erro comum é focar demais em métricas que não estão alinhadas ao propósito do produto. Por exemplo, o Homem de Ferro poderia se orgulhar muito da potência de seus propulsores, mas eles seriam um desperdício se não o ajudassem a de fato ter resultado contra seus inimigos.

Portanto, a dica para o Homem de Ferro e para os Product Owners é que se preocupem tanto com os requisitos funcionais quanto com os não funcionais. Além disso, foquem nos requisitos que estão alinhados ao propósito principal de seu produto.

Kanban

Pare de começar e comece a terminar

Quadro Kanban
Quadro Kanban

O movimento Lean, em português traduzido para enxuto, é a iniciativa baseada na redução do desperdício e no aumento do foco. A pioneira foi a Toyota, que conseguiu reduzir os altos custos de estocagem gerados pelo escasso espaço físico japonês. A abordagem foi simples, mas revolucionária: produzir um veículo do início ao fim continuamente, em vez de criar grandes quantidades de peças, para depois juntá-las.

O benefício disso não foi só a redução do espaço físico. Fazendo um produto de cada vez, é possível identificar defeitos mais rapidamente e evoluir o produto. Além disso, fica nítido quando existe algum gargalo na produção, incentivando a resolução dos problemas para removê-lo.

Ficou claro que os benefícios da mentalidade Lean não se aplicam somente à produção de veículos. Para a área de software, tudo isso se encaixa perfeitamente. Não é à toa que o Kanban, que vou falar mais à frente, é uma metodologia altamente popular no desenvolvimento de software.

O desenvolvimento de software tem uma característica universal: tudo volta. Tarefas geram bugs, que voltam para serem corrigidas. A alteração em uma parte do código pode gerar a necessidade de refatoração em outra parte. Muitas vezes, uma funcionalidade não atende completamente ao usuário e é necessário um ajuste. Enfim, é previsto que virão imprevistos.

Quando há grande quantidade de trabalho em aberto, ou seja, não terminada, cada pequena tarefa vai voltar de alguma forma. Com isso, o planejamento se torna extremamente complexo e o que acontece na maioria das vezes é que a empresa se enrola e os prazos não são cumpridos.

A mentalidade Lean resolve essa questão, pois são criados mecanismos para impedir que se abram frentes demais. É preciso terminar o que está em andamento antes de começar algo novo.

O Kanban é uma metodologia Lean, que tem como característica principal o uso do quadro Kanban e a limitação do work in progress (WIP).

O quadro, que pode ser físico ou digital, define a sequência de passos para que uma tarefa saia da primeira coluna – to do – e vá para a última coluna- done. O quadro deixa claro o fluxo e o andamento das tarefas, tanto para os desenvolvedores, quanto para o PO e até outros stackeholders.

O que faz com que o fluxo seja de fato Lean é a limitação do WIP. Todas as colunas intermediárias devem ter um limite de tarefas em aberto. Isso obriga o time a mover tarefas para a próxima etapa antes de pegar novas tarefas. Além de impedir que se tenha muitas tarefas em aberto, também há outra vantagem: quando há um gargalo a produção fica travada, incentivando ao time que ataque imediatamente o problema, em vez de postergá-lo.

Muitas vezes o Kanban é até definido como um método de evolução de processos, já que ele é ótimo para deixar claro quais são os problemas do seu fluxo de produção. Além disso, ele é genérico o suficiente para encaixar em diferentes contextos.

Independente da metodologia, seja mais Lean. Pare de começar e comece a terminar! =D

O que faz um PO?

PO é o Product Owner, ou seja, o dono do produto.

Antes de entender o que faz o dono do produto, é preciso entender o que é um produto.

Produto é algo que veio para resolver o problema de alguém. É o iPod que foi lançado quando você queria ouvir música sem ter que carregar caixas e caixas de CD; é o biscoito que mata aquela sua fominha da tarde; é o álbum de fotos do seu casamento, que vai ajudar a eternizar aquele momento.

Quando falamos de produto, na verdade estamos falando de pessoas. De enxergar o que poderia melhorar a vida de alguém e oferecer uma solução.

O dono do produto é aquele que entende o seu produto e seu cliente. É aquele que sabe traduzir a necessidade de alguém para algo concreto.

A palavra dono às vezes leva a uma falta de compreensão do que faz o PO. Afinal, no senso comum, dono é aquele que faz o que quer com aquilo que possui. Dono seria aquele que manda. Mas quando falamos de metodologias ágeis, a palavra dono significa outra coisa. Dono seria o decisor: aquele que diz o que o produto deve e não deve ter. Ele não diz como deve ser feito e nem quem exatamente vai fazer. Ele não é responsável pela produtividade da equipe ou pelo trabalho dos outros. O compromisso dele é com a eficácia: o produto está seguindo seu propósito e resolvendo a necessidade do cliente?

Falar do trabalho do PO é falar de empatia, design thinking, métricas relevantes, comunicação, conhecimento do negócio e do produto, teste de hipótese, escrita de histórias de usuário, priorização de tarefas e muito mais.

Nos próximos posts vou falar um pouco disso tudo, assim como, o que o PO deve saber e que habilidades deve ter. Até mais!