Conheça alguns mitos do Scrum

Olá, seja muito bem-vindo!

              Nesse artigo iremos apresentar-lhe alguns mitos referentes ao Scrum que eventualmente são disseminados por profissionais em redes sociais, treinamentos ou até mesmo em livros. Você já os conhece?

A Reunião Diária deve ser realizada em pé

Embora muitos treinamentos e artigos sobre o Scrum nos dizem que a Reunião Diária deve ser realizada em pé, tenha em mente que essa é apenas uma boa prática que pode ser adotada ou não pelo Time de Desenvolvimento e, dessa forma, é opcional.

              A maioria dos Times de Desenvolvimento realizam a reunião em pé, pois isso gera um certo desconforto, uma vez que ninguém gosta de ficar muito tempo em pé. Dessa forma, isso ajuda a manter a reunião curta, direta e objetiva. Esse formato é conhecido como Stand Up Meeting.

              Porém caso você visualize algum Time de Desenvolvimento realizando a reunião em uma sala de reunião ou sentado, lembre-se que isso não significa que a equipe está ferindo uma regra do Scrum.

Durante a Reunião Diária, as três perguntas devem ser respondidas.

              Vamos apresentar mais um mito referente ao Scrum. Muitos livros e treinamentos, principalmente os mais antigos nos dizem que, na Reunião Diária, os membros do Time de Desenvolvimento são obrigados a responderem às seguintes perguntas:

  • O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint?
  • O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint?
  • Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint?

Porém a partir da versão 2017 do Guia Scrum, é possível ao Time de Desenvolvimento estruturar e conduzir a reunião de diferentes formas, desde que se foque no progresso em direção à meta da Sprint. Dessa forma, as 3 perguntas acima passam a ser opcionais, e não mais obrigatórias.

Os membros do Time de Desenvolvimento devem ser capazes de executar qualquer tipo de trabalho

O Guia Scrum nos diz Time de desenvolvimento deve ser multifuncional, ou seja, necessita possuir todas as habilidades que são necessárias para desenvolver os incrementos do produto. O time precisa ser capaz de desenvolver o produto por si só, sem depender de outras equipes ou pessoas externas.

Muitas pessoas pregam que multifuncionalidade significa que os profissionais de um Time de Desenvolvimento devem ser multidisciplinares, ou seja, que eles devem ter a capacidade de executar todas as funções necessárias para desenvolver o produto. Esse é o famoso conceito de que “todo mundo deve fazer tudo”.

Porém essa definição está incorreta. Em nenhum momento o Guia Scrum nos diz que os profissionais do Time de Desenvolvimento devem ser multidisciplinares. Ele diz que o Time de Desenvolvimento deve ser multifuncional. Isso quer dizer que o time como um todo deve possuir todas as habilidades necessárias para desenvolver um incremento do produto. Consegue perceber a diferença?

Em um projeto de desenvolvimento cujo produto final seja um Software, o Time de Desenvolvimento pode ser composto por profissionais que tenham conhecimentos específicos em desenvolvimento, arquitetura, bancos de dados, web design, testes, etc.  É muito difícil um profissional possuir conhecimento em várias disciplinas e ser realmente bom em todas elas. Mas é fato que o Scrum irá propiciar aos membros do time se aprimorarem e aprenderem novas habilidades, uma vez que eles devem se ajudar para completar o trabalho e gerar o incremento do produto. Durante o andamento de uma Sprint, caso todas as atividades de banco de dados tenham finalizado, o profissional de banco de dados pode ajudar na execução dos testes. Uma vez que o analista de Banco de Dados não é experiente nessa atividade, ele provavelmente irá testar as funcionalidades de menor complexidade, deixando as demais para o analista de testes.

Os itens do Backlog do Produto devem ser descritos no formato de histórias de usuário

Certamente em algum momento você já viu ou ouviu em algum lugar que os itens do Backlog do Produto devem ser descritos utilizando o formato de histórias de usuário.

Porém é importante esclarecer que o Guia Scrum, em nenhum momento, irá dizer como devemos descrever os itens do backlog do Produto. Dessa forma, é permitido que o backlog seja descrito e detalhado utilizando histórias de usuário, protótipos, casos de uso, especificações técnicas ou qualquer outro tipo de documentação que a organização desejar. No entanto, ao utilizar o Scrum, o mais comum é que os itens do Backlog do Produto sejam descritos utilizando histórias de usuário.

É obrigatório utilizar o gráfico Burndown para acompanhar o progresso da Sprint

Embora sejam muito úteis, os gráficos Burndown, Burnup e Diagrama de Fluxo cumulativo são apenas boas práticas sugeridas pelo Guia Scrum. Dessa forma, seu uso é opcional. Caso você não os conheça, segue um breve resumo sobre cada um deles:

  • Gráfico Burndown
    • O gráfico Burndown é utilizado com o intuito de demonstrar o progresso e desempenho da equipe, comparando o que foi planejado com o que já foi entregue. 
    • O gráfico Burndown apresenta o quanto ainda falta para ser realizado durante a execução do projeto ou da Sprint. Dessa forma, ele é apresentado em forma decrescente.
  • Gráfico Burnup.
    • O gráfico Burnup é semelhante ao gráfico Burndown. A diferença é que esse gráfico irá apresentar o que já foi realizado até o presente momento.
  • Diagrama de Fluxo Cumulativo.
    • O diagrama de Fluxo Cumulativo é utilizado para demonstrar o progresso e o desempenho do projeto como um todo. Esse diagrama irá nos apresentar uma visão clara de como está a distribuição do trabalho entre as etapas do Projeto.

A Sprint Zero (0)

Alguns times, antes de iniciar a primeira Sprint do projeto, optam por executar uma iteração conhecida como Sprint 0. Essa Sprint usualmente destina-se a:

  • Preparação do Backlog do Produto.
  • Preparação do ambiente de trabalho como, por exemplo, realizar a aquisição e instalação de equipamentos e softwares. Além disso, pode ser necessário adquirir materiais e outros suprimentos a serem utilizados durante o andamento do projeto.
  • Podemos também definir o tamanho das Sprints e elaborar a Definição de Pronto.
  • Eventualmente, durante a Sprint Zero, pode ocorrer a formação do Time de Desenvolvimento.
  • Enfim, ela pode ser destinada à realização de quaisquer atividades que sejam necessárias para a preparação inicial do projeto.  

Conforme podemos perceber, a Sprint 0 não resulta em nenhum incremento do produto funcional e potencialmente pronto para entrega ao Cliente.

É importante frisar que o Guia Scrum nos deixa claro que, ao final de uma Sprint, um Incremento do Produto deve estar “Pronto” e em condições de ser utilizado. Ou seja, como a Sprint 0 não gera nenhum incremento, não podemos considera-la como sendo oficialmente válida.

Muito obrigado pela atenção e até breve!