fbpx

Pare de medir a produtividade de seu desenvolvedor

Ao longo da história o que não faltaram foram iniciativas – fracassadas – para medir a produtividade de desenvolvedores.

Quantidade de linhas de código, pontos por função e os mais recentes Story Points são algumas das tentativas de mensurar a produtividade de um programador.

A questão é que a atividade de desenvolvimento de software é muito complexa e medi-lá pode trazer problemas para sua organização, tanto para você quanto para o seu time de desenvolvimento.

Esses problemas são alguns dos maiores fatores de turnover por parte de programadores, segundo eles, uma gestão que não conhece de fato as minúcias do desenvolvimento de software acaba gerando um desconforto para ambos os lados, pois o gerenciamento é feito como se fosse uma atividade operacional e muito focada no imediatismo.

E é exatamente por isso que resolvi criar esse post, aqui vou tentar dar algumas dicas para melhor avaliar o trabalho de um desenvolvedor sem ter que recorrer a medição de produtividade ou comparação com outras pessoas.

Vamos lá?

Escrever mais código não significa ser mais produtivo

Um dos maiores erros dos gestores no mundo de tecnologia é achar que quanto mais códigos um desenvolvedor escreve mais produtivo ele é.

Como ja sabemos, quantidade de linhas de código não tem relação nenhuma com produtividade, pois um código com menos linhas pode ser tão ou mais eficaz que um código com mais linhas.

Além de que códigos não podem ser comparados, pois cada pessoa pode ter uma linha de raciocínio diferente.

Um bom exemplo de um “código ruim” com muitas linhas.

Mais horas de trabalho não traz mais produtividade

Outro grande erro de muitas empresas, acreditar que a quantidade de tempo que uma pessoa passa na frente de um computador trabalhando tem relação com a sua produtividade.

Quantas vezes você ficou travado por horas em um problema, e quando foi tomar uma água ou foi ao banheiro voltou com uma solução?

Esse tipo de situação é comum na vida de um programador. Pois a natureza do nosso trabalho é criativa e não operacional.

Dessa maneira, medir a produtividade do desenvolvedor por horas trabalhadas pode trazer mais problemas do que resultados positivos.

Cuidado com a falsa sensação de velocidade

Medir a velocidade de um time pode parecer uma maneira de medir a produtividade de um time, afinal, se ele está indo mais rápido, significa que está sendo mais produtivo, correto?

Não. Já citamos diversas vezes aqui nesse blog, o problema da falsa sensação de velocidade. Essa, que pode ser criada por uma falta de qualidade no código, ou por alguma ocasionalidade da entrega, como mal entendimento de um requisito.

Essa sensação só vai piorar as entregas do seu time no médio e longo prazo, então tome muito cuidado com ela.

Então como medir a produtividade de um desenvolvedor?

Não meça. Pare de medir produtividade individual, mais importante que isso são as métricas do seu negócio e do seu time.

No âmbito de negócio, meça a qualidade das entregas, assertividade de resolução de problemas e frequência de lançamento.

No de time, existem ótimas métricas ágeis para visualizar como o seu time esta se desempenhado, porém, é importante lembrar que essas métricas são para ter mais previsibilidade e assertividade nas entregas, não para medir produtividade.

Dê mais liberdade para o seu time, e acompanhe os resultados.

Quando você da a direção certa para pessoas boas, o time obtém sucesso. E naturalmente os que não estão se esforçando ou que não tem interesse são expurgados do time.

Para finalizar, termino com um pensamento que me marcou muito do livro A Startup Enxuta do Eric Ries:

As empresas estão mais preocupadas se o seu software vai sair no prazo e custo esperado, que se esquecem do que realmente mais importa, se aquilo resolve de fato, algum problema.

Qualquer dúvida, deixe aqui nos comentários que respondemos o mais rápido possível! 🙂

Kanban X Scrum: qual devo utilizar no meu projeto?

Kanban X Scrum, qual o melhor para o meu projeto?

Se você gosta de gestão ágil, com certeza já caiu nessa questão. Mas afinal de contas, qual devo usar para gerenciar meu projeto? E qual deles vai se adequar melhor a realidade da minha equipe?

Bom, nesse artigo vamos ver algumas comparações entre os dois, para entender melhor as características de cada um. E no final, você poderá avaliar com mais clareza, qual deles é melhor para o seu projeto.

Kanban: Uma breve visão

O método Kanban, foi inspirado no sistema de produção Just In Time (no momento certo). A ideia é que as tarefas sejam executadas em etapas, e sob demanda. Para utilizar os recursos de forma inteligente, sem desperdício e mantendo o fluxo de trabalho em funcionamento constante.

