Scrum - Agilidade, Controle e Qualidade

Apresentação Introdutória sobre o uso do Scrum na gestão de projetos para a AIESEC Porto Alegre

Boa tarde a todos! É um grande prazer falar, mais uma vez, com vocês da AIESEC. O primeiro contato que eu tive com vocês foi graças à minha filha Aline, que apresentou-me à organização. Depois, em novembro deste ano, a equipe da AIESEC Foz do Iguaçu participou de uma palestra que fiz sobre Cidades Inteligentes. Já aprendi o quanto vocês são dinâmicos, ágeis e focados. Por isso estou fazendo, hoje, uma apresentação completamente diferente de todas as outras que já fiz sobre Scrum até agora. Não tenham a preocupação em anotar nada pois, tão logo eu chegue em casa, esta apresentação, assim como a sua transcrição e os links que menciono aqui estarão disponíveis, na Internet, para todos vocês.

Em primeiro lugar, vocês sabem o que é Scrum? Antes de explicar o que é a metodologia, quero mostrar um slide apresentado no início deste mês, por Jeff Sutherland, um dos criadores da metodologia, na conferência Agile Boston:

•há seis meses, nos Estados Unidos, havia 40.000 vagas abertas para trabalho com Scrum;
•hoje são 420.000!

Ou seja, no mínimo Scrum é algo que merece ser observado, especialmente para quem está começando no mercado do trabalho.

Mas vamos lá, o que é o Scrum? Eu peguei esta foto do Google Images, de uma turma da AIESEC no Congresso Europeu que aconteceu na Áustria em 2010. Vamos dizer que esta foto tenha sido tirada no meio de um campo de futebol e que eu grite para este pessoal:

- Todos os que tem o primeiro nome iniciando com as letras de A a M são do time A e fazem gol do lado direito do campo. Os com o primeiro nome iniciando com as letras de N a Z são do time Z e fazem gol do lado esquerdo. Quem marcar o primeiro gol ganha viagens, com tudo pago, para o Caribe, para dez pessoas do seu time. Vocês têm dois minutos a contar de agora. Aqui está a bola!

Aí atiro a bola no meio deles. O que irá acontecer?

A analogia pode ser meio exagerada, mas em 1976 dois professores da Universidade Hitotsubashi, do Japão, Hirotaka Takeuchi e Ikujiro Nonaka escreveram um artigo que foi publicado na Harvard Business Review: The New New Product Development Game. Neste artigo, considerado a base do Scrum, os autores dizem que “no mundo competitivo de hoje, a velocidade e a flexibilidade são essenciais. As empresas estão aprendendo que a abordagem sequencial para o desenvolvimento de novos produtos não serve mais. Ao invés disto, as empresas estão usando um método holístico — como no rugby, a bola é passada dentro do time enquanto ele move-se, como uma entidade única, pelo campo.”

Daí surgiu o nome “Scrum”, essa “embolada” no jogo de rugby onde os jogadores têm que dar um jeito de coordenarem-se, muito rapidamente, para ficar com a bola e avançar posições com ela, trabalhando em equipe.

Ainda que sejam considerados os padrinhos do Scrum, Takeuchi e Nonaka não foram os únicos a influenciar a metodologia. Em 1975 foi publicado um livro com uma coletânea de ensaios de Fred Brooks Jr, arquiteto responsável pela arquitetura tecnológica /360 da IBM, que permanece viva, em encarnações com nomes diferentes, até hoje. Fred, que é catedrático da Universidade de Chapel Hill, na Carolina do Norte, Estados Unidos, buscou transmitir, neste livro, o que aprendeu com sua participação em vários de seus projetos e na observação de projetos desenvolvidos por outros. No artigo que dá nome ao livro, “O Mítico Homem-Mês”, ele diz que adicionar mais pessoas a um projeto que já está atrasado tem um único efeito: atrasar ainda mais o projeto. Em outro artigo ele diz que não há uma bala de prata única que sirva para todos os lobisomens: cada problema é diferente e requer soluções diferentes. Em “A equipe cirúrgica” ele sugere como deve ser o perfil das pessoas que trabalham no desenvolvimento de um projeto, influenciando muito a forma como se montam os times no Scrum hoje.

São vários os padrinhos e pais do Scrum mas a metodologia, como tal, foi apresentada oficialmente em 1995 em um artigo de Ken Schwaber e Jeff Sutherland. Jeff trabalhou em muitas empresas de software, leu muito sobre metodologia de desenvolvimento de projetos e, em 1993, enquanto trabalhava em uma grande empresa de desenvolvimento de software, fez estas perguntas a seu chefe:

“Quantas entregas você já fez para este cliente?”
“Cerca de onze nos últimos anos.”
“Alguma delas aconteceu dentro do prazo?”
“Não.”
“Alguma delas satisfez o cliente?”
“Não.”
“Por que você continua fazendo isto?”

