O Scrum é o framework Ágil mais adotado em todo o mundo. Relatórios como o State of Agile indicam que o Scrum (e suas variantes) detém mais de 80% do mercado. Isso se deve a sua (aparente) simplicidade mas aos resultados impressionantes de ganho de produtividade que as empresas que o adotam demonstram. O Scrum Guide é documento oficial que descreve o Scrum pode ser baixado sem custos. A seguir colocamos os seus principais componentes e discutimos os fatores que levam ao sucesso da adoção do Scrum em organizações de todos os portes.
Os pilares do Scrum são: Transparência, Inspeção e Adaptação. Transparência é a propriedade de um processo que seja visível aos que o observam. Um exemplo de falta de transparência são as caixas-pretas: sabe-se o que que entra e o que sai delas mas não o que se passa ali dentro. No Scrum é preciso poder explicar tudo o que se passa. Assim é possível aos outros membros da equipe Inspecionarem o trabalho e oferecerem sugestões para se Adaptar à realidade.
Por exemplo, se um programador está com dificuldade com uma rotina, na reunião standup diária ele deve expor a questão e pedir ajuda aos colegas. Um colega mais experiente se oferece para conversar sobre o problema.
Muitas vezes durante esta conversa a própria pessoa entende o que a está "travando" e encontra a solução. Se não, o seu par pode sugerir uma adaptação: que trabalhem juntos no desenvolvimento porque há alguns conceitos que o desenvolvedor não domina e o profissional mais experiente pode ajudar a descobrir o caminho.
Mas se a data de entrega estiver muito próxima, uma outra possível adaptação é passar o problema a um programador mais experiente para reduzir o risco de perder o prazo.
Importante: no Scrum todos são co-responsáveis, de forma que todos se interessam diariamente pelo que está pendente e devem voluntariamente ajudar a fechar a tarefa. A responsabilidade compartilhada por todo o projeto é uma das características mais interessantes e rigorosas do Scrum: não se pode culpar ninguém se houver uma perda de prazo pois todos são igualmente responsáveis. Quem não concordar com isso não deve participar de equipes Scrum.
Os cinco valores do scrum são: Coragem, Foco, Compromisso, Respeito e Mente Aberto.
A Coragem é importante para que as pessoas sejam transparentes e falem a verdade. Não se trata de ser mais ou menos "diplomático", sempre se pode dizer a verdade observando a forma de falar. Discutimos como dar más notícias no curso de Comunicação para Gestores de Projeto.
O Foco é essencial por que o tempo é curto para se fazer tudo o que foi combinado. Sem foco as pessoas entram em longas e improdutivas reuniões. O Scrum não condena as reuniões mas disciplina os membros da equipe a se prepararem para os tópicos a serem discutidos e a ter um facilitador que mova a pauta para frente quando o pessoal se perde em discussões improdutivas.
O Compromisso vem do entendimento tácito (implícito) entre os membros da equipe: se todos estão comprometidos com o resultado, todos devem se esforçar para atingir os resultados propostos. O compromisso é sobretudo com a equipe, pois se um membro da equipe não entregar vai sobrar mais para os demais uma vez que a responsabilidade é sempre compartilhada por todos.
O Respeito é importante em ambientes em que as pessoas possam ser honestas. Mesmo que você não concorde como um colega da sua equipe está conduzindo o trabalho, o respeito impõe que você aborde a questão de forma objetiva, sem querer impor a sua perspectiva, mesmo que você tenha muito mais experiência do que seu colega.
A Mente Aberta é a garantia de um diálogo franco. Se um colega mais experiente fizer comentários para melhorar o seu trabalho, você deve ser suficientemente maduro para entender que se trata de uma oportunidade de melhorar ou pelo menos ver o o mundo por outra perspectiva. Se você se fechar em suas idéias, seja por insegurança ou por desprezo às idéias alheias, você talvez não devesse estar nesta equipe.
O Scrum Sprint, Planejamento, Standup Diário, Revisão e Retrospectiva.
O Sprint é a alma do Scrum: trata-se de um período de tempo no qual a equipe está dedicada e entregar um "incremento do produto". Dura de uma semana até um mês e contempla todos os demais eventos dentro de si. A equipe Scrum deve ter de 6 a 9 pessoas para garantir que não haja problemas de comunicação, típicos em grupos grandes. Sprint é uma palavra em inglês que significa "corrida de curto alcance"e foi escolhido pelo senso de urgência e pressa que carrega em si, e que é o oposto de uma maratona que enfatiza a sua resistência...
O primeiro evento é a reunião de Planejamento (Scrum Planning) em que a equipe se reúne com o cliente para em até oito horas definir o que deve ser feito durante o Sprint que acaba de começar.
Durante Sprint, todos os dias a equipe se reúne rapidamente, em pé, na reunião "Standup Diário" (Daily Stand-up) para sincronizar suas expectativas e cada membro da equipe deve informar o que fez ontem, o que fará hoje e se há algum problema ou obstáculo a ser superado. Se a equipe tiver o seu tamanho máximo de nove membros, cada um terá pouco mais de um minuto para falar porque a reunião não pode passar de 15 minutos, não importa quantas pessoas existem na equipe. Isto é: "mais pessoas = cada um fala menos"porque a reunião não pode passar de 15 minutos.
O evento de Revisão (Scrum Review) é para que a equipe possa apresentar o produto ao cliente, usuários e demais interessados (como o patrocinador). Nela se discute o que foi feito e o que ficou pendente. Aproveita-se para verificar que as necessidades do cliente foram bem compreendidas e ara tirar dúvidas quanto os próximos passos. Esta reunião não deve durar mais do que quatro horas. Novamente, manter o foco é crítico.
Finalmente a reunião de Retrospectiva (Scrum Retrospective) é interna e só os membros da equipe podem participar porque nela se "lava roupa suja". Na verdade é uma reunião para discutir como a equipe está trabalhando, se há alguma discordância de opinião entre os membros que não possa ser resolvida diretamente entre eles, esta reunião é o lugar para se levantar a questão. O Scrum Master tem de saber conduzir para evitar atritos desnecessários. Esta reunião não deve durar mais do que três horas.
No Scrum só há três papéis: Scrum Master, Product Owner (Dono do Produto) e os Desenvolvedores do produto. Não há mais nenhum título (por exemplo, testador, tech lead, gerente de documentação) nem nenhuma hierarquia dentro da equipe.
O Scrum Master (SM) deve apoiar a equipe a praticar Scrum corretamente e para isso precisa entender bem as razões que fundamentam cada regra. Além disso, o Scrum Master deve apoiar controlando o tempo das reuniões e evitando conversas impróprias para cada tipo de reunião. Ele atua como um líder servidor, cujo sucesso depende do sucesso de todos.
O Product Owner (PO) é responsável pelo sucesso do produto, desde suas características até o calendário de entregas (Release Plan). Ele deve ser o elo entre os clientes/usúarios e a equipe Scrum ao levantar as necessidades e incluir num Product Backlog que será usado pela equipe para orientar sue trabalho. O PO deve saber traduzir entre leigos e técnicos então é melhor que ele tenha uma boa formação técnica.
Os artefactos são os dispositivos, as ferramentas usadas pelo Scrum.
O Backlog do Produto é uma lista de características que o produto deve ter devidamente classificadas por ordem de importância para que a equipe trabalhe no mais importante primeiro. Este backlog é de responsabilidade do Product Owner, ninguém mais pode interferir nele sem sua autorização.
O Backlog do Sprint é uma lista detalhada de tarefas a serem realizadas durante aquele Sprint. Ele vem do Backlog do Produto mais tem mais detalhes porque é feita e controlada pelos desenvolvedores.
A Definição de Feito (Definition of Done) é uma lista de tudo que deve ser feito para se considerar a tarefa como completada. Vai desde coletar dados para escrever os testes, escrever o teste, programar a solução, rodar os testes e colocar num ambiente comum (por exemplo, github) para distribuição.
Acessoriamente se fala no Painel do Scrum (Scrum Board) que tem 4 colunas: a fazer, fazendo, feito, recebido. Em geral se coloca cada tarefa em cartões que ficam colados ao painel e vão andando de uma coluna para outra na medida em que o trabalho prossegue.
Usa-se Scrum para situações de grande incerteza. Esta incerteza pode estar em duas áreas: no produto e na tecnologia para implementar este produto. Se o objetivo é bem determinado e as técnicas são bem conhecidas, como ocorre numa fábrica de software ou num projeto de engenharia civil para construir um prédio, deve ser usada a metodologia sequencial em que todos os passos sejam bem definidos desde o início. Neste tipo de projeto, os desvios do plano é que devem ser justificados. Normalmente considera-se uso de Scrum em duas situações:
1.Para projetos inovadores, de novos produtos cujas características ideais ainda devem ser descobertas, recomenda-se o uso do paradigma Ágil e dentre eles o Scrum, que é a materialização mais comum por sua grande flexibilidade (*).
2.Se o objetivo for bem determinado (por exemplo: desenvolver uma nova versão do sistema de Folha de Pagamento) mas a tecnologia for novidade (por exemplo: vamos portar a versão desktop para rodar como um app na nuvem), também há muita incerteza e se justifica adotar o Scrum. Em suma: Scrum é uma ferramenta para enfrentar grandes incertezas.
Se Scrum é tão bom, por que não se usa sempre? Se por um lado Scrum parece fácil de implementar e por isso é muito popular, por outro há várias armadilhas quando a equipe não está preparada para praticá-lo. Uma das primeiras coisas a fazer ao se escolher o Scrum é estudar para entender o espírito de cada regra. Assim se pode definir como ela deve ser implantada no seu caso específico. Este é um processo demorado que exige tempo e dedicação da equipe.
Por exemplo, quando não se entende para que serve a reunião de standup diária, ouve-se gente sugerindo que ela seja feita apenas duas ou três vezes por semana. Isso indica que quem sugeriu não entendeu que a reunião só funciona se for rápida (até 15 minutos de duração) e diária para que todos fiquem sempre sincronizados e nenhum tropeço/obstáculo passe despercebido. Aumentar o tempo entre estas reuniões não poupa tempo (afinal, a reunião é rápida) e aumenta a zona de "sombra" sobre o projeto, reduzindo a transparência, que é um dos pilares do Scrum.
(*) O Scrum não é uma metodologia mas um framework, que dita os principais objetivos mas deixa a implementação a cargo de cada situação. As metodologias (como a XP, extreme programming) ditam como as coisas devem ser feitas, mas um framework dita o que deve ser feito, não como fazer.
Nem todas as empresas e grupos de trabalho estão aptos a operar com Scrum de forma eficaz. Numa metodologia sequencial exige-se que cada participante seja capaz de entregar dentro de sua área de especialização.
No Scrum as equipes são multi-disciplinares i.e. elas são compostas com membros com várias habilidades (skills) de forma que todas as habilidades necessárias para se entregar o produto existem na equipe. Cada integrante da equipe deve poder atuar em mais de uma área para tornar a equipe mais resiliente (robusta a choques).
A outra exigência do Scrum é as equipes que sejam auto-administradas: os seus membros devem ser capazes de administrar o seu próprio trabalho, o que implica em maior maturidade profissional. Os integrantes decidem o que podem entregar a cada Sprint e como se organizarão para isso, dividindo as tarefas enter eles e assumido juntos a responsabilidade pela entrega acordada.
Scrum serve para mim? Devo adotá-lo? Você é que sabe. Em empresas ou equipes onde não há transparência (leia-se, confiança) e onde vale a cultura de culpar os outros, os projetos Scrum costumam não ter sucesso. Ou se cria um ambiente separado, com valores próprios ou a empresa não deve adotar Scrum até que esteja pronta para aceitar a transparência e aprenda a trabalhar em equipe sem buscar culpados.
Algumas empresas têm muita dificuldade em tirar poder dos gerentes para entregá-lo à equipe Scrum. Os gerentes gostam muito de seu poder para abrir mão dele, assim sem o apoio do alto escalão da empresa para se exigir uma nova postura, dificilmente os gerentes vão se dispor a passar seu poder. Neste caso, Scrum não será uma boa opção e deve ser evitado até que o "micro-management" deixe de existir.