Palestra de Danilo Bardusco – Globo.com, a apresentação está disponível no SlideShare. Já havia assistido uma palestra dele e novamente foi muito competente e direto no assunto que tratava. Passando experiência de utilização e conceitos do Scrum na mesma palestra.
Antes de começar é bom saber, escalar desenvolvimento ágil é a única coisa que você deve fazer. Comece simples! A velocidade de decisão tem que ser rápida e menos pessoas decidem mais rápido.
Danilo Bardusco
O Scrum é auto-escalável, ele contém todos os elementos necessários para lidar com a complexidade. E para uma adoção de Scrum ser boa, ela não deve ter um único responsável, ela vai acontecendo gradualmente baseada em resultado.
De acordo com Ken Schwabber:
Scrum precisa de gerenciamento inteligente e mão na massa
Como é na Globo.com?
Na Globo.com existem dois cenários: um com equipes que trabalham independentes umas das outras e outro cenário com equipes diferentes que trabalham em um mesmo projeto.
Ao iniciar a adoção do Scrum, 7 departamentos foram transformados em 17 times Scrum. E uma lição que saiu desta adoção foi que quando se está transformando, é preciso mostrar para as pessoas porque será melhor. Ao escalar o Scrum em equipes independentes é importante lembrar de:
- Simplicidade: é a arte de maximizar a quantidade de trabalho não feita. Se não tem certeza de que algo é necessário, não escreva o código.
- Iterações: Ser simples significa ser incremental. O Scrum exige que você pense como uma artista, vá refinando a sua obra, vá refinando a sua idéia sobre o que deseja fazer. E você irá parar quando achar que já tem o suficiente. (Em sua apresentação ele utilizou um slide bem bacana, ilustrando esta diferença mostrando um quadro da Monalisa). Se você tem 3 dias para fazer um cadastro de clientes, faça o melhor cadastro possível em 3 dias, faça algo entregável.
- Cliente e/ou usuário colaborando: Isto é difícil em empresas maiores. Não é para escolher nada do cliente.
- Kaizen Mind: senso de urgência. Fazer as coisas de forma melhor.
- Ambiente de confiança e aprendizado.Para aprender é preciso errar. As pessoas não se sentem confortáveis de apontar onde está errado. A principal coisa que gera confiançaé entregar software funcionando.
- Entregar software funcionando a cada sprint: mesmo que seja pouco, você vai melhorando e corrigindo. Eles tinha dois problemas maiores para entregar software funcionando. Os times não eram 100% autônomos e a alta direção não se sente confortável de por algo que não está ainda pronto. Alguém pode copiar a idéia ou causar má impressão. Mas viram que é mais competitivo entregar antes do que ficar planejando.
Ao Implantar Scrum é importante saber que o Scrum não é fácil.
Escalando Scrum
No desenvolvimento da nova plataforma de gerenciamento começaram com 1 time em 12 sprints. As coisas não estavam indo bem, era preciso ser mais rápido. A direção colocou 6 times à disposição do projeto. Mesmo sabendo que 9 mães teriam um filho em um mês, eles começaram a escalar o Scrum.
- Os times foram replicados: uma pessoa do time original foi colocada em cada um dos novos times.
- O Product Owner original virou o Product Owner do Backlog geral.
Estes times tinham:
- Sprint sincronizado.
- Plannings individuais.
- Daily meetings no mesmo horário, às 09:30.
- Daily Scrum of Scrums às 09:50.
- O Review é feito no auditório com todos.
Velocidade dos times
Algo que eles aprenderem neste projeto foi que é importante achar a velocidade local de um time antes de distribuir para outros times. É importante sentir se o time está desempenhando da forma que o projeto precisa antes de distribuir.
A arquitetura estava ruim, muito difícil de desenvolver. Outras coisas que aprenderam foi:
- Integre os projetos ao menos uma vez por dia. Se a equipe demorar muito para fazer o Merge, corre o risco de ter muito retrabalho.
- Cuidado com a automação de testes, evite gerar uma manutenção difícil. Eles gravavam muitos testes de web e depois tinham que regravar muita coisa. O mesmo cuidado que você tem com o código, deve ter com o teste.
Coordenação entre os times
É fundamental que as pessoas se falem, daily meetings e sincronismo entre os Product Owners. É preciso isolar uma user story de outra.Além disso, para facilitar a coordenação é importante não paralelizar trabalho, que nos dá os seguinte benefícios:
- Diminui o estoque de produtos não acabados.
- Ajuda na auto-gestão.
- Regula o tamanho da equipe: não vai ter story para que 15 pessoas trabalhem na mesma.
- Tira o time da zona de conforto.
Fez uma pequena observação: eles fazem reuniões semanais entre os especialistas de uma área que estão espalhados pelos times, (por exemplo designers), para que troquem experiências.
Seja preguiçoso
- Só faça o absolutamente necessário para a meta.
- Não reinvente a roda.
- Simplifique.
- Automatize depois que fizer algo, automatize tudo!
Ao fim das palestras, Danilo disse que a Globo.com é uma boa prova que se pode fazer software de qualidade sem burocracia.