A questão é que, ainda hoje, ao desenvolvermos projetos, temos a tendência de querer saber tudo o que faz parte dele, quais serão as entregas, o que desejamos, o que o cliente deseja. Queremos nos proteger e proteger os clientes através de um grande contrato que especifique exatamente o que irá ser feito. Só que as coisas mudam rápido demais e, na medida em que avançamos em qualquer projeto, descobrimos coisas que não conhecíamos quando começamos a defini-lo, temos novas ideias, novas tecnologias nos trazem novas possibilidades, algo que era caríssimo cai pela metade do preço, alguém que nem estava no nosso projeto disponibiliza algo que pode nos fazer ganhar muito tempo... O que mais pode acontecer?

Em 2001 Jeff e várias outras pessoas que trabalhavam com o Scrum e outros métodos ágeis criaram o Manifesto Ágil, que representa uma quebra em uma forma convencional de desenvolvimento e gestão de projetos e tem quatro declarações básicas:

•Indivíduos e interações são mais importantes que processos e ferramentas
•Software em funcionamento é mais importante que documentação abrangente
•Colaboração com o cliente á mais importante que negociação de contratos
•Responder a mudanças é mais importante que seguir um plano

Ainda que o segundo item, no manifesto ágil, refira-se a software, o Scrum não é usado apenas para o desenvolvimento de software. Interpretemos aqui o software como qualquer projeto em andamento.

Eu vou falar agora sobre a equipe e cada um dos artefatos e práticas essenciais do Scrum usando os nomes que vocês encontrarão na literatura, caso desejem aprender mais sobre a metodologia. Os nomes, porém, não são o mais importante. A atitude sim. Os nomes, aliás, podem até assustar alguns clientes com os quais vocês venham a ter contato, que já estão fartos de tanto jargão de marketing. Vocês também encontrarão pela Internet formas de introduzir o Scrum em modo “Stealth”, ou seja, camuflado! Seu cliente passa a usar o Scrum sem nem saber que está utilizando.

A Equipe Scrum

O Dono do Produto (Product Owner) é quem define o produto, ou o que é esperado como resultado de um projeto. Ele é quem terá a palavra final sobre a prioridade das tarefas e é ele quem dá o aceite nos trabalhos.

O ScrumMaster garante que a equipe seja plenamente funcional, incentiva a cooperação, protege a equipe de influências externas e remove os obstáculos a seu trabalho. É ele quem marca reuniões e cobra o bom andamento dos processos e o bom uso dos artefatos.

A Equipe é multifuncional, composta de 5 a 9 membros. Ela escolhe seus próprios objetivos, especifica os resultados do trabalho com total liberdade. Ela se auto-organiza e demonstra o trabalho ao Dono do Produto ao final de cada iteração.

Cada um escreve o que quiser no seu cartão de visitas.

Processos e artefatos

O Dono do Produto irá reunir-se com todos os interessados no projeto, aqueles que se beneficiarão dele ou o utilizarão, e criará uma lista priorizada de todos os itens do projeto: o Product Backlog. Respeitando as prioridades no Product Backlog, a equipe do projeto irá reunir-se e definir o que pode executar dentro de cada ciclo de trabalho (Sprint Backlog), já estimando os tempos de execução. As negociações podem ocorrer entre os Sprints, nunca enquanto eles acontecem. Dentro de cada Sprint o Scrummaster e a equipe manterão um registro do trabalho previsto versus o executado, o Burndown Chart. Todos os dias, em horário predeterminado, haverá uma reunião rápida, com todos em pé, chamada de Daily Scrum. Nela o Scrummaster perguntará a todos os participantes:

1.O que você fez ontem?
2.O que fará hoje?
3.Há algum obstáculo no caminho?

Esta reunião não é um relatório para o Scrummaster, mas um compromisso assumido entre todos os membros da equipe. O Scrummaster ficará responsável por eliminar os obstáculos. Ao final de cada Sprint é feita uma revisão dos trabalhos daquele Sprint, o que deu certo, o que deu errado e quais as lições aprendidas. É importante que cada Sprint contemple a entrega verificável de uma parte do projeto (ou alguma funcionalidade de um produto). Todos devem ver o projeto crescer através de pequenas vitórias incrementais.

Ao final do projeto, depois que ele for entregue, é feita uma retrospectiva de todo o trabalho, sempre visando a contínua melhora para os próximos projetos.

Como criar o Product Backlog

Uma discussão sobre o que será o projeto fica bem mais "visível" com o uso de mapas mentais. Cada um dos itens de trabalho pode detalhado e facilmente expandido. Com o mapa exposto para a equipe de projeto e seus patrocinadores fica fácil de, olhando cada ramo do mapa, priorizar as tarefas usando, por exemplo, o poker do planejamento ou qualquer outra técnica que você preferir.

Priorizadas as tarefas você têm seu Product Backlog e agora pode dividi-las em fases semanais (seus Sprints) buscando garantir que o esforço em cada semana será dividido da maneira mais uniforme possível. No caso do surgimento de uma nova tarefa ou da necessidade de repriorização, volte ao mapa mental. Através dele será fácil mostrar que uma nova tarefa pode impactar o projeto como um todo, incluindo o tempo para a sua conclusão.

Como acompanhar a evolução do projeto

Kanban e Burndown Charts (exemplo online)

Modelo para o Burndown Chart

Perguntas

Links:

brodtec.com/scrum



Design: Dobro Comunicação. Desenvolvimento: Brod Tecnologia. Powered by Drupal