Farei uma série de dois artigos para relatar a experiência da implantação do SCRUM em uma fábrica de software,
detalhando o
amadurecimento na metodologia ao longo de um ano.

Neste primeiro, vou tratar da motivação para uma
mudança
cultural na equipe que demandaria uma nova metodologia. Em seguida
serão
detalhados os primeiros passos na implantação do SCRUM em uma fábrica
de
software.

No segundo e último artigo será detalhado o amadurecimento da
utilização do SCRUM e as conclusões para você que pretende utilizá-lo
na sua
equipe.

Introdução

Quando custo, prazo e escopo são fixos, o que varia é a qualidade. Autor desconhecido

Confesso que fico um pouco desestimulado quando leio alguns
artigos pela Internet vendendo o Scrum em 5 minutos, 1 hora e até em
alguns
dias.

Quero pregar justamente o contrário: o
Scrum não é
fácil (a sua
aparente facilidade
engana!), não serve para qualquer equipe e, definitivamente, não é a salvação para
todos os problemas
da sua empresa.

A motivação

Apesar de contar com uma equipe já formada há mais de um
ano trabalhando no mesmo projeto, nossa
realidade era de projetos sendo entregues com uma qualidade aquém do
esperado pelo
cliente e com constantes estresses nos dias de entregas das versões. Esses
problemas
representavam apenas a ponta de um iceberg, que era composto de:

• Estimativas feitas por apenas um
  profissional;
• Constantes paralisações de pessoas da
  equipe para desenvolverem trabalhos fora do
  escopo inicial;
• Equipe sem comprometimento, onde
  cada um era
  responsável pela sua atividade;
• Falta de integração entre os
  profissionais da
  equipe;
• Alto consumo de
  tempo do gerente do projeto com os
  controles que ficavam desatualizados constantemente;
• Mudanças constantes de escopo;
• Cronogramas que não refletiam a
  situação atual;
• Grande volume de versões indo e
  voltando do
  cliente, acarretando em problemas de versionamento e controles
  de módulos;
• Horas extras eram comuns em véspera
  de entregas;

Eu sentia a necessidade de uma metodologia que tornasse
meu dia-a-dia mais fácil, com menos
controles e mais trabalho de valor. A nossa realidade era de projetos
menores,
com entregas frequentes,
o que,
invariavelmente, gerava inúmeras versões periodicamente. Essa situação
acarretava em um fluxo enorme de versões indo e voltando e o cliente
sem muito
controle do que estava sendo entregue.

Após escutar alguns amigos falarem sobre o Scrum,
resolvi
aprender um pouco mais sobre a metodologia. Estudei bastante, li
inúmeros
artigos, questionei, critiquei e
procurei
entender do que se tratava antes de me arriscar por esse caminho. E eu
afirmo:
conhecendo conceitualmente
uma
metodologia, a implementação torna-se
muito mais fácil. Nessa importante etapa contei com a ajuda de dois
amigos no
entendimento geral sobre o Scrum: Ricardo Mitrano, que já trabalhava
com a
metodologia em uma grande empresa, e o Claudio Cardozo, que fez a
certificação
Scrum Master.

O passo seguinte foi a “venda” do SCRUM: como
conseguir
vender algo ainda pouco difundido e que chegaria para substituir o
PMBoK?
Difícil, mas não impossível.
Preparei
uma apresentação “daquelas” e fui atrás da diretoria para mostrar os
benefícios
que uma mudança de metodologia trariam. Contei com a ajuda de um grande
amigo
nessa empreitada e o resultado, se não foi satisfatório, foi aceitável:
“use,
mas não deixem o cliente saber”. Essa frase pareceu um tanto quanto
surreal,
pois como eu conseguiria implantar uma metodologia que envolve
diretamente o
cliente, sem envolvê-lo? A solução foi improvisar: combinei com o time
as ações
que adotaríamos e fui envolvendo o cliente aos poucos, sem ele perceber.

No início, começamos com cada projeto fazendo o
papel de um
sprint (o que não é muito correto), mas mantendo algumas reuniões
propostas
pelo Scrum:

• Sprint Planning: onde o time e o
  cliente
  selecionam os itens do Backlog que encontrarão
  no próximo desenvolvimento;
• Daily Meetings: reuniões diárias de
  15 minutos
  onde os membros da equipe abordam três questões: o que fiz?; o que
  pretendo
  fazer?; existe algo impedindo meu trabalho?

Além disso, desde o início procuramos utilizar o
Scrum Board
com algumas colunas: requisitos pendentes, atividades a fazer,
atividades em
andamento, atividades concluídas e backlog. Nessa parte, méritos para o
meu
amigo Cláudio Cardozo, que me incentivou na utilização do Scrum Board.

Infelizmente, foi difícil fazer as retrospectivas
no início.
Mas, mesmo assim, eu considerava que manter as reuniões diárias e o
envolvimento do cliente e do time no planejamento das atividades já
seria um
bom ganho.

“Mas você ainda não
utilizava Scrum”!

Exatamente! Tudo isso era apenas a preparação do terreno e
fazia parte do amadurecimento da equipe para a metodologia. Afinal,
eles também
precisavam aprender aos poucos!

Após três meses utilizando o básico do básico,
apliquei uma
pesquisa bem simples com todas as pessoas do time e os resultados
começavam a
aparecer: grande parte da equipe sentia-se mais motivada e percebia as
melhorias no dia-a-dia.

Mas ainda faltava o principal: o cliente! E ele
foi fisgado
após oito meses, quando sentiu a necessidade de uma mudança
mais profunda no dia-a-dia da equipe. Nesta hora, mostrei a ele o que
já
utilizávamos e tantos outros processos que poderíamos utilizar que
melhorariam
sensivelmente nosso trabalho. O principal argumento utilizado para a
venda do
Scrum foi a possibilidade de mantermos apenas duas entregas mensais
(sprints
quinzenais), o que tornaria o trabalho dele no recebimento dessas
versões muito
mais simples e controlável.

Aguarde no próximo artigo a inclusão do cliente na
utilização
da metodologia e as dicas para quem pretende utilizar o Scrum na empresa.