Perguntas e Respostas sobre Scrum

Perguntas e Respostas sobre Scrum

Olá Gerentes de Projeto,

Tenho tido o imenso prazer de lecionar em treinamentos de Scrum e participar de discussões calorosas sobre implantação , adaptações e problemas contextuais e organizacionais. Dessas aulas e discussões tem surgido uma série de perguntas que irei compartilhar abaixo.

A lista será atualizada periodicamente, a última atualização foi em 29/09/2014.

  1. Scrum funciona somente para projetos pequenos?
    O Scrum funciona para projetos de qualquer porte, desde que se dividam as entregas em sprints. Em projetos com sprints paralelos é importante aplicar o Scrum of Scrums.
  2. O Scrum é aplicável somente ao gerenciamento de software?
    Não, como qualquer outra metodologia é aplicável a outros tipos de projetos.
  3. Como gerenciar um projeto com o escopo aberto?
    O escopo não é aberto, é alterável. Os métodos de gerenciamento de projetos permitem alterações de escopo, desde que haja análise de impacto, replanejamento e aceite do cliente. Todo projeto está sujeito a alterações de escopo, isto depende tanto de fatores técnicos quanto externos ao projeto, como: mudanças de regras de negócio, leis ou a própria opinião do cliente. No caso do Scrum, as alterações são feitas no planejamento do product backlog e refletidas nos sprints, a análise de impacto é realizada nas duas etapas e o replanejamento é visualizado através das “time boxes”.
  4. Um método que permite alterações de escopo não tende a retardar indefinidamente o projeto? É questão de realismo: É sabido que os clientes normalmente refinam seus requisitos ao longo do tempo, por isso é melhor ter um prazo alterável que um prazo irreal. Independente do método, não existe planejamento que não seja alterado ao longo da execução.
  5. O Scrum permite definir uma data final para o projeto?
    Ele permite que se tenha uma visão de data final através do “burndown graph”, o prazo vai sendo modificado ao longo da execução do projeto (diariamente) e cabe ao Scrum Master garantir o cumprimento do prazo de cada sprint. Uma estratégia para alcançar um prazo específico é o dimensionamento dos sprints (mais curtos, mais longos, com maior ou menor quantidade de entregas ou de sprints).
  6. Como gerenciar o prazo no Scrum?
    A partir de uma lista de requisitos priorizados, geram-se sprints, que são blocos de tempo (time boxes) que os implementam. Desse modo pode-se planejar e acompanhar o prazo do projeto. Ex: Se existem 10 sprints de 1 mês, o projeto levará em torno de 10 meses para ser completado. Se houver alterações de requisitos que impliquem em aumento ou redução dos sprints basta projetar o impacto até o final do projeto.
  7. Como é o processo de atualização do taskboard/kanban/quadro scrum com post-its?
    Veja uma explicação detalhada clicando aqui.
  8. Então, como estimar o custo de um projeto Scrum?
    O custo de um projeto geralmente é uma composição de horas e aquisições. Estimam-se os custos das aquisições através de orçamentos, estima-se o total de horas e multiplica-se por um fator de custo da empresa.No caso da estimativa de horas, existem métodos bastante utilizados no mercado, como: Opinião de especialistas, Pert, Estimativa análoga, paramétrica e planning poker. Além dos métodos especificos para a área de software como: linhas de código, pontos de função e pontos por casos de uso.
  9. Que forma usar para fazer um contrato no Scrum?
    As mesmas formas tradicionais são aplicáveis, com suas vantagens e desvantagens normais, são elas: Preço fixo, tempo e material e reembolso de custo.
  10. É obrigatório ter uma equipe máxima de 12 pessoas?
    É o que a teoria prega, pois facilita a integração da equipe e permite a agilidade. Também pela premissa de que um projeto grande demais deve ser quebrado em projetos menores, menos complexos e portanto mais fáceis de gerenciar. Se ainda assim a equipe for maior, é recomendável que se aplique o Scrum of Scrums.
  11. É obrigatório que as pessoas estejam no mesmo local físico?
    Segundo o Scrum, sim. Se for impossível, é importante que ao menos na daily meeting estejam todos juntos.
  12. Como lidar com terceirizados em uma equipe scrum, dado o problema de autoridade e diferenças de processo?
    Os terceirizados precisam se adequar ao modelo da organização em relação a processos e permitir que o Scrum Master coordene o processo de trabalho, já que a equipe é auto-gerenciável.
  13. Se a equipe é auto-gerenciável, qual a importância do Scrum Master?
    O Scrum Master faz o controle do escopo, da alocação da equipe, puxa o ritmo de trabalho e arbitra conflitos, se necessário. Ele também a porta de comunicação com Product Owner e alta gerência.
  14. Como são distribuídas as atividades entre os membros da equipe?
    No Scrum, cada pessoa pega a atividade que desejar fazer, conforme a “prioridade de negócio” definida para cada estória.
  15. É realmente viável que a equipe escolha suas atribuições, dadas as diferenças de skill, ou é apenas idealismo?
    É muito viável e o trabalho flui melhor, as pessoas se sentem importantes, pois podem tomar decisões e acabam ficando mais motivadas e comprometidas.Por exemplo: Se uma equipe de um projeto multidisciplinar for composta por 3 pessoas: dois físicos e um psicólogo. Se psicólogo pegar uma atividade de Física Quântica para fazer e não estiver conseguindo terminar. Antes de um dos físicos pegar uma nova tarefa, terá que ajudar o psicólogo a terminar a sua, de modo que o resultado da equipe seja alcançado.

    “Sempre terminar uma estória (user story) antes de pegar a próxima”.

  16. O que é o Scrum of Scrums?
    Em linhas gerais, é uma organização que permite que um grande projeto seja executado utilizando o Scrum. O projeto é dividido em equipes e a junção de todas elas é o Scrum of Scrums.
  17. O que fazer se as atividades da sprint não terminarem dentro do mês?
    Primeiramente, a Sprint é um período que pode ir de 3 a 30 dias, logo não é “um mês”.Segundo, a sprint segue o conceito de TIMEBOX, o tempo é fixo, variam as entregas. Ou seja, se o tempo acabar, vale o que foi terminado até o “cronometro zerar”.
  18. O que fazer com as estórias (User stories) que não couberam na Sprint?
    Voltam para o product backlog para serem repriorizadas.
  19. As alterações de escopo obrigatoriamente devem acontecer no planejamento da sprint?
    Não, as alterações podem vir a qualquer momento, mas são replanejadas no product backlog e não no sprint backlog. Toda nova estória (ou alteração de uma existente) deve ser priorizadas pelo Product Owner, nada garante que a alteração fará parte especificamente da próxima Sprint.Recomendação: Deve-se atualizar o product backlog sempre para manter a rastreabilidade.
  20. Daily meeting: Qual o impacto de não se fazer daily meetings todos os dias? Qual o impacto das pessoas estarem em locais e horários diferentes? existe alternativa?
    A daily meeting deve ser realizada diariamente. Os possíveis impactos são: perda do controle do trabalho e redução do  comprometimento da equipe, pois não estarão explicando o que estão fazendo na daily meeting. A alternativa para problemas de horários e locais é a participação via teleconferência.
  21. Daily meeting: Quem pode levantar um impedimento? o scrum master? qualquer pessoa? Qualquer pessoa envolvida no projeto, a qualquer momento.
  22. Daily meeting: O que fazer se não for possível resolver um impedimento? Pausa a sprint até que seja resolvido?
    Quando não for possível resolver um impedimento, deve-se partir para a próxima user story. Se impactar toda a sprint, o que é bem improvável, toda a equipe deve se mobilizar para resolvê-lo.
  23. Retrospective: Quem faz e como funciona (na prática) a retrospective meeting?
    É o Scrum Master com a equipe inteira. Faz-se um balaço dos prós e contras, o que for bom deve ser mantido (e ampliado) e o que for ruim, deve-se procurar as causas e evitar que aconteça no futuro.
  24. User stories: Como saber quantas horas vale cada user story, se o esforço depende da senioridade dos recursos que vou usar?
    As user stories devem ser estimadas em story points através do planning poker (ou outra técnica), que mede a proporcionalidade entre os requisitos.
    Ao planejar cada sprint, a equipe pode oferecer suas estimativas em horas, cada um na sua senioridade.
  25. User stories: Como comparar diferentes projetos se as user stories usam proporcionalidade entre requisitos?
    Não se deve comparar projetos diretamente através das user stories, pode-se sim comparar pontos positivos, negativos e lições aprendidas.
  26. Quais as principais diferenças entre o SCRUM e o PMBOK?
    As diferenças são muitas! O SCRUM utiliza um conjunto de princípios que o leva a controlar escopo, prazo e qualidade de forma “ágil”. Para que isso aconteça ele estabelece regras, cerimônias, artefatos e papéis, de modo que, sendo seguidos, levam as equipes a um melhor desempenho. O conceito de prazo é baseado em timeboxes, a comunicação é constante e a motivação da equipe é incentivada e monitorada.O PMBOK tem uma proposta diferente, pois busca coletar boas práticas e associá-las a grupos de processo e áreas de conhecimento. É um arcabouço vasto de informações, técnicas e processos, que pode ser aplicado a projetos de qualquer tamanho, tipo e em qualquer cenário. Requer um monitoramento constante de vários parâmetros e não define “cerimônias”.
  27. Daria para usar Scrum e PMBOK ao mesmo tempo?
    Pela perpectiva do PMBOK seria possível, desde que fiquem claros alguns pontos:
    – A documentação como Termo de Abertura não será utilizada;
    – Um documento substituto a Declaração de Escopo será o Product Backlog;
    – O gerenciamento do tempo será feito em timeboxes e não com técnicas de PERT/CPM, utilizará o Sprint Backlog e não um cronograma;
    – Os custos poderão ser gerenciados apenas pelas horas de alocação da equipe, já que não se coletam horas gastas;
    – etc.Já pelo lado do Scrum, não haveria o menor sentido adotar dentro de uma sprint documentações do PMBOK, pois iria de encontro aos princípios da agilidade. Uma solução intermediária seria o PO “gerenciar o projeto” enquanto o SM gerenciaria o andamento de acordo com o Scrum.
  28. Qual a diferença entre o Scrum Master e o Gerente de Projetos?
    As perspectivas são um pouco diferentes, no SCRUM as atividades de gerenciamento são distribuídas entre PO, SM e ST (scrum team). No Scrum não existem certos controles como custos, riscos e nem definições sobre práticas, ex:
    – O SM tem foco maior no gerenciamento da execução
    – O PO gerencia escopo
    – A qualidade é garantida e controlada por todos, em especial o PO
    – Custos não são gerenciados Já o Gerente de Projetos precisa planejar, gerenciar, monitorar e controlar as 10 disciplinas ao longo de todo o ciclo de vida do projeto.
  29. Uma equipe Scrum pode trabalhar em múltiplos projetos?
    Não!!! A grande razão da efetividade do Scrum é justamente o FOCO. Os requisitos (itens do product backlog) são priorizados conforme o “valor de negócio” e devem ser implementados (desenvolvidos) seguindo exatamente essa prioridade. A equipe deve trabalhar focada e unida para finalizar o trabalho da Sprint. Se tirarmos o foco da equipe como poderemos exigir que dê resultado?
  30. Devo medir as horas trabalhadas da equipe?
    Não precisa medir, basta calcular! Se todos trabalharem focados em um projeto apenas, basta multiplicar o número de pessoas pela quantidade total de horas da Sprint. Exemplo: Se 5 pessoas trabalham numa Sprint de 5 dias, temos: 5 pessoas x 5 dias x 8 horas diárias = 200 horas no total.
  31. Como saber a produtividade da equipe?
    Todo projeto deve ter sprints fixas, isto é, com a mesma quantidade de pessoas e de dias. Cada Sprint, no entanto, realiza/constrói uma quantidade diferente de story points (SP). A produtividade é medida por quantos SPs a equipe faz por sprint, é o que chamamos de “velocidade média”.
  32. Devo controlar a produtividade individual no Scrum?
    Sabemos que ninguém trabalha 8 horas por dia, há sempre alguma distração. Por que medir as horas se sabemos que as pessoas vão mentir no reporte? Ora, ninguém vai ter coragem de dizer que na segunda-feira trabalhou (efetivamente) apenas 2 horas, as vezes até menos. Por isso, o Scrum não se atém a essas medições. Outro ponto, toda filosofia do Scrum é baseada no trabalho em equipe, em estruturar as prioridades, o processo de trabalho, retirar impedimentos e permitir que as pessoas se autogerenciem. Se são times dinâmicos, autogerenciáveis e ágeis, por que cometeríamos o contrasenso de medir suas horas?

