Escolha uma Página

Planejamento de Sprint: Como minimizar os riscos envolvidos?

Será que o meu time se compromete com a entrega de todos esses itens?

Essa é uma pergunta relativamente corriqueira em reuniões de planejamento de sprints. Frequentemente essa pergunta é respondida com um “acho que sim” ou um “vamos acompanhar e ver o que acontece”.

Pois é! No decorrer da sprint podemos confirmar que determinada quantidade de itens é adequada ou não para cada time.

Mas, como podemos melhorar esse processo?

Será que existe alguma maneira simples e prática de saber qual o risco envolvido quando assumimos os compromissos?


Nessa publicação iremos apresentar um método muito fácil e rápido para melhorar o planejamento das suas sprints.

Você terá uma visão sistemática sobre os compromissos assumidos pelo time, e poderá medir quantitativamente os riscos que os times estão sujeitos a enfrentar.

Se interessou? Então vamos lá…

A primeira coisa que você vai precisar é do histórico de itens entregues pelo seu time nas últimas sprints.

Quanto maior a quantidade de dados nesse momento, mais estruturado será seu planejamento e resultado.

Para começar, devemos montar uma lista conforme imagem abaixo.

Agora podemos ordenar os dados em ordem decrescente da coluna “número de itens”.

Até aqui, nada de outro mundo, certo?

Pois bem.

Agora crie um índice para cada uma das linhas, sendo que a primeira será a linha 1, a segunda a linha 2 e assim por diante.

Atenção agora. Pegue o total de linhas (no nosso exemplo são 13 sprints) e calcule 10% deste valor, e consecutivamente 25%, 50%, 75% e 90%.

Se o número foi quebrado, calcule o número inteiro que vem a seguir.

Agora, utilize os números obtidos como índice na consulta da sua tabela de dados.

Por exemplo, se ao calcular 50% seu valor foi 7, então você deve pegar a linha com índice 7.

Pronto. É só isso. Você acaba de descobrir que assumir um compromisso com 8 itens têm o mesmo risco que jogar cara ou coroa, ou seja, 50%. Você, seu time e o cliente estão confortáveis com esse risco? 

Se você gostaria de ter um pouco mais de segurança do que pode acontecer no planejamento da sprint, talvez queira assumir um risco menor, digamos de 25%.

Logo, vamos pegar o índice resultante do cálculo de 75%, que no caso da 10, e em seguida saberemos que assumir o compromisso com 7 itens têm um risco de 25%.

Assim dizendo, um risco muito menor, com apenas 1 item a menos.

OK! Mas fica uma dúvida:

Por que não calculamos a situação com 0% de risco?

Simples, porque ela nunca vai existir.

Toda vez que um time se compromete com alguma entrega, ele está assumindo que “no futuro” terá entregue X itens, por exemplo. Mas nunca conseguiremos ter certeza do futuro.

Quer dizer, não temos a possibilidade de saber, sem nenhuma margem de erro, todos os eventos que podem influenciar a entrega de um time.

Do ponto de vista de comunicação com o cliente, também estaremos muito mais embasados, pois não estamos só comunicando que “acreditamos ser possível”, mas estamos dizendo que “com base no histórico de entregas do time, o risco envolvido em se comprometer com X itens é de 25%”.

Assim, conseguimos uma comunicação muito mais clara, transparente e orientada a dados.

Fazer este cálculo é muito simples!

Ele ajuda o time a assumir os compromissos com muito mais segurança, nos ajuda a comunicar ao cliente os riscos envolvidos, e nos ajuda a determinar a velocidade de entrega de cada time.

O cálculo pode ser feito utilizando outras medições, por exemplo, a quantidade de Story Points entregues em cada sprint.

O método de cálculo é o mesmo e a interpretação dos resultados também.

É importante destacar que ter essa visão no momento de assumir o compromisso não dispensa o acompanhamento diário, via cerimônias, de cada entrega e a tomada de ações corretivas caso o time se desvie do planejamento.

Mas isso é assunto para um próximo post.


Essa publicação foi desenvolvida pelo Zappter Luciano Osório, Squad Leader aqui na Zappts.

💙 Quer aprender mais? Confira nossa publicação Scrum: entenda de uma vez por todas o que é, como ele aumenta expressivamente os seus resultados e porquê utilizá-lo.

Criando uma documentação para aplicações FrontEnd

Esta é uma republicação do post do blog do Vinnicius Gomes – Senior Frontend Engineer aqui da Zappts.

Nesse post vamos falar sobre como criar uma documentação para uma aplicação FrontEnd de forma simples e intuitiva.

Se você não gosta dos padrões antigos de documentação que nem eu, seus problemas acabaram! 🤩

Hoje vou te mostrar uma ferramenta que vem ganhando bastante espaço na comunidade e no mercado, que é ninguém menos que o Storybook, uma ferramenta Open Source que prepara um ambiente de desenvolvimento para componentes de UI.

Então bora para o que importa 🤓

Ah, antes de começar, eu vou utilizar o Storybook com o React, mas ele da suporte para vários outros frameworks e libs como 👇

