Um dos fatores mais importantes que qualquer método ou framework ágil tenta alcançar, é a entrega de valor para o cliente mais rapidamente. Ou seja, quando usamos Scrum, no final da sprint temos um incremento do produto que já pode ser testado em produção. No caso do Kanban, temos o fluxo contínuo de entregas, onde dependendo do lead time da equipe, pode ser de horas, ou até mesmo, dias. Mas, para conseguirmos fazer isso com mais sucesso, devemos encontrar a fatia perfeita das features.
Rafael Sabbagh, em seu livro Scrum – Gestão Ágil para Projetos de Sucesso, fala uma frase que gosto bastante:
Simplicidade – A arte de maximizar a quantidade de trabalho não feito.
Quando pensamos em algo simples, automaticamente começamos a pensar em algo “fácil” e passamos a identificar apenas o que é necessário para alcançarmos algum objetivo. Sem perceber, partimos para o princípio de lean que essa frase nos remete: a redução do desperdício.
Trazendo esse pensamento para o contexto de desenvolvimento de software, nota-se o quão difícil é para aplicarmos logo de cara. A ideia de entregar algo que seja perfeito é tentadora, mas ela acaba tornando-se uma grande vilã. Cabe a nós estarmos sempre questionando:
Até aqui, resolve o problema do nosso usuário?
Lembre-se, a evolução de um produto ocorre de forma iterativa e incremental. Atuando como Scrum Master, devemos auxiliar o Product Owner (PO) e o time de desenvolvimento em enxergar a forma mais simples para conseguirmos entregar um incremento, prezando sempre pela qualidade do trabalho. Para isso, costumo utilizar alguns pontos:
Entender o problema.
É de extrema importância que todos tenham conhecimento do problema que estamos querendo resolver. Para isso, a comunicação é essencial e, como todos sabemos, a forma mais efetiva para isso acontecer é cara a cara.
Construir a solução juntos.
Durante o refinamento do backlog, gosto de iniciar a discussão com o problema a ser resolvido. Para mim, o principal objetivo aqui é do time construir uma solução em conjunto com o PO e, se possível, com stakeholders e usuários. Outra coisa que gosto de fazer durante o refinamento é a prototipação colaborativa. Isso ajuda muito a alinhar as expectativas de todos.
Ei, PO!! Utilize essa cerimônia para demonstrar como esse problema impacta no negócio.
Negociação com o PO.
Com a solução em mãos, começo o processo de negociação entre o time de desenvolvimento e o PO através do fatiamento da feature. Por exemplo, vamos considerar que nossa user story é “como um usuário XPTO, gostaria de logar no sistema para realizar a compra dos produtos da loja”.
![Exemplo de Login](http://agile.pub/wp-content/uploads/2017/08/login-example-1.jpg)
Exemplo de Login
Com o esboço em mãos, pergunto ao PO qual é o mínimo aceitável por ele. Daí para frente, é só comunicação e alinhamento de expectativas. O resultado desse processo, em geral, é a transformação de um épico em três a cinco histórias.
Por exemplo, no cenário acima, temos:
- história 1: Fazer login pelo Facebook;
- história 2: Fazer login pelo Twitter;
- história 3: Fazer login pelo Google;
- história 4: Fazer login pelo próprio sistema;
Depois de todas essas etapas, essas histórias entram no nosso backlog a espera do planning.
Percebam que ao termos histórias pequenas, ganhamos velocidade. Ou seja, menos linha de código para desenvolver, consequentemente menos itens para testar, menos tempo de code review, mais tempo para refatorar e melhorar a qualidade do que está sendo feito, etc..
Outro ponto que ressalto é que gosto de trabalhar com timebox curtos (no máximo uma semana). Caso comecemos na segunda, temos que ter uma entrega na sexta. Isso ajuda muito a cadenciar o time e criar ritmo.
Portanto, o valor em histórias pequenas é muito maior do que desenvolver uma funcionalidade completa e ter atrasos na entrega. Porém, isso pode ser uma faca de dois gumes, pois pode ocorrer de entregar algo sem nenhum valor para o cliente caso o problema não esteja bem entendido.
Para combater isso, é essencial que os problemas de negócio estejam muito claro para todos e, a partir daí, devemos começar a pensar em soluções. Uma solução emergente do time resulta no engajamento em dar vida para aquilo. Sem contar também que a comunicação entre Time e PO deve ser franca e transparente.
No exemplo que eu mostrei, caso o login do Facebook já alcançasse o valor de negócio previsto, as outras histórias referentes à ela são, naturalmente, re-priorizadas.
Essa é a forma que tenho feito para ir atrás da fatia perfeita. E vocês?
Grande abraço,
Olá Diogo, tudo bem!
Muito legal seu texto, o trabalho de fatiar é sem dúvidas o mais difícil para o PO ou BA. Achei bem bacana você compartilhar que como SM ajuda bastante nessa etapa.
Um ponto que tenho percebido que acaba dificultando o desenvolvimento por Fatias pequenas é a baixa experiência dos desenvolvedores em trabalhar de forma incremental, pois ele teimam em querer desenvolver tudo de uma única vez.
Você já passou por essa situação?
Opa.. td bem, Vladson?
Ja passei sim por situações como essa. O que pude perceber, geralmente é:
1- Falta de definição do pronto: o conceito de pronto pra cada membro do time pode estar desalinhado.. ou seja, é preciso estar explícito para todos o que de fato é o pronto.
2- Falta de criterios de aceitacao da feature:
EX.: História 1 – Login pelo facebook:
Essa história estará pronta para ir pra produção quando:
– O usuário clicar no icone do facebook e logar no sistema;
– etc, etc…
3 – Timebox da sprint muito grande:
No meu caso (sprints de 1 semana), procuro estar sempre perguntando pro time: “Conseguimos entregar isso na sexta-feira?” Caso o time fala que dê para entregar, então vamos planejar a entrega dessa feature. Se fracassar, temos as retrospectivas para ir melhorando o time. Outra tática interessante é definir tamanhos máximos de esforço para história.. se a história passar de 5 pontos, é preciso fatiar mais (Esse acordo é construindo em conjunto no inicio do projeto, sendo revisto a cada entrega)…
4 – Tamanho do WIP: talvez a quantidade de working in progress de vcs esteja alta e seja preciso limitar fazendo com que o time pare de paralelizar as historias em desenvolvimento.
Lembrando que nao existe bala de prata, cada cenario eh diferente.
Diogo concordo com as situações que você citou, mas estava falando de experiência técnica mesmo. Do desenvolvedor estar preparando e com o conhecimento para perceber o ganho que existe em evoluir a solução a medida que recebe o feedback.
Vladson, acredito que é uma dificuldade natural, como desenvolvera atuava para simplesmente codar. Mas quando estamos codificando para alguém e resolver os problemas desse alguém temos que ter um noção que nem sempre acertamos. E o feedback é uma maneira simples para sabermos se estarmos indo na direção certa para resolver o problema. Com essa aprendizagem tem a questão de retrabalhar o código, e isso para quem ama o seu código é dolorido. (Já sofri da síndrome do meu código). Mas o código não é meu, é de todos, e o código deve evoluir, melhoria continua. É complicado trocar essa ideia com os devs às vezes, mas tem que perceber o valor de negócio. Tem outros cenários que não falei.
Mas podemos conversar via Slack.
Espero ter ajudado. Abraço