A partir dessa ideia, foi concebido o método Kanban e seus princípios. Ele, se tornou uma ferramenta importante, e que pode ser utilizado não só como uma metodologia de desenvolvimento de software, mas também como um gerenciador do seu fluxo de trabalho.

O Kanban, assim como outras metodologias ágeis, é um processo evolucionário. Por isso, você pode começar com uma implementação simples e evoluir isso com o tempo.

Se tiver mais interesse em Kanban, dá uma olhada nesse artigo!

Scrum: Entendendo como funciona

O scrum é um framework ágil, que pode ajudar muito na organização do seu projeto e também da sua equipe. O nome scrum veio de uma famosa jogada de Rugby, onde basicamente o time todo se une para conseguir marcar o ponto.

Por esse motivo, o scrum não é apenas uma boa ferramenta para o seu projeto, ele pode ajudar também, a melhorar o processo para a equipe como um todo.

O scrum possui 3 pilares, transparência, inspeção e adaptação. Ele considera todo o time de desenvolvimento, stackholders e cliente, e com isso pode gerar um engajamento maior dos envolvidos no projeto.

Além disso, ele também é um processo evolucionário, que pode ser melhorado com o tempo e se adequar ao que sua equipe precisa. 

Se você quer entender melhor sobre o Scrum, dá uma olhada nesse artigo!

Kanban X Scrum: Principais diferenças

Agora que já falamos resumidamente de cada um, vamos falar do Kanban X Scrum e entender as principais diferenças entre eles.

Kanban

  • Fluxo puxado: As atividades são adicionadas na “esteira de produção”, conforme a demanda do time.
  • Visualização do trabalho em andamento: O board auxilia muito o gestor do projeto, a ter uma ideia do status do projeto e por isso, na tomada de decisões também.
  • Terminar mais tarefas ao invés de começar novas: Por ter um fluxo puxado, no Kanban sempre prezamos em finalizar atividades em andamento. 
  • Limitação de WIP (Work In Progress): Limitar a quantidade de trabalho em andamento no board, ajuda o time a focar mais na entrega. E limitar o WIP por coluna do board, ajuda a evitar GAPs nas fases do projeto. 
  • Maior adaptabilidade em projetos de manutenção: Pelo trabalho ser passado ao time, com o princípio “on demand“, fica mais fácil encaixar demandas de última hora no fluxo. Como bugs por exemplo.

Scrum

  • Fluxo empurrado: Normalmente através do ritual de Planning Poker, o time define quantas atividade vai entregar no período da Sprint. 
  • Papéis definidos: Apesar de ser uma framework adaptável, o scrum exige papéis que são fundamentais para ele funcionar. 
  • Eventos determinados: O scrum possui eventos definidos, que podem ter sua cadência adequada as necessidades da equipe. E todos eles com um timebox recomendado.
  • Maior dificuldade com projetos de manutenção: Apesar de ser sim possível executar um projeto de manutenção com o scrum, ele é um pouco mais complicado. Isso devido ao controle de atividades da sprint, onde o time define previamente o que vai entregar. E quando surge um bug de última hora, é preciso encaixá-lo, podendo tirar uma tarefa que estava planejada.

Mas afinal, qual devo utilizar?

Isso tudo depende do que sue projeto precisa e de como seu time funciona. Eu recomendo utilizar scrum em projetos que estão começando, e depois o Kanban quando o projeto entrar em fase de manutenção. No entanto os dois funcionam nos dois cenários. 

Kanban

Se você deseja metrificar suas entregas por exemplo e ter maior previsibilidade, o Kanban pode funcionar muito bem. Afinal você não vai se basear em estimativas, mas em um histórico do que o time já entregou.

Algumas métricas como Lead Time e Througput, são simples de controlar com o uso do Kanban e também fáceis de entender. Se quiser saber mais do assunto, leia esse artigo: Como medir os resultados do Kanban?

Scrum

Já o scrum é muito bom para ajudar a organizar a “casa”. Equipes que estão com dificuldades de priorizar suas atividades, e não tem muita regularidade nas reuniões de projeto, podem se beneficiar muito do uso scrum. 

Fazer o planejamento do que será entregue, revisar o trabalho que foi feito. E fazer uma retrospectiva de como a equipe está trabalhando, são alguns dos eventos do scrum que podem ajudar nisso.

E claro, temos o melhor dos dois mundos o Scrumban, que reúne os rituais do scrum e modelo de gerenciamento do Kanban. É uma excelente forma de trabalho, que pode auxiliar você e seu time.

No artigo de Scrum no dia a dia, eu falo um pouco sobre o uso do Kanban em conjunto, e algumas outras dicas que podem ajudar na implementação do scrum.

Extras

Para finalizar, tem também esse vídeo onde falo um pouco sobre Kanban X Scrum.