Sem mais delongas, vamos para o código:

Vamos criar uma aplicação React utilizando o CRA, rodando o comando:

npx create-react-app my-app

Com o projeto criado, vamos fazer a instalação do Storybook, rodando o comando: npx sb init

Você pode acessar a documentação para saber mais sobre a instalação através desse link.

Depois que a instalação for concluída vai ser criado duas pastas no nosso projeto 👇

Uma pasta chamada .storybook e outra dentro de /src/stories, a pasta .storybook contém as configurações que não vamos abordar hoje, mas você pode ler mais sobre essas configurações na documentação, e também foi criado a pasta /src/stories que vai ser onde vamos escrever nossas histórias.

Vamos rodar o Storybook

Execute o comando npm run storybook e acesse http://localhost:6006 você vai ver uma tela como essa 👇

Isso quer dizer que nosso Storybook foi instalado e está rodando corretamente! 🤩

Agora vamos entender a interface do Storybook

No lado esquerdo da tela, temos a lista de stories. O Storybook criou alguns componentes de exemplo.

Clicando no componente de botão, vamos ver algo parecido com isso 👇

Onde é renderizado o componente, e na parte inferior temos um menu com algumas opções que podemos interagir com o componente e ver o seu funcionamento.

No menu superior temos uma opção Docs, clicando nela vai ser aberto a documentação do componente 👇


Agora vamos criar uma nova Stories

Para começar, fiz uma limpa na pasta stories deixando somente a introdução e os assets 👇

Vamos criar um simples componente de Alert, então pra isso vamos criar 3 arquivos 👇

Como o foco desse post não é criar um componente, vou pular essa parte, o código do componente está disponível nesse repositório.

Nosso componente de Alert ficou assim 👇

Agora vamos criar a Storie, para isso crie um arquivo Alert.stories.js 👇

Calma, sei que tem bastante coisa ai, mas vou te explicar as partes importantes!

Linha 6–16: Aqui estamos criando a configuração default da nossa Storie, definindo um title, apontando o componente e definindo os args padrões. Na linha 10 estamos defindo que a props type vai ser exibida como um select na tela do Storybook recebendo um array de opções:

Linha 17: Estamos definindo nossa Story

Linha 19: Aqui estamos definindo as props para o componente Default, que vai receber um title e uma message

E o resultado vai ser esse 👇

E pronto, é simples assim 🎉

Vamos adicionar as outras variantes do nosso Alert 👇

A diferença aqui é que foi adicionado a props type dentro do args, automaticamente o Storybook vai listar todas as variantes do componente 👇

O arquivo Alert.stories.js final ficou assim 👇

// Alert.stories.js
import React from "react";

import Alert from "./Alert";

export default {
  title: "Alert",
  component: Alert,
  argTypes: {
    type: {
      control: "select",
      defaultValue: "default",
      options: ["default", "info", "success", "danger", "warning"],
    },
  },
};

export const Default = (args) => <Alert {...args} />;
Default.args = {
  title: "Alert example",
  message:
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer vestibulum neque est, at laoreet dolor bibendum eu.",
};

export const Info = (args) => <Alert {...args} />;
Info.args = {
  title: "Alert example",
  type: "info",
  message:
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer vestibulum neque est, at laoreet dolor bibendum eu.",
};

export const Success = (args) => <Alert {...args} />;
Success.args = {
  title: "Alert example",
  type: "success",
  message:
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer vestibulum neque est, at laoreet dolor bibendum eu.",
};

export const Danger = (args) => <Alert {...args} />;
Danger.args = {
  title: "Alert example",
  type: "danger",
  message:
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer vestibulum neque est, at laoreet dolor bibendum eu.",
};

export const Warning = (args) => <Alert {...args} />;
Warning.args = {
  title: "Alert example",
  type: "warning",
  message:
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer vestibulum neque est, at laoreet dolor bibendum eu.",
};

E pronto, criamos nossa primeira Storie, simples né?! 😎

Caso você queira rodar a aplicação na sua maquina, você pode acessar o repositório nesse link.

Scrum x Kanban. E o vencedor é…

Qual estrutura de processos implementar em um projeto? Leia o artigo e entenda mais sobre as metodologias Scrum e Kanban!

Por Luciano Osorio – Scrum Master da Zappts

scrum kanban

Recentemente, um cliente estava considerando seriamente adotar a metodologia Scrum, mas de uma forma bastante particular.

As prioridades mudariam o tempo todo, o time estaria parcialmente alocado com pessoas compartilhadas entre vários projetos e as sprints deveriam ter uma semana de duração.  

Ele me pediu para ajudar a fazer esse modelo funcionar.

De acordo com o cenário exposto, recomendei o método Kanban como sendo o mais adequado, porém, a sugestão não foi aceita de início. Então, continuei estudando as melhores possibilidades.

Um dos problemas enfrentados nos projetos deste cliente era a falta de visibilidade sobre quanto trabalho realmente estava sendo realizado e como ele poderia melhorar a execução dos processos.

Mantive a recomendação e sugeri testarmos o Kanban por algumas semanas.