Enviem novas perguntas através dos comentários abaixo! Links com mais perguntas e respostas:

Veja também alguns cases de implantação do Scrum na seção Downloads. Eli Rodrigues

Publicado por: Eli Rodrigues

There are 12 comments for this article
  1. peixotmarc at 19:07

    Estamos muito orgulhosos pela citação do nosso post sobre Gestão com Scrum do Blog Ágil Pioneiro. (www.agilpioneiro.wordpress.com)

    • EliRodrigues at 19:20

      Pela qualidade com que escreve, pode ter certeza que citarei várias vezes. Abs, Eli

      • peixotmarc at 20:02

        E sempre que precisares de ajuda, pode ‘prender o grito’, estamos a disposição.

  2. Renato Torres at 20:50

    Muito bom o texto, Eli!

    Mas me responde uma dúvida, qual a diferença do Scrum Master para o Gerente de Projeto?

    • EliRodrigues at 09:51

      Oi Renato,
      Finalmente consegui responder! E tem um link bem bacana que acrescentei sobre as diferenças entre o SM e o GP. abs

  3. peixotmarc at 09:58

    A gestão segundo o PMI é feita apenas por uma figura, o Gerente de Projeto. Já no Scrum, a gestão é feita por 3 papeis: Product Owner (Macro Gestão), Scrum Master (Gestão de Processos) e o próprio time (Micro Gestão).

  4. Rafael Rufino at 19:18

    Senhores, estou fazendo meu projeto final. meu tema é utilização de métodos ágeis para desenvolvimento scrum, visando os contras e positivos do uso do scrum. Meu projeto nao vija um marketing da metodologia muito menos uma crítica, mas ambos os tópicos.
    Preciso de ajuda pra eu fazer uma entrevista via email ou skype. Serão alguma perguntas sobre as dificuldades que a empresa passou durante a implatação do scrum, e se após a implantação o resultado foi como esperado ou não.
    Algum de vocês são scrum master ou trabalha em alguma instituição que poderia me ajudar?

    Desde já muito grato.

  5. Pingback: Gerenciamento de Riscos – EAR para projetos de software « Gestão de Projetos na prática
  6. Pingback: Links da semana #3 Tudo sobre GP | Projetizando
  7. D Günther Böttger at 18:10

    Eli, boa tarde.

    Entendo e conheço algumas ferramentas para o controle do horas nos métodos de gerenciamento em cascata, porém, em Scrum, o que pode ser indicado para o controle de horas de cada membro do time? Principalmente no caso do time tocar diversos projetos (sprints) simultaneamente.

    Obrigado pela resposta e por todo conteúdo disponibilizado.

    Abraço!