Espero que tenham gostado do artigo e que ele possa auxiliar você e seu time no momento de fazer essa escolha. Se tiver alguma dúvida, deixe nos comentários. Até a próxima!

Health Check Board: O que isso significa?

O Health Check Board de projetos, basicamente é um quadro que nos mostra de forma rápida, como está a “saúde” de um ou mais projetos.

Esse quadro funciona como uma matriz, onde as colunas são os indicadores a serem avaliados. E as linhas são os nomes dos projetos. E para cada indicador a equipe pode fazer uma avaliação, que normalmente é respondida com níveis, como por exemplo baixo, médio e alto.

Os itens são selecionados para que o time de desenvolvimento possa avaliá-los. E com isso, dar uma visão de como está o status do projeto para o gestor do projeto.

Mas como devo montar meu quadro e o que avaliar? Para entender isso melhor, dá uma lida no conteúdo abaixo.

O que devo avaliar no meu Health Check Board?

Bom, a ideia é poder avaliar o que quiser no quadro, porém precisamos ter indicadores que façam sentido para mostrar ao gestor o momento de agir. E que além disso, ajudem na tomada de decisões.

Nós também devemos tomar cuidado com a quantidade de indicadores selecionados, o recomendado é de 4 a 6.

Quanto ao que devemos avaliar, normalmente pensamos em itens mais subjetivos ou que não seja possível metrificar de forma exata.

Abaixo vou listar alguns indicadores que você pode utilizar no seu projeto:

Satisfação do cliente

O quanto o cliente está satisfeito com o projeto na visão do dev team? Este é um item interessante, não pelo que está avaliando em si. Mas para exibir diferentes pontos de vista, pois as vezes para o gestor o cliente está insatisfeito, no entanto para o time ele está satisfeito. Isso ocorre geralmente, quando a equipe não tem acesso aos feedbacks do cliente.
Então este item acaba auxiliando em dois aspectos. Ver a satisfação do cliente e saber se equipe e gestão estão alinhados sobre o real status do projeto.

Satisfação do time

Além de entender como está a satisfação do cliente, é muito importante também entender como está a satisfação do seu time. A equipe está satisfeita em trabalhar naquele projeto?

Dica: Você utiliza métricas como Throughput e Lead Time por exemplo, para medir suas entregas? Se sim, é possível comparar o nível de satisfação do time com as entregas. E com certeza será possível perceber que as equipes com maior índice de satisfação, entregam mais.
Caso não saiba o que são essas métricas, ou queira entendê-las melhor, dá uma lida neste artigo aqui.

Colaboração do time

O quanto o time está colaborando entre si? Diferente dos dois anteriores onde o time normalmente chega a um consenso para avaliar o indicador, neste item é interessante fazer uma média das respostas. Ou seja você pode atribuir valores para as respostas, perguntando para cada membro da equipe como ele avalia a colaboração entre o time. E as respostas seriam: Baixa (1), Média (2), Alta (3). E então tirar a média dessas respostas.

Colaboração do cliente

Além de avaliar a colaboração do time, é bem legal avaliar também o quanto o cliente ou equipe do cliente colaboram com o projeto. Aqui a equipe pode considerar tempo de resposta a dúvidas, disponibilidade do cliente para acompanhamento do projeto. Afinal fica complicado um projeto andar rápido, quando o cliente não tem disponibilidade para reuniões de alinhamento, ou demora muito para homologar uma entrega.

Domínio do projeto

O quanto a equipe sente que domina do projeto. Aqui também podemos utilizar aquele esquema de tirar a média. Assim o tech lead pode visualizar o quanto cada membro se avalia em relação ao projeto, e alinhar essa visão se for preciso. Podendo oferecer auxílio ou designando alguém para auxiliar pessoas que estejam com dificuldades no projeto.

Pode-se separar este indicador em duas frentes, domínio do ponto de vista técnico e de regra de negócio. Assim fica ainda mais fácil de direcionar a ajuda as pessoas do time, que avaliem seu domínio do projeto como “Baixo” por exemplo.

health check board

Quais são os níveis de avaliação que utilizo no meu Health Check Board?

Bom, aqui na ez nós utilizamos 3 níveis:

  • Alto
  • Médio
  • Baixo

Eles se encaixam com todos os indicadores, e tornam a avaliação mais simples. Mas claro que na hora de montar, você pode definir isso dentro da sua empresa. O importante é que todos os times utilizem os mesmos níveis.

Quando devo atualizar meu quadro?

O período de atualização é normalmente é de uma semana. Pode parecer muito, mas de uma semana para outra pode se mudar bastante a situação de um projeto. E com uma avaliação semanal é possível acompanhar mais de perto o que está acontecendo, e assim tomar as ações necessárias.