Agora, você pode estar se perguntando: mas qual o motivo da insistência em relação ao Kanban?

Bem, vou explicar o porquê dessa recomendação e aproveitar para esclarecer sobre as principais diferenças entre Scrum e Kanban.

Continue a leitura para descobrir!

Scrum x Kanban: A diferença está no compromisso e no foco

Vamos começar entendendo a diferença entre Scrum e Kanban e quais critérios avaliar para uma escolha assertiva e eficaz.

Scrum

No Scrum, o time se compromete com o produto. Toda sprint tem um objetivo para ser cumprido, que leva o time um passo à frente na entrega do valor do produto.

O time estima o trabalho que será incluído numa sprint e se compromete em realizar aquele trabalho com a maior qualidade possível. Sem interrupções ou mudanças de prioridade.  

O foco no objetivo da sprint é a principal temática das reuniões diárias do time. Elas devem ser realizadas com os propósitos de identificar problemas que impedem o alcance do objetivo e propor soluções removê-los dos processos.  

Ao final de uma sprint, aquele trabalho com o qual o time se comprometeu é avaliado e aceito como incremento de valor ao produto.

O time segue com uma avaliação de como o trabalho foi realizado durante a sprint e planeja as ações para trabalhar melhor na próxima.

Para entender mais sobre o que é Scrum, indico a leitura deste artigo, disponível em nosso blog.

É um conteúdo bem completo e com boas referências para se aprofundar no assunto 😉

Kanban

No Kanban, o time se compromete com o fluxo, ou seja, com o ritmo em que o trabalho realizado passa pelos passos do processo.

É necessário identificar os fatores que influenciam o fluxo e trabalhar para melhorá-lo sempre. Assim, é possível garantir que o trabalho não fique represado enquanto aguarda por algum passo.  

É preciso entender o passo mais lento e alinhar o ritmo para que ele ocorra de maneira fluida, sem acúmulos.

Além disso, no Kanban os membros do time executam um trabalho de cada vez. Esse foco ajuda a melhorar muito a qualidade do trabalho realizado.  

Aqui, mudanças de prioridade podem ocorrer livremente, pois ao selecionar o próximo trabalho, cada membro do time sempre escolherá o que é mais prioritário em um dado momento.

E para o time? O que é melhor: Scrum ou Kanban?

A resposta vai depender do contexto.

Em ambos os casos (Scrum e Kanban), times multidisciplinares executam o trabalho.

A relação entre os membros dos times seguindo os valores ágeis é fundamental em ambos os casos, além de uma liderança que deixe claro o propósito que eles devem perseguir, motivando-os a entregar o seu melhor sempre.

No caso do Scrum, a estrutura do framework com time-boxes cria a noção de começo, meio e fim a cada sprint, o que produz a sensação de atingir um objetivo.

Já no Kanban, o fluxo é contínuo e por não haver time-boxes, cada melhoria de fluxo conquistada pelo time deve ser celebrada, mantendo o foco na melhoria contínua.

Foco na coisa certa, ter objetivos claramente traçados e alinhados aos valores do time é sempre o melhor, e isso pode ser atingido com Scrum e Kanban.

Mas e o controle?

Em ambos os modelos há controle.

Métricas específicas, como Sprint Burndown mostram o avanço dos times Scrum ao objetivo diariamente e métricas como “velocidade” ajudam na previsibilidade das entregas.

No Kanban, o Diagrama de Fluxo Acumulado (Cumulative Flow Diagram), mostra claramente quais são os passos do processo que aumentam o Lead Time e que, portanto, necessitam atenção.

A métrica de Eficiência do Fluxo mostra a relação entre o tempo gasto em passos que estão trazendo valor e aqueles que não o fazem, mas que são necessários para o controle do processo, como inspeções, backlogs, etc.

Portanto, novamente, desde que com o foco adequado, Scrum e Kanban oferecem métricas que ajudam no controle e previsibilidade dos processos.

Scrum x Kanban: E o vencedor é…

Agora que já expliquei um pouco sobre as diferenças entre Scrum e Kanban e como avaliar a opção mais adequada, chegou o momento de responder à questão título deste artigo:

Scrum ou Kanban: qual o melhor?

Bom, como pudemos ver, não há vencedor neste “duelo”. O que há é uma necessidade de alinhar a escolha com o contexto, comprometendo-se com o que faz mais sentido.

Se estamos lidando com um time de produto, com um propósito definido, um escopo de projeto que evolui, mas de maneira ordenada e com prioridades definidas, o Scrum é recomendável e pode ajudar muito na realização dos objetivos do produto.

Por outro lado, se estamos lidando com um time que trata de uma demanda variável, com prioridades que mudam o tempo todo e problemas para conseguir completar o trabalho iniciado (o que se encaixa na situação do cliente que citei, lembra?), o Kanban ajudará na criação de um fluxo que tem um ritmo previsível.

Espero que essas informações possam te ajudar a entender Scrum e Kanban. São métodos aplicados para simplificar processos, ter mais flexibilidade no atendimento das demandas, e claro, melhorar o desempenho e integração da equipe de trabalho.

Abraço e até o próximo artigo!