quinta-feira, 4 de outubro de 2012

Scrum

Aqui estamos novamente com um dos ótimos posts do meu amigo Rondinelli, escritor, programador e dono dos sites Datrix e Telfem. Espero que gostem do assunto de hoje.

Scrum

Um dia você chega ao trabalho e não tem a menor noção de o que vai fazer, seu chefe não sabe o que está sendo desenvolvido, então já ali na quarta xícara de café seu chefe te dá aquela olhada direta e penetrante e pergunta se você está ocupado. Claro que você está ocupado, isso é óbvio senão não estaria no trabalho e sim em casa deitado em sua cama confortável dormindo para aproveitar o restinho da manhã gostosa, mas não você está ali no local de trabalho e aí tu responde que está ocupado, apesar de não saber bem com o quê. Não é nada fácil trabalhar assim e quando chega o final de uma semana está todo mundo perdido e sem saber bem como que tudo começou a acontecer nem pra onde está indo.

Não é legal ficar o funcionário sem saber o que fazer e o chefe perguntando a cada 10 minutos o que você está fazendo, então num momento desses é interessante haver algum tipo de auxílio. Particularmente eu gosto de ter uma lista de tarefas priorizadas e organizadas assim fica mais fácil fazer um gerenciamento do tempo. Acho muito, muito chato mesmo ter alguém me importunando com perguntas ainda mais se for pra perguntar o que estou fazendo, pois há alguns momentos em que estamos fazendo tantas coisas ao mesmo tempo, algo atômico que precisa ser feito em conjunto senão não daria certo e numa hora dessas é bom ter algum lugar onde o seu chefe consultar e se sentir seguro de que o dinheiro que ele paga pelo seu salário está em uso e não desperdiçado no tempo ocioso do cara que não recebe pra ficar assistindo vídeos, atualizando blog e morrendo de rir de postagens do Facebook e Twitter.

Como resolver isso? Com uma pitada de Scrum!


O que é Scrum

É um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software. Apesar de não descrever o que fazer em cada situação ele permite o acompanhamento de trabalhos complexos quando não é possível determinar todos os problemas serão solucionados com a solução de software prevista, ou seja, as coisas nem sempre continuarão no mesmo fluxo pois cada etapa de desenvolvimento pode ou não afetar as próximas etapas até que o produto final seja entregue.


Jeff Sutherland, John Sumniotales e Jeff Mackenna conceberam o Scrum em 1993, assimilando os modelos de gerenciamento de Takeuchi e Nonaka, então em 1995, Ken Schwaber formalizou as definições. Embora tenha sua função original seja gerenciar o desenvolvimento de software, ele pode ser utilizado em outros contextos, como a manutenção de software ou mesmo no acompanhamento de executar um trabalho complexo onde haja envolvimento de muitas pessoas.
No decorrer do processo existem três papeis básicos a serem interpretados pelos envolvidos, são eles o Scrum Master (que substitui um gerente de projeto), Product Owner (o dono do produto) e o Team (equipe multifuncional que desenvolve o projeto).

Sprints

O período de tempo que geralmente dura entre uma semana e um mês é uma constante no processo, dentro dessa “unidade de tempo” onde um conjunto de tarefas deverá ser executado, incrementando o produto de maneira que algo possa ser entregue, ou seja, ser testado e utilizado. Um fator importante no processo é entender que nem sempre a meta será cumprida e algumas tarefas poderão ser realocadas em outro Sprint, além disso o cliente pode mudar de ideia ou algum outro fator externo pode modificar todo o conceito planejado.

Por exemplo, um projeto é iniciado para fazer uso de uma determinada tecnologia de rede social como interface de usuário, contudo, a empresa que mantém o funcionamento da mesma resolve modificar toda a API de comunicação ou restringir a interface de uma maneira que impeça a aplicação do mesmo como esperado. Isso deverá ser apresentado em uma reunião com o Product Owner e algumas tarefas diretamente ligadas ao uso da interface deverão ser canceladas e revistas.

Fluxo do Sprint

  1. Encontro de Sprint (Planning Meeting)
  2. Priorização de tarefas do backlog
  3. Seleção de tarefas que a equipe seleciona que podem ser executadas no Sprint
  4. Direcionamento de tarefas para cada integrante do Team
  5. Pequenos encontros diários da equipe (Dayling Meeting)
  6. Deve ser sempre no mesmo lugar e horário, preferencialmente de pé, assim as pessoas falam menos.
  7. Reunião geralmente pela manhã onde o Team se reúne para um de cada vez falar pelo menos três coisas: O que fez. O que vai fazer. O que o atrapalha.
  8. Se for identificado algum problema durante o encontro o mesmo deverá ser resolvido durante o dia e não durante a reunião, pois a mesma deve ser rápida, menos de 15 minutos.
  9. Reunião Retrospectiva (Retrospective)
  10. Reunião com todos os interessados.
  11. Apresentação informal e rápida como resultado natural.
  12. Comparação do resultado ocorrido com os objetivos iniciais do Sprint.