Claro que cada um também pode mudar este tempo, mas é recomendado que não seja um período muito longo.

Dica extra

Uma dica, é utilizar uma planilha ou qualquer outra ferramenta que seja para armazenar o histórico do Health Check Board. Assim podem ser feitas várias análises do histórico do projeto, com o que foi respondido no quadro.

Bom, se você gostou da ferramenta e pretende utilizá-la dá uma olhada nesse ez.tips, onde eu falo um pouco sobre o que é o Health Check Board e como ele funciona:

Como medir os resultados do Kanban?

Como medir os resultados do Kanban? Sempre que falamos da utilização da metodologia Kanban em projetos, essa é é uma das primeiras dúvidas que surgem.

Por ser uma metodologia menos prescritiva, onde o fluxo de demandas é “puxado” de acordo com a necessidade do time. Algumas pessoas acreditam que Kanban não trabalha com prazos. Mas não é bem assim que as coisas funcionam.

O Kanban possui várias recomendações, e uma metodologia muito efetiva se praticada da forma correta. Como já mencionei neste artigo sobre Kanban, não basta ter um board dividido em colunas, com alguns cards distribuídos, para realmente trabalhar com Kanban.

Além dos pontos citados no artigo que mencionei acima, o Kanban tem uma outra vantagem. Todos os resultados que metrificamos são baseados em histórico e não estimativas ou achismo, isso nos dá uma grande vantagem.

Mas chega de falar dos benefícios, vamos ao que interessa.

Como medir os resultados do Kanban?

O primeiro passo para conseguir medir os resultados, é ter um workflow bem definido. Ou seja, mapeie muito bem as fases do seu processo de desenvolvimento. Desde o momento em que a demanda é concebida, passando pelo desenvolvimento em si e chegando até a entrega efetiva para o cliente.

É claro que devemos sempre considerar que o Kanban é um processo evolutivo. Então não faça mais do que você precisa, comece com o básico. Primeiro criei o board com um processo básico, e depois vá adicionando as fases que fazem sentido.

Com o processo rodando bem, você deve evoluir para começar a medir os resultados. E ai é importante ter tudo bem detalhado. Uma dica é utilizar o esquema de colunas de espera e de ação, por exemplo uma coluna “Aguardando teste” e a seguinte seria “Em teste”. Assim você consegue medir o tempo em que a tarefa levou para ser testada, e o tempo em que ficou na fila de espera.

Na maioria das vezes, a tarefa leva mais tempo “esperando” do que sendo executada, ai você começa a identificar os gargalos no processo.

Medindo os resultados através do Throughput

A primeira métrica que vamos abordar é o throughput, e apesar do nome ser meio complicado, ela é bem simples de entender.

Basicamente ela mede a capacidade de entrega do seu time, em um ciclo de tempo. Ou seja, quantas tarefas ou histórias de usuário seu time consegue entregar dentro de uma semana?

Com isso você pode perceber a frequência das entregas e a “capacidade” do seu time. Se pensarmos em um cenário onde a equipe trabalha com histórias de usuário com tamanho e complexidade parecidos, é possível ter previsibilidade de quando uma feature será entregue.

Uma forma muito boa de se quebrar tarefas é utilizando a Matriz de complexidade e incerteza. Se você ainda não conhece, dá uma olhada nesse artigo Requisitos em equipes ágeis: Falando sobre complexidade e incerteza do Raphael Albino.

Como medir os resultados do kanban

Nesse gráfico podemos observar que a equipe não está tendo uma tendência nas entregas. Seria um pouco difícil de dar previsibilidade para o cliente dessa forma.

Uma segunda coisa interessante deste gráfico é a categorização de atividades. Como pode-se observar existe uma separação entre “Story” e “Bugs”.

Categorizando atividades

Uma prática muito boa também para medir os resultados do Kanban, é sempre categorizar as atividades. Assim é possível perceber onde o esforço da equipe está sendo investido. Pois o time pode estar entregando 10 atividades por semana, mas se 8 forem bug, com certeza o cliente não vai estar enxergando muito valor nessas entregas. E nesse caso é necessário fazer um alinhamento de expectativas, e entender o motivo de tantos bugs.

Entendendo o Lead Time

Uma segunda métrica que pode ajudar bastante no entendimento do que está acontecendo no projeto, e na tomada de decisões é o Lead Time.

O Lead Time é bem simples também, ele contabiliza o tempo total para uma tarefa fica pronta. Desde o momento em que ela entrou na fila de desenvolvimento “To do”, até o momento em que ela é entregue e chega na coluna “Done”.

Como medir os resultados com Lead Time e Lead Time Breakdown

Além do Lead Time, existe o Lead Time Breakdown. Nele podemos visualizar o tempo total para tarefa ficar pronta, e ainda quanto tempo ela ficou em cada fase.

