30
jan
08

Scrum um caminho sem volta

Eu tenho falado bastante de Scrum nos últimos tempos com alguns amigos fora da empresa, além de viver um bocado disso todo dia na Globo.com, então resolvi criar esse post para dar uma introdução ao Scrum, para aqueles que ainda não ouviram falar.

Scrum é uma metodologia ágil para gerenciamento de projetos, criada por Ken Schwaber, Jeff Sutherland e Mike Beedle na década de 90, baseada no Pensamento Lean (Lean Thinking), que segue algumas regras bastante simples:

Existem três papeis dentro do Scrum:

Product Owner – Representa os clientes do projeto. Sua visão é de negócio e deve mostrar essa visão ao Time. Ele é responsável em manter o Product Backlog e priorizá-lo baseado no valor de negócio.

Time – O Time é multidisciplinar e deve ter o conhecimento necessário para trabalhar no projeto em questão. Ele deve entender a visão do Product Owner para desenvolver incrementos para o projeto a cada Sprint de acordo com as prioridades definidas pelo Product Owner.

Scrum Master – É o facilitador do Time. Sua responsabilidade é resolver qualquer impedimento que o Time esteja enfrentando. Ele protege o time e trabalha com o Product Owner para maximizar o retorno de investimento. Ele cuida para que os ideais do desenvolvimento ágil sejam respeitados por todos.

Artefatos do Scrum:

Product Backlog – É uma lista de todos os requisitos ordenados pelo valor de negócio. A prioridade de um ítem no backlog pode mudar, requisitos podem ser adicionados ou removidos.

Selected Product Backlog - É o resultado do Sprint Planning. Define o que o Time aceitou durante o planejamento. Não pode ser modificado durante todo o Sprint.

Sprint Backlog – É a lista tarefas que o time define para cada História. Será utilizada para que o Time saiba o que será feito durante cada Daily Meeting.

Impediment Backlog - É a lista com todos os problemas the atrapalham o time a progredir. Pode ser dividida em duas listas, Team Impediment, que são os impedimentos que podem ser resolvidos pelo próprio time e Organization Impediment, aonde o time não pode resolver.

Dia-a-dia do Scrum:

Inicialmente fixa-se o tempo de cada Sprint, que no meu caso é de 15 dias, esse período é chamado Sprint.
No início de cada Sprint, realizamos o Sprint Planning 1. Trata-se de uma reunião para definir quais dos ítens do Product Backlog deverão ser implementados. A partir dessa reunião teremos o Selected Product Backlog, nesse ponto faremos uma nova reunião somente o Time e o Scrum Master para que o Time defina em tarefas o que é necessário para fazer cada história e a partir disso teremos o Sprint Backlog.

Todos os dias do Sprint o Time faz uma reunião de 15 minutos em um horário pré estabelecido e no mesmo local (Daily Meeting), aonde cada membro do time responderá tres perguntas.

O que eu fiz ontem?
O que eu vou fazer hoje?
Quais impedimentos estou enfrentando?

Ao fim do Sprint realizamos o Review e a Retrospective.
No Review o time demonstra ao Product Owner cada ítem do backlog. Caso algum ítem precise de alguma modificação, uma nova história deverá ser adicionada ao Product Backlog, da mesma forma novas idéias.

Na Retrospectiva o time identifica o que foi bom no Sprint e o que pode ser melhorado.

scrum flow
About these ads

6 Responses to “Scrum um caminho sem volta”


  1. 4 de março de 2008 às 12:41

    Achei interessante o resumo, legal pq quando me perguntarem o que é Scrum vou passar esse link, sumariza de uma maneira bem esquematizada.

    []’s

    Cleydson

  2. 9 de agosto de 2009 às 21:56

    Olá, estou pesquisando sobre Scrum e fiquei apenas com uma dúvida…
    Como é resolvido o fato de futuramente o cliente pedir uma alteração ou ser necessária uma manutenção e eu estou com uma outra equipe que não trabalhou naquele projeto sendo que utilizando esta metodologia, nenhum artefato documentador é gerado? A nova equipe não perderá muito tempo tentando se localizar ou acabará refazendo o trabalho por não entender a lógica aplicada?

    Gostaria de ressaltar que acho esta pergunta extremamente relevante, pois trata de uma possibilidade que certamente vai ocorrer e eu acredito que existem técnicas para resolução. Qual sua consideração neste aspécto?

  3. 10 de agosto de 2009 às 10:55

    Erich, muito bacana essa sua dúvida.
    A respeito de documentação, nós sim, fazemos documentação, mas diferente de construir uma casa, a documentação é feita sob demanda, e não antes de iniciar qualquer linha de código. Nós aqui criamos inclusive manuais de uso, além de eventuais documentações.
    Além disso, uma ótima forma de documentação são os testes. Com eles além de serem criados “exemplos” de como aquele trecho de código deve se comportar, caso alguém faça alguma manutenção que quebre uma funcionalidade ao serem rodados os testes eles irão automaticamente alertar que algo deixou de se comportar como deveria. Isso na verdade dá muito mais segurança na manutenção do que pura documentação (que inclusive pode se tornar desatualizada facilmente).
    Essa sua dúvida é bem comum, principalmenete quando se compara desenvolvimento de software com construção de casas, leia esse post do Guilherme Chapiewski, que fala justamente dessa diferença de pensamento http://gc.blog.br/2008/07/20/cuidando-para-que-o-software-nao-apodreca/

  4. 25 de outubro de 2010 às 13:06

    Um resumo BEM resumido, mas ficou legal. Bom para despertar o interesse em scrum.

  5. 30 de março de 2012 às 20:29

    Excelente explicação, precisa e suscinta.


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

%d blogueiros gostam disto: