Scrum é um método de ágil para gerenciamento de projetos. Como a maioria dos métodos ágeis, ele foi baseado no manifesto ágil, de 2001. Segundo o próprio nome, um dos objetivos principais é trazer agilidade para o gerenciamento de projetos, aumentando o nível de resposta a mudanças.
Aplicado inicialmente no desenvolvimento de software, área onde tradicionalmente os projetos sofrem constantes mudanças de escopo, devido a mudanças no ambiente de negócios, inovações, legislação, concorrência e outros fatores, Scrum vem sendo aplicado em outras áreas, atingindo bons resultados, na maioria dos casos.
Ainda assim, implantar Scrum nem sempre é uma tarefa simples. Diversos fatores contribuem para simplificar ou, em alguns casos, complicar o processo. No mínimo, são pontos que precisam de atenção. Entre eles, vale destacar:
Síndrome da bala de prata. Não existe solução mágica! Saiba reconhecer se Scrum é o método mais adequado para o seu projeto ou organização, entendendo quais situações onde ele se aplica melhor e tem os maiores benefícios.
Projetos de inovação, com alto grau de mudanças, escopo não muito bem definidos ou que precisam de resultados no curto prazo são fortes candidatos.
No outro extremo, situações em que existem fortes requisitos contratuais, amarrando fortemente prazos e escopo – ou quando a organização já possui maturidade e experiência com projetos semelhantes (implantações de sistemas, por exemplo) – podem ser candidatos para uma abordagem mais “tradicional”.
Prazo de entrega e custo dos projetos. Uma das criticas comuns ao Scrum é que não existe uma data para o término do projeto. Embora seja sim possível ter estimativas com Scrum, aqui existe a necessidade de uma mudança de paradigma.
Toda estimativa, seja de prazo ou de custos, por mais realista e bem feita que seja, ainda é uma estimativa, possui uma margem de erro e fatores de riscos associados. Algumas abordagens mais tradicionais de gerenciamento de projetos tentem a se proteger das mudanças, criando processos, às vezes complicados ou mesmo burocráticos, para tornar alto o custo da mudança.
Métodos ágeis tratam a mudança como parte natural do processo, onde a mudança e o aprendizado da equipe e do cliente levam a um produto final melhor. A equipe se compromete com aquilo que vai realmente entregar e nada além. À medida que essas entregas são realizadas com sucesso, o cliente vê o resultado e adquire confiança de que a equipe pode não prometer com tudo o que ele deseja, mas entregará aquilo com o que se comprometer. É um começo, pois trabalhar com objetivos realistas é melhor do que a frustração de não alcançar esses objetivos. Ainda assim, pode não ser aplicável para todos os tipos de projetos.
Não despreze a engenharia de software. Outra critica comum ao Scrum, especialmente em desenvolvimento de software, é que com ele não existe documentação do projeto e / ou produto. Na verdade, Scrum é um método ágil de gerenciamento de projetos, que não restringe quaisquer outros tipos de atividades que podem e devem ser realizadas.
Qualquer que seja o método de gestão adotado, levantamento de requisitos, análise, projeto, codificação, testes e documentação devem estar sempre presentes, pois são disciplinas de engenharia de software, e embora não estejam formalmente previstas, a organização deve adotar seus próprios mecanismos para garantir a qualidade do produto.
A diferença fundamental é que todas essas disciplinas /atividades são realizadas em ciclos menores (sprints), e de forma incremental.
Gerentes funcionais. Outra questão que deve ser considerada é a posição do gerente funcional no Scrum. A equipe passa a ter autonomia para definir o que será e o que não será desenvolvido em cada sprint e o papel do gerente funcional pode mudar consideravelmente quando isso acontece. Na maioria dos casos, ele não define mais o cada funcionário fará e passa a atuar mais como facilitador, provendo os recursos necessários para que a equipe alcance os resultados do projeto, ajudando os scrum masters na realização de seu trabalho de remoção de impedimentos.
Nesse sentido, passa a ter um papel menos ligado as atividades diárias, e mais ligado ao desenvolvimento dos profissionais, aumentando a capacidade de resposta da própria equipe. Alguns gerentes podem resistir a esse tipo de mudança, encarando como perda de influência, e por isso essa questão precisa ser muito bem alinhada, com uma clara (re)definição de papéis.
Mantenha a disciplina sempre. O Scrum não possui muitos processos de controle e mesmo as reuniões previstas tem objetivos muito bem definidos. A reunião diária foi desenhada para ser a mais objetiva e rápida possível (15 minutos, no máximo).
Ainda assim, é importante garantir que os (poucos) processos sejam seguidos, para que os resultados sejam mantidos no longo prazo, para que impedimentos sejam levantados e removidos, para que exista o canal de comunicação constante com o cliente, e para que ocorra a evolução do próprio processo.
Após a fase inicial, existe uma tendência de “relaxar” em alguns processos, não realizar algumas reuniões, em especial quando o time trabalha muito próximo (times pequenos) e com grau de interação alto. Não caia nessa tentação, mantenha a disciplina.
Dicas para o processo de implantação
Além desses pontos, algumas dicas podem ajudar no processo de implantação:
Capacite a equipe, crie uma base de profissionais qualificados. Uma forma simples de reduzir a resistência é capacitar pessoas chave que possam disseminar as práticas e conduzir a fase inicial de implantação. Esses agentes de mudança serão os primeiros scrum masters.
Comece simples, crie um case, mostre resultados. Dependendo da cultura da organização, pode ser difícil tentar mudar completamente o processo de trabalho. Começar com um grupo menor, ou mesmo com um projeto mais simples, mostrando os resultados atingidos, poderá facilitar a aceitação da mudança. Não tente fazer tudo de uma vez.
Adicione complexidade aos poucos. Se o grau de resistência à mudança for alto, é possível iniciar com algumas reuniões e práticas e incluir novos processos quando os anteriores forem assimilados pela equipe. Por exemplo, pode-se iniciar com reuniões de planejamento no inicio do sprint, mais reuniões diárias e uma reunião simples ao final do sprint, combinando review e retrospective.
Quando essas práticas forem assimiladas, novos processos podem ser introduzidos. Um dashboard, ainda que simples, dá visibilidade ao processo, e é altamente recomendável desde o inicio.
Busque apoio externo (treinamento / consultoria), quando possível.
Defina claramente o cliente. Defina o Product Owner e tenha certeza que ele representa os principais stakeholders e tem autoridade para tomar decisões: um grande desafio em alguns projetos é definir o cliente. Diversos stakeholders podem ter expectativas em relação ao produto final, e nem sempre essas expectativas estão alinhadas. Sempre que possível, defina alguém (Product Owner) que represente os interesses dos diversos stakeholders, alinhando e centralizando as expectativas sobre o que deve ser efetivamente entregue. Tenha esse elemento sempre próximo ao time e certifique-se de que ele tenha autoridade suficiente para tomar decisões.
Comunicação, comunicação, comunicação. Fato: com scrum, o número de reuniões aumenta muito. Também aumenta o grau de interação entre os membros da equipe e entre cliente e equipe. Mas a equipe pode e deve realizar suas próprias reuniões de planejamento técnico e todas as outras que forem necessárias. Importante também manter os stakeholders alinhados com a evolução dos sprints ? o dashboard ajuda, mas as vezes não é suficiente. Use todos canais disponíveis para comunicar o projeto ? e-mails, blogs, newsletters etc.
Mensure a velocidade da equipe. A cada sprint, a evolução do trabalho da equipe deve ser registrada, para que se possa ter uma noção clara do ritmo das entregas – se o objetivo será alcançado, ou se existe algum problema impedindo que o objetivo seja atingido. Esse histórico irá gerar uma base sobre a qual a própria equipe poderá melhorar com tempo, identificando gargalos e tomando ações de melhoria.
No planejamento, seja realista. Depois de alguns sprints, a equipe começa a enxergar melhor a sua própria capacidade de resposta. É sempre importante ter os pés no chão durante o planejamento, assumindo entregas que sejam desafiadoras, mas que a equipe seja realmente capaz de atingir. Nada mais frustrante que chegar ao final de um ciclo e não alcançar o objetivo definido. [Webinsider]
……………………………………………………………
Mais na Wikipedia: Scrum (development) e também Agile Manifesto.
.
André Barros
<strong>André Barros</strong> (andre@predicta.com.br) é gerente de desenvolvimento da <strong><a href="http://www.predicta.com.br" rel="externo">Predicta</a></strong> e um dos autores do blog corporativo <strong><a href="http://blogs.predicta.com.br/namedida/index.php/author/andre/" rel="externo">NaMedida</a></strong>
10 respostas
Na verdade o Scrum é uma grande piada. Está mais para “processo para jardineiros” do que para desenvolvimento de sistemas em si. Se você considerar que os sistemas se parecem e muito com uma máquina – seja um avião, uma prensa ou algo do tipo – desenvolver de forma “ágil” e sem documentação é tão cômico quanto imaginar engenheiros da Boeing em pé todos os dias dizendo “hoje vou fazer as turbinas funcionarem” enquanto o outro diz “acabei o trem de pouso ontem, mas não tenho como testar sem a hidráulica pronta”. Tudo isso pra no final descobrir que o avião nem passa na porta do hangar !
Gilberto,
No Scrum, o cliente está sempre muito próximo ao time – quando não diretamente, é representado pelo Product Owner. Ele participa do planejamento dos sprints e tem uma certa autonomia para alterar os itens que serão desenvolvidos a cada iteração, com base no valor agregado e prioridades do negócio.
Com isso, ao escolher o metodo de gerenciamento para seu projeto, um dos fatores a se considerar são os requisitos contratuais e o modelo sob o qual escopo/prazo/custo serão regidos. Se você estiver em um projeto muito amarrado contratualmente, talvez uma metodologia mais tradicional seja mais indicada. Scrum tem como um de seus objetivos maximizar o valor agregado do projeto para o produto e ao negocio e possui algumas premissas para funcionar bem. Projetos com escopo não bem claro e/ou com alto grau de incerteza/variação podem ser melhores candidatos para sua aplicação, como projetos de inovação, e/ou envolvendo tecnologias de ponta, por exemplo. Modelos contratuais como time & materials ou valor-hora, da mesma forma, combinam melhor. Claro, o cliente precisa entender e aceitar as regras, em especial em projetos terceirizados.
Abraços,
André Barros
Walker,
Scrum possui um foco maior em gerenciamento de projetos e menos em engenharia de software. Não há, portanto, nenhum modelo previsto no método para documentação, use cases, ou mesmo etapas/práticas como levantamento de requisitos e testes, comuns em algumas metodologias de desenvolvimento – Essas são peculiaridades do universo de desenvolvimento de software e, embora Scrum seja largamente aplicado nessa area, foi concebido de maneira a ser aplicado para (virtualmente) qualquer tipo de projeto.
Com isso, fica seu criterio escolher os modelos e praticas que melhor se adequem a sua realidade.
Abraços,
André Barros
Handerson,
Concordo com você que é papel do PO definir o que deve ser implementado. Porém, cabe a equipe definir a quantidade de trabalho possivel dentro de cada Sprint – é nesse sentido que me refiro quando digo que cabe ao time definir o trabalho que será realizado – não ao o que, mas sim quanto. Isso difere, por exemplo, de projetos com metodologias mais tradicionais, onde as entregas/quantidade de trabalho são definidas no inicio do projeto, durante a fase de planejamento. Associado com prazos fixos, cabe a equipe apenas implementar o trabalho definido (as vezes, a custa de vários finais de semana).
Abraços,
André Barros
Uma correção: Scrum (como a maioria das metodologias e frameworks ágeis) antecede o Manifesto Ágil, portanto não é baseado nele.
Excelente artigo André, não conheço a fundo e nunca participei de nenhum projeto que tenha adotado o Scrum, mas fiquei curioso com uma coisa, como é tratado o desvio de escopo, prazos e principalmente custos em um projeto que flexibiliza o escopo e se tem liberdade para decidir qual artefato, passo ou fase deve ser executado? Pergunto isso por que atuo como consultor e sempre estou amarrado a prazos e custos bem definidos.
Abcs,
Gilberto.
Olá André,
Sou Analista de Sistemas e tenho focalizado mais o meu trabalho no levantamento de requisitos, especificação e documentação de softwares. Atualmente utilizo muito a UML e o RUP como metodologias de engenharia. Minha empresa está com sérias necessidades de agilidade nos processos de desenvolvimento de software e eu estou estudando alguns deles, dentre eles o Scrum.
Gostaria de saber se há para o Scrum, algum modelo de documentação de software, algum modelo de documento de especificação, use cases e etc…?
Abraços…
Walker Nolasco
Legal o artigo André, mas há duas passagens que gostaria de comentar:
A equipe passa a ter autonomia para definir o que será e o que não será desenvolvido em cada sprint e o papel do gerente funcional pode mudar consideravelmente quando isso acontece.
No Scrum, quem define o que será e o que não será desenvolvido em cada Sprint é o Product Owner, com base na prioridade dos items no Product Backlog. A equipe decide como a solução será desenvolvida, e pode inclusive sugerir alguns items ao Product Owner devido à detalhes técnicos, mas no final a decisão do que será desenvolvido pertence ao Product Owner.
Quanto ao número de reuniões, acho que concordamos que a medida importante não é o número mas o tempo total gasto com elas. Na minha experiência o tempo gasto em reuniões diminui com o uso de metodologias ágeis quando comparados com processos mais formais como RUP.
As reuniões diárias são super curtas e apenas o time de desenvolvimento tem voz ativa. Cada membro responde 3 perguntas simples: O que você fez ontem? O que pretende fazer hoje? Há algum impedimento para que você realize as suas atividades hoje?
Outro fator importante é a quebra do projeto em interações. Cada interação tem um sub-conjunto das funcionalidades que serão implementadas e as reuniões discutem apenas esses items. A diminuição do escopo faz com que as reuniões sejam mais curtas e mais produtivas.
Abraços,
Handerson Gomes
Olá Monthiel,
Eu particularmente nunca utilizei SCRUM, apenas li alguns artigos a respeito, porém utilizo as práticas do PMBOK… não vejo relação direta para gerar comparação entre XP e SCRUM… XP foca no processo de desenvolvimento e o SCRUM em gerenciamento de projetos.
As premissas da XP (eXtreme Programming) são:
Programação em Pares, User Stories, rápido ciclo de entrega, participação efetiva do cliente entre outros… voltado ao desenvolvimento de software.
Já o SCRUM, por ter foco em projetos, pode ser utilizado para planejar a festa de aniversário do seu vizinho… Claro q hoje é muito empregado para desenvolvimento de software, aliás, algumas vezes é feito um mix com XP, pois qualquer metodologia é melhor aplicada quando adaptada a realidade da equipe e da empresa.
Abraços.
Olá,
Na empresa em que eu trabalhava usava o método XP (eXtreme Programming), e, com o tempo, decidiram mudar para Scrumm. Foi uma série de reuniões para tratar dos assuntos que envolviam essa mudança, inclusive o que afetaria no dia-a-dia já que todos os produtos e projetos eram usados paralelamente pelos clientes…. Enfim, durante as reuniões achei interessante o assunto.. mas infelizmente saí da empresa antes da mudança começar a acontecer.
Depois disso deixei de pesquisar sobre isso, mas vou dar uma olhada na internet sobre..
Ótimo artigo,
Monthiel