Por isso é importante termos a separação das colunas de espera e de ação. Imagine por exemplo que uma demanda ficou 15 dias na coluna “Ready to homolog”, aguardando a homologação do cliente. E depois apenas 2 dias na coluna “In Homolog”. Ou seja, seu cliente levou duas semanas para homologar um item que ele pode validar em apenas 2 dias. 

Dei esse exemplo, pois isso já aconteceu em projetos que gerenciei. E foi através do gráfico de lead time breakdown que mostrei ao cliente, que os atrasos dos quais ele questionava, estavam sendo causados pela demora dele na fase do processo que dependia dele. 

Como medir resultados do kanban

Este gráfico particularmente é um dos meus preferidos, é simples de entender e pode dar muitas informações. No eixo X temos os itens de trabalho, e no eixo Y os dias que levaram para serem feitos. 

Além disso, podemos observar quanto tempo o item ficou em cada fase do processo. O número 0 nas colunas, significa que o item não ficou nenhum dia naquela fase.

Neste exemplo podemos observar que existe um GAP imenso na fase de deploy. Isso pode ser causado por falta de um processo bem definido de publicação, ou burocracia interna. O ideal seria um processo de deploy automático, mas sabemos que no dia a dia nem sempre é assim.

Sendo assim, seria o caso de acionar algum responsável na empresa que pudesse resolver isso, para agilizar a liberação de novas funcionalidades em produção.

Tem muito mais para medir os resultados do Kanban…

Essas métricas são apenas algumas das que podemos utilizar no nosso dia a dia. Mas se você nunca utilizou, sugiro que comece por elas. Garanto que irão ajudar muito, tanto no relacionamento com sua equipe, quanto no alinhamento de expectativas com o cliente.

Além dessas, temos também o Burn Down, muito utilizado com o Scrum. O Burn Up, CFD, gráfico de eficiência do fluxo e muitas outras métricas que podem ser utilizadas.

Se interessou pelo assunto? Então fique de olho no blog, que em breve sai post novo falando mais sobre métricas.

E caso tenha alguma dúvida, deixe nos comentários.

Até a próxima!

Scrum na prática: Entendendo o fluxo

Para dar continuidade em nossa trilha de como utilizar scrum na prática, neste segundo artigo vou falar sobre o fluxo do scrum.

Caso você ainda não tenha ouvido falar de scrum, ou não esteja familiarizado com os termos deste framework. Sugiro que leia o primeiro artigo da nossa trilha “Scrum na prática: Introdução“.

Bom, agora que já temos a introdução aos termos e conceitos, é hora de começar a entender o fluxo do scrum. Vamos lá?

Scrum na prática

Visão do produto

O primeiro passo para um time que vai utilizar o scrum na prática, começa um pouco antes dos tradicionais eventos que sempre ouvimos falar.

Antes de por o scrum pra rodar, é importante que o P.O., passe para o time uma visão clara do produto. Esse visão pode ser dada de uma forma macro, para que a equipe possa visualizar os seguintes pontos:

  • Qual o objetivo do produto que estamos construindo
  • O que queremos alcançar com este produto
  • Quais os objetivos de negócio envolvidos no nosso projeto
  • Quais são as expectativas do cliente com esse produto

Enfim, tudo que está relacionado a direção do produto em si. Desta forma, teremos uma equipe alinhada com os objetivos daquele projeto e fazendo parte da concepção do mesmo.

Montando a lista de funcionalidades

Depois de alinhar com o time os pontos citados acima, é hora do P.O. definir uma lista de funcionalidades para atingi-los. Ou seja, ele precisa definir quais as funcionalidades e recursos necessários que precisarão ser desenvolvidos para criar um produto alinhado com os objetivos do cliente.

Por ser uma missão um pouco complexa, o P.O. pode pedir auxílio para o S.M. e até mesmo para membros mais experientes do Dev Team no momento de definir essa lista.

Priorizando as funcionalidades

Após ter a lista completa de funcionalidades, o P.O. deve fazer a priorização delas. Ou seja, ele precisa definir a ordem em que todas as atividades serão desenvolvidas.

Além disso, é muito importante que o P.O. sempre leve em conta o valor agregado que cada recurso irá trazer para o produto. Dessa forma ele conseguirá juntamente com o Dev Team, desenvolver um projeto que entrega valor para o cliente frequentemente.

E com essa lista de funcionalidades definida e priorizada, temos o nosso primeiro artefato do scrum. O Product Backlog, será o pontapé inicial para a equipe começar a usar o scrum na prática.

scrum na prática - fluxo

Começando o scrum: Planejamento

Com o product backlog pronto, vamos começar nosso fluxo. Mas para falarmos deste fluxo, precisamos entender primeiro sobre o principal ciclo de trabalho do scrum, a sprint.

A sprint nada mais é do que o ciclo de trabalho onde o time desenvolve uma lista de funcionalidades pré-selecionadas. Normalmente com duração de duas a quatro semanas. É importante enfatizar também, que as sprints do projeto devem ter tamanho fixo, ou seja, se a sua primeira sprint durou duas semanas, esse ciclo de duas semanas deverá se repetir até a conclusão do projeto.

Com isso entendido, vamos continuar falando do fluxo. E aqui vamos entender o primeiro evento do scrum, o Sprint Planning.

No evento de sprint planning, o time se reuni e seleciona quais atividades do product backlog, irão formar o sprint backlog. Sempre respeitando a ordem de priorização da primeira lista, não se pode por exemplo pegar o primeiro e terceiro item do product backlog, deixando o segundo pra trás.

A ideia é planejar os itens que iremos conseguir entregar ao final da sprint. Claro, que é difícil tem essa previsão. Mas para isso podemos utilizar o Planning Poker. E com o tempo, a equipe vai entendendo melhor os pontos, e o que consegue fazer em cada sprint.

Além disso, o sprint planning não deve ser utilizado apenas para definir “o que será entregue”, mas também “o como isso será desenvolvido”. Então é importante que o time discuta tecnicamente sobre os itens, e sane com o P.O. as dúvidas relacionadas as regras de negócio. Por isso, o timebox recomendado para este evento, varia de 4 até 8 horas, dependendo do tamanho da equipe e duração da sprint a ser planejada.

Continuando com o Scrum: O Fluxo de trabalho

Após definirmos o nosso sprint backlog, é hora de começar a rodar nossa sprint. Então o dev team inicia o desenvolvimento das atividades efetivamente, de acordo com o que foi definido no sprint planning.

Durante esse ciclo, a equipe deve realizar diariamente a daily scrum, no horário combinado. Para que seja alinhado como está o andamento do projeto, devemos lembrar que inspeção e transparência são pilares do scrum.

Garantir que o evento da daily seja realizado todo dia, que a equipe participe ativamente e respeite o timebox máximo de 15 minutos, é papel do S.M. Isso é tão importante quanto remover os impendimentos que possam surgir no caminho, e está contemplado na atuação dele dentro do projeto.

Um pouco mais de Scrum: O fechamento do fluxo de trabalho

Ao terminarmos a sprint, entramos na fase final do fluxo de trabalho. A etapa onde iremos revisar e avaliar tudo que foi desenvolvido e praticado durante a sprint.

A primeira reunião de fechamento é a sprint review, que como já mencionei no artigo anterior serve para avaliarmos se os itens desenvolvidos na sprint, estão de acordo com o esperado. Nela o P.O.  também pode dar manutenção no product backlog.

Depois da review, acontece a retrospectiva. Esta é a reunião aonde avaliamos como está nossa execução do processo, e como anda nossa prática do scrum. Como também já falei anteriormente, nesse espaço a equipe pode discutir sobre o que precisa parar de fazer, ou melhorar na próxima sprint.

Além disso, no final deve acontecer o incremento do produto. Devemos lembrar, que no scrum o time é sempre responsável por manter uma versão estável e utilizável do produto. Por isso a entrega deve agregar novos recursos funcionais, mas sem prejudicar o que já existe.

Concluindo o ciclo do scrum

Bom pessoal, esse é um resumo de como o fluxo do scrum funciona. E apesar de parecer muita coisa, o importante é entender os conceitos e começar a aplicá-los no dia a dia.

O próximo e último artigo dessa trilha fala sobre Scrum no dia a dia, e nele dou algumas dicas de como aplicá-lo. E também falo de ferramentas complementares, que podem auxiliar na utilização deste framework.

Scrum na prática: Introdução

Como utilizar o scrum na prática? E como aplicá-lo no dia a dia de forma efetiva?

Se você trabalha com gestão de projetos, ou desenvolvimento de software, com certeza já ouviu falar de Scrum. E provavelmente sobre alguns dos cases de sucesso famosos com sua aplicação, como no Spotify por exemplo.

Apesar de sempre vermos o scrum definido como “um framework simples para gerenciar projetos complexos”. A verdade é que ele é bastante prescritivo, e leva um tempo para a equipe se adequar a todas as suas práticas. Mas com certeza podemos alcançar bons resultados com ele.

Neste artigo vou falar dos conceitos deste framework. Este será o primeiro de uma trilha que irei escrever, que irá desde da teoria até o scrum na prática. Vamos lá?

Scrum na Prática

PILARES

Transparência

Todo o time pode e deve ter acesso a todas as informações relacionadas ao projeto. A ideia é que a informação fique compartilhada, e assim, gestores, clientes e stakeholders possam acessá-la a qualquer momento.