Backlog

O product backlog é o conjunto de funcionalidades desejadas para o produto, geralmente vista sob uma visão generalizada sem detalhes e com o tempo é divida em tarefas executáveis, tais como tarefas diretas, casos e de uso e histórias. Essa lista é priorizada pelo P.O. Essas funcionalidades devem agregar algum valor de negócio ao produto, então em cada apresentação de Sprint o cliente trará novos requisitos que devem ser analisados. Dessa maneira o produto é refatorado durante sua concepção.

Scrum Master

Facilitador do processo
Proteger a equipe de interferências externas que impeçam o funcionamento do Scrum
Evitar que a equipe fique com otimismo exagerado, sempre alertando para possíveis mudanças
Resolver os problemas identificados nas Reuniões diárias
Manter o backlog do Sprint
Manter um gráfico Top/Dowm onde deve ser comparado o total de pontos das tarefas do Sprint com o tempo de horas restante

Product Owner

Reunir-se com os Stakeholders (Clientes, fornecedores e demais interessados no produto)
Conhecer o negócio e os requisitos sempre atualizados

Team

Equipe multifuncional com programadores, analistas e testadores de sistema
Deve ser auto-gerenciável, ou seja, não deve ser necessário o controle de execução de tarefas por um líder

Scrum Final

Embora oficialmente um produto tenha uma conclusão no desenvolvimento, na prática um software é um organismo vivo que deve ser mantido saudável enquanto estiver em execução no cliente, o que é possível de ocorrer por muitos anos se conseguir um bom contrato de manutenção de software. Ainda assim existe um momento em que o produto será declarado pronto, pois todas as tarefas do Backlog foram executadas, nessa etapa é feito um último Sprint para finalizar o produto com o objetivo de preparar uma versão do produto e eliminar os erros.

Scrum Distribuído

A metodologia de Scrum é muito boa para equipes reunidas, entretanto não é eficiente para uso com equipes onde os integrantes estejam fisicamente distantes, pois requer o envolvimento próximo do Team. Mesmo num ambiente em que a equipe esteja próxima as barreiras culturais, o modo de trabalho e os problemas de comunicação podem interferir no bom andamento do processo. Ainda assim é possível utilizar Scrum em equipes distribuídas, contudo deverão ser criadas sub-equipes e cada uma com seu próprio Sprint, então os mesmos poderão reunir-se periodicamente para integrar-se.

Scrum Solo

Ah, então você tem um projeto que vai executar sozinho e quer uma metodologia para se organizar, logo o Scrum também ajuda nisso. No lugar das reuniões faça uma reflexão com o problema proposto e faça seu backlog e seja rigoroso consigo mesmo para mantê-lo atualizado e organizado. Seguir uma metodologia sozinho é mais difícil que em grupo, porque exige muito mais persistência e resistência a tentação de deixar a documentação dos artefatos de lado e seguir apenas a memória e as ideias que fluem.

Um pouco de humor

Lembrando de uma história que ouvi na faculdade sobre a faquinha de presépio em reuniões, achei interessante colocar esse conceito avançado de antropologia no universo Scrum. Pra quem não conhece a história da vaquinha, apenas imagine a coisa mais importante do Universo acontecendo, os anjos cantando, os reis magos trazendo presentes e a vaquinha ali totalmente inútil.

Pense no Scrum da seguinte maneira, o Scrum Master é o dragão Teamat que protege o Team do Vingador que tenta impedir de cumprir o Backlog, o Product Owner é o Mestre dos Magos com seu conhecimento todo e incapaz de traduzir na maioria da vezes em ação a sua sabedoria e o Team são os garotos perdidos da Caverna do Dragão tentando entender as tarefas e o cliente é o unicórnio Uni o tempo todo berrando, dificultando tudo e bagunçando sempre as tarefas no Backlog.

Lembre-se que nenhuma metodologia é capaz de salvar você de sua própria incompetência e falta de conhecimento, então estude muito e seja exigente consigo mesmo e com sua equipe.

Referências:

Agille Alliance
Scrum Alliance
Mountain Goat Software
Site do Ken Schwaber
Site da Agilcoop