Por isso é importante que a equipe defina quais ferramentas irá utilizar para se comunicar, e quais documentos irá gerar no decorrer do processo. Já que isso não é definido pelo Scrum, que deixa essa parte por conta do próprio time, para que faça da melhor forma.

Uma ferramenta que pode auxiliar nisso, originada de outra metodologia ágil é o quadro kanban. Que pode dar visualização de como estão todas as atividades do time.

Inspeção

Tanto o desenvolvimento das atividades, quanto a execução do próprio processo podem ser inspecionados a qualquer momento. A intenção da inspeção é que todos fiquem sempre alinhados sobre a situação do projeto. Mas essa inspeção, não deve ser excessiva a ponto de atrapalhar o desenvolvimento das atividades, ou de micro-gerenciar as pessoas.

Na parte do desenvolvimento a inspeção ocorre através de dois eventos, que são “Daily Scrum” e “Sprint Review”. Já o processo, pode ser inspecionado durante a “Sprint Retrospective”. Todos esses eventos, serão explicados mais abaixo.

Adaptação

O último pilar, garante que o processo do Scrum seja sempre adaptado quando necessário. O mesmo é válido para as diretrizes do produto, que como possui ciclos menores de interação com o cliente, também tem a possibilidade de ser adaptado com maior facilidade.

Scrum na prática

PAPÉIS

Product Owner (P.O.)

Responsável por direcionar o produto, é ele quem define quais as funcionalidades que serão desenvolvidas. E também faz a priorização delas para o time. Além disso, ele deve sempre deixar claro quais são os objetivos daquele projeto e passar a visão do produto para sua equipe.

Scrum Master (S.M.)

É o membro da equipe que deve dominar as práticas do Scrum. Conhecido como facilitador, ele sempre auxilia e garante que o time está executando o processo corretamente.

Dev Team

É quem propriamente desenvolve o produto, e tem o poder de decidir a melhor forma de fazer isso. No Scrum o time de desenvolvimento tem autonomia para escolher de qual maneira irá desenvolver suas tarefas, para atingir os objetivos do projeto. A equipe deve ser auto organizada e multifuncional.

EVENTOS

Sprint Planning

Nessa reunião, o dev team conversa sobre os itens do product backlog e seleciona o que entrará na sprint backlog. Sempre respeitando a ordem de priorização definida pelo P.O.

Além disso, o time também aproveita para debater como a demanda será desenvolvida, e nessa hora o P.O. pode explicar os requisitos e objetivos daquela estória de usuário. Assim a equipe conseguirá ter um entendimento mais claro, e poderá definir em conjunto qual a melhor forma de atender a demanda.

Daily Scrum

Reunião que deve acontecer diariamente para que toda a equipe fique alinhada sobre o andamento do projeto. Deve ser feita com todos os membros de pé, pois precisa ser algo rápido, durando no máximo 15 minutos.

Normalmente os desenvolvedores respondem a 3 perguntas:

  • O que foi feito ontem?
  • O que planeja fazer hoje?
  • Teve ou tem algum impedimento?

Sprint Review

Realiza ao final de toda sprint, essa reunião serve para avaliar se todos os itens de trabalho da sprint estão de acordo com o que cliente espera. Aqui o time apresenta o que foi desenvolvido para o P.O., e ele irá avaliar a entrega.

Nesta reunião, é comum a participação de stakeholders do produto. E nela também, que podemos realizar a manutenção do product backlog.

Sprint Retrospective

Realizada após a review, a reunião de retrospectiva serve para equipe avaliar como está trabalhando como o framework em si. Ou seja, como estão utilizando o scrum na prática e quais os resultados disso.

Alguns textos falam sobre levantar pontos negativos e positivos da sprint. Mas eu prefiro os autores que sugerem utilizar os seguintes questionamentos:

  • O que fizemos de bom?
  • O que precisamos melhorar?

E para tudo aquilo que precisamos melhorar, a equipe pode definir uma ação.

Scrum na prática

ARTEFATOS

Product Backlog

Lista de funcionalidades do produto, é criada, priorizada e mantida pelo P.O., utilizada pelo time durante o sprint planning.

Sprint Backlog

Funcionalidades selecionadas do product backlog, pelo time de desenvolvimento durante o planning. O ideal é que essa lista de itens, seja entregue no final da sprint.

Entregas Incrementais

Ao final de toda sprint, a equipe deve incrementar o produto com um entrega funcional.

Este foi o primeiro artigo da trilha de “Scrum na prática”. Onde dei uma introdução dos conceitos deste framework. E no segundo artigo, você pode conferir como funciona o fluxo do scrum.

Como escrever tarefas para o time de desenvolvimento?

Qual a melhor forma de passar demandas para o time de desenvolvimento? Sempre que falamos de gerenciamento de projetos, caímos nesse impasse. Mas como podemos fazer isso de uma maneira efetiva?

Como já falei em outro post do blog, o Kanban é uma boa alternativa pra organizar o fluxo de desenvolvimento. Mas além disso, é importante também, criar tarefas bem descritas para a equipe.

Para isso, podemos utilizar alguma estrutura padrão ao montar nossos cards no board.

Claro que os rituais como Refinement, ou Planning são de extrema importância para compartilhar as demandas com o time de desenvolvimento.

No entanto, neste post vou falar apenas em como escrever os cards de atividades e os resultados que podem ser obtidos.

Motivação

Pra começar, é sempre bom definir qual a motivação daquela tarefa. A ideia é que ao ler esse tópico, o desenvolvedor entenda o porquê de estar realizando aquela atividade. E além disso, qual o objetivo dessa funcionalidade dentro do sistema, o motivo dela existir e precisar ser desenvolvida naquele momento.

Pode parecer desnecessário, ou que isso está sempre subentendido. Porém, ter essa descrição na tarefa pode trazer muitos benefícios, como por exemplo:

  • Sensação de pertencimento do desenvolvedor, pois ele percebe que pode ajudar a pensar na solução.
  • Empatia pelo usuário. Quando se entende o problema que será solucionado e como o recurso será utilizado, fica mais fácil ter essa visão.
  • Alternativas de soluções mais eficientes. Quando o desenvolvedor consegue enxergar o todo, ele pode sugerir alternativas menos custosas em tempo de desenvolvimento, e por isso pode solucionar o problema com menos recursos.
  • Facilidade no entendimento. Ao entender os motivos relacionados a atividade, a compreensão do todo fica mais clara.

Critérios de aceite

Essa é uma parte fundamental ao escrever as tarefas. Quando listamos os critérios de aceite, estamos definindo o escopo do que será entregue e o que deve ser considerado no desenvolvimento dessa atividade. Portanto, é vital definir muito bem todos os critérios de aceite.

Os critérios de aceite precisam ser claros e objetivos, e além disso devem garantir a qualidade da entrega. Afinal é a partir destes critérios, que iremos alinhar com o time as expectativas dos stakeholders envolvidos. Portanto, esse tópico certamente é o mais importante a ser considerado no momento de escrever nossas tarefas.

Além dos pontos citados acima, a definição bem feita dos critérios de aceite contribui para o foco naquilo que deve ser entregue. Ou seja, o time de desenvolvimento sabe exatamente o qual o resultado esperado e investe seu tempo apenas no necessário.

Membro do time de desenvolvimento realizando teste
Os critérios de aceite e casos de teste, auxiliam o time de desenvolvimento na validação das atividades.

Casos de teste

Um outro ponto importante a se considerar no momento de escrever as tarefas, são os casos de teste.

Além dos critérios de aceite, é muito importante criar casos de teste para garantir que a entrega esteja alinhada com a expectativa do cliente.

Quando você define como testar uma atividade, consequentemente contribui para que o desenvolvedor entenda melhor o que precisa fazer.

E acima de tudo, os casos de teste servem para validar a qualidade da entrega. Auxiliando o time de desenvolvimento a realizar testes mais precisos que podem verificar funcionalidades específicas de suas atividades.

Uma boa ferramenta para auxiliar na escrita destes casos de teste é o Forrest.

Extra: Mockups!

Não é para toda demanda, mas mockups das telas são essenciais na maioria dos casos. Ter o desenho do resultado final da tela, pode ajudar e muito o time de desenvolvimento no momento de entender e desenvolver uma atividade.

Existem alguns casos, como demandas onde já existe um padrão de tela, que isso não é necessário, mas devemos utilizar deste recurso sempre que possível.

Conclusão

Resumindo, quando vamos escrever tarefas para o time de desenvolvimento, devemos adicionar os detalhes que irão contribuir para a qualidade da entrega e que valem o esforço.

Ou seja, não devemos investir tempo demais adicionando informações que ninguém irá utilizar, ou que não ajudarão efetivamente a equipe.

Sabemos que não existe um modelo perfeito e nem um padrão único, que possa se adequar a todas as equipes ou projetos.

No entanto, com essa estrutura você pode ter bons resultados. E com o tempo pode evoluir isso da forma que for melhor para o seu time.

Caso esteja com dificuldades ao alinhar as expectativas ou garantir a qualidade das entregas. Ou até mesmo, se estiver tendo muito retrabalho com o seu projeto, experimente escrever as tarefas seguindo essa estrutura. Você pode ter bons resultados com o seu time de desenvolvimento!

Se tiver alguma dúvida, deixe nos